he era of agile software development is upon us. Chances are, if your development shop doesn’t already practice some form of agile development, you’re probably competing with a company that does. The rapid-release nature of the agile mindset alongside the idea of releasing features incrementally and frequently inherently increases the risk of introducing unforeseen problems into the software. The charge for any development manager working in these conditions is to find such problems early and provide processes to handle them appropriately.
If anything is clear about the agile philosophy of software development, it is that it requires new and efficient processes for finding bugs early and handling them efficiently; rapid communication of problems and events is critical. These problems have always existed, even in more traditional models of software development, but longer delivery cycles made them less urgent.
It is important to point out that while the term “agile” may have been coined in the software development industry, the problems inherent to managing fast-moving processes are not software-specific. In other industries such as auto manufacturing and national retailing (think Wal-Mart) corporate inventories are dependent on carefully orchestrated supply chains. Industry leaders have long recognized that “lean thinking” can be a considerably more efficient business model. The idea is that by keeping less stock on the shelf, and by acquiring or manufacturing goods just-in-time, companies are able respond more quickly to changes in consumer demand, have fewer wasted goods that go unpurchased, and reduce storage and inventory costs. By letting customer demand drive purchasing, suppliers can provide the right items in the appropriate quantities precisely when and where they are needed.
Without strict governance of the processes and constant communication about faults in the supply chain, the entire system becomes very unstable. With little or no reserve stores of supplies and goods, problems in the chain have to be fixed quickly to prevent shortages. Stopped assembly lines and empty retailer shelves must be avoided at almost all costs. The software construction industry must implement similar processes to manage the rapid changes in the software. Further, like a healthy supply chain, problems in the software must be detected early and often to ensure that such problems do not cause problems for the project by either delaying the release date or reducing software quality.
Two processes that provide big payoffs for developers are unit testing and continuous integration. I covered unit testing for Visual Studio Team System in a previous article. This article shows you how to implement a continuous integration process that will rebuild the software project every time new code is checked into the project. The benefit that continuous integration brings to the development process is early detection of problems with the “quality” of the software. In this case, quality is judged by the success of the build and the success of unit tests run against the new build. While other tools are available that serve similar purposes, we will use the tools provided by Team Foundation Server. This article will not specifically discuss the Team Build tool provided by Team Foundation Server but rather show how to run Team Build automatically.
|Author’s Note: Perhaps the best philosophical reference available for continuous integration is Martin Fowler’s web page aptly titled “Continuous Integration.” While not the seminal article on the subject, Fowler’s page is heavily referenced in many discussions about continuous integration and provides practical guidance on why it is important and how to make it work.
This article reuses the sample project code provided in my earlier article on unit testing, retrofitting the project code so it rebuilds automatically when changed code gets checked in. First, download the code and create a new team project named DevXLibrary. In the rest of this article I’ll show you how to create and automate a team build type for the project.
Creating the Team Build Type
In Team Foundation Server (TFS) parlance, a “build type” is the complete definition of a software build. It specifies the project to be built, what configurations to build, where to build the software, where to put the build output, and which unit tests should be run following the build. Figures 1 though 7 show the process of creating the team build type.
|Figure 7. Review Build Type Selections: This dialog provides a summary of the settings and options you chose in the preceding steps. Press the Finish button to add the new team build type to the team project when you’re satisfied.
To create a new build type, right click the “Team Builds” directory under the DevXLibrary team project and select “New Team Build Type?.” I chose to name the build type “Continuous Integration Build.” Figure 3 shows the window that allows you to select the projects that should be built. In this example, there is only one project. Out in the wild, a team project will consist of many projects that can be included in the build process. Then, Figure 4 allows you to select the configurations you would like to build. While only the Debug configuration is selected, you can select to build other
|Figure 8. Team Build Tool: The Team Build tool builds a set of directories containing both source files required to run the build and to hold the results of the build process.
configurations and even multiple configurations in the same build. In the “Select Build Location” window shown in Figure 5, you provide TFS with the name of the server used to build the software and the location to drop the resulting files. In this case, we will be using the existing server named VSTS. Figure 6 shows the “Select Build Options” window. Using Visual Studio Tester Edition, test lists can be built that organize unit tests into logical groups. Unfortunately, test lists are only created by either the Tester or Team Suite editions of Visual Studio 2005. Test lists will not be included in this build type.
After you are finished creating the build type, run the build and explore its output. Expand the “Team Builds” directory under the “DevXLibrary” team project. Right click on the build type labeled “Continuous Integration Build” and select “Build Team Project DevXLibrary?.” When the build starts, you will see a “Build Progress” dialog while the build starts. As soon as the build is underway, Visual Studio’s Build window opens, showing each step of the build and its results. When the build completes, navigate to the directory you provided for the build drop location and examine its contents. Figure 8 shows the directory structure produced by the “Continuous Integration Build” process.
Automating the Build Process
|Figure 9. Select Install Location: Select the Team Foundation Server site to use when installing the CI Web service.
Now that you have created and tested a build type, the next step is to configure it to run whenever a developer checks code into the team project. Microsoft supplies a notify.asmx Web service that can automate the team build when a check-in event occurs. You need to download and install the Web service, configure it, and bind the source control check-in event to the Web service.
|Author’s Note: In the preceding code, replace the underlined sections of the string with the appropriate values for your own implementation.
After configuring the Web service, you can use the utility bissubscribe.exe from a command prompt to bind the check-in event for the DevXLibrary team project to the notify.asmx Web service. You’ll find bissubscribe.exe in the C:Program FilesMicrosoft Visual Studio 2005 Team Foundation ServerTF Setup directory. Execute bissubscribe.exe using the command line show below (enter the command on a single line). Replace the underlined portions of the command line below with the name of the server where you run Team Foundation Server.
bissubscribe /eventType CheckinEvent /address http://vsts:8080/ci/notify.asmx /deliveryType Soap /domain http://vsts:8080
When bissubscribe runs, the output (shown below) will report a Subscription ID that identifies the subscription that binds the check-in event for the DevXLibrary team project to the notify.asmx Web service.
BisSubscribe - Team Foundation Server BisSubscribe Tool (C) Copyright 2006 Microsoft Corporation. All rights reserved. TF50001: Created or found an existing subscription. The subscription ID is 8.
|Author’s Note: Keep track of the subscription ID as you experiment with these subscriptions, because you’ll need it later to unsubscribe from the web service.
To unsubscribe from the Web service, execute the following command.
bissubscribe /unsubscribe /id 8 /server vsts
Run the Build
|Figure 10. Testing the Sample Project: Following a source control check-in event, the build process starts automatically.
Now you’re ready to test the configuration. Check out one of the source files in the DevXLibrary team project. Make a small modification to the source file and check it back into source control. When the check-in process completes, Team Foundation Server will call the notify.asmx Web service, which will instruct TFS to launch the DevXLibrary project’s “Continuous Integration Build.” To verify that the build process started successfully, right click “Continuous Integration Build” from the list of build types, and select “Open”. Figure 10 shows the Build window, which indicates that the build is initializing. Each time you build the team project, a new entry will appear in this list. Double-clicking the build labeled “Continuous Integration Build_20060910.1” opens the Build Status window shown in Figure 11, showing the detailed status of the build.
At this point, if the build ran successfully when you checked in your code change, you’ve completed the process to automatically build a software project when source code is checked in.
Going a Step Further
To use an automated build process in your development group, there are other things you should consider. First, it’s useful to make the notify.asmx Web service more flexible by modifying the notify.cs file in the Web service to support other build team projects and build types. At minimum, I would suggest adding alerts to email the appropriate personnel when important steps in the build process fail. Although a detailed discussion of the possible changes is beyond the scope of this article, you can study the Web service source code and experiment with changes.
If continuous integration is too big an initial step, consider running team build on a scheduled basis. You could run a build daily or weekly, depending on your needs. There is a short article on the MSDN web site that walks you through the process for scheduling a team project build.
Finally, you might consider subscribing the project leadership to build events so that they are notified when developers check in code, when a build process completes, or when a build’s quality changes. To do this, right click the team project “DevXLibrary” and select “Project Alerts?.” The Project Alerts window (see Figure 12) sends email notification when certain events occur in Team Foundation Server.
If your development group is considering an agile approach to developing software, you should definitely consider automating your build process. As with any efficient process, rapid feedback of information is critical to proper management. A continuous integration process can help by providing rapid feedback about the quality of the source code checked into source control.