The Next Generation: Build Management Essentials

support changes to the Build definition once it's status reaches the "svtest" state.

2. If a change is made to the build definition in the "sitest" state, the status is rolled back to "select".  This might be the case if an urgent bug fix was needed to achieve build success.

3. If a publicly defined Build Notice has been cancelled, the status is set to Obsolete.

4. A build can end up in any state.  For example, if a build fails verification, it is not necessary to roll back the build from sitest state to the select state repetitively adding updates until it passes verification.  A subsequent build can be defined to hold updates for the next attempt.  Only those builds which are selected for production will go through all of the promotion levels (at least as shown in our state flow above).

This is, perhaps, a fairly simple set of policies to define how builds are treated.  Yours may be simpler or more demanding.  But it is crucial that the CM or ALM tools used support these policies and do not permit inconsistencies.  So the CM/ALM tool should not permit, in our example, a build to be rolled back after it has attained "svtest" or higher status.

Builds and Context
A record of a Build is important.  It's critical to be able to, at any time in the future, recreate the Build Artifacts from the Build Record in the CM/ALM Repository.  Typically, a CM/ALM tool has a means to retrieve all of the "source" corresponding to the record so that the build can be reproduced.

However, a Build Record should be of much greater benefit in a next generation CM/ALM tool.  You should be able to select any Build Record and place your CM/ALM tool session into the context of that build.  Now if you look at any file, the revision corresponding to the Build Record is used.

Furthermore, you should be able to ask questions such as: Is this update in the build?  Did this problem get fixed in the Build?  Is this feature in the Build?  What test cases failed for this Build?

One of the more general capabilities of a Build, or a Build context, is to be able to use it to compare against something else.  For example, you may wish to compare the contents of your workspace against a specific Build Record to verify that the workspace contains the same code, or perhaps to identify the differences.

Build Comparisons
There are much more significant Build Comparisons that should be a key component of every shop.  And Next Generation tools are necessary to realize them.  For example, I have a series of builds that work successfully, and then all of a sudden I find a big problem in one.  I need to find out where the problem was introduced.

Step 1.  What Build was it first introduced in? 
This is answered by testing the build artifacts.  Build reporting can help in several ways.  First if there is a specific test case for the failed feature, it can identify when that feature last passed successful testing.  That leaves a series of say, a dozen potential builds where the problem could have been introduced.  The build records could then be used to test half-way back, to narrow the search.  This binary search for the bad build could save a lot of test time, especially if it takes significant time or resources to set up the correct build and test.

In some cases, it may be desirable, in parallel to do a build comparison between the current build