Running The Gauntlet

This week I had the chance to discuss using Team Foundation Server in a large team setting specifically as concerns Build and Deployment.

As I was organizing my thoughts to answer a question about check-in policies, merging and branching, and so forth and I kept coming back to my guiding principles:

• The Build is the build. There is only one Build.
  
• Build anywhere you like, as much as you like, but it only counts if it is in the Build.
  
• If it doesn't work in the Build, it doesn't work.
  

Now I am certainly familiar with having to manage simultaneous release schedules, juggling branches, and so forth, but that doesn't mean I like it. I absolutely support the mainline concept. Much like the Highlander, when it comes to the build, there can be only one.

We could argue that there are many techniques to allow these fancy behaviors but that doesn't make it okay. Just because you can do something, doesn't mean you should. Experience tells us that if you have a big team, you can't afford to have anyone interrupt the flow of the system. This includes breaking the build, causing failures of critical tests, etc. When more people or organizations are involved, the cost increases.

In the agile communities there is a push towards Continuous Integration (CI) which is really an attempt to implement the Only One Build concept as an ideal. When you can do it, you should. When the amount of code grows or the number of loose connections increases this can be cost-prohibitive, primarily in time. Compiling 1.8 million lines of code is going to take a little while regardless of how big the build machine might be. And when it comes to running Build Verification Tests, these problems are compounded. Especially if you are using disparate services that are loosely coupled.

The idea behind CI is to bring compilation and integration issues to the attention of the team as soon as possible thereby minimizing distribution. Going beyond that are tools that would actually test code entering the system before check-ins occur and reject or accept them based on the results. With TFS policies this is fairly straightforward to set up and an open source effort has begun to bring this to life. You can find out more about this effort at http://www.opengauntlet.org/.

If you prefer to wait until this functionality is built-in, you'll be glad to know that the next product release most likely will include a similar feature with a working title of "Gated Checkin".