This post is part of a series on TeamBuild 2010:
What is a “Gated Check-in”? It’s a new type of build which is launched automatically every time a developer makes a check-in. But unlike continuous integration, a “Gated Check-in” will reject the check-in if the build is on error.
Technically, the “Gated Check-in” uses shelvesets. When a developer makes a check-i, Visual Studio will prompt him with a new dialog asking to shelve it’s modifications:
As you can see, the developer can also bypass this mechanism and force a check-in if he has the appropriate rights. If he goes for the “Gated Check-in” a build will be launch and the following steps will happen:
- The build controller will start as any other build by creating the drop location and compute a build number.
- The build agent will get the latest source code and then will unshelve the developer’s code. But it will not set a label and will not associate the build with the changset and workitems.
- The build and tests will be executed.
- The source indexing and symbol publishing will be done.
- If no error occurs, the controller will finish the “Gated Check-in” by checking in the code from the shelveset (adding in the comments “***NO_CI***” to make sure another build is not triggered) and will now associate the build with the changeset and workitems:
If there was an error, the developer will be able to unshelve it’s code using the build explorer so that he can correct it:
You can also manually queue a “Gated Check-in” build. In this case the dialog window has new options:
The user can launch the build with the latest sources as with any other build type by selecting “Latest sources” in “What do you want to build?” or he can launch a build on the latest sources with a shelveset. When using a shelveset, the user can specify if he wants it to be check-in at the end if no error occurs (this is a normal “Gated Check-in”).
Being able to specify manually the shelveset brings us to the second new build type: the “Private Build”. A “Private Build” is a build launch only manually with a shelveset specified. This build will execute as a “Gate Check-in” with the following restrictions:
- No build number will be generated.
- There is no source indexing and symbol publishing.
- The build will no be associated to changeset or workitems.
- The build output will not be copied to the drop location (only the build log).
The “Private Build” can be used on any build types (manual, continuous integration, …) and can help developer validates their changes using the same process on the same machine the build will use. This helps for example prevent a build error when the developer has added a third party component on his local machine but not on the build server.
Private builds can be compared to local builds with TeamBuild 2008 using the “IsDesktopBuild” property but a thousand times better
To conclude, “Gated Check-in” are a great addition and can insure that no broking code is checked in but can be a little to intrusive for me. Private builds, on the opposite, are my preferred choice as they let the developer with the freedom to check their code in a reliable manner.