Deploy and configure a build server
To use Team Foundation Build (TFBuild) with an on-premises Team Foundation Server, you must deploy at least one build server.
If your team project collection is hosted on Visual Studio Online 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:
A single build controller
One or more build agents
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.
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 Permission reference for Team Foundation Server.
What do you want to do?
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.
You deploy a build server by installing the Team Foundation Build Service. Before you begin this process, here are some tips:
You can connect a TFBuild 2010 or TFBuild 2012 server to your on-premises Visual Studio Team Foundation Server 2013 application-tier server.
You cannot run Visual Studio Team Foundation Server 2013 TFBuild on the same computer as TFBuild 2012 or TFBuild 2010.
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 Set up 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 Set up Team Foundation Build Service.
After you deploy your build server, you can configure it to meet your team’s needs.
Log on to the build server that you want to configure.
From Windows Start, run Team Foundation Administration Console.
The Team Foundation Administration Console appears.
In the tree pane, expand the name of the server.
Choose the Build Configuration node.
If the message Configure Installed Features appears instead of a build controller or build agents, as shown above, see Deploy a build server.
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.
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 Visual Studio Online.
You can strengthen security by using Hypertext Transfer Protocol Secure (HTTPS) with Secure Sockets Layer (SSL). See Set up HTTPS with Secure Sockets Layer (SSL) for Team Foundation Server.
Under Run the Service as you can specify the accounts that enable the build server to provide its services.
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.
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.
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 Visual Studio Online: When you connect your on-premises build server to Visual Studio Online, then the Use same identity as Windows Service check box is automatically cleared and the account you used to connect to Visual Studio Online (for example, a Windows Live account) is specified beneath it.
For most purposes, you should run your build server as a Windows service, which is the default setting. However, there are a few tasks (for example running coded UI tests or running tests on a Windows Store app) 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
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.
On the Build Service Properties dialog box, choose Stop the service.
Under Run the Service as, choose Change, and then specify the credentials of the build service account.
Select Run the Service interactively.
Choose Start, and then choose OK.
Leave the build service account logged on to the build server.