CI Tools and Best Practices in the Cloud

Continuous Integration

Subscribe to Continuous Integration: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Continuous Integration: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Continuous Integration Authors: Stackify Blog, Aruna Ravichandran, Plutora Blog, Dalibor Siroky, PagerDuty Blog

Related Topics: Virtualization Magazine, Continuous Integration

Virtualization: Article

Continuous Integration with Team Foundation Server 2008

Widely accepted best practices easily incorporated into any development methodology

Build Automation
TFS uses MSBuild for build automation. MSBuild, introduced in the .NET Framework 2.0, Windows Server 2003, and Vista, uses the same "Project" (*.csproj, *.vbproj, *.proj and *.targets) files as the Visual Studio IDE, but can be invoked from a command line. Team Build extends MSBuild to fully automate the build process and integrates many other features including testing, code coverage, and analysis.

Team Build is implemented through the concept of a "Build Type" (see Figure 1). The Build Type is defined by an MSBuild Project file named "TfsBuild.proj." This is an XML document that will be familiar to anyone who's used nANT and is not difficult to learn for those who've never cracked open their "csproj" or "vbproj" files. Here's a good overview of Team Foundation Build.

New build types are created in Team Explorer using a simple Wizard (see below for a walkthrough of defining a Build Type). A new build type can use either an existing MSBuild Project file, or a new one created by executing a sub-wizard. An MSBuild Project file calls a series of "targets," which specify a list of tasks that have to be accomplished for a build.

TFS ships with a standard Build Targets File to control team builds. This file should never be modified, since it may change with every new release of TFS (as it did with the 2008 release). Instead, customization can occur via override targets provided by Microsoft. The team that built TFS did a great job incorporating community input by enhancing these extension points in the 2008 release - it's unlikely that users will need to modify the Team Build's "Core" targets.

Build masters can write their own targets to do custom operations at these extension points using MSBuild Tasks, or write their own Custom Tasks. Furthermore, a rich source of pre-written tasks is available from the "MSBuild Community Tasks Project".

Self-Testing Build
Automated Testing is another practice introduced via agile methodologies that has been adopted industry-wide. The testing tools introduced in the Visual Studio Team Test and Developers Edition are fully integrated into Team Build. In the Team Build Project wizard, the user can choose to have tests run as part of the build, and specify a test metadata file and the "test list" to indicate exactly which tests will run. If this option is selected (see Figure 2), a build isn't considered successful unless all tests are passed. Otherwise, the build is only considered to have "partially succeeded."

Daily Commits Across the Project Team
This is an agile practice that insists on frequent code commits. This means daily - if not more frequent - check-ins to the source repository. Obviously this is a feature of the Version Control component and its integration with the IDE. Additionally, TFS' reporting feature will aid in enforcing this policy, since managers can see how often each developer is actually checking code in. There is also an "email on check-in" subscription to notify interested parties via email when check-ins occur.

In methodologies that don't insist on frequent check-ins, such as a VSS environment, the specter of lost work arose whenever a disk crashed, a laptop got stolen, or a user accidentally deleted (or overwrote) source files. The "Shelving" feature of TFS Version Control is useful when code isn't in a stable enough condition to be checked into the mainline of code. The changes are stored on the TFS Server but not committed to the source tree.

Every Commit Should Build...
The crux of CI is triggering a build from a check-in. The feature is built right into TFS 2008. It's done in TFS by the trigger of a build type. One option is "Build each check-in (more builds)." Another choice, preferable to some, is "Accumulate check-ins until prior build completes (fewer builds)." This will reduce the number of builds by only checking changes at fixed interval (say every 10 minutes) and triggering the build if one or more changesets have been committed in that period.

Some build automation may necessitate the second option. For example, if you want to automate the "versioning" of your binaries, a popular solution is to use the MSBuild Community Task Project's "Version" and "AssemblyInfo" Tasks. To do so, you will likely have your build script check-out and check-in in a file in Version Control. If the "more builds" trigger was selected, TFS would generate infinite builds - each check-in during the build script would trigger another build! To prevent this problem you can include "*** NO_CI***" in the comments for the check-ins to prevent infinite recursive builds.

Another option that may be sufficient for many development groups is simply a daily build. There's a trigger called "Build every week on the following days" in which the user can specify the time and day of the week. By default no build will be triggered if there are no check-ins (this can be overridden).

(See Figure 4 on the walkthrough for the scheduling options.)

...The Mainline...
When creating a build type, the TFS Workspace is defined. A Workspace is a mapping from the Version Control System to the file system on a client machine. To build from the mainline, the user would simply select the mainline in source. However other methodologies may actually choose different branching strategies. Branching and merging is no longer to be avoided when necessary due to limitations of the Source Control product.

If branching and merging is desired, Build Types would be established for each branch, and the workspace for each would specify the appropriate alternate branch. There's an excellent discussion of different branching strategies from Microsoft Patterns and Practices group at

...On the Integration Machine
Another new feature of VSTS2008 is the "build agent." This specifies the actual server that will execute the build. It's never a good idea to have the builds running on the same server as TFS itself since this will introduce performance issues.

Building an application on the same server running the data and/or application tiers can cause resource contention. Implementations that do so may experience a slowdown in check-ins or "gets" while a build is running. Instead, the build can be moved off the server using a build agent. The actual machines that the build agents run can be desktop-grade machines running any Microsoft XP operating system or later. Server operating systems are supported but not required.

Furthermore, the build type specifies a drop location where the output will be staged. This can be any UNC Path - it's not tied to the machine the build agent is running on. This makes the build machines a great virtualization target . A standard image for build machines can be established, and new build machines can be easily created on a virtual server as the need for more builds develops for scaling purposes. (See Figure 3.)

More Stories By Daniel Sniderman

Daniel Sniderman first learned to program FORTRAN in high school in the late ?70s using a keypunch machine. He has a BA in History from the University of Illinois at Urbana-Champaign, and a MCSD.NET and MCTS in Team Foundation Server. Dan has been a senior consultant with Magenic since 2004.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.