Developer Product Briefs

Automate Your Build Process

Team Foundation Build provides an integrated solution for performing automated builds, testing, and reporting build results.

• By Jeff Levinson
• 07/24/2006

Automate Your Build Process
Team Foundation Build provides an integrated solution for performing automated builds, testing, and reporting build results.
by Jeff Levinson

July 24, 2006

Up until recently, Visual Studio had no automated way to perform builds. You could do builds within the IDE, but with virtually no options. And automating the build process required another development team to write an application to perform the builds. NAnt, the open source tool based on Ant, was the first viable option enabling VS developers to perform automated builds. NAnt is a good, solid tool, but it lacks the detailed knowledge of projects and has no knowledge of Team Foundation Server.

Now Visual Studio has its own build tools: MSBuild and MSTest, included with Visual Studio 2005 Professional Edition; and Team Foundation Build, part of Team Foundation Server. Team Foundation Build provides an integrated solution for performing automated builds, testing, and reporting build results. It's important to understand that Team Foundation Build relies on MSBuild and MSTest for most of its functionality, so any discussion about Team Foundation Build must include these tools. I'll start by looking at MSBuild.

MSBuild, the heart of Team Foundation Build, is the command-line tool included with Visual Studio 2005 Professional for performing automated builds. MSBuild accepts as one of its arguments a file that contains a series of tasks MSBuild performs. These tasks provide MSBuild its power. And whether you know it or not, you have used MSBuild.

To see how this works, create a new Console application in Visual Studio. Once you've created the project, open the .proj file in Notepad (see Listing 1). The project file is an MSBuild file, and it lists the various build configurations, the required references, and the items to compile.

Running MSBuild on a solution yields the results shown in Figure 1. Note that the command line used to execute Team Foundation Build is simply MSBuild. No parameters have been passed; MSBuild automatically searches the current directory for a file with the "proj" extension and acts on it. This build includes no unit tests; it is simply a build. Next, I'll show you what happens when you add unit tests to the project.

Automated Testing With MSTest
MSTest is the command-line tool included with Visual Studio 2005 Professional for running unit tests. It's a simple, straightforward tool that allows you to run specified unit tests or lists of unit tests. You can specify the test run configuration file, the file where results should be saved, and the Team Project and build you want to associate with the test run.

Once the unit tests are added to a project, you can run the automated tests using this command line: mstest /testcontainer:[test dll] /resultsfile:[result file location]. Note that in order to run this, you either need to provide the full path to the test container or run this from the directory where the unit tests compile to. The output is shown in Figure 2.

So now you've seen how to build projects using MSBuild and run automated tests using MSTest. The Team Foundation Build (TFSBuild.exe) command-line tool brings these tools and Team Foundation Server together.

Building With Team Foundation Build
Using Team Foundation Build requires that you have it installed on the machine where the builds will be run (this might be the development machine or another machine—for the purposes of these examples, I'll assume Team Foundation Build is installed on the same machine as the development machine). Team Foundation Build is a separate installation from Team Foundation Server.

Create a Team Foundation Build by expanding your project and the Team Builds folder from the Team Explorer pane. Right-click on the Team Builds folder and select New Team Build Type, which starts a wizard that guides you through the steps of creating a new build type (see Figure 3).

Once you create the new build, you can run it. A couple of things to note when you're going through this wizard: First, the account that the Team Build service is running under must have change access to the drop location. Second, the tests that run as part of the build must be in a test list (this is also a requirement for enforcing build verification tests). You'll see the status displayed during the build (see Figure 4).

It is critical to note that if you want to run unit tests, Team Edition for Software Developers or Team Edition for Software Testers must be installed on the build machine.

Once the build is done, you can examine the results and set the build quality. The results include build information (when the build started, how long it took, and so on), test results, code coverage results, associated changesets, and associated work items. Finally, you can view the results as a report. This means stakeholders can view these same details through SQL Server Reporting Services (see Figure 5).

You can use or purchase additional products (such as CruiseControl.NET, available on SourceForge.net) that enable you to implement a Continuous Integration process, which is critical for agile development methodologies. The idea of Continuous Integration is that whenever you change code and check it in, you should immediately perform a full build to ensure that you have no incompatibilities and that no other code breaks because of your changes. In addition, you need a completed build to publish test results because the results must be associated with a specific build.

Team Foundation Build is a huge help to Visual Studio developers who need to work together. This process should help developers get along better by not breaking builds, and ensure that errors are caught and fixed as early as possible in the process. Stakeholders will also gain major benefits because they can see how a project is shaping up and take action if necessary when a problem is detected. Overall, the improvement in visibility and quality will ensure cleaner, better software and better communication.

About the Author
Jeff Levinson is a solution design and integration architect at a Fortune 500 company. He is a Microsoft Architect MVP and holds the MCAD, MCSD, MCDBA, SCJP, and Security+ certificates. He is a coauthor of the new book, Pro Visual Studio 2005 Team System.