Team Foundation Build Service is designed in a way that you can start with a smaller, less complex build system. As your code base expands and your team grows larger, you can expand your system incrementally with relative ease by adding build machines to the system that you already have.
Single-machine system (shared with application tier)
The following configuration can support a very small team, especially a team that runs builds infrequently and only during off-hours. (For example, you run only a single nightly build.)
In most cases, a topology with a single build machine is insufficient because of the following reasons:
The build agent places heavy demands on the processor, which could significantly decrease the performance of your 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 a build machine. For example, a malicious user could construct a build definition to run arbitrary code to take control of the server and steal data.
Single-machine system (stand-alone)
The following configuration is good starting point for a small team.
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 machine. However, the configuration in the illustration has the advantage of making build system changes less disruptive, such as when you must repair or replace the build machine.
The build controller's presence on the same machine as the application tier is generally not a problem from a processor standpoint. However, you might move up to a more scalable topology for the following reasons:
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 a build machine. For example, a malicious user could construct a build definition to run arbitrary code to take control of the server and steal data.
Multiple-machine system
Medium and large teams will generally need multiple build machines to support their efforts. In the following example, two build machines are deployed.
By using multiple build machines, you can dedicate each machine to a different purpose, as described in the following example:
One build machine could be dedicated to build agents that process continuous integration 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. You would use build process parameter settings to ensure that builds run quickly. These settings could include not cleaning the workspace, running only top priority tests, and setting a low value for the Maximum Execution Time setting.
Another build machine could be dedicated to scheduled and ad-hoc builds that require a lot of time to process. For example, you could set up the build definitions that target the build agents on this machine so that the definitions clean the workspace, perform all tests, and run code analysis.
Multiple-machine system with multiple controllers
The following topology example can support enterprise-level software efforts.
Each team project collection must have its own build controller, as shown in the illustration. Notice how this topology isolates the build machines. Team members who work on Team Project Collection A can use only the build agents that Build Controller A controls.
Extracted from : - http://msdn.microsoft.com/en-us/library/dd793166.aspx
No comments:
Post a Comment