Change Management Is Essential to the Building Processes

[article]

In his CM: the Next Generation series, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.

enumeration of file revisions (including tool/process components), as is done for a typical baseline, or perhaps in terms of an existing baseline plus a set of change packages relative to that baseline.

Push: Ability to check-in code without forcing it into the next build(s), completed code that's out on a developer's disk is a liability. It's prone to disk crashes; it's prone to becoming out of date; it's likely to go through fewer verification cycles. Completed code belongs in a
repository where it can be used by others, simply to review, or as a basis for future changes, without the need to have a parallel change branch. A developer should be able to put a source change into the repository even before dependent changes are checked in. The developer then pushes the change to the "ready" state after confirming it's ready
to go into an integration build.

Pull: Ability to differentiate between check-in authorization and build acceptance [similar to (1)]. Often, especially at the beginning of a release development effort, any 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.

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.

About the author

Joe Farah's picture Joe Farah

Joe Farah is the President and CEO of Neuma Technology and is a regular contributor to the CM Journal. Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe at farah@neuma.com

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03