Team Foundation Build has a straightforward architecture with three distinct layers. On the uppermost layer sits the role-based Visual Studio editions and the Team Explorer. Using these tools, you can tap into Team Foundation Server to manually launch or stop a build, edit build types, or view build run reports and logs. You can also view build reports from the reports node in Team Explorer or set up a Web part on the Team Portal. Visual Studio enables you to manipulate source code, work with work items, and schedule builds. Team Foundation Build's data infrastrure is laid out as follows: There is a data tier layer, which has the build store or the build database, where all the data is stored, and client side reports are generated from it. This data is also pushed to the overall TFS warehouse from which reports are generated using SQL reporting services.
Finally, you have the build server. You can install Team Foundation Build under many scenarios: as a desktop build engine, on the same server as Team Foundation Server, and on a standalone server. Microsoft recommends the standalone server scenario as a good option. This makes sense for several reasons, including the reduction of CPU load on the other components of Team System. If you want to run tests or static analysis, you additionally need to install the Team Edition for Software Testers or the Team Edition for Software Developers, depending on your requirements and the type of tests you need to run. Figure 23-1 illustrates the layout of Team Foundation Build's architecture.
Team Foundation Build's installer can be found in the build directory on the Team Foundation Server media (on CD or DVD)
Before you can deploy Team Foundation Build, you must first develop a strategy based on your needs. The outcome will determine how Team Foundation Build is configured, including security and build policies. Here are some of the factors you should consider:
Roles and Permissions. Within your team, you will have predetermined roles based on the RAPI model (see Chapter 22). Who within your team will be responsible for configuring the build server? You must determine who will have the rights to initiate a build, collect build metrics, change the build process, and so forth.
Policies. What is considered a successful build and what is considered an unsuccessful build? How should each of these cases be handled? When and in what way should a team member be notified of build errors? The determination of policies will be based on factors such as internal practices and mandatory standards compliance, such as Sarbanes-Oxley (SOX). Build policies go hand in hand with check-in policies.
Procedures. How often will you require a build? If you are a small Agile development team, then most likely you will lean toward frequent builds, every time a check-in is performed. Nightly builds may be suitable if you have a larger shop with millions of lines of code to manage. Do all builds require the same tests? What is your test failure threshold to fail a build?
Integration. How will Team Foundation Build integrate with your current development environment? This includes implementing buddy builds or continuous integration (CI). In the section that follows, you'll learn how Team Foundation Build integrates with the rest of Team System.
Microsoft likes to refer to Team Foundation Build as "your own private build lab." When you install Team Foundation Server, please note that Team Foundation Build is not installed automatically. You must consciously and purposefully install it. The installer is located on the Team Foundation Server installation media. In addition, you need a local administrator account on the target machine in order to install Team Foundation Build.
In the installer, Team Foundation Build is referred to as Team Foundation Server (build)
During the installation process, you have to provide the installer with account information such as the username and password. You should create a dedicated account with sufficient privileges to enable the TfsBuildService to successfully run. If you have misconfigured the build machine account, you can easily add the permission later and the Services Control Panel applet to set the service to run.
To perform test automation, you need to have the appropriate Team System role-based edition installed on the build machine. We recommend installing the Team Edition for Developers, as it contains important automated tests such as unit tests and static code tests.
After the install finishes, create two folders that will be used as part of the build process. The first one is the interim folder, called the build location, where Team Foundation Build will extract and build your solution. The second is the drop location, a shared folder that must be accessible over the network using the Universal Naming Convention (UNC) format (/server/shareddropfolder/). This folder must be given full permissions to the build service account and the Team Foundation service account (TFSSERVICE). The reason for this is twofold: First, if you don't share the folder, your team members will not be able to access the builds unless they have physical access to the build machine. Second, the build process will fail primarily because the drop location is the place where all build results, including test results, are published. In a scenario where a tester is manually publishing test results against this build, he or she would need to have permission to publish content on this folder. Hence, it is recommended that everyone have valid permissions on this folder. You can test whether the drop folder has been configured correctly by browsing to the folder over the network.
Team Foundation Build integrates with Team System in several ways:
Work Items Database. Team Foundation Build automatically creates work items when a build fails or annotates an existing work item with build information.
Team Foundation Version Control. The main integration points are as follows: to synchronize sources from source control, to label sources that were built, to get information regarding the changesets that went into a particular build, and to store the build type files. Team Foundation version control is the only supported source control system supported in V1. In order to use a third-party solution like Borland's StarTeam, you will build steps and replace the Source Control extraction step that is part of Team Foundation Build.
Team Explorer. Once a Team Project is created, build configuration and reports are integrated in the Team Explorer tree within a Team Builds folder. Using Team Explorer, you can perform many build tasks, such as initiating a build, creating build types, and viewing build reports.
Test Integration. Team Foundation Build integrates deeply with Team System Tests. You can incorporate tests such as unit testing, code coverage, and static analysis in the build process by creating test runs and associating them to a build.
Reporting Integration. Team Foundation Build provides holistic information about the health of your data, including how builds rank against historical data. Build information is automatically stored in the Team System data repository, including build configuration, errors, and status information.
Web Service Integration. Using the BuildStore and BuildController Web services, you can access status information and control the Team System build engine. These Web services are enabled via the Team Foundation Server. Please refer to the end of the chapter for more information.
Team Foundation Build has specific security rights and permissions built on top of Team Foundation Server's security groups. In fact, Team Foundation Build has a series of specific privileges to enable (or disable) functionality. The inclusion or omission of permissions will affect the Visual Studio 2005 UI. For example, if you are allowed to perform an action, the corresponding UI command button or option will be enabled. Here are a few of the more important build privileges you should be aware of:
Start a build. This allows a specific user to initiate a build using the build command-line tool tfsbuild.exe or using the UI. You have the choice of assigning this privilege level to an existing role or creating a specific account for the purpose of starting builds.
View project level information. This allows you to view reports and receive e-mail notifications from the build server.
Edit build status. This permission set allows you to change the build quality within the reports.
Administer a build. This permission set allows you to create, edit, and delete build configurations. When you are logged on to an account with these permissions, corresponding buttons are enabled in the Build Configuration dialog box. This permission set is also required for stopping and deleting builds.
Update build. This permission set allows you to add and update build configuration information. Specifically, it gives you write permissions.
For a list of build privileges, please refer to Chapter 19. The MSDN Documentation also offers extensive coverage under the Build Security Rights and Permissions heading.