Introduction to Team Build 2008 for Team Build 2005 Users

If you haven't already gotten a chance to play with TFS 2008 (Beta 2), I recommend it.  My experience is that it is solid and seems to work better than the RCs worked for the 2005 release.  My primary interest is in the Team Build enhancements, although there are a few other interesting TFS 2008 features such as Destroy and the integration of key TFS Power Tool elements.

From a Team Build perspective, the basic build concepts with 2008 are similar to 2005.  It is still an integrated lifecycle build process layered on top of MSBuild.  It does have some significant architectural changes and features that make it a far more compelling tool.

From an architectural standpoint, infrastructure supporting build has evolved.  The team build service is still installed on your build server(s) and listens on a TCP port using .NET remoting.  The service does very much the same thing that it did in 2005; that is, listen for build requests from the associated TFS and then work with the TFS to perform the build process.  It still uses a TFSBuild.proj file with MSBuild to drive the build process and a TFSBuild.rsp file to provide the command-line MSBuild overrides.

The contents of the TFSBuild file are somewhat changed although they seem to be compatible with the existing project but some of the properties seem obsolete. and other items and properties have been enhanced.  Here are some differences I've noted:

• BuildMachine is not used anymore.  If you create a new build in Team Build 2008, this property is set to "UNKNOWN".
• BuildDirectory is also not used and defaults to UNKNOWN.
• DropLocation is also not used.
• SolutionToBuild now has additional item metadata to allow specification of explicit Targets and Properties.

There is a moderate selection of other new properties exposing additional capabilities as well as the usual suspects.  Amongst the new configuration properties that I like are IncrementalGet and IncrementalBuild.  Setting these two properties to true may significantly increase the speed of your team builds by maintaining a workspace and only getting deltas of changes files between builds, and by only compiling projects which have changes.  This is certainly useful for Continuous Integration or similar build models that have a high build frequency.  You may well still omit these properties or leave them false if you are concerned about workspace integrity or tampering on the build machine.

If you've been paying attention, you'll notice that previously critical properties such as BuildMachine are now gone and that I have omitted mention of the WorkspaceMapping.XML file!!!  The reason for this is that Team Build has been restructured such that this data is stored elsewhere.  We used to have "Build Types" which were indicated by folder name under the TeamBuildTypes folder at the root of version control in each team project.  Team Build 2008 uses "Build Definitions" which contain this meta data and point to the TFSBuild.proj file.  This has a side effect of allowing you to carry your TFSBuild.proj file with your solution(s) which allows them to easily follow your branching strategy.

The primary elements in a build definition include:

• The name and description of the build definition.  These are located on the General tab of the build definition dialog.
• The Workspace mapping for the build.  Since this is separate from the TFSBuild.proj file, it is possible to have multiple build agents  with different workspace mappings using the same TFSBuild.proj.  Or in other words, I can have two related branches with branched versions of the same build file (e.g., $/.../Test/TFSBuild.proj and $/.../Dev/TFSBuild.proj) which effectively specify the same build process but are managed by two different build definitions with their own workspace mappings. It is nice to have a UI to manage workspaces instead of just an XML file:
  
• Of course, you still need a reference to the Project File, which points to your TFSBuild.proj file in version control.  If you don't already have one, you can create one using a wizard similar to the build type wizard for Team Build 2005.
• These is a new Retention Policy capability in Team Build 2008 allowing you to specify how many recent builds to keep before they are automatically deleted.  For Team Build 2005 you had to manually clean up old builds using "TFSBuild DELETE", custom code or other hacks.  Now you can simply specify how many recent copies of the build to keep based on the build outcome (i.e., Failed, Stopped, Partially Succeeded, or Succeeded).  Regardless of the retention policy you can lock builds manually if they are of interest to protect them from being deleted.
  
• The Build Defaults are specify the default Build Agent and Drop Location.  The Build Agent is another new construct which is used to define the build server, the communications settings, and the working directory for the build.  The first time you create a build definition in a team project you'll need to create a new build agent definition; after that you can reuse it for any other build definition in the team project:
  
• The last portion of the build definition wizard specifies the Trigger settings.  This allows you to define if and when builds should automatically start.  By default, builds will be manually started just as they are in the out-of-the-box Team Build 2005.  However, by just setting a radio button and perhaps a few other setting you can schedule builds or do automated build based on check-in.  In fact, you can easily specify batched builds where a series of checkins can be batched into a build or one-to-one checkin to build.  The ability to actually do one-to-one builds against checkins is facilitated by build queuing.  Team build still only supports one build per team project per agent at a time, but it now supports the ability to request a build and if it can't be done because the agent is busy, it will be queued up and the build will take place when the agent becomes available.  This little feature was rare in some of the available Team Build extensions which provided Continuous Integration for TFS 2005.  With it in place, Team Build can now determine exactly who to assign a bug to when build breaks!
  

Another improvement over Team Build 2005 is that you can now maintain portions of the build process using a user interface instead of purely through XML files.  The TFSBuild.proj file is still maintained using an XML file editor, but the build definition and build agents can both be maintained using a user interface!

There are certainly other changes in Team Build 2008, but this should summarize all of the significant change.  I rarely recommend prerelease software for any of my clients.  However due to the vast enhancements in Continuous Integration support (i.e., triggers, queuing and retention policies), both my company and one of my customers are using TFS 2008 Beta 2 and it's go-live license.  Note that for my client, the users are still using Visual Studio 2005 and Team Explorer 2005...  but the Team System back end is all 2008!

Give it a look... And enjoy!