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:
Set these options in the web.config file are as follows:
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.
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.
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:
On the other hand, there are some disadvantages:
This often requires a shift in the developer mindset.
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.