You have CI (Continuous Integration) Build running on each check in (or once a day) and the "Found In Build" drop down list in the Bug Work Item keeps growing each day...
You don't need all those builds there - you need only the build which QA actually deploy to their environment.
You can maintain this list manually by editing the Global List which TFS holds for each team project as described by Benjamin Day in Managing TFS Team Build History: Delete Completed Builds From "All Build Types" & Bug Work Item Drop-downs, but this is tedious work to do manually.
You can edit it with the "TFS Power Tools" new menu:
Tools --> Process Editor --> Global List --> Open Global List from Server
But it is still manual work.
You can actually use Jason Prickett's Blog to tell TFS which builds should get in the list from the start by adding conditions to the event subscription of the "Build Completion Event". but still you will be able only to filter the non successful builds - not all the builds except the deployed ones.
Actually the main issue here is Microsoft's decision to insert builds into the list on the "Build Completion Event".
So now to my (little chutzpa) solution:
- Delete the original TFS "Build Completion Event" subscription (as suggested by Jason) - BUT - don't recreate it with a filter.
- Write your own web service and implement TFS event handler web method for the "Build Status Change" Event (BuildStatusChangeEvent) (which should have been called "Build Quality Change Event" as it triggers only on quality changed)
In this handler check if the Quality has been changed from NULL to something.
If it's true - just call the Notify method on TFS WorkItemTracking Integration web service with the xml it waits for.
You will need of course to build this xml and bring the missing information from the BuildStore service, but those are easy steps.
Don't forget to set the HttpRequest's UseDefaultCredentials to true (or pass other valid credential) or you will get unauthorized exception from TFS.
- Subscribe your web method to the BuildStatusChangeEvent.
Now all you need to do is to instruct your integration team to change the build quality of each build they take to deploy on QA environment from "Unexamined" (or null on TFS 2008) to "Ready For Initial Test".
The BuildStatusChangeEvent will be called, it will call Microsoft's original implementation of adding the build to the Global List, and this is exactly what I want.
See the code at the attached c# file: