Reset Association between Changesets and Builds

I was catching up on some MSDN Build Automation forum posts recently and came across a very interesting question by Wayne Sepega.  I have run across the same problem a couple of times in the past and haven’t had a good answer until now.

Here is a scenario that we are facing with the TFS Build and the way change sets are associated with builds.

Each build generates an MSI and the MSI is moved from environment to environment.

     1) We get a request to do some work

     2) The work is completed and changes are checked into TFS, as a result of the work over a few days there are 5 change sets.

     3) A build (build 1) is done, and deployed to QA, the 5 changes are associated with Build 1

     4) QA finds a bug in Build 1

     5) Bug is fixed which results in 2 change sets

     6) A Build (build 2) is completed and deployed to QA

     7) Build 2 passes QA and is then promoted to Production and deployed.

In the above scenario there are actually 7 change sets that need to be noted in the deployment to production. However, the final build, Build 2, only has the last two change sets associated with it.
Is there a built in way in TFS to have all outstanding change sets associate with a build once the build quality is promoted? Is there a built in way to get a list of change sets for a build type based on the build quality?

Basically I need to find a way to know about ALL 7 change sets with the final build, without having to do a separate build script for each environment as we want to deploy exactly what QA tests and not rebuild.



This is a fairly common scenario for an organization that uses a Binary Promotion process to move their application through environments. 

Binary Promotion is a methodology in which a build occurs and the resulting binary code is packaged together (zip, msi, etc) and stamped with a unique name usually containing a version or build number.  This package is then given to QA to deploy to their environment and test.  If anything is found to be wrong with the application, the entire package is thrown out and another version (hopefully with a fix) is built, packaged and promoted to QA.  Once the app passes QA, it is promoted to Production by sending the exact package that was tested in QA to the IT group for installation on the Production Servers, thus “promoting” the binary package through the enviromnents.

Aaron Hallberg responded that the “good build” flag is responsible for associating changesets with a build.  This means that a changeset only gets associated with a build if that build completes successfully.  The good build flag is implemented by a bit field aptly named GoodBuildFlag located in the Builds table of the TFSBuild database.  To get access to this flag, you call the BuildStore.UpdateFlags method.  Passing false to the UpdateFlags method will reset the GoodBuildFlag and reset the association.