One of my most favourite features in TFS 2010 is Gated Check-Ins; they are CI on steroids. In classic CI scenarios you build and verify your code on every check in. That sounds cool as you can detect any issues with the code straight away. However, that means the defective code can be retrieved by someone else at any point. Gated Check-Ins on the other hand, will shelve your changes instead of checking them in, execute a TFS build script and if that build is successful, your changes will be checked in automatically. Here’s an example of how the Gated Check-In dialog looks like:
Lets assume your build was successful and your changes are checked in. You will now need to reconcile your workspace to reflect the version on source control. There are two ways around this, one is via the build’s summary page or the build notification tool. The build summary page will look something like this (actions as links at the top):
The TFS Build Notifications Tool which happens to be part of Visual Studio 2010 Premium and above now days, provides something a lot more simple;
For failed builds you get the option to unshelve those changes. Also note that those options are available in build explorer as well.
I am sure the next question is how to set them up. This is pretty straight forward as the only thing you need to do is to specify Gated Check In as your build’s trigger:
With Gated Check-Ins you guarantee no work interruption due to defective code been checked in. Your build scripts can be as complex as you like to include automated testing and deployment, giving you a better understanding of how reliable your work is.