As soon as folks start using Team Build, especially with some sort of continuous integration support, several issues pop up regarding the integration with work item tracking, including how not to have bad builds listed and how not to have every build from every build type listed.
When TFS is installed, work item tracking adds a subscription, via bissubscribe.exe, to receive all build completion events. Builds are listed in the “found in” and “fixed in” fields in work item forms. Since there is no filtering, every single completed build is added to the list of builds.
Jason Prickett, a developer working on Team Build, has written a couple of posts that address these issues. In the first post, he explains the steps needed to change which builds are listed in work item tracking.
One of the fields that ships with the standard Bug Work Item Type in Team Foundation is called “Found In Build”. It allows the user to enter the build number of the build in which they found the bug. It can be found on the Details tab of the Bug work item.
The “Found In Build” field starts off with the value “<None>” in its drop down list. As Builds are created with Team Foundation Build Automation, the build number is added to this list. This is accomplished by a subscription to the Build Completion Event that was created during installation.
Unfortunately, the default subscription listens for ALL build completions. In other words, even builds that have compilation errors or fail tests, still make it into the list. This can be a real problem for shops that do frequent builds.
In the second post, Jason lists the fields that you can use to customize the filter so that you get only the builds you want being listed in work items.
What I didn’t give you were the actual filters that you probably need. But first, let’s talk about the fields in the event that you can filter. The following list contains the fields and a brief explanation of what they represent.