Everybody should be already familiar with Continuous Integration or should I say Continuous Building? Automatically building a development codeline after a check-in is often not immediately followed by an integration action towards a main branch. I picked up the term Continuous Building in this article of Martin Fowler.
Apart from the fact how this “build automation” should be called, there are many reasons why you should enforce this behavior on different branch types for your applications. The ultimate goal is to improve the quality of the software application and to reduce the time to release the application in production. By setting up early validation (compilation, automatic testing + other quality gates) through “build automation” you will at least be notified as soon as possible of all kinds of validation errors (= quality check) and you will have a chance to fix them before other team members will be impacted by pulling a get latest on the repository.
Automatically firing a validation build after a check-in will in the end not prevent broken builds and that’s where the Gated Check-in Build will come into play with Team Foundation Server 2010.
The Gated Check-in Build in TFS2010 will prevent broken builds by not automatically committing your pending changes to the repository, but the system will instead create a separate shelveset that will be picked up by the Gated Check-in Build. The build itself will finally decide if the pending changes need to be committed to the repository based on the applied quality gates.
The picture above describes the full process of a Gated Check-In build.
How to setup a Gated Check-in build?
The Trigger Tab in the Build Definition window has now an extra option for selecting Gated Check-in.
At the moment a check-in is attempted by a developer in the branch where the Gated Check-in build is active, the developer will be faced with a dialog box.
Cancelling this window will not kick off the build, but will also not commit your pending changes to the repository. If you really want to overrule this build with committing your changes directly to the repository, you may select the 2nd checkbox to bypass the validation build (not recommended). By default your pending changes will reside in your local workspace (first checkbox). In the situation where you immediately want to start with new changes – not relying on previous changes – it might be appropriate to uncheck the first option.
In the ideal situation, the build will complete without any validation errors and will eventually commit the changes to the repository. This will also lead to a Gated Check-in notification for the original committer via the Team Build Notification tool.
If you had previously chosen to preserve the changes locally (default), you may have noticed that the files you were working on were still checked out during the build … and in fact after a successful build these changes do not reflect the as-is situation anymore of the repository. With the above window you get the option to immediately reconcile your workspace with the up-to-date repository. So, clicking the “Reconcile …” button will give you the opportunity to select the desired files to force an undo in your local workspace and to pickup the changes that were committed by the Gated Check-in build for these files.
Another way to reconcile your workspace (if you for example ignored this window or when the build notification is way too slow) is by right-clicking the completed Gated Check-in Build in the Build Explorer and selecting the option to reconcile your workspace.
If you did not choose to preserve the changes locally, there won’t be any changes to reconcile after the Gated Check-in build, even if you forced the reconciliation.
The Gated Check-in build may also be kicked off manually where you may need to create a shelveset or where you may point to an existing shelveset.
A last thing to note is that the comment that was originally supplied to the changeset by the developer will be suffixed with the NoCICheckinComment variable (default = ***NO_CI***) to prevent that another continuous integration build will be fired after the final check-in done by the Gated Check-in build.
Summary
What meant to be a small post on the Gated Check-in feature in Team Foundation Server 2010 ended up in a more detailed explanation of how it works and how you can work with it in the Visual Studio IDE. Remember that you should setup the most appropriate build types according to your specific branches. Not all branches may need a Gated Check-in build. Only configure this for branches that should never have a broken build. A Gated Check-in build may for example validate a big merge operation from a development branch to a stable main branch.
We are using scheduled builds, triggered every night, without using continous integration. This build process works perfectly and until now served our needs. Recently, with TFS 2010, we introduced Gated Checkin in order to disallow ‘damaged’ code checkin. And suprise… after a couple of checkins, and their validation, the nightly build was not triggered.
Somehow it seems, the Gated Checkin prevents the scheduled build execution. I understand such Gated Checkin should prevent continous integration (***NO_CI***), but it is not clear why a scheduled build is omitted.
Is is a bug or a feature, or maybe a bug in our build script?
Is it possible to have both a Gated Checkin and a Scheduled one?
On the trigger tab (schedule option) you also have a checkbox to build even if nothing has changed since the previous build. Make sure that’s checked!
I am aware about the BUILD EVEN WHEN NO CHANGES. But checking this control seems a wrong solution: I really don’t want to build when there are no changes (After release, source is unchanged ‘forever’, no build is needed). I checked in code so there is a change. The fact I checked in with validation (i.e. gated check-in, triggering a build just for test), shouldn’t prevent a scheduled build, as it is scheduled for a certain time.
One more point: the gated check-in will trigger (probably) an incremental build, as it is mainly for validation only. But the scheduled build is a full build, for creating a releasable executable set.
So it seems the logic of gated check-in has a bug; it should allow not clearing the list of check in savesets in order to allow a scheduled build, even without the mentioned check-box (‘build always’) turning on.