Continuous integration and gated check-ins

Continuous integration (CI) is generally considered a good thing. And there are some hard facts out there. And I agree that it is hard to find a situation where CI does not add value. I guess the only case where you would opt to not use CI is when the cost outweighs the benefits. In my mind that is when the build time approaches hours. Because the classical CI scenario uses CI to verify check-ins and if your check-in breaks the build you get right back to fix it. But if the time between check-in and feed back is too long the developer will probably have lost focus since he (or she) has started to work on something new. Also in a large team (or several teams working on the same code base) a build failure might interrupt a number of developers since it might be unclear exactly what change broke the build.

Gated check-ins to the rescue. A gated check-in means that a build is performed with one set of changes from one developer and if that passes those changes are checked-in. This means that breaking changes never get it into the code base which I think is a good thing. Especially if it saves time as a whole. This is a feature that is available in Teamcity but does not exists in TFS 2008. Gated check-ins are however supported in TFS 2010. There is however a tool that adds gated check-ins to TFS 2008 - BuddyBuild.

So if you use gated check-ins I can no longer find a single scenario where CI does not improve your development process.