Team Foundation Build, Part 1: Introduction

This post was originally published here.

There’s been some interest recently for our team to utilize more features of Team System, including Team Foundation Build.  Rather than send out a blanket email, I’m following Jon Udell’s advice and maximizing the value of my keystrokes by posting a series of blog entries on this topic.

Visual Studio Team System introduced quite a few productivity enhancements for development teams including work items, process templates, reporting, source control, and builds.  Team Foundation Build is the build server component of VSTS.  Build definitions in VSTS are:

• Managed in Team Explorer
  • Represented by MSBuild scripts
    • Stored in Team Foundation Source Control
      • Executed on a build machine by the Team Build Service
        • Can be initiated through Team Explorer
          • Report results to Team System</ul> So why should we use Team Build over a home grown solution like batch files, Nant scripts, etc.?

          Centralized management

          All builds are defined, managed, and viewed through Team Explorer.  Since builds are stored in source control, we get all of the benefits source control provides, such as versioning, security, etc.  We also have one central repository to view and edit builds.  I can double-click a build definition to view all of the executed builds with status (success/failure), and drill down into a single build to view more details.  If I’m using ReSharper, I get IntelliSense and refactoring tools for MSBuild.

          Defined with MSBuild

          MSBuild is the new build platform for Visual Studio.  Project files (.vsproj, .vbproj, etc.) are now defined as MSBuild scripts.  Tasks in MSBuild are customizable and extensible, so I can define new tasks and use community built tasks.  Team Build definitions also allow extensibility points, similar to the ASP.NET page event model, by extending certain targets such as “BeforeGet”, “AfterTest”, and “AfterDropBuild”.

          Status and reporting

          There are usually two pieces of information I’m curious about when looking at builds:

          • What is the status of the current build? (In progress, successful, failed)
            • Is there a trend in the build statuses?</ul> All of this information can be seen through Team Explorer.  Additionally, I’ve seen tray icon applications that will display a red, yellow, or green light indicating the status of a certain build definition.

            Where do we go from here?

            In coming posts, I’ll discuss installation and configuration, defining builds, and outlining a set of values, principles, and practices Team Build can be used to encourage and enforce.  I’ll also outline some ideas on what kinds of build definitions are good to have, and what kinds of activities we might want to accomplish as part of our builds.