Visual Studio Team Build

One of the goals of VSTB is to provide a "build lab out of the box" experience. Sure, you can press F5 to get that developer build out, but getting a good public "team build" is a difficult task. That's because you are building all source code in the team project, including changes by the entire development team, on a separate build machine.

A typical public build involves many steps, including cleaning the remote build machine, getting the sources from the source control on the build machine, compiling, running static analysis, running the build verification or post-build tests, and then communicating the build result to the project team. You might be doing something similar in your build scripts. What VSTB provides is a simple way to kick-start this build process. You go through a simple five-page wizard, and what you generate is a build script.

Figure 18.2 shows a screenshot of the wizard that helps you do this.

Figure 18.2. VSTB setup.

This build script automates the entire build process and more. After you have an out-of-the-box build process running out of VSTB, you can edit the build script if you need to further customize or extend the process. To provide this end-to-end integration, VSTB integrates seamlessly with other VSTS tools, such as Team Foundation Source Control, Team Foundation Work Item Tracking, and Team Test.

When the build process is over, a comprehensive report is generated with information about the build result and the general health of the build. Some of the things included in the report are the number of errors and warnings for each build configuration with links to the log files, results of the test runs included in the build, a list of change sets that went into the build, and who checked it in (which could be used to detect the cause of build failure). Other information, such as the code coverage of the tests and work items associated with the build, is listed (which could be used to determine the quality of the build). The report has active links to change sets, work items, and test results for further details.

Let's examine a scenario to illustrate this a little better. A developer has just looked at a work item assigned to him and fixes his code. While checking into Team Foundation Source Control, he associates the work item with the check-in. VSTB picks up the source for the nightly build, and as a post-build step, it updates the Fixed In field of the work item with the build number. The generated build report lists all the work items that were associated with this build. The tester looks into it to make sure the work item opened by her was resolved in this build and installs the build for further investigation. This is a small example of an integration pointing among the Team Foundation Source Control, Work Item Tracking Tool, and VSTB.

Figure 18.3 explains the VSTB flow.

Figure 18.3. VSTB architecture.

But what if your organization has some extra steps beyond what VSTB provides out of the box? Fortunately, you can customize VSTB to suit your needs. The underlying build engine is MSBuild, and most of the steps in the build process are MSBuild tasks. All that you need to do is write an MSBuild task that executes the extra steps and include it in the build script that the wizard generates. Through some simple editing, you can specify the order in which this custom step needs to run.

Did you find the information on VSTB interesting? The information is taken from the Team Foundation blog at http://blogs.msdn.com/Team_Foundation. If you go to this site, you will find more incredibly useful information. One thing to note is that VSTB is being designed to work with MSBuild.exe and no other build tool. So before you get excited about adopting it, and unless the specs have changed, you had better roll out MSBuild before spending much time on this tool.