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.
Tip
|
|---|
|
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.
See Use the Hosted Build Controller in a team project collection hosted on Team Foundation Service.
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 Team Foundation Service.
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 Install 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.
