Scale out your build system

To use Team Foundation Build for automated building and testing of your app, you must first set up a build server, add a build controller and a few build agents, and finally designate a drop folder. If you have a small start-up team working on a new project, you can probably deploy all these build system components on a single computer in a few minutes. As your team and your code base grow, you can expand your build system incrementally, with relative ease.

Here are some examples that demonstrate how you can start small and simple, and then later scale out the build system as your requirements become more demanding.

• Visual Studio Online with Hosted Build Controller

• Visual Studio Online with on-premises build servers

• Build system for trial usage or a very small team

• Build system for a small team

• Multiple-build-server systems

• Build system to support multiple team project collections

• Next Steps

Visual Studio Online with Hosted Build Controller

If your team project collection is hosted on Visual Studio Online you might be able to use the Hosted Build Controller instead of deploying your own build servers.

See Use the Hosted Build Controller in a team project collection hosted on Visual Studio Online.

Visual Studio Online with on-premises build servers

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.

Build system for trial usage or a very small team

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.

Build system for a small team

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.

Multiple-build-server systems

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.

Build system to support multiple team project collections

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.

Next Steps

• 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.