How to Determine the Work Items Fixed in a particular TFS Build when using Branches?

Question

We have begun using the following branching structure in TFS 2010:

All changes so far have been performed in the Development branch, and all check-ins have been associated with a Task work item. The Tasks are all children either of a Bug or a Product Backlog Item work item. Each CI build is triggered for a particular changeset, and the changeset is associated with a Task, so we can manually figure out which Bug or PBI was just built.

Some time after the code has been built, deployed to our Integration environment and tested by the developer, it is merged to the Main branch. Obviously, more than one changeset may be merged to Main at the same time. The nightly build will build this code if we don't manually trigger the nightly before that. QA will later deploy one of these "Main" builds to the QA environment.

There may have been several builds of the Main branch since the last time QA have deployed. These builds are associated with the "Merge" changesets, not with the original changesets which were associated with the Tasks.

How do I determine the set of tasks which have been addressed by a given "Main" build, which is a build of a different branch than the one associated with the Task work items?

Once we've begun preparing for a release, we may very well need to make changes in the Release branch, which will complicate things further since we will be merging back from Release to Main, and the Release changesets will be associated with Tasks. Those will then be merged to Development, making life even more interesting!

---

P.S. The question "How to determine the work items associated with a source branch in TFS 2010?" comes close to asking the same question, but not quite.

Answer 1

Take a look at Jacob Ehn's blog post Automatically Merging Work Items in TFS 2010. He wrote a plug in that can be downloaded from codeplex. It will automatically associate the work items that were associated with the merged changesets. So when you merge to Main or Release the work items will be associated with the changesets in those branches, and the work items will be included in the build reports for builds off of those branches. The plug-in is super easy to deploy.

Answer 2

The other option is that you can build a custom workflow activity that you can run during your build that can traverse the merge history for each of the changesets that would normally be associated. It's essentially walking the tree starting with a known set of associated changesets. I would prefer this approach since you can let your developers worry about only needing to associate work items with the original changesets instead of having to also do it with merge changesets as well. This also allows you to get around having to deploy a custom work item policy as Bryan described in his suggestion.

I might have some sample code to get you started with traversing the merge history tree if you want to contact me at http://www.edsquared.com