If your team project collection is hosted on Visual Studio Online and your team needs larger scale or customized build agents, you can connect your on-premises build servers to Visual Studio Online.

If you are using Team Foundation Server on a trial basis or work on a very small team, the following topology might work for you.

This topology might work for a team that runs builds infrequently and only during off-hours, such as a team that runs only a single nightly build. However, for many teams, it is insufficient because:

• The build agent places heavy demands on the processor, which could significantly decrease the performance of the 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 the computer. See Build Server: Understand security risks.

If you work on a small team with an on-premises Team Foundation Server, consider this topology:

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 server. However, the topology in the illustration has the advantage of making build system changes less disruptive, such as when you must repair or replace the build server.

As the size of your team and your code base increases, you can incrementally add resources to meet your requirements. For example, you could add an additional controller and build agents.

The presence of Build Controller A on the same machine as the application tier is generally not a problem from a processor standpoint. However, you might move the build controller to another server because of the memory pressure and attack surface issues mentioned previously.

By using multiple build servers, you can dedicate each server to a different purpose, as described in the following examples:

• A build server on a high-performance computer dedicated to build agents that process continuous integration or gated check-in 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.

• A build server dedicated to nightly scheduled BVT builds that require a lot of time to run processes such as large test runs and code analysis.

• A build server prepared and dedicated to specialized tasks such as building and testing a Windows Store app.

Tip
In scenarios such as these you can apply tags to specialized build agents and then constrain your build definitions to use only build agents with the correct set of tags. See Assign tags to represent build agent capabilities or purposes, Specify Which Build Agents Process Your Build for a simple default build process, and Run activities on the build agent for an advanced custom build process.

The following build system topology example could support an enterprise-level software effort.

Each team project collection must have its own build controller, as shown in above. Notice how this topology isolates the build servers. Team members who work on Team Project Collection A can use only the build agents that Build Controller A controls. This constraint could be useful in situations where you need to tightly control access to more sensitive intellectual property.

Deploy and work with a build server

To use Team Foundation Build with an on-premises Team Foundation Server, you must deploy at least one build server. You can also connect one or more on-premises build servers to Visual Studio Online.

Tip
As you scale out your system, you can replace an existing build server when you deploy a new build server. For example, you might want to host the same configuration and set of build controllers and build agents on a new, more powerful computer. See Set up Team Foundation Build Service.

Deploy and configure a build controller

Use a build controller to pool one or more build agents. You can host one build controller on a build server.

Deploy and configure build agents

Use a build agent to do the processor-intensive work of your build, includes getting files from version control, provisioning the workspace, compiling the code, and running tests.

Set up drop folders

You can prepare and then designate one or more drop folders so that your build system can deliver binaries, test results, and log files to your team.

Manage your build system

After you deploy your build server, you can manage it from the Team Foundation Administration Console. You can manage the build controller and build agents from either Team Foundation Administration Console or from Visual Studio.

Use Team Foundation Build

With your build system in place, your team is ready to create a simple build process (for example, a continuous integration build) and benefit from automated building and testing of your app.