Deploying Process Template Changes Using TFS 2010 Build

UPDATED (24 June 2013): This should work now with TFS 2012 as well. Have included a download link to the SkyDrive folder with both versions of the build process template XAML file. Thanks a ton to Neno Loje for figuring out what updates were necessary to get it to work for TFS 2012!

I mentioned in my last blog post about using TFS to manage TFS that I’d talk a little about how I use TFS 2010 to manage and deploy process template changes. I’m excited to be able to provide some more details about it!

Background

I use to create batch files for deploying process template changes and store them in version control. There’s certainly nothing wrong with that approach but I really wanted have an easier way to maintain this process that allowed reusability and even continuous integration. Whenever I checked in a change to the process template branch for the test environment, I wanted it to immediately deploy those changes to that environment. I also wanted to make it super easy for others to be able to make changes and then queue a deployment.

I need a build definition using TFS 2010 Build!

Build Process Template

So I have created a build process template that does exactly this. My goals for this process template were to not require any custom workflow activities or custom assemblies to be required to get the build process template to work. You simply only need to check-in the XAML file and begin using it. That one requirement ended up being tougher to follow than I originally thought. I had to take a few alternate methods that didn’t always end up with the best user experience but I think you’ll see that the template is still helpful. (If you have ideas for improvements, please let me know!)

I hope you’ll see it as an example for creating “builds” that don’t necessarily compile & run tests. Using Windows Workflow Foundation in Team Build 2010 makes it extremely useful for any type of process you want to automate.

Overview

At a high level, here is what this build process template attempts to accomplish:

• Standard Build Features:
• Build Versioning
• Label the source using the version number
• Getting Latest Version or Specific Version
• Associate Changesets & Work Items
• Gated Check-In, Continuous Integration, etc.
• Ability to specify multiple team projects to update
• Ability to specify multiple work item types to update
• Backup each of the the work item type definitions that are currently being used in each team project (just in case!)
• Copy the version of the work item type definitions that are used and backups to a drop folder

Disclaimer: I’m going to give this template the “works on my machine” label. This template may not perform as advertised including blowing up your server, deleting everything on your hard drive, or cause your hair to fall out. Use at your own risk! You have been warned. If it works for you, awesome! If not, please let me know about any issues or areas of improvement.

How to Use the Build Process Template

After you downloaded the template and check the XAML file into your build process templates folder, you’ll want to create a new build definition to use it. Make sure you have also checked in your process template to a version control folder.

Workspace Definition

Specify the version control folder that contains your process template. By default it will download the entire team project and scoping down the build process template allows your build to run quicker since it is not downloading everything in the team project.

Process Tab

Choose the new build process template file from the available process templates:

Note: If you don’t see the build process template as an available item in the combo box, you’ll want to click New and then choose the XAML file you checked in as the existing build process template.

The next thing you’ll want to do is specify the team projects you want to update and the URL for your TFS 2010 team project collection.

The last two required process parameters are extremely important. You need to specify the work item type names and the server path locations to the work item type definition (XML) files. Each of the process parameters are string lists so you’ll want to make sure you match them up in the exact order in both lists.

Work Item Type Names (for MSF Agile)

Work Item Type Definition Files

Make sure you specify the server path location for each of the WITD files! I ended up reusing a dialog for this purpose that you may have been used to seeing in other builds you have configured. It’s the same editor that allows you to choose solution and project files to build. We can use it for this purpose too! Just be sure to select the “All files (*.*)” filter for the Items of Type combo-box.

Again — make sure you put each of the XML files in the same order that you used for the work item type names. For example, your Bug.xml file will be the first in the collection and UserStory.xml will be the last if we are using the same WITs as the figure above.

Other Details

Make sure that your build agents have Visual Studio Team Explorer 2010 installed so that witadmin.exe will be located. You can always use the new build agent tagging functionality to identify which agents have Team Explorer available and then use the Agent Settings process parameters to limit the build to only reserve agents with the tags you specify.

Finally, make sure your build service account has the appropriate permissions to be able to import new work item type definitions to your team projects.

[Updated — 6/24/2013]

Thanks for reporting feedback and bugs! Latest version includes the following bug fixes and improvements:

• 10/26/2010: Will properly associate work items and changesets correctly now.
• 10/26/2010: Discovers location of witadmin.exe on build servers with a 32-bit OS installed.
• 10/26/2010: Detects error on import and writes as build error instead of message. Allows for the build to not succeed in this circumstance.
• 3/24/2011: Reduced the verbosity of some of the build workflow activities. This should reduce the noise in the build log and show what is most important. Be sure to set the entire build’s verbosity higher if you need to troubleshoot issues. (If you are interested in how to lower a particular workflow activity’s tracking verbosity, check out page 402 in our new TFS 2010 book).
• 6/24/2013: Neno provided an update of the build process template .XAML that works with Team Foundation Server 2012 as well. Check out our new TFS 2012 book!

Download the Build Process Template for TFS 2010 or TFS 2012

Let me know if you have any feedback about things you like or areas for improvement! Feel free to comment below so I don’t lose track of the suggestions.

Ed Blankenship