Improve Build Management with TFS 2010 Build Services

The Visual Studio 2010 Team Foundation Server (TFS) 2010 build system automates the compiling, testing, and deployment of software for developmentorganizations of all sizes -- from small software efforts to large development enterprises. TFS's build services can scale out to accommodatedevelopment as the code base grows -- which facilitates TFS's adoption in most scenarios. The TFS build system can also scale out and scale up thebuild environment, which can greatly reduce the amount of time it takes a team to complete a build. Finally, TFS supports the use of ContinuousIntegration (CI) builds, which can improve your code by providing frequent feedback on build quality. This article covers the features available inTFS's build services and the different taxonomy options for creating a build environment, using a typical scenario for using the build capability.

TFS Build Scenario

To see the benefits of TFS 2010 and TFS build services, let's look at a simple example of a 500-employee organization that has approximately 50 peopleworking with TFS. The TFS group's project teams include:

This simple team structure represents three main uses of TFS build services.

The development team is interested in continuous feedback on the quality of code that is being checked into TFS's source control. The code's quality isdetermined not only by whether it compiles but also by automated tests that are run as part of the build process. The build succeeds only if itcompiles and all automated tests pass. It is acceptable to have all logical layers of the application run on one physical machine.

The test team's aim is to test the application at the end of each development iteration. The application that the team tests should be of high qualityand free of any known defects. The application's logical layers are deployed to different physical machines based on the physical architecture.

The build and deployment team packages the software after it has completed and passed all testing and development cycles. Deployment may be manual orautomated depending on the team's requirements.

Branching Strategy

To support the team structure, a branching strategy is employed that allows a separate code base each for the developer, tester, and build anddeployment teams. Figure 1 shows a branching strategy that has a Main branch representing the code base for QA testing.


Figure 1: Branching strategy in Source Control Explorer

Main branches into theDevelopment folder to create development branches for each iteration. Once all testing is done and Main is ready to be released, a branch into theRelease folder is created.

Figure 2 shows the branching from Main to Development. (This diagram is taken from the open sourceVisual Studio TFS Branching Guide 2010 v1.)


Figure 2: Branching diagram

When thedevelopers are confident their code is ready, a merge will take place from Development to Main. When all testing is completed, a branch from Main toRelease occurs.

This is important since the workflow for Development builds might differ from QA builds and Release builds. Having three separate code bases allows forthree different build definitions to exist. (I discuss build definitions in more detail later.) But before a build definition can be created,there must be a build environment.

Build Environment

The build environment consists of one or more build machines. A build machine is a computer that has the TFS Build Services installed. Thismachine can be a physical or virtual machine. Any type of machine can be set up as long as the Build Services can be installed. The larger the softwaredevelopment effort, the more build machines may be needed.

A build environment requires configuration of a build controller and one or more build agents. A build controller is registered toone team project collection. Each controller manages the build agents and distributes the workload of the builds to the agent machines.

The build controller processes the workflow -- for example, creating a label in source control, naming the build, updating work items, and reportingthe build's status. The controller's activities are not in themselves processor intensive, so it might work to have the controller installed on avirtual machine or even on the TFS application tier. However, in some situations the controller requires a large amount of memory, so it is importantto have adequate memory on the controller machine.

Each build agent is registered to a build controller and does the processor-intensive work, such as getting files from source control, compiling thecode, and running tests. More than one build agent may need to be part of the environment, depending how much build work needs to be done. You mightalso need to have more than one agent if machines need specialized capabilities. For example, if you build and deploy the database using databaseprojects, you might require the build to be done on the machine that has the database server installed. The same might apply to building a webapplication: The build might need to be done on a machine that has the web server installed. It is possible to use tags to assign the agentthe build is run on. A tag is an attribute that can be assigned to a build agent. The tag can be specified in a build definition. If tags are not used,the controller will decide what agent to use based on the current load on the agent machines.

For small teams, it may be adequate to have the controller and agent installed on the application tier server. However, in most situations, this is nota good idea. For medium-size teams, the controller can be installed on the application tier while the agents are installed on separate machines. Forlarge teams, the controller might need to be installed on its own machine and the agents installed on separate machines.

Build Definitions

Once the build environment is set up, you can create one or more build definitions. A build definition defines the workflow and process that occur in abuild. Some of the properties that are set in a build definition are

You create a new build definition using the New Build Definition wizard. The first screen of the wizard is simply the name of the build definition.This name should indicate the build definition's purpose. For example, if the build definition is for a Development branch as shown in Figure 2, itcould be named Dev_CI, which stands for a Continuous Integration build of the development code base. The second screen in the wizard determines thetrigger for launching the build.

Figure 3 shows the options for triggering a new build.


Figure 3: Build definition trigger

Here are the options:

The wizard's third screen sets the workspace of the build definition. This maps the location of the code in source control to a location on the buildagent. By default, the build agent folder path starts with $(SourceDir). This variable is set on the build agent machine's Working Directory property.This property by default has the following path: $(SystemDrive)Builds$(BuildAgentId)$(BuildDefinitionPath). The environment variable$(BuildAgentId) is an automatically generated integer that identifies the build agent ID in the team project collection. The environment variable$(BuildDefinitionPath) consists of the team project name and build definition name separated by a backslash. Thus, if the team project is namedClientA, the build definition is named Dev_CI, and the build definition has a build agent folder set to $(SourceDir)Application, as in Figure 4, thephysical path on the build agent is C:Builds1ClientADev_CIApplication.


Figure 4: Workspace mapping

The fourth screen in the wizard is the Build Defaults screen, which is where you select the controller and drop folder. The drop folder is a UniversalNaming Convention (UNC) path where the final compiled code will be dropped. The service identity of the build agent must have rights to this sharedfolder.

The final screen in the wizard, the Process screen, is where you select the build process template, what project(s) to build, what tests to run, andother items for the build. This is the screen that determines what is going to happen when a build is queued.

Build Process Template

TFS 2010 Build Services is based on Windows Workflow Foundation (WF) 4.0. The build process template is a WF XAML file that controls the process andflow of a build. There are three out-of-the-box process templates:

The Default template is the most commonly used template. It has a workflow that handles all standard areas of a build:

You can configure which of these steps will be performed by setting the properties on the Process screen.

Process Template Customization

Even though the Default template is well suited for applications based on the .NET Framework, you may need to customize the workflow. For example, youmight need to run special scripts to deploy the application or to assign a version number to the assemblies -- tasks that can only be done during abuild. To accomplish this, you need to be familiar with the process template workflow and XAML. You will also need to decide whether an existingactivity can be used or a custom activity needs to be created.

Activities -- the backbone of a WF application -- drive the processing of the workflow. Since activities are nothing more than .NET assemblies, it ispossible to create custom activities and use them within a custom workflow.

To customize a process template, you must first open it in the Workflow Designer or in a text editor to work with the raw XAML. With each team projectcreated, a BuildProcessTemplates folder containing the three out-of-the-box templates is created in source control. I strongly recommend that you makea copy of any process template that will be customized. Open the DefaultTemplate.xaml file in the Workflow Designer to display its contents in designmode, as shown in Figure 5.


Figure 5: Default Template in the Workflow Designer

Understanding the Default template's workflow has a learning curve, but once you understand the workflow, the template isrelatively easy to customize.

If custom activities are part of the workflow, they must first be stored in source control before they can be used in a build. Once the customactivities are in source control, you must configure the build controller(s) to point to the custom activities' location. You can do this in TeamExplorer by following these steps:

Figure 6: Build controller properties

Running a Build

To queue a build, right-click the build definition name under the team project in Team Explorer and select Queue New Build. This opens a window thatallows some of the build definition properties to be overridden. You can change the build controller along with the drop folder, the priority in thequeue, and whether a build of a shelveset is done. You can also change other build definition properties, such as clean workspace, logging verbosity,perform code analysis, agent settings, and label sources.

When a build is running, a window opens showing the build's progress. Depending on the logging verbosity chosen, the current step in the workflow isshown in real time. Once the build is finished, the full build report is displayed, showing details of the build: build status, summary, test results,code coverage results, associated changesets, associated work items, and impacted tests.

From this report, you can open the drop folder, view the log, and choose whether to delete the build or retain it indefinitely. You can also assign abuild quality that can be used to categorize the build. The report is stored in TFS for the time period set on the Retention screen of the builddefinition configuration. The retention policy is based on the build outcome. For each build outcome, the number of builds to retain and what to deleteis specified. Delete options include details of the build (e.g., build steps, requestor, date/time queued); drop folder output; test results; label;and symbols.

Better Builds

The TFS 2010 build environment can make a development team more productive by creating fast, reliable builds and can improve the quality of code beforeit ever reaches the testers by allowing integration of automated tests in the build process. Additionally, the use of WF in TFS 2010 Build Servicesmakes the task of customizing the build process much easier than in previous TFS versions. Finally, with TFS 2010's build support for deploymentautomation, development teams have more confidence that all components make it and nothing is missing from the build.

Brian Minisiis an ALM Ranger and a software architect for Computer Enterprises, Inc. (CEI), a consulting company specializing in Microsoft technologies. Follow himon Twitter: @brianminisi.