Continuous Integration Using Team Foundation Build
Khushboo Sharan, Program Manager, Visual Studio Team System
Kishore, M N, Software Development Engineer, Visual Studio Team System
Revised: December 2006
Microsoft Visual Studio 2005 Team Foundation Server
Summary: Create a regularly available public build securely and reliably with continuous integration. (6 printed pages)
Click here to download CI.msi.
Organizations always need a repeatable and reliable method to create a regularly available public build. In my previous organizations, I used in-house tools.—I even used a continuous integration build type. I just did not know at that time that it had a name!
What is continuous integration? Continuous integration is the process of generating a build whenever a programmer checks code into the source control server. When you use this process, it is a good idea to have a dedicated build server where you can synchronize and compile the sources, and run unit tests.
Software development life cycle processes evolved over time. Development teams realized the importance of having periodic builds. It started with a weekly build. Then it grew tighter when "nightlies" began, and tighter still with "hourlies." As the benefits of frequent builds became more obvious, organizations wanted more builds. And now we have continuous integration. But nightlies still exist. Many organizations still count on them to get a formal, reliable build.
Team Foundation Build is the build automation tool in Visual Studio Team System. Built on top of MSBuild, Team Foundation Build integrates with other Visual Studio Team System tools such as source control, work item tracking, and test execution. This provides an end-to-end build process. Team Foundation Build does not provide continuous integration out of the box, but you can easily customize it to do so.
You can download a sample that customizes Team Foundation Build to implement continuous integration. You can easily use this sample to set up continuous integration.
To install the continuous integration sample, use a computer that runs IIS 6.0. Make sure you install the sample on a computer where you have already installed the application tier of Team Foundation Server.
The setup installation creates a virtual directory underneath the root of the application-tier server for Team Foundation Server. This should be an IIS Web site called "Team Foundation Server" on port 8080. You must make sure that the virtual root runs in the "TfsAppPool" application pool. This is necessary because the sample must run in a user context and not ASP.NET context. As an option, you can create a new application pool with a user credential that has the required access to the Team Foundation Server. You can run this in the same account that is used in each project's Build Services Group.
The sample consists of the following:
- web.config—the configuration page containing the properties for continuous integration.
- app_code\*.cs—the source code for the application.
- bin\*.dll—the; reference assemblies.
Configuring Continuous Integration Settings
Set these options in the web.config file are as follows:
- TeamFoundationServer—URL for the application tier in the format http://machine:8080.
- TeamProject—team project for which you want to enable continuous integration.
- BuildType—build type to be used while creating continuous integration builds. Typically this is configured just for builds. You can also add a basic level of testing and static analysis.
- Build Machine—an optional parameter.
- Use this to override the default build machine specified in the build type.
Registering for CheckinEvents
For CheckinEvents registration, use the bissubscribe tool available at %programfiles%\Microsoft Visual Studio 2005 Team Foundation Server\TF Setup\BisSubscribe.exe on the server. The command to use is:
Bissubscribe /eventType CheckinEvent /address http://myServer:8080/CI/notify.asmx /deliveryType Soap /server myServer
Where myServer is the name of the computer where you installed Visual Studio Team System. It also assumes that you installed the continuous integration software in the default virtual directory.
Locate the web.config file in the /CI virtual directory and create the following appSettings:
<add key = "1" value = "TeamServer=http://myServer:8080;TeamProjectName=myTeamProject;BuildType=myBuildType" />
To get e-mail notifications every time a build completes, select your team project in Team Explorer, right-click and then click Project Alerts. In the Project Alerts dialog box, check A build completes and enter the e-mail address where you want to receive the notifications.
Description of Source Files
The source code is in two files. The first file is checkinEvent.cs. It contains the definition of the CheckinEvent, which is generated by creating a class from the check-in event that XSD defined in the registration entry for the Version Control tool. The second file is named notify.cs. It contains the code that runs the entire continuous integration process.
Description of the Continuous Integration Process
Figure 1. Continuous integration process
When you receive an event for the first time, the system reads the configuration settings for all projects and stores the information in a CIProjectSetting object list.
The system calls the notify function in response to any check-in event for all the team projects for which you have registered. If you used the BisSubscribe command to subscribe, you will receive check-in events for all team projects. Once it receives the event, the system searches the list of configured projects. If it finds a match, it starts a build for that team project. It uses the build type defined in the configuration file. This call waits until the build actually completes. If another build is in progress, the system queues the new request. Once the current build completes, the system starts the new build.
The continuous integration system can handle multiple team projects at the same time.
These are some of the advantages of continuous integration:
- You catch build breaks early on.
- In a distributed development environment where developers do not always communicate with one another, continuous integration is a great way to assure the developer that the build he or she is building is the latest one.
- Continuous integration also causes less regression
- The feedback loop is smaller.
- A developer does not have to wait for the end of the day or week to find out how the check-in affected the build.
- Integration testing moves up in the chain.
- Every check-in goes through the integration testing where problems are caught early.
- Continuous integration enforces better development processes.
- Each developer is held accountable.
- You always have a latest-and-greatest build to use in demos, showcases, etc.
On the other hand, there are some disadvantages:
- Maintenance overhead often increases.
- Some teams find that the level of discipline required for continuous integration causes bottlenecks.
This often requires a shift in the developer mindset.
- The immediate impact of a check-in often causes a backup because programmers cannot check in partially completed code.
Is it written in stone that continuous integration is the way to go? I wouldn't say so, but it definitely has benefits and should be considered.