NEXT GENERATION CM: Building: Change Management First

code that has been marked ready is automatically picked up by the nightly integration build.  Although this may be sometimes sufficient, it is not sufficient as the release approaches and changes are more selectively pulled into the build for integration.  The developer pushes, the  integration team pulls.

(5) Roll-back:
Ability to roll-back changes that "broke the build" in an easy manner.  A change breaks the build.  The best solution is to put in a new change to fix the broken part of the change.  This provides full traceability of the problem.  However, sometimes, it's too complex to fix and the best solution becomes "roll-back" of the change so that it is not part of the build.  Ideally this is a simple state change on the build.  If changes are already stacked on top of this change, it may require "yanking" changes.  More complex CM tools/processes use parallel streams for promotion (as opposed to state changes).  In such cases, rolling back a change may entail additional steps, some of which may even be required in more than one of the parallel promotion streams.

(6) Fix-the-Build:
Ability to adjust the snapshot (ie continue to (re)define it) by adding or remvoing changes, until it is frozen [extension of roll-back].  More generally than a roll-back, it must be possible to arbitrarily modify a build record (i.e. notice) so that additional fixes may be added to it or errors in definition of the build record may be corrected.  This must be easy to do so that the build can be successfully completed for the team's use.  It should only be done on a change-by-change basis - never on a file basis.  A change must always be in or out, never partially in.

(7) Dependencies:

Ability to keep the build definitions in a consistent state for the build operations.  As changes are added or swapped out of a build record definition, the CM tool must notify you of violations in dependent changes.  For example, if a second change has already been built on the one being pulled, the tool must notify you of this and allow you to take approprate action to ensure a consistent definition results.

(8 ) Structure:
Ability to associate structure changes with a change.  It's no good pushing and pulling changes if the structural changes that go with the change are not also pushed/pulled.  For example, if a change moves a data file from one directory to another, or deletes an existing file, these structural changes must be packaged with the source code changes
so that everything moves together through the system, whether forward or backwards.

(9) Promotion Levels:

Ability to support multiple levels of integration, especially in larger projects.  Promotion to integration is a single promotion step.  In larger projects, there are several levels of integration, especially in task-based development environments where a major task might be sub-divided into smaller tasks which are then integrated prior to integrating the larger task into the "mainline".  Larger projects will have more promotion levels.  I am often reluctant to use parallel streams for promotion because there is a natural reluctance to running through an additional merge cycle when a new promotion level is added.  Instead, I prefer state changes with a process which tends to support a higher percentage of changes moving through the promotion levels in the same order as they are checked-in to the repository.

(10) Get:
Ability to retrieve files for a build into an integration workspace.  Given the definition of a build record, it must always be possible to easily retrieve the files from the repository so that they can be readily and reliably built.  This includes support for both incremental
and full workspace retrievals.  Along side this is the ability to easily identify differences between any snapshot and the contents of a workspace.

(11) Stream:

Ability to identify changes and do builds for multiple development streams