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.
If your team project collection is hosted on Team Foundation Service, you might be able to skip all these steps, and use the Hosted Build Controller instead, as explained below.
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.
If your team project collection is hosted on Team Foundation Service you might be able to use the Hosted Build Controller instead of deploying your own build servers.
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.
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.