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.
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.