June 18, 2010 10:00 AM
by Ed Blankenship
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!
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!
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.
At a high level, here is what this build process template attempts to accomplish:
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.
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.
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.
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.
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.
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:
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.
Have you tested this with dev11?
a@href@title, b, blockquote@cite, em, i, strike, strong, sub, sup, u
Hi! I am Ed Blankenship and a Product Manager at Microsoft for Visual Studio Online, Team Foundation Server, and the Application Lifecycle Management family of tools. I am an author of a few books, former Microsoft MVP of the Year, and a former ALM consultant.
Powered by Azure Websites
Site design by Jeremy Kratz