Inside TFS

Creating a Build Definition in TFS

A build definition describes the details of what your build is supposed to do, and when it's supposed to do it.

In the past few columns you've learned about the benefits of an automated build process, as well as how to configure Team Foundation Build. Once Team Foundation Build is installed, you need to define a build definition to run an automated build. A build definition describes the details of what your build is supposed to do, and when it's supposed to do it.

To get started, click on the Builds link in Visual Studio Team Explorer. This will open the Builds page. This shows you all the build definitions for your team project and allows you to manage build controllers and build quality. Click the New Build Definition link at the top of the page to start a new definition. This opens a build definition tab (Figure 1), where you can specify the details of the build.


[Click on image for larger view.]
Figure 1. The Build Definition Tab

The build definition is divided into seven different tabs. Let's look at each tab individually.

General Tab
The general tab is where you specify the name and description of the build, as shown in Figure 1. You can also specify the queue processing option for this build. "Enabled" is the default option; it allows the build to run when queued. "Paused" means that builds triggered by this build definition will be queued to run, but won't actually run unless forced to start. And "Disabled" means no builds can be triggered by this definition.

Trigger Tab
The trigger tab of the build definition, shown in Figure 2, tells Team Foundation Server when the build needs to run. There are five different trigger options:

  • Manual. The build will only run when explicitly queued
  • Continuous Integration. A build is queued for every check-in related to the build-related code
  • Rolling Builds. Similar to continuous integration, but will batch several check-ins together to reduce the number of builds performed
  • Gated Check-in. This trigger indicates that check-ins to the areas of code covered by the build aren't allowed until a build has executed successfully
  • Schedule. Allows builds to be executed on a specific daily schedule

[Click on image for larger view.]
Figure 2. The Trigger Tab of the Build Definition

Workspace Tab
This tab allows you to define the working folder mappings used for the build. These mappings help determine what files in Team Foundation Server are relevant to the build, as well as where those files should be stored on disk during the build process. By default in a new build definition, the working folder is the root of the teamĀ  project. This is normally too broad, and should be narrowed down to only include the appropriate files for the build.

Build Defaults Tab
On this tab you specify the build controller to use for this build definition, as well as where to copy the files output by the build. Team Foundation Build 11 includes three options:

  • Don't copy the files anywhere
  • Copy the files to a fileshare
  • Copy the files to a Source Control Folder

The third option is a new feature in Team Foundation Build 11.

Process Tab
The process tab (Figure 3) is used to decide which Windows Workflow 4.0-based process will perform the build. The initial process is set by the process template of the team project, but new processes can be added by clicking the New button. Once a process is selected in the drop down box, the properties for that process are displayed in the table below. Required properties are shown with a triangle next to them. This section is where you can edit and customize the build process for this build definition in great detail.


[Click on image for larger view.]
Figure 3. The Process Tab of the Build Definition

Retention Policy Tab
The last tab on the build definition helps set, for each type of build, how many of the build results you'd like to keep by default. As you can imagine, build results can accumulate quickly, especially with triggers such as continuous integration, so managing the results of your build process can be very important.

As with most things in Team Foundation Server, build definitions can be customized, allowing you to create custom build templates as well as custom workflow activities. But for many developers, especially those who have never used an automated build process, simply using the default build template will allow you to quickly and easily make use of automated builds in your TFS environment.

About the Author

Mickey Gousset spends his days as a principal consultant for Infront Consulting Group. Gousset is lead author of "Professional Application Lifecycle Management with Visual Studio 2012" (Wrox, 2012) and frequents the speaker circuit singing the praises of ALM and DevOps. He also blogs at ALM Rocks!. Gousset is one of the original Team System/ALM MVPs and has held the award since 2005.

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube