Team Foundation Build Quick Start

MSBuild is a build engine rather than a build automation tool, which is where Team Foundation Build (which we will refer to as Team Build for short) comes into the picture. Team Build is a component of Microsoft Visual Studio Application Lifecycle Management. Team Build provides build automation that integrates tightly with the other Visual Studio Application Lifecycle Management components, such as version control, work-item tracking, testing, and reporting.

Why discuss Team Build in a book about MSBuild? Apart from the fact that both are build tools, the good news is that Team Build uses MSBuild to build solutions and projects, so the MSBuild knowledge that you’ve gained in the previous chapters will be put to good use.

Team Build changed significantly between Visual Studio Team System 2008 and Visual Studio 2010 by moving the build process orchestration from being MSBuild-based to Workflow Foundation–based. This change enables scenarios that were difficult to implement using MSBuild (such as distributing builds across multiple machines), provides a graphical build process designer, and provides a customizable user interface for queuing builds and editing build definitions.

Introduction to Team Build

This section discusses the features and architecture of Team Build to familiarize you with its key components and how they relate to each other. These features and components are covered in more depth in later sections.

Team Build Features

Team Build 2010 has a comprehensive set of features that should meet the needs of almost all build automation requirements, and even if it doesn’t, it is highly configurable and extensible.

Some of the key features in Team Build 2010 are as follows:

• Provides a default build process suitable for building most Microsoft .NET Framework applications

• Build process is based on Workflow Foundation and is highly configurable and extensible

• Supports the queuing of builds and multiple build machines

• Supports manual, scheduled, continuous integration, and gated check-in builds

• Private builds (also known as buddy builds)

• Retention policies for removing old builds

• Integrates with reporting, testing, version control, and work item–tracking components of Visual Studio Application Lifecycle Management

• Includes an API for automating, extending, and integrating with Team Build

High-Level Architecture

A high-level diagram of Team Build’s architecture is shown in Figure 13-1.

Figure 13-1 High-level architecture

The Team Build architecture includes:

• Team Build client Visual Studio provides a number of built-in clients for Team Build, including Team Explorer, which is an add-in for Visual Studio; TfsBuild.exe, which is a command-line client for Team Build (and is described in detail in the section entitled “Working with Build Queues and History,” later in this chapter); and Team Foundation Server Web Access, which is a Web interface for Team Build (and other components of the Visual Studio Application Lifecycle Management). Team Build also has an API that can be used to develop your own clients for Team Build, and that will be discussed in Chapter 14, “Team Build Deep Dive.”

• Build controllers This Windows Service orchestrates the overall build process and is responsible for initializing the build, reserving build agents, delegating parts of the build process to one or more build agents, and finalizing the build. A Team Project Collection can have one or more build controllers associated with it, but each build controller can be associated with only a single Team Project Collection and a machine can have only a single build controller installed on it.

• Build agents This Windows Service is responsible for executing the bulk of the build process. A build controller can have multiple build agents associated with it, but each build agent can be associated with only a single build controller. Unlike build controllers, a machine can have multiple build agents installed on it. Because builds are CPU- and I/O-intensive, this is generally not recommended, but if you have sufficiently powerful hardware or your build process isn’t resource-intensive, you may be able to increase build throughput by running multiple build agents on each physical build machine.

• Team Project Collection Team Project Collections are a new concept in Team Foundation Server 2010, and as you might expect, they are collections of Team Projects. The Team Projects in a Team Project Collection share a database on the database tier and can be backed up, restored, and managed as a single entity. Each Team Project Collection is completely independent, and this is the reason that a build controller can be associated with only a single Team Project Collection.

• Team Foundation Server application tier Any Team Build client that wants to communicate with a build controller does so through the Team Foundation Server’s application tier. The application tier is implemented as a number of web services hosted using IIS. Communication from the application tier to build agents is always done via the controller.

• Team Foundation Server data tier The data tier for Team Foundation Server is hosted as a configuration database (TFS_Configuration), a warehouse database (TFS_Warehouse), and a database for each Team Project Collection (for example, TFS_DefaultCollection) in Microsoft SQL Server.

• Team Project Collection database This database stores operational build data such as the list of build controllers and agents, build definitions, build queues, build history, and so on.

• TFS_Warehouse database This database stores historical build data for reporting even after it has been purged from the Team Project Collection database.

• Cube This multidimensional online analytic processing (OLAP) cube is implemented in SQL Server Analysis Services and is populated regularly from the TFS_Warehouse database for high-performance reporting.

• Drop folder When a build completes the build logs, build outputs (if the build is successful or partially successful) and test results are copied to a shared network folder. Public and private builds for the same build definition can be dropped to separate root drop folders.