NEXT GENERATION CM: Building: Change Management First

of a product.  A stream is a separate codeline targetting a different release of a product.  For example, release 1 and release 2 would generally have separate development codelines, with release 2 slightly, or not so slightly, overlapping release 1.  A stream is basically a codeline that culminates in a new release.  The CM process and tools must support
this function.  Many processes will use a single "mainline" which switches at some point from release 1 to release 2.  I do not recommend this.  It introduces a number of arbitrary decision points and more complexity into the development process.  For example, the process for making a change to release 2 changes at least twice in the single mainline approach: once when the switch of the mainline to release 2 is completed, and again when the switch for a subsequent release is completed.

(12) Product:

Ability to identify changes and do builds for multiple, possibly dependent, products.  CM tools need to support and clearly identify multiple products.  Dependencies between
the products need to be identified, both for build purposes and for impact analysis.

(13) Compare:

  Ability to compare any to builds to identify the difference in terms of changes (as  opposed to lines of code).  For a successful build operation, it must be possible to easily compare any two builds.  For example, the build manager should be able to take the new build definition and identify the changes that are being added to the previous definition. It's not so much the code changes that are important as the logical changes - i.e. what is being done.  It's the logical changes that will be pushed and pulled in correcting an errant build.  It's also necessary to be able to identify problems fixed, features added, etc. so that integration testing can first focus on the correctness of these features prior to regression testing of pre-existing features.  Ideally, your CM tool will let you point to any two builds and compare them in such a manner.

That's a pretty long list of requirements.  Are they comprehensive?  I don't think so, but it's a good start.  Design your build processes around a solid change management capability and you're well ahead of the game.  Start from an inadequate base and you'll be playing catch-up forever.  That was OK when we were trying to figure out what CM is.  But now that
we know, and now that we have a much more solid understanding of Change Management,

Change Management: Requests and Changes

Change Management has two key components and Build Management must fully
support these.  On the one side, there's the Change Request; on the other there are Changes (i.e. change packages).  Builds are defined in terms of Changes applied to a previous build or baseline definition.  This eliminates the tedium of managing file versions and labels.  Each Change needs to be targeted to a specific product and to a specific stream of the product.  The Change should exist prior to the first checkout operation.  The promotion level of a change, typically indicated by its "state", is used to determine which builds it will be part of.  Promotion is always done on a Change basis.  And Changes must indicate their dependencies on one another, either implicitly through
file history, or explicitly through pre-requisite data.  The build process must use the dependency information to alert the build team, the CM manager, or even the developer, whenever a promotion operation leaves dependents behind.

Change Requests are quite different from Changes and should not be used as a Change container.  A Change Request might be implemented in several Changes across several
releases.  Or multiple Change Requests might be addressed by a Change.  The originator, or requestor, of a Change Request communicates the request to the product team, which ensures that it has a proper understanding of the request.  Once this handoff occurs and the product team accepts