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.

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, but 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.

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