An Overview of Team Foundation Build

Many development organizations leverage a build lab to create both public and private builds of their software releases. Distilled to its basics, a build lab is a set of hardware and software resources that take all the source code files from the team project, centralize them on a Build server, and then compile the system with all the latest changes. Ideally, this build is then packed up and copied over to a central, accessible location that everyone on the team can access. Quality Assurance (QA) resources are then free to run their test suites against the software and determine what sorts of changes need to be fed back to the development team.

Team Foundation Build's stated goal is to provide a build lab in a box. In essence, it strives to eliminate much of the manual work from the build process while at the same time enabling team members to gain information about the health of a particular build. The Team Foundation Build platform provides a variety of benefits to the project team:

• It enables a build process to be constructed and initiated quickly and easily from within Visual Studio.

• It provides the project team with the tools necessary to determine the overall health of the build.

• It allows for build-to-build comparison for a historical look at overall project progress as each build is created and tested.

Team Foundation Build Architecture

Team Foundation Build services are provided by four subsystems within the Visual Studio Team System ecosystem. Each plays a specific role in the high-level build process:

• The Team Build client (Visual Studio) will define a build (which can be stored in the Team Foundation Source Control system) and then initiate the build.

• The Team Foundation Server application tier will listen for any build requests that come through from the Team Build client; it then passes off the build request to the Build server.

• The Build server is the workhorse here: It runs the Team Build Service, which will examine the specifics of the build, grab the necessary files from the source control system, compile the source files, run tests, and publish results. Notifications of the build completion can then be sent to the team. In addition, the Build server will publish the build out to a specified location.

• The Team Foundation Server data tier fills its typical role as data repository: The build details and log events are all stored here, allowing the Build client to view and analyze the build.

Figure 23.1 identifies how these components work with one another.

Figure 23.1. The Team Foundation Build system.

Note

The diagram presented in Figure 23.1 is a logical architecture. The Team Foundation system can be physically structured in a variety of ways. For example, although it makes sense to have a dedicated Build server for larger projects, you could host the Build server on the same machine that is hosting the Team Foundation Server application tier or, for that matter, the data tier.

In fact, for very large projects, it may make sense to have an entire farm of Build machines running the Build server components.

The Team Build Client

Team Explorer, hosted inside Visual Studio, functions as the primary client for the Team Foundation Build system. Within Team Explorer, builds are managed and configured through the Builds node. Under the Builds node, every defined build within the scope of the current team project is visible. Each of these entities represents a variety of settings, including which files should be incorporated in the build, what tests should be run as part of the build, where the build should be published, and so on.

Figure 23.2 shows a list of build definitions (known as a build types) within the Team Explorer window.

Figure 23.2. Builds within the Team Explorer window.

The Application Tier

The Team Foundation Server application tier exposes Team Foundation Build as a set of four web services (see Chapter 18, "Managing and Working with Team Projects," for a look at all the web services implemented by the TFS application tier machine):

• The Build Controller web service exposes the API for managing and controlling builds. It is capable, for instance, of issuing start and stop commands for a build and signaling build completion, among other things.

• The Build Store web service provides methods for saving and retrieving build information to the TFS data tier.

• The Build Integration web service allows the Build server and other clients to interface with other team project entities.

• The Publish Test Results web service is the API used to distribute test results run against the build to the project team as a whole.

The Build Server

As mentioned previously, the Build server is the core engine that really implements the build process. It consists of a windows service (named Team Build Service) that processes commands issued from the application tier. This service is responsible for invoking the underlying build engine (MSBuild) based on the build information retrieved from the build database. We'll discuss the MSBuild technology later in this chapter.

The Build Repository

The build repository is implemented by the Team Foundation Server data tier within its own SQL Server database called TfsBuild. This database contains more than 20 tables that store information related to build definitions, test results, and related work items.

As an example of the information stored here, Figure 23.3 shows the data model for a few of the core tables used to define a build.

Figure 23.3. Partial data model for the Build database.

Now that you have the fundamentals in hand, it's time to see how to manage the build process within the Visual Studio Team System.