Team Foundation Build

Team Foundation Build

In addition to writing and running various quality and performance tests, another facet of the software development life cycle that often applies to developers is that of building the application(s). To have a successful software development life cycle project, it is important to employ an automated build system that should support the ability to build the software project at scheduled intervals as well as the ability to revert back to a previous build. A typical build scenario requires the need to execute tasks other than compilation only; for example, running unit tests as part of the build and deploying the compiled bits to a central location. Prior to Team System, this proved very difficult, if not impossible, to support in Visual Studio.

NOTE
Team Build is actually part of Team Foundation Server and thus applies to everyone on the team—regardless of role; hence the name Team Foundation Build. As a feature, it's at the same level as work-item tracking and version control, so it is available throughout the various Visual Studio Team System editions.

Open source tools, such as Nant, made a splash in the development community in their ability to support complicated build processes. Nant is a build tool framework that executes builds based on a set of instructions and tasks defined in an XML-based script. A task might include getting the latest source code from the source code repository, executing a set of unit tests, or copying files from one location to another. Nant was successful as a build tool because it had the ability to execute tasks, in a defined sequence, other than just compilation. The true reason why it was such a success, however, was because it was extensible. If a particular task didn't exist to support a step in your build process, you had the opportunity to create it and plug it into the Nant build framework. With its strong community backing, Nant provided a significant number of tasks to support complex build scenarios.

MSBuild is Visual Studio's new build engine that is very similar to Nant. As with Nant, MSBuild executes builds based on a set of instructions and tasks defined in an XML-based script. MSBuild is also extensible and supports a wide range of tasks to build your .NET solutions. The difference between Nant and MSBuild is that MSBuild is supported by Microsoft and will ship with the .NET Framework and eventually the OS. Team Foundation Build takes the MSBuild engine and extends it into a full build automation system.

Team Foundation Build is a flexible and extensible build automation system that forms a tight integration with the Team System tools. Team Foundation Build executes builds that are defined by a combination of scripts defined under a structure called a Build Type. You can define a number of build types for your Team Project to support various scenarios such as full builds, partial builds, nightly builds, incremental builds, and so on. Team Foundation Build includes an easy-to-use wizard interface to create your initial build types. The build type definition lays out a sophisticated build process that includes the following steps:

1. Get source files from version control

2. Run static analysis

3. Compile sources

4. Execute unit tests

5. Update work items

6. Calculate code coverage

7. Calculate code churn

8. Generate build reports

9. Drop binaries into predefined location

NOTE
If all of your requirements are not fully supported by the default build type, you have the opportunity to modify and extend the process to fit your needs. Be sure to read Chapter 9 for more information.

At the conclusion of a build, Team Foundation Build produces a comprehensive report that outlines the general health of the build. Some of the items reported might include the changesets included in the build, errors and warnings from the compilation process, unit test results, code coverage, and static analysis results. As your project progresses over time, the combination of build reporting data allows you to monitor and track your product quality from the early stages of development to the day you deploy your application. With its integrated features and comprehensive reporting capabilities, Team Foundation Build provides a richer implementation model for building .NET applications over other tools such as Nant.

Build Type

Utilizing Team Foundation Build for your build process begins with the creation of a build type, which is a set of files that combine to define the conditions under which a solution or set of solutions is built. The build type maintains a set of parameters that informs the build service how to perform the build. These parameters include information such as which solution or set of solutions to build, which solution configurations to use, what build machine to use, where to perform the build, where to copy the build output to, what tests to perform (if any), and whether or not to perform code analysis.

Creating a Build Type

Creating a build type begins by invoking the New Team Build Type Creation Wizard. (See Figure 6-22.) This wizard can be launched from the Team Build node in Team Explorer or from the Build menu. The first step in creating a build type is defining a name for the build type, for which Team Foundation Build will uniquely identify this build with the other build types defined for your Team Project.

Build types are defined to build a solution or set of solutions in your Team Project. The solutions that are available to be included in a build type are the ones that exist in the version-control system for your Team Project. Figure 6-23 shows the Solution Selection page of the wizard. Solutions are listed based on a selected workspace. After a workspace has been selected, the solutions found within that workspace are listed. You have the option to select one or more solutions to participate in this build. The solutions will be built based on the order they appear in this list. Solutions that depend on one another should be placed in the correct order. For example, if Solution1 depends on Solution2 to be built before it, you must move Solution2 to the top of the list by highlighting Solution2 and using the arrows to position it within the list.

Figure 6-22 New Team Build Type Creation Wizard provides an interface to defining the build steps and parameters needed to perform a build

Figure 6-23 Solutions are listed based on the specified workspace, and selected solutions are built sequentially based on the order they appear in the list

A Visual Studio solution maintains one or many configurations that define various parameters and have a direct effect on how projects within the solution are built. Each configuration has a sole purpose in determining how the underlying compiler compiles the projects within the solution. These configurations define items such as conditional compilation constants and acceptable warning levels. Typical configurations that exist in any given Visual Studio solution are Debug and Release.

After the solutions have been selected for the build type, you have the opportunity to select which configurations of the selected solutions should be processed. (See Figure 6-24.)

The Team Foundation Build Service is a Windows service application that accepts requests from the Team Foundation Server to execute a specified build type. A build machine is defined as a machine in your build lab that is running the Team Foundation Build service. Figure 6-25 shows the page in the wizard in which you specify the build machine that will be responsible for executing the defined build type. You also specify a build directory that exists on the build machine. This build directory is the location that the build service will first synchronize the source files to and then execute the build against. A Universal Naming Convention (UNC) share called a drop location is specified as well. The drop location is where all of the built binaries and log files are copied to after the build has completed.

Figure 6-24 Select the configurations that should be processed for the defined build type

Figure 6-25 Select the appropriate build location

NOTE
Both the build directory and drop location must have significant permissions for the build to execute successfully. The user assigned to run the Team Foundation Build Service must have write access to each directory and write access on the share permissions for the drop location.

A successful build isn't one that just compiles; it should compile as well as pass a number of tests to verify the functionality performs as expected. A Build Verification Test (BVT) typically consists of a broad variety of unit tests that are used to verify the overall quality of a build. Figure 6-26 shows the list of options to include in your build process, including running tests and performing code analysis.

All the test metadata files defined in your Team Project are available for selection. After a test metadata file is selected, you can then choose which test lists to run as part of the build. In addition to running tests as part of the build, you also have the option of running code analysis, which checks conformance to design rules defined within your Team Project. The test results and code analysis results are collected and combined in the final build report.

Figure 6-26 You can optionally select to run a set of tests or perform code analysis

Executing a Build

To execute a build, click the Build menu inside Visual Studio and select Build {Team Project Name}. This displays the Build Configuration dialog box, in which you have the opportunity to select which build type you want to run. After you select a build type and click Build, a request is sent to the Team Foundation Server, which in turn sends the request onto the build machine specified in your build type. You can track the results of your build request or view the results of prior build requests on the Team Builds screen. (See Figure 6-27.)

Figure 6-27 Build results are shown with their status along with the date and time they were completed on

Viewing the Build Results

The Team Builds screen displays the build requests that have been processed, with their status and the date and time of completion. Builds that have completed will have a status of either Successfully Completed or Failed. To view the results of a build, double-click the particular build run you want to view. The build report then displays. (See Figure 6-28.)

Figure 6-28 The build report shows how your build fared

The build report displays a number of items, including the status of the build, the build machine on which the build was executed, the time the build started and completed, and the links to the drop location and the build log file. The build report also links the associated work items and changesets, as well as the results from any optional test runs and code coverage analysis.