Share via

Chapter 7 – Team Build Explained

  • Article

 

patterns & practices Developer Center

Team Development with Visual Studio Team Foundation Server

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

J.D. Meier, Jason Taylor, Prashant Bansode, Alex Mackman, and Kevin Jones
Microsoft Corporation

September 2007

Applies To

  • Microsoft® Visual Studio® 2005 Team Foundation Server (TFS)
  • Microsoft Visual Studio Team System

Objectives

  • Understand Microsoft® Visual Studio® Team System Team Build architecture.
  • Learn the components that make up Team Build.
  • Understand the functionality Team Build provides.
  • Select an appropriate build strategy.
  • Identify ways in which your build strategy may need to be changed if you work on a large project.

Overview

This chapter explains how you can use Team Build to automate the build process. It outlines a number of common build-related stumbling blocks and compares various approaches to builds ranging from daily scheduled builds to continuous integration builds.

Team Build is built on top of the Microsoft Build Engine (MSBuild) and you can use it to retrieve the necessary source code for a build, compile solutions and (if required) execute unit tests and static code analysis tools as part of the build process. You can also release build output to a specified shared location. 

Team Build labels the source code used for a particular build with build numbers so that you can retrieve the source used to create a specific build at some point in the future. In case of failures, you can configure Team Build to create work items and to notify the users about the build failures it encountered.

How to Use This Chapter

Use this chapter to learn about the functionality that Team Build provides for automating and managing the build process, and to understand the different strategies for scheduling builds. To gain the greatest benefit from this chapter, you should:

**Read “Chapter 8 - Setting up Continuous Integration with Team Build”**to learn more about using continuous integration with Team Foundation Server (TFS).

Read “Chapter 9 - Setting up Scheduled Builds with Team Build” to learn more about using scheduled builds.

Read the companion How To articles to help perform build-related tasks:

Architecture

This section introduces the architecture of Team Build through a description of its physical architecture and logical workflow.

Physical Architecture

The physical architecture of Team Build consists of the following components:

  • New Team Build Type Creation Wizard – This client-side component accessed from Team Explorer, enables you to create new build types.
  • Team Build Browser – This client-side component accessed from Team Explorer, enables you to view the Team Build reports and build progress information in Team Explorer.
  • Source Control Web Service – This application-tier component is used by the build service to access source code.
  • Team Foundation Build Web Service – This application-tier component accepts requests from the client and coordinates the execution of build steps.
  • Build Service – This service runs the build steps in response to instructions from the Team Build Web service. You can locate the build service on a separate build server or on the application-tier server.
  • Team Foundation BuildStore – This data-tier component is used to hold records related to Team Build processes.
  • Source Code database – This data-tier component is used to store the source code which is accessed by Build Service during the build process.

Logical Workflow

Figure 7.1 shows the Team Build logical workflow.

Bb668958.image001(en-us,PandP.10).gif

Figure 7.1Team Build logical workflow

Team Build integrates with TFS through the application-tier and interacts with work items, code coverage, code analysis, test cases and reporting. 

The TFSBuild.proj file controls the build, including what projects to build, configurations, drop locations, code analysis, and tests to be run. This file is generated by the Team Build Type Creation Wizard, when the build is first created. You can edit it directly.

Team Build uses the eventing system in TFS. You can use events fired by Team Build to create custom build steps, or to generate notifications of build status changes or build completion.

Key Points

Keep in mind the following key points related to Team Build physical architecture:

  • Team Foundation Build is built on top of MSBuild.
  • The TFSBuild.proj file contains all of the build settings. You generate this file by using Team Build Type Creation Wizard. You can then edit the file directly.
  • The TFSBuild.rsp file contains command-line options for MSBuild. You can modify this file to further customize the build.
  • Event notification enables custom build steps or notifications through the BuildStatusChangeEvent and BuildCompletionEvent events.
  • Team Build integrates with work items, code coverage, code analysis, and test cases.

How Team Build Works

Team Build consists of the Team Build Service layered on top of the MSBuild build system. MSBuild is responsible for the build itself, while the Team Build Service is responsible for communicating with the TFS application-tier. Team Builds are created from the Visual Studio client and you can start them from the client, by an event on the build server, or from the command-line, for example as a scheduled task.  Once started, the build process consists of the following steps:

  1. Get sources from source control into the build directory.
  2. Compile the source and generate binaries.
  3. Run code analysis (Optional).
  4. Create a work item if there is a build failure.
  5. Run tests (Optional).
  6. Calculate code coverage (Optional).
  7. Log build details.
  8. Copy the build to the drop location.

After the build is complete, the following are available:

  • Build details. You can view details from any client or from reports.
  • Build binaries. Binaries are placed in the drop location.
  • Build Log. You can review the log for errors and warnings.
  • Work item. If the build fails, a work item is created to track the build break.

How to Determine Your Build Strategy

Use the following steps to determine your build strategy:

  1. Consider your build consumers.
  2. Review solution scenarios.
  3. Understand common stumbling blocks.

Consider Your Build Consumers

Most development teams have one or more of the following build consumers:

  • Development team
  • Test team
  • Internal build adopters
  • External beta adopters
  • Customers

Each consumer has different needs in terms of build quality and frequency. In general, build consumers can be divided into two groups; those who need predictable, scheduled builds and those who need rapid, event-driven builds. Scheduled builds are most commonly daily builds but can occur more or less frequently. Event-driven builds are usually initiated by a check-in and are designed to give the development team rapid feedback. If your development team has problems with breaking builds, consider using a gated check-in model, where check-ins are tested before they are allowed into the source tree and are rejected if the tests fail.

Review Solution Scenarios

Choose solution scenarios based on how closely their purpose and build consumers match your team’s situation. When in doubt, use the simplest build scenario possible, such as a scheduled build, and add more complex scenarios only if necessary.

Build Scenarios

The following are the most common Team Build scenarios:

  • Team with single daily builds. Most teams rely on a scheduled build in order to provide consistent binaries to their test team and other users.
  • Team with daily builds and continuous integration builds. Some teams choose to use continuous integration builds in order to provide rapid feedback to their developers upon every check-in. Although a pure continuous integration build works well for small teams, larger teams are likely to overload their build server due to high-frequency check-ins and longer build times. When this happens, a rolling build can be used to build less frequently without giving up too much time between check-in and build feedback.
  • Team with multiple build labs, each performing daily build and continuous integration builds. Very large teams are likely to require more complex solutions to improve build quality and timeliness. You can use gated check-ins to reduce build breaks by rejecting bad check-ins before they make it into source control. Teams that branch can use multiple build servers, one per branch, to keep the builds focused on each branch’s purpose. For example, integration branches create integration builds, while development branches create development builds.

Scheduled Builds

A scheduled build is a time-based build based on a fixed time frequency. The purpose of a scheduled build is to produce consistently reliable builds that can be used to gain feedback on the quality of the build. Scheduled builds are usually daily builds, but they could occur more or less frequently depending upon your needs.

The consumers of a scheduled build are most often:

  • Test team.
  • Internal build adopters.
  • External adopters.

Use the following steps to create a scheduled build:

  1. Create a batch file with a command line build.
  2. Use Windows Scheduled Tasks to execute the batch file on a schedule.

For more information, see “Chapter 9 - Setting Up Scheduled Builds with Team Build.”

Continuous Integration Build

A continuous integration build is triggered any time a check-in occurs. The purpose of a continuous integration build is to gain rapid feedback about build quality as soon after a check-in as possible.  Development teams are typically the consumers of a continuous integration builds.

Depending on the size of your team, the length of your build, and the number of check-ins, choose one of the following strategies:

  1. Continuous integration build immediately following each check-in.
  2. Rolling build after a specified number of check-ins, or a specified time period (whichever comes first).

For more information, see “Chapter 8 - Setting Up Continuous Integration with Team Build.”

Gated Check-ins

Gated check-ins is a process that requires each check-in to meet some quality standard before it can be added to the source tree. The purpose of a gated check-in is to reduce the number of build breaks and improve the quality of the build by requiring that each check-in be run through a set of tests before it can be admitted.

Understand Common Stumbling Blocks

There are several common scenarios that Team Build does not fully support by default.  Review the following scenarios and consider whether your team is likely to face any of them:

  • Building a project with external dependencies. If you use branching to bring external dependencies into your team project, you can use project references and the build will work on the build server without any additional steps. If you use client-side workspace mapping to reference external dependencies, you need to maintain the mapping on the build server in order for the build to complete successfully. For more information, see “Chapter 6 – Managing Source Control Dependencies in Visual Studio Team System.”
  • Building a setup project. Team Build does not support setup projects by default. Use a custom post-build step to compile the setup project and copy the binaries to the build drop location. For more information, see “Walkthrough: Configuring Team Foundation Build to Build a Visual Studio Setup Project” at https://msdn.microsoft.com/en-us/library/ms404859(VS.80).aspx
  • Building .NET 1.1 Applications. Team Build does not support .NET 1.1 applications by default. The MSBuild Extras – Toolkit for .NET 1.1 (MSBee) supports .NET 1.1 builds but requires that your projects and solutions be upgraded to Visual Studio 2005. If you cannot upgrade to Visual Studio 2005 projects and solutions, you can use a custom post-build step to compile your .NET 1.1 applications. To download MSBee, go to https://www.codeplex.com/MSBee. For more information about creating a custom build step to compile a .NET 1.1 applications, see Nagaraju’s blog entry at https://blogs.msdn.com/nagarajp/archive/2005/10/26/485368.aspx or see “Microsoft SDC DevEnv task” at https://www.codeplex.com/sdctasks.
  • Building Microsoft Visual Basic® 6.0 applications. Team Build does not support Visual Basic 6.0 applications by default. Use a custom post-build step to compile the Visual Basic 6.0 application. To see a similar post build step that can be used to compile a .NET 1.1 applications, see Nagaraju’s blog entry at https://blogs.msdn.com/nagarajp/archive/2005/10/26/485368.aspx or see “MSBuild task to build VB6” at http://freetodev.spaces.live.com/blog/cns!EC3C8F2028D842D5!261.entry.

Considerations for Large Project

If you work on a large development team, there are additional considerations to keep in mind. Large development teams typically differ from smaller teams in the following ways:

  • They require a more complex branching and merging structure.
  • They are more likely to manage dependencies across solutions and team projects.
  • They are more likely to maintain multiple builds for components and teams.

Keep the following considerations in mind when working with large development teams:

  • Large teams are likely to have longer build times. The frequency of continuous integration builds should be less than the build time to avoid too much queuing and loading of the build server.
  • If your team branches, you can set up a build server per branch. This enables each build to be focused on the purpose of the branch, for example integration or development.
  • Integration branches are likely to have scheduled builds only. Development branches may have continuous integration and scheduled builds.

Build Customization

To modify information about the build, such as the build server, drops location or build directory you can edit the TFSBuild.proj file.

The TFSBuild.proj file contains much of the information needed to execute a team build. This information includes the build locations and whether the build should perform static code analysis and run unit tests. To modify the build you edit the TFSBuild.proj file. To edit the file you:

  1. Check the file out of source control.
  2. Update the build information in the file.
  3. Check the file back in, committing the changes.

The next time the build is executed it will use the amended build data.

For more information about customizing the build, see the “Customization” section in “Build Guidelines” and “Build Practices” in this guide.

Summary

Team Build is built on top of MSBuild. It integrates with TFS through the application-tier and interacts with work items, code coverage, code analysis, test cases, and reporting features. 

When determining your build strategy you need to consider your build consumers and build requirements. Common build strategies include using scheduled builds for consistent, reliable builds that can be used by the test team and others to give feedback on the quality of the build, and using a continuous integration build to gain rapid feedback on build quality for the development team.

Additional Resources

patterns & practices Developer Center