Understanding a Team Foundation Build System

You can use Team Foundation Build to compile, test, and deploy your software in an automated and distributed system. This software is designed to support small "start-up" software efforts, in addition to mature software development enterprises. The system is designed to help you scale out your build system as your team and code base grow.

In this topic

• Build Machines

  • The Team Foundation Build Service

  • Using Virtual Machines as Build Machines

• The Build Controller

• The Build Agent

• Build System Topology Examples

• Next Steps

Build Machines

To use Team Foundation Build, you must have at least one build machine. For any medium or large software effort, you will probably need multiple build machines. Later in this topic, examples of several build system configurations are offered.

A build machine is a computer on which you have installed and configured Team Foundation Build Service. The machine can be a physical machine (for example, a personal computer that is sitting under your desk or a workstation in a lab). You can also take advantage of the flexibility of a virtual machine to serve as a build machine.

Although you configure, modify, and manage a build machine directly on the computer where Team Foundation Build Service is running, the configuration data itself is stored in the team project collection.

The Team Foundation Build Service

To set up a build machine, you install, configure, and run Team Foundation Build Service.

Team Foundation Build Service is a Windows service that is listed in different locations within the operating system. Where it is listed depends on whether Team Foundation Build Service is running as a Windows service or an interactive service. (For more information about how to set this option, see Configure a Build Machine.)

When Team Foundation Build Service is running as a Windows Service:

• In the Services node, Team Foundation Build Service is listed as Visual Studio Team Foundation Build Service Host. You can view the Services node in one of the following locations:

  • On a server operating system (for example, Windows Server 2008) in Server Manager

  • On a client operating system (for example, Windows Vista) in Computer Management

• In Task Manager, Team Foundation Build Service is listed as Visual Studio Team Foundation Build Service Host on the Services tab.

When Team Foundation Build Service is running as an Interactive Service:

• In Task Manager, Team Foundation Build Service is listed as TFSBuildServiceHost on the Applications tab.

Using Virtual Machines as Build Machines

You can deploy Team Foundation Build Service on a virtual machine (for example, a Hyper-V virtual machine that is running on a physical computer that is running Windows Server 2008). By taking this strategy, you can easily perform the following tasks:

• Re-build the system from any state and any point in time. For example, if the system becomes corrupted, you can quickly revert to a snapshot of a clean environment and re-build the system.

• Take a snapshot of a virtual machine, export it, and then archive it or share it with another member of your team.

The primary disadvantage of using a virtual machine is that it does work more slowly than a physical machine. If the amount of work that your builds require is small or if you run builds infrequently (for example, nightly), a virtual machine might suffice as a build machine in your system.

You can perform the following tasks to improve the performance of Team Foundation Build Service when it runs on a virtual machine:

• Run your virtual machines on a physical machine that has a multi-core processor. If, for example, your physical machine has a quad-core processor, you could run four virtual machines at the same time, and they will perform reasonably well as build machines for many situations.

• Dedicate and mount a physical hard disk to each virtual machine.

The Build Controller

Each build controller is dedicated to a single team project collection. The controller accepts build requests from any team project in a specified team project collection.

Each build controller pools and manages the services of one or more build agents. It distributes the processor-intensive work (such as compiling code or running tests) to the build agents within its pool.

The build controller processes the workflow and typically performs mostly lightweight work such as determining the name of the build, creating the label in version control, logging notes, and reporting status from the build.

Because a build controller does not typically require significant processor time, a virtual machine is often sufficient to serve as the platform for a build controller. However, a build controller can demand a significant amount of memory in certain situations. Therefore, you should make sure to provide sufficient memory to the physical machine or virtual machine on which you set up your build controllers.

The Build Agent

Each build agent is dedicated to and controlled by a single build controller. The build agent does the processor-intensive and disk-intensive work. This work includes getting files from and checking files into version control, provisioning the workspace, compiling the code, and running tests.

When you assemble a build system, you can start with a few agents. You can then scale your build system out by adding more build agents as you add team members, as your code base grows, and as the work that must be done by your build system increases.

If you set up your agents to have specialized capabilities, you should assign tags to those agents. By following this strategy, you can then create build definitions that can use these specialized agents. For example, you could apply the BVT tag to a pool of agents that are designed to run your BVT tests. You could then define a nightly build to use only these build agents.

Because build agents do most of the processor-intensive work, you should make sure that the build machine has sufficiently powerful hardware to enable the build agent to do the work in an acceptable period of time.

Build System Topology Examples

Team Foundation Build Service is designed in a way that you can start with a smaller, less complex build system. As your code base expands and your team grows larger, you can expand your system incrementally with relative ease by adding build machines to the system that you already have.

Single-machine system (shared with application tier)

The following configuration can support a very small team, especially a team that runs builds infrequently and only during off-hours. (For example, you run only a single nightly build.)

In most cases, a topology with a single build machine is insufficient because of the following reasons:

• The build agent places heavy demands on the processor, which could significantly decrease the performance of your application tier.

• The build controller can exert pressure on the system's memory, especially if the controller is managing many active build agents at the same time.

• Installing Team Foundation Build Service increases the attack surface of a build machine. For example, a malicious user could construct a build definition to run arbitrary code to take control of the server and steal data.

Single-machine system (stand-alone)

The following configuration is good starting point for a small team.

Because build agents perform the processor-intensive work on a separate machine, they do not affect the performance of the application tier when builds are run.

You could also run the build controller on the dedicated build machine. However, the configuration in the illustration has the advantage of making build system changes less disruptive, such as when you must repair or replace the build machine.

The build controller's presence on the same machine as the application tier is generally not a problem from a processor standpoint. However, you might move up to a more scalable topology for the following reasons:

• The build controller can exert pressure on the system's memory, especially if the controller is managing many active build agents at the same time.

• Installing Team Foundation Build Service increases the attack surface of a build machine. For example, a malicious user could construct a build definition to run arbitrary code to take control of the server and steal data.

Multiple-machine system

Medium and large teams will generally need multiple build machines to support their efforts. In the following example, two build machines are deployed.

By using multiple build machines, you can dedicate each machine to a different purpose, as described in the following example:

• One build machine could be dedicated to build agents that process continuous integration builds. The team needs these kinds of builds (especially gated check-in builds) to run quickly so that their work is not held up waiting for a build. You would use build process parameter settings to ensure that builds run quickly. These settings could include not cleaning the workspace, running only top priority tests, and setting a low value for the Maximum Execution Time setting.

• Another build machine could be dedicated to scheduled and ad-hoc builds that require a lot of time to process. For example, you could set up the build definitions that target the build agents on this machine so that the definitions clean the workspace, perform all tests, and run code analysis.

Multiple-machine system with multiple controllers

The following topology example can support enterprise-level software efforts.

Each team project collection must have its own build controller, as shown in the illustration. Notice how this topology isolates the build machines. Team members who work on Team Project Collection A can use only the build agents that Build Controller A controls.

Next Steps

Now that you understand how a Team Foundation Build system works, you are ready to take the next steps:

• Configure Your Build System

• Manage Your Build System