Get in the Loop: Continuous Integration Build-and-Deploy Systems

by Ken Spencer

These days, many shops are evaluating commercial automated build systems and investigating how to create the custom extensions that you often have to develop to fit these solutions to your needs. Automated build systems are key to the modern, iterative process of creating applications, letting you gather requirements, build preliminary solutions, test, deploy, and repeat until you have the solution your organization requires. The faster you can build the different application pieces and deploy them into testing, the faster you can develop your solution. This approach has given rise to “continuous integration” solutions, which continuously build new application versions for testing as new code segments are checked into the solution. Enter the need for automated build systems such as Microsoft’s Team Foundation Server and MSBuild and the open-source CruiseControl—at least as a starting point for creating your own continuous integration systems.

Using MSBuild

As part of a project team working on one of the largest tax collection systems in the Southeast United States, Solid Quality Mentors™ recently was responsible for creating a solution that handled daily builds of the large, complex application. The team consisted of about 20 members representing various vendors as well as developers from inside the client organization, dispersed throughout the country. The application consisted of many different components, including

·          .NET components

·          .NET Smart Client UI

·          .NET Web services

·          SQL Server 2005 database, including T-SQL, Integration Services, and other features

·          COM+ hosted components

·          Microsoft Retail Management System extensions

·          Various batch processes

The number of components in the application continued to expand as the application matured, with BizTalk components added to the mix later on.

The hard part of our task was not the build process itself but rather the requirement to create an automated system that would not only build the application but install the various components on the proper servers, letting the testers work with the new application features. After all the bits were installed, the application had to run without further intervention. The automated system ideally would build and deploy the application in less than an hour to effectively facilitate the iterative build/test process. And the installation of the application bits on the target environment had to be performed by an IT person not a developer.

Faced with these requirements, Solid Quality™ developed a system that routinely let us perform builds in less than 20 minutes. Our fastest build-to-application runtime was 11 minutes. For this project, we began with the free Microsoft Build Engine (MSBuild) for Visual Studio 2005; see http://msdn2.microsoft.com/en-us/library/ms171452(vs.80).aspx for an overview of MSBuild. But it’s easy to see that you couldn’t meet such requirements by using MSBuild or most other third-party tools alone. And creating a bunch of batch files that someone must run on each server might work, but it’s an error-prone process that’s not extensible. We ended up customizing and extending the MSBuild solution to accommodate various application pieces such as Integration Services.

Using Team Foundation Server

Now in 2007, part of the Solid Quality Mentors™ team has moved on to another government agency project, this one even more complex and involving more than 100 people. For this project, we are tasked with creating a continuous integration build solution that works with Visual Studio 2005 Team Foundation Server (TFS), which wasn’t available in time for our previous project, and that works in a secure environment. The goal of the build team is to be able to build the .NET features and bring up the application for testing in just minutes not hours or days.

TFS is truly an integrated, automated collaboration and build system, pulling the application from the TFS source control system and building it for you. (See http://msdn2.microsoft.com/en-us/teamsystem/aa718825.aspx for more about TFS.) TFS lets you run builds from Visual Studio and schedule them automatically; plus you can call the build engine from a batch file. TFS also includes a portal for logging into status information. Although TFS is a good jump start to creating an automated, continuous build system, most organizations will still find that they’ll need to extend the functionality to handle all the application pieces they have to build and test.

The most import part to remember about doing regular builds and test deployments is to just do them. Over time, developers have learned that the traditional waterfall method of building applications—in which you gather all requirements up front, build the complete application, then test it and show it to your users—doesn’t work in most cases. It’s nearly impossible to foresee all application requirements before you start development. And you end up spending lots of time creating functionality that you have to rewrite completely or trash. Even small shops can and should institute automated build systems. If you have more than one developer working on a project, these systems let you safely and efficiently change the application and feed the new bits to users for testing on a regular basis. And in the case of the free MSBuild and the open-source build tool CruiseControl, the cost is painless.

Learn from Our Experience Solid Quality Mentors™ provides services to automate your build and deploy processes, making them happen in minutes instead of hours or days. Our custom software can provide a basis for your new build system and leverage any source-control systems you might already be using, including TFS, MSBuild, or custom tools. Contact info@solidq.com for information about how we can help you build better solutions faster.