The Gated Check-in build in TFS2010

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.

Gated Check-In Build process

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.



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.

18 Responses to The Gated Check-in build in TFS2010

  1. blapath says:

    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?

  2. 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!

  3. blapath says:

    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.

  4. Roberjo says:

    I have set up gated check-in as well as single signout/exclusive checkout. Now when my users try to run a gated check-in, the option to “Preserve my pending changes locally” cannot be checked (greyed out/disabled and unchecked). Any ideas why this happens? I need to be able to preserve local changes so my users do not have to search for their shelveset and wrestle with unshelving changes.

  5. Micha Ben-Efraim says:

    If you check the PRESERVE check box, the changes files will remain checked out in your workspace. If these are checked out EXCLUSIVE, the gated check in will fail as it will not able to pull these locked sources.
    As far as I saw, when you have exclusively locked files, TFS doesn’t give you the option preserving local changes as it doesn’t make sense (check in will fail).

    Therefore I assume your problem is is the exclusive lock

  6. Rune says:

    Thanks for the article, but i have a question which I can’t find answer on anywhere… Is there possible to change NoCICheckInComment in 2010? In 2008 it was done in the msbuild file, but since 2010 uses WF, where can we do this?

  7. ugur says:

    You said that:
    “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.”

    Why? I want to get latest version of code from source control otherwise i have to get the latest version of code manually. Neither build failed or succeeded i can reconcile my workspace.

  8. @ugur: to get a latest version that didn’t originate from your changes, you will always need to request a “get latest” manually. You are always in control for your workspaces. Reconcile actions are only possible for your own changes/shelvesets.

  9. ugur says:

    Hi Pieter,

    Thanks for your response. Anyway, i’m talking about my own changes which is originated by me. Exclusive check-out is enabled on our team project. As you know “Preserve my changes locally” option is disabled on gated checkin screen. When gated checkin build finishes successfully, reconcile doesn’t work. It says “no changes to reconcile”. But i’m the person who made the check-in and i want to get latest code automatically by reconcilation.

  10. […] that since TFS 2010, there is also the Gated Check-in trigger option that will even prevent broken builds by delaying the actual commit until a successful build was run […]

  11. […] that since TFS 2010, there is also the Gated Check-in trigger option that will even prevent broken builds by delaying the actual commit until a successful build was run […]

  12. Chandrashekar Vuppala says:

    Thanks for the article, I have a question
    My scenario demands Gated checkin build as well as Continuous Integration build : How to achieve this?

  13. Chandrashekar Vuppala says:

    I got my answer for enabling CI build after Gated Checkin by looking at the above comments.

  14. Chandrashekar Vuppala says:

    I have to modify the workspace of the Gated checkin build: I want to get the code based on the checkin files.
    Suppose, if I checkin dsfff.cs file i want get the bin location and solution directory of dsfff.cs file.
    But my gated checking should trigger at Team project level which will have around 7 branches.

  15. Thanks a lot for providing individuals with a very remarkable chance to read in detail from this web site. It’s usually so beneficial and also jam-packed with a great time for me and my office co-workers to search the blog nearly 3 times per week to read the new guidance you have got. And indeed, I’m also usually satisfied with your mind-boggling ideas you give. Some 1 points in this post are completely the most effective we have all had.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: