Deploy and Configure a Build Server

To use Team Foundation Build with an on-premises Team Foundation Server, you must deploy at least one build server.

Tip

If your team project collection is hosted on Team Foundation Service and your team’s needs can be met by a single standard build agent, you can use the Hosted Build Controller instead of deploying your own build agent.

Each build server serves a single team project collection. In fact, although you configure, modify, and manage a build server directly on the computer where Team Foundation Build Service is running, the configuration data is stored in the team project collection.

On a build server, you can run:

1. A single build controller

2. One or more build agents

3. A single build controller and one or more build agents

You can host a build server on the same computer as your Team Foundation Application-Tier Server, but, in most of these situations, this build server should not host any build agents. Build agents place heavy demands on the processor, which could significantly decrease the performance of your application tier. In addition, you might want to avoid running build server components on the application tier to avoid increasing the attack surface. For more detailed examples of viable build system topologies, see Scale out Your Build System.

Required Permissions

You must be a member of the Windows Administrators group on the build server and a member of the Project Collection Build Administrators group on your team project collection. See Team Foundation Server Permissions.

What do you want to do?

• Understand security risks

• Deploy a build server

• Begin configuring a build server

• Connect a build server to a team project collection

• Specify service accounts

• Run your build server in interactive mode

• Take next steps

Understand security risks

Installing Team Foundation Build Service increases the attack surface of the computer. Because developers are treated as trusted entities in the build system, a malicious user could, for example, construct a build definition to run arbitrary code that is designed to take control of the server and steal data from Team Foundation Server. Customers are encouraged to follow security best practices as well as deploy defense in-depth measures to ensure that their build environment is secure. This includes developer workstations. For more information regarding security best practices, see the TechNet Article Security Guidance.

Deploy a build server

You deploy a build server by installing the Team Foundation Build Service. Before you begin this process, here are some tips.

Have you installed Visual Studio 2012 Update 2 CTP on your on-premises application-tier server?

• Yes

  • You can connect a Team Foundation Build 2010 server to your on-premises Team Foundation 2012 application-tier server.

  • You cannot run both Team Foundation Build 2010 and Team Foundation Build 2012 on the same computer.

• No

  • Only a build server that is running Team Foundation Build 2012 can connect to Team Foundation Server 2012 application tier.

  • Although a build server that is running Team Foundation Build 2010 cannot connect to your application tier, you can run both Team Foundation Build 2010 and Team Foundation Build 2012 on the same computer.

    Note

    Upgrade template builds might not function correctly in this kind of side-by-side configuration.

Some more tips:

• If you install the build service while you are logged on as a member of the Project Collection Administrators, the installation automatically adds the build service account to the Project Collection Build Service Accounts group, so you don't need to do it manually.

• You can replace an existing build server by copying its configuration to the new build server. See Install Team Foundation Build Service.

• You can set up an ad-hoc build server on any client or server computer that has adequate processing and storage capacity. For example, an individual developer who has an extra computer could set it up as a build server.

• You can deploy a build server on a physical computer or a virtual machine.

For step-by-step instructions to deploy a build server, see Install Team Foundation Build Service.

Begin configuring a build server

After you deploy your build server, you can configure it to meet your team’s needs.

1. Log on to the build server that you want to configure.

2. From Windows Start, run Team Foundation Administration Console.

   The Team Foundation Administration Console appears.

3. In the tree pane, expand the name of the server.

4. Choose the Build Configuration node.

   

   Note

   If the message Configure Installed Features appears instead of a build controller or build agents, as shown above, see Deploy a build server.

5. Choose Properties.

   

   The Build Service Properties dialog box appears.

   

   Before you can configure the build server, you must choose the Stop the service link. See the sections below for details about how to configure your build server.

Connect a build server to a team project collection

Under Communications, next to Provide Build Services for Project Collection, choose the Browse button to connect your build server to a team project collection on an on-premises Team Foundation Server or on Team Foundation Service.

You can strengthen security by using Hypertext Transfer Protocol Secure (HTTPS) with Secure Sockets Layer (SSL). See Setting up HTTPS with Secure Sockets Layer (SSL) for Team Foundation Server.

Specify service accounts

Under Run the Service as you can specify the accounts that enable the build server to provide its services.

Specify the build service account

Immediately under Run the Service as, you can specify the build service account.

NETWORK SERVICE account

For most purposes, the best setting is NT AUTHORITY\NETWORK SERVICE.

One advantage of this approach is that if someone changes the password of a user account (some network administrators require such a change on a regular basis), the build server does not go offline.

User account

Occasionally, you might be required to specify a user account, such as NORTHAMERICA\FABBUILD.

Examples of situations where you must specify a user account include:

• You want to run your build server in interactive mode, as explained below.

• Your Team foundation Server is inside your firewall, but the build server is outside your firewall.

Regardless of the account you specify, the build service account must belong to the Project Collection Build Service Accounts group.

Specify the account used to connect to your Team Foundation Server

You can usually leave the second text box empty. However, in the following cases, your build server can't connect to your Team Foundation Server using the build service account.

Domain trust differences: The domain of the Team Foundation Server does not trust the domain of the build server. For example, the build server is in domainb, and Team Foundation Server is in domaina, which does not trust domainb. You could specify the build service account in the first box, and an account from domaina in the second box:

Team project collection hosted on Team Foundation Service: When you connect your on-premises build server to Team Foundation Service, then the Use same identity as Windows Service check box is automatically cleared and the account you used to connect to Team Foundation Service (for example, a Windows Live account) is specified beneath it.

Run your build server in interactive mode

For most purposes, you should run your build server as a Windows service, which is the default setting. However, there are a few tasks that a build agent can perform only on a build server that is running as an interactive process.

To run your build server in interactive mode

1. Identify the user account that will act as the build service account. The build service account must:

   • Be a member of the Windows Administrators group on the build server.

   • Be a member of the Build Service Accounts group on your team project collection. See Grant a Build Server Permission to Serve a Team Project Collection.

   • Have Change and Read privileges on the drop folder, if any, that you plan to specify in your build definition. See Select a Staging Location and Set Up a Drop Folder.

2. On the Build Service Properties dialog box, choose Stop the service.

3. Under Run the Service as, choose Change, and then specify the credentials of the build service account.

4. Select Run the Service interactively.

   

5. Choose Start, and then choose OK.

6. Leave the build service account logged on to the build server.

Next Steps

• Deploy and configure a build controller
  Use a build controller to perform lightweight tasks and distribute the processor-intensive work of your build process to its pool of 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. You host can one or more build agents on a build server.

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

• Scale out your Team Foundation Build system
  As your team and your code base grow, you can expand your build system incrementally, with relative ease.

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