The Team Foundation Build Default Template enables you to define a build process that can perform the basic tasks you expect from your build system. Use MSBuild to build the bits, run MSTest to test the bits, label the code, publish symbols to SymStore, drop the binaries in a folder, etc. DefaultTemplate.xaml has got you covered; you can get your build process defined and running in a matter of minutes.

But suppose you need your build process to run some custom process against the binaries after building the code. Or to publish some documentation to a web server. My anecdotal experience from monitoring various virtual user groups has left me with the impression is that specialized build processes are the norm rather than the rule.

If you are one of these customers, here is my holiday present to you, hot off the presses:

Team Foundation Build Activities

This article describes in detail the Team Foundation Build Activities, which are the fundamental components of the build process. I wrote this topic with hopes of making it as easy as possible for you to create your own custom build process.

Floor wax and dessert topping

As I researched this content, I saw two major use patterns: reference and usage guide. A reference answers questions such as: What does this activity do?  What is this property for? But I also wanted to help the developer working from the other side of the equation, focused on a specific goal they have in mind.  So the answer to whether I should structure the content as a reference or as a usage guide was: both; both a floor wax and a dessert topping.

Reference: How do I work this?

 

toolbox and reference I know that many readers need the answer the question best expressed by the Talking Heads: “How do I work this?” So in the topic you will find an alphabetical list that contains a link to information about each activity.

Usage guide: How do I get there from here?

 

goals Whenever I get an opportunity to spend some time writing code, I hope for but often don’t get a goal-oriented guide to the classes, methods, functions, or whatever set of constructs I’m working with. So in the topic I offer a list of goals. I also organized the material by goal to support easier reading from end to end.

Leaves a shine? Tastes great? Other?

One other major design decision I made was to use a minimalist approach wherever possible. I enumerate the properties in lightweight bulleted lists instead of tables. I am intentionally inconsistent, abbreviating sections that cover simple activities. When I need to point to a deeply embedded element in the workflow, I use a terse but hopefully easily traversed format (as described in Navigate in a Complex Windows Workflow).

How does the format of Team Foundation Build Activities work for you? Any information not covered that you need? As always, I welcome your feedback.

Andy