Professional Visual Studio 2005 Team System (Programmer to Programmer)

Overview

One of the biggest problems with most software development packages is a lack of integration between the build engine and the rest of the systems. As a project leader, deployment manager, or build manager, a lot of your time is spent writing build scripts and configuring your environment to try to integrate other "closed" systems and tools. Another challenge you might have to face is scalability: The build server has to be able to handle multiple requests from members of your team. MSBuild is meant to be used on a single machine and doesn't scale very well on its own. NAnt is a great .NET build tool, but it hasn't yet reached v.1.0 status at the time of writing (and therefore would not be a likely candidate for an enterprise environment).

When you are using Agile process methodologies, the build step is a key component of your project: The quality of your end product (the compiled code) is wholly dependent on the quality of your build. Agile methodologies typically advocate quick iterative cycles with an emphasis on avoiding "build breaks." Builds are produced every hour (depending on your churn and the size of your team, you might be rebuilding several times per hour). The resulting binaries serve as a yardstick for determining the health of a project.

Team System simplifies the integration of Visual Studio 2005 and the build system with Team Foundation Build. What are the differences between Team Foundation Build and MSBuild? MSBuild is a new build engine specially designed for Visual Studio 2005. Team Foundation Build, conversely, is a build automation tool that "wraps" around MSBuild to provide that end-to-end build experience. Using Team Foundation Build, you can automate your build tasks and generate rich metrics.

Here is a rundown of the typical execution steps using Team Foundation Build. In most scenarios, you would have to script these steps using other build engines:

• New builds are associated with a Team Foundation project and are created using a Wizard in Visual Studio. The Wizard leads you through all the steps necessary to set up a new build type. This includes generating an MSBuild XML file that represents the build script that is later executed, identifying the target location, and naming the build. The build scripts get checked into source control and synchronized with the build server, which may be different from the Team Foundation Server machine. One or more machines in team system environment may be designated as build servers.

• The build process is either started from the command line or initiated through the Team Foundation Build Client UI in Team Explorer. Team Foundation Build supports scheduling using the command-line build tool. The command-line options let the process be initiated using NT Scheduler for normal process scheduling. This process uses the StartBuild web method with a half a dozen parameters. Team Foundation Build can also support continuous integration scenarios, which are triggered in response to Source Code check-in events.

• The build request is sent to the Team Foundation Server. The builds do not execute on the Team Foundation Server machine, but are handled by the Build Server Machine that is set up to listen on the network for the build process to be run.

• The build server uses MS Build and MS Build Tasks to pull down source code and build scripts into a local workspace, carry out a build, and execute test suites. Any test can be run in the build process by defining a test list within the script. This can be done either through the wizard or by editing the wizard-created script directly. The test list and associated tests must be created before performing the build. Test lists can be defined under <TestingArgs> in the Team Foundation Build script as follows:

  <TestingArgs>/testmetadata: $(SolutionRoot)\SimpleApp\SimpleApp.vsmdi /testlist:BuildVerifyTest</TestingArgs>

• Test results (static analysis, code coverage) and build results (logged bugs) are sent to an operational data store. Test results are published and reported with the build results. All tests stored must be associated with a Team Foundation Build ID. This requires you to install Team Foundation Build and create and run a Team Foundation Build script in advance of publishing the test. (Team Foundtion Build is only required for test results. Work items, for example, do not require a Team Foundation Build ID.)

• Associated work items are then marked with the build number. New work items bugs are created for build failures. (Team Foundation Build maintains links to work items, reports change- sets that went into this build, and also maintains links to these changesets.) The default behavior for Team Foundation Build is to stop the build process should any step fail.

• The compiled code is copied to a drop location.

• A build report is published to the Team Project website using data from the Team Foundation Data Warehouse. The generating build name is based on the local server time.

The tight integration between Team System components provides an added benefit of automating many of your tasks. For example, a build report will be automatically generated and displayed on the Project Site via SQL Reporting Services once a build has been completed. Work items are updated automatically based on the results of a build. The build engine runs through a gamut of tests and enables you to integrate customized or generic tests in the process using Team Test.

These build steps are not etched in stone. You can customize the build process to fit your needs. You can also customize your build settings, tests, and reports. You'll learn more about Team Foundation Build customization later in the chapter.

Team Foundation Build can be launched manually, scripted to provide continuous integration during your development process, or set up to run nightly. Team Foundation Build can also be installed locally on your desktop or installed as part of Team Foundation Server. Using custom tasks and types, you can configure with a very high level of granularity your builds on a per-project basis.

In this chapter, you'll learn the important features of Team Foundation Build. You'll first find out how to set up the build engine, including planning a build strategy and setting up build security. Next, you will learn the tasks for the day-to-day operations of Team Foundation Build, such as creating build types, configuring e-mail notifications, and running builds. You will get a good overview of the command-line tools you can use, and learn how to leverage the tools in setting up your recurring build schedules (such as nightlies and short iterative builds). Team Foundation Build has effective reporting features to help you determine the health of a build. Finally, the chapter covers Team Foundation Build extensibility, and you will learn how to program and configure Team Foundation Build using XML configuration files and the .NET API.

Without further ado, you can begin with the preliminary setup of Team Foundation Build.