Inside VSTS

New Features in Team Build 2008

One of the best benefits of Team System 2008 are the Team Build improvements -- including wizards, new test and scheduling options, and much more. Find out what they can do for you.

• By Jeff Levinson
• 12/11/2007

The first and most obvious change is the new "wizard" for creating a team build (see Figure 1). Many of the improvements are embodied in this dialog. The Workspace tab allows you to pull source code from anywhere in TFS and gives Team Build its own workspace. You can also copy an existing workspace so you don't have to recreate everything from scratch. This option doesn't require any workarounds and solves the problem that developers had when trying to build across Team Projects.

There's also a new Retention Policy which lets you clean up the drop locations based on various conditions. In 2005, there was a frequent issue with the drop server running out of disk space, especially for teams using continuous integration. This is no longer an issue in 2008.

One the most requested features is the ability to run tests that aren't in a test list -- although you don't have as much control over which tests run. You can select an assembly that contains the tests you want to execute and all of the tests in the assembly will run against your code.

You can also specify build agents which execute the builds on different machines. While you could do this with TFS2005, you couldn't mark agents as enabled or disabled or configure the communications parameters with these agents. Now, you can.

In Figure 2, you can see the WithTests build and the NoTest build are running at the same time because they use different build agents on different servers. The tab at the bottom lets you switch between queued builds and completed builds. For completed builds, you can elect to delete them directly from Team System or you can lock them so they're retained indefinitely (and aren't cleaned up by the Retention Policy). You can also set the process priority if one build needs to run before other builds.

The biggest change, as shown in Figure 1, is the ability to schedule builds based on a variety of scenarios. "Build each check-in" is the Continuous Integration setting when you're dealing with smaller code bases. The "Accumulate check-ins" option triggers a build when the prior build has finished, and includes all of the check-ins up to when the build begins. This saves you from a massive backlog of builds that may not be kicked off until hours after your check in, which can be useful when the build takes a long time to execute or many developers are all doing check-ins at once. The last option is scheduled builds. Goodbye, Windows Scheduler! You can now do it all from within TFS.

Another nice change is the ability to edit a build by selecting "Edit Build Definition" in Team Explorer. Unlike 2005 which opened the raw XML file, this reopens the user interface and allows you to make changes (although you can and do still have to make changes to the actual TFSBuild.proj file, depending on your needs).

The last feature worth mentioning is the ability to put build projects anywhere you want to put them; they no longer have to be in the root of the team project. This can be a blessing and a curse, however. If you put the build on a code line and branch that code line (now you have two identical build definitions), only the original build definition will run as the build is linked to the TFSBuild.proj file. However, you can create a new Build Definition and point it to the branched TFSBuild.proj file. So branch the build files with caution and provide a naming procedure that helps identify the build and the branch that it's on!

With all of the new build features in TFS 2008, there should be no excuses not to use it. Automated builds help improve the quality of your code, let you pinpoint build errors more quickly and easily, and will help increase your confidence in your code.