I already have a CI build running on my Tfs2010 instance, but I'd like to get a Gated checkin build running as well. There are subtle differences between the ways I would like these two builds would run, however. Specifically, I'd like the Gated checkin to not produce bug workitems on failure, not associate changesets and workitems on build, not move builds to the drop, and not maintain previous builds. Since builds initiated by Gated checkins are uncommitted changes, these steps seem unnecessary to me, but I would definitely like the CI build to perform these functions.
Unfortunately, there's this NO_CI thing that appears on my changesets after they're committed by the Gated Checkin build, and the CI build is never triggered. I found this thread that seemed to indicate that my DefaultTemplate.xaml should have a "Get Activity" NO_CIOption parameter in there somewhere; however nothing in the configuration file seems to indicate anything of the sort. Neither string is present, and I can't find any reference documentation in the msdn library.
In fact, in the msdn library, there's a page that seems to link to the page I want, however where the link would actually be there's a misplaced, duplicate link to "Control where the build system places your binaries." You can see the identical link directly below it.
Anyhow: how is the NO_CIOption parameter used in the build template files? Where is it placed? Has no anyone else ever wanted to do this before?
Side note: is it bad practice to cross-post between SO and the MSDN forums?
To follow up on this, after looking through the Xaml and using reflector on the Build binaries, I found the NoCIOption property on the SyncWorkspace action. Setting this to false seems to have allowed CI builds to trigger after gated checkins, as well as removing the somewhat unsightly NO_CI checkin comment appendix.
See http://donovanbrown.com/post/How-to-have-CI-builds-run-after-a-Gated-Build for information on how to do this.
Related
We are developing a project and we use VS 2013 and TFS 2013 Express for version control. In team project source control settings I created two check-in policy. First is changeset comment policy that works and builds check in policy that requires last build was successful. But I think builds check-in policy that does not work because any file that prevents successful build (for example there is a syntax error in this file and project cannot be built) can be checked in. I can check in all broken file(s) although builds check in policy is added. So I need your help, I don't want broken code in tfs.
You need to set up a gated check-in build. Gated check-ins are a form of continuous integration that forces a build to run and validate that the code builds successfully (as well as enforcing that unit tests pass and code analysis is successful, depending on how you configure it). Only if the gated check-in is successful, is the code actually checked in.
However, checking in broken code is a cultural issue. Developers should be compiling and testing their code on their own without the need for an automated process to slap them on the wrist first. Gated check-ins will help you solve the cultural issue by making life inconvenient for people who routinely check in broken code.
On a large application, you'll actually want to have multiple gated check-in builds -- one for each logical subsection of the application. The gated check-ins need to run as fast as possible, because every second that someone else is waiting for a gated checkin to complete so they can get the latest code is wasted time. The longer they have to wait, the more likely it is that they'll go get coffee, use the bathroom, or otherwise take a break, which can be massively counterproductive if they were in a productive, focused headspace when they were more or less forced by the tooling to stop focusing.
Is there anyway to setup some 'workflow' in which when a developer do a checkin, there's a requirement to code review that may go back to developer (if there's something to change) or get accepted and go with the checkin. That would be a development branch.
No checkin should be accepted if (Code Review wasn't accepted. It does not build, It has not passed unit tests).
How and where to configure this things?
For code review check-in policy you can use "Colin's ALM Checkin Policies" -
http://visualstudiogallery.msdn.microsoft.com/c476b708-77a8-4065-b9d0-919ab688f078
This should satisfy what you are looking for but if not then you can write a custom check-in policy. Check below URL:
http://blogs.msdn.com/b/jimlamb/archive/2010/03/31/how-to-implement-package-and-deploy-custom-check-in-policy-for-tfs-2010.aspx
For your other part of the question you an use Gated check-in to make sure the code compiles and all unit tests pass before code gets checked-in. See below images on how to set that up. You can go to this URL to understand how it works: http://msdn.microsoft.com/en-us/library/dd787631.aspx
By default there is none. You can build a custom checkin policy to require this
We recently adopted the concept of feature branches in one of our bigger projects, to segregate work on different aspects of the product that can be completed independently of each other.
For each so-called feature, we are creating the following:
a branch from 'main', aptly named after what the feature is supposed to be
a new team in the project portal, containing the people that will work on the feature
a build definition to validate check-ins against the source on the branch
The main point I would like to see discussed here is about the build definition. Currently, each one of them is set to gated checkins.
The question then, is: what is the best practice on associating work items to a build?
In our case, these feature branches are supposed to be disposable: we would like to be able to delete these builds/branches/teams later on when the feature is complete, but still be able to track them throughout the product lifecycle.
If I associate work items with these temporary builds, I'll lose tracking capability later on when the feature implementation ends. At the same time, I just found out that gated checkins always associate work items, regardless of what is configured in the build definition.
Would it be feasible to disable work item integration with the feature branches (in this case also converting them from gated to continuous integration) and enable it in the main build, so that these features can be tracked in the main product line? Or maybe this should be only enabled for Release build definitions, so that we can find out what was integrated on a certain release? For those of you who follow the sprint/feature concept, how do you handle this situation? Do you also have a build for each branch?
Update:
I just found something similar (but not exactly like what I wanted) in this question. The answer there lead me to a plugin that automatically associates work items on merge checkins. This should offer great traceability on it's own, so I think I'll give it a shot.
Would still like to hear what your thoughts are in regards to the builds in this scenario.
You're approaching this wrong IMO. You shouldn't be worrying about associating Builds and WI's, but rather associating Changesets and WI's. When your developers check-in changes in the feature branch you should ensure that they are linking them to the relevant WI(s). You can even enforce this via a Check-In Policy.
Now if you ever want to inspect that feature in the future to see all the changes associated with it, you can by inspecting the Feature WI, and looking at all linked Changesets. Even if you delete the branch all the Changesets are still available.
I am setting up a CruiseControl.Net server. So far, it only builds a project (.Net website), and I kind-of know how to set up unit testing, code coverage, etc in the future.
What I will need to have soon is this:
The developers commit changes to SVN continually, thus CCNet builds often.
CCNet will publish the latest version to the development server, as soon as a commit is validated (with unit tests etc).
The project manager validates a specific version, in order to publish it to the pre-production server, and create a SVN tag from this revision.
The last point is where my problem lies: how exactly can I set up things so the project manager can, for instance, browse to the CCNet web dashboard, select a previous specific build, and says "this is the build I want to publish" ?
I believe that my thinking is flawed somewhere, but I can't put my finger on it. Maybe CCNet is not the right place to do these manipulations ?
In my mind, I can create a SVN tag using CCNet, and mostly work from the trunk, but maybe I can't ? Maybe it's the other way around, and I should add a CCNet project every time a tag is created under SVN ?
The final goal is that I want to automate the publication process: zip creation (for archiving), web.config modification (using Nant for instance), and website publication (using FTP).
In all these steps, I want to limit the manual intervention to the maximum. If I can avoid to add a new project to CCNet every time a tag or branch is created in SVN, that would be awesome.
Thanks for your help, and sorry if it's not very easy to read, but it's not very clear in my head either...
Since you can create any task, you should be able to achieve the goal, though unfortunately not out-of-the-box.
Since you use SVN, it all depends actually on revision. I think I'd create a separate project for your third scenario and added a parameter where PM would provide revision number. Then based on that I'd tag sources etc. in my own task.
Regarding the other points, I think this is similar. Recently for web projects we started using MSDeploy, and in each stage build the MSDeploy package was created. Then there was a separate build called Deploy, that when forced allows us to select which package we want to deploy using MSDeploy.
Having several environments, however, started a little bit like overkill for managing with CCNet, and I'll be looking into kwakee at some time.
I would like to implement a sort of CI where I build my solution on every checkin. There is one problem, however, and that is that my build scripts often will automatically update certain files that do not change the actual compiled assemblies. Is there a way to stop the automatic build (or to not even start) if the only check-in that's triggering it is from one of these "content" files?
Thanks,
Matthew
You can add the *NO_CI* tag to the checkin comment for these changes and they wont trigger a build. Bing it and you'll find lots of examples for how to use it.