Continuous Team Builds

Microsoft is taking on Continuous Integration -- should you?

• By Kathleen Richards
• August 15, 2007

The element of surprise works well for landmark birthdays ending in "0." But with software projects, the "gotchas" at development milestones can lead to backtracking or failure. How can team managers monitor the health of a .NET project?

Microsoft Visual Studio 2008, slated to ship in December (available in beta 2 now) will offer Continuous Integration (CI) out of the box for Team Foundation Server (TFS). The lack of CI when TFS first shipped in March 2006 was duly noted by many .NET users. After the uproar, Microsoft's GotDotNet team quickly released a CI plug-in for TFS. That tool has been "productized" in Visual Studio 2008, says Jeff Levinson, a senior consultant with Accentient Inc.

"Continuous integration is a best practice: It absolutely can't hurt and it will find build problems as soon as they appear," he says. "Everybody should be doing it."

Continuous integration is a technique that allows developers to check their local work against the larger codebase and everything that goes along with it. When developers take everything on their local machines and check it into the source-code control server, the software kicks out a build that has access to all the latest versions of the codebase, along with the project libraries, tests, dependencies and other files. Developers can view a report to see if their code is playing nicely with other team members' work -- or breaking the build.

"What it's really designed to do is to find breaking changes in integration aspects of your code," says Levinson.

Check-In
Team members check their code into a centralized source-code control server, which scans the code and kicks off a build when changes are found. Continuous integration, however, is often constrained by the size of the dev team, the number of check-ins, how involved the build process is and the dev environment.

"Suppose they have a codebase that's a million lines long: It may take 15 minutes to do a compile and build, and while you're in the middle of doing that somebody else checks in, and soon what you have is a build server that has 15 builds running on it at the same time, totally bogging it down," says Levinson.

"In some cases we tell people not to do continuous integration and just do nightly builds," he says. "In other cases we'll say: 'Only check code in when you're absolutely certain that you've got everything done and shelf it and store code on the server.'"

If a developer is working on a specific product feature, for example, it can be important to compile and build it on the local machine before checking the code into the build or CI server. Another common pitfall is when developers don't check in all of the relevant code and updated files from their local machines.

Automate
If executing builds multiple times a day sounds like a major hassle -- it is. A build automation or scripting tool can automate the build process by accessing all of the executables, dependencies, test cases, libraries and other files. Project managers should automate the build, whether they're doing CI or not, advises Levinson. The automated build process includes build-verification procedures known as "smoke tests" to ensure that the application still runs after the build. Team Build, which is built on top of MSBuild, is the build-automation tool in Visual Studio Team System.

Continuous integration may not include all the tests needed to take into account different systems or integration points, but some level of automated testing is usually built into the process. Unit testing should be done before each check-in.

"Once you've got unit test cases, you can integrate those into the build to leverage those test assets," says Carey Schwaber, senior analyst at Forrester Research Inc. "It's always been easy to associate automated test cases with each build. In addition, Team System lets you run code analysis prior to check-in and warn developers if their code doesn't conform to coding standards, or even -- if desired -- prevent them from checking it in."

Microsoft's unit-testing tools are currently available only in Visual Studio Team Editions for Software Testers and for Software Developers. In Visual Studio 2008, the unit-testing framework will become part of the Professional Edition. NUnit is a popular open source tool for unit testing in .NET environments, and CruiseControl.Net and Draco.Net are highly regarded CI tools.

"There's definitely a mix between processes and the tools that support the processes, which is what Team System is," says Levinson. "So I try and stress that the tool itself is not going to solve your problem -- you've got to have processes outside of the tool."