Every developer knows that builds are an integral piece to the Application Lifecycle. Using an automated build and testing process will help speed the time to market for your application. Visual Studio and Team Foundation Server offers a number of features to help with this process.
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 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.
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.
Microsoft Azure has introduced a new service called Build and Deployment. This service uses hosted agents and provides a wider range of capabilities because it will also allow you to deploy software using the Release Management capabilities Microsoft is developing in Visual Studio Online. Authoring Release Management pipelines will be sold separately (per user) and Microsoft will begin previewing this aspect of the service soon. Currently this requires an MSDN subscription (Visual Studio Test Professional with MSDN, MSDN Platforms, or Visual Studio Enterprise with MSDN) because you need to download and install the Release Management client in order to configure release pipelines.
For more information on the new service and pricing, visit here.
If you’d like more information on Azure DevOps, contact us at Perficient and one of our 28 certified Azure consultants can help you envision your complete Azure powered ALM solution.
