by Ewald Hofman
20. April 2010 05:49
In the series the following parts have been published
- Part 1: Introduction
- Part 2: Add arguments and variables
- Part 3: Use more complex arguments
- Part 4: Create your own activity
- Part 5: Increase AssemblyVersion
- Part 6: Use custom type for an argument
- Part 7: How is the custom assembly found
- Part 8: Send information to the build log
- Part 9: Impersonate activities (run under other credentials)
- Part 10: Include Version Number in the Build Number
- Part 11: Speed up opening my build process template
- Part 12: How to debug my custom activities
- Part 13: Get control over the Build Output
- Part 14: Execute a PowerShell script
- Part 15: Fail a build based on the exit code of a console application
- Part 16: Specify the relative reference path
Who created a new build definition in TFS 2008 knows that Team Build 2008 heavily relies on MSBuild. The workflow that is executed during the build is defined in a custom scripting language in XML. The language is powerful, but not intuitive. It is hard to understand what is going on exactly, especially for novice users.
In TFS 2010 the build relies on Windows Workflow 4.0. With Workflow you can create a workflow based on activities. The advantages of this approach is that Windows Workflow is very intuitive and it supports parallel execution. Microsoft brings a lot of activities out of the box, but if required you can add your own activities too. This series of blog posts tells you how you can modify the Build Process Template to your own needs. Before starting to build your own customized build process template, it is good to first know how Team Build 2010 works.
Build Controller and Build Agent
When you queue a build in TFS 2008 you choose one of the available Build Agents to execute the build. In TFS 2010 there is a new component introduced, called the Build Controller, to initialize the build. When you queue a build, you choose the Build Controller which starts processing the build. The Build Controller initializes the build and chooses an available Build Agent. The Build Controller persists the workflow and hands it over to the Build Agent, which will continue executing the build and do the heavy lifting. For a deep insight in the overview see Understanding a Team Foundation Build System.
Build Process Template
In TFS 2008 the build was executed based on a MSBuild script. This script imports the %ProgramFiles%\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets file. This file contains all the logic to execute the actual build. In the TFSBuild.proj file you override targets and properties to customize the build to your needs. All target files you import (your ‘templates’) in the TFSBuild.proj must exist on the build server. It is not possible in TFS 2008 to store it in Source Control so the build automatically picks up the latest target file. If you have a build farm of multiple build servers, you needed to sync the template target file over all the build servers.
In TFS 2010 you also have a template, which is called the Build Process Template, but it is defined in Windows Workflow. This template is stored in Source Control, so you don’t need to deploy it to every build server anymore. The Build Controller will just use the version that is stored in Source Control.
You configure the build now by choosing a Build Process Template and set the properties that are defined in the template.
In my opinion, Microsoft has made a giant leap to make the build much easier to configure.
You can download the full solution at BuildProcess.zip. It will include the sources of every part and will continue to evolve.
Subscribe