Configuration Management Planning: What To Do Before you Start


Don't get into the situation where you have to have a team to do tool integration. Even worse is to have to outsource the same. If you have different groups picking their own management tools for the various functions, that's where you'll be headed. Instead, collect requirements and look around. You'll find that some do-all tools might not be the best in each function, but they're generally the best in some functions and have an added value of an integrated architecture. If traceability is important, integration is important.

Configuration Management Process

It pays to understand your process. Don't just throw existing tools in front of your team along with a handbook. Go through each part of your CM process. Ask yourself: Is this the way the user really wants to be doing this? The myth is that developers don't want tools and processes, as they just get in the way. The fact is that developers don't want tools and processes that just get in the way. Most processes and tools get in the way a bit but provide just enough payback to convince developers to use them.

Your processes and tools need to make sense. If they're not adding value to the users, take another look. It's not good enough to say: "We're a team, you're helping the downstream process by using them." A great number of them aren't interested in downstream process, which may be a separate problem. Good tools and processes should benefit the users as well as the rest of the team.

Using Change-Based CM Instead of File-Based

CM cuts down the number of steps the developer must take, and supports a simpler user interface, but not if the change concept is just glued onto a file-based CM tool. Change-centric CM tools manage change without having to keep revisions front-and-center. Similarly, an intelligent context-view mechanism helps to simplify things

Do your CM plans include the overloading of branches so that, besides parallel development, branches are used to track promotion states, releases, change packages, etc. If so, try to drop the baggage. Make sure your tools and processes deal with items such as branches, changes, builds/releases, baselines, etc. as first class objects on their own. A set of labels does not convert a branch into a build definition. Builds have a state flow all of their own, very different from branches. The same goes for changes

And don't confuse a change with a feature. Any number of changes could be required to implement a feature and any number of features might be implemented by a change (hopefully not, though). Similarly, you should have a process managing your 100s of features which is distinct from the process handling your 10s of 1000s of problem reports. They are very different beasts.

Look carefully at the main trunk vs trunk per stream scenario. Although a main trunk sounds simpler, it doesn't match reality and so is much more complex than a branch per stream scenario. Wrestle with this problem ahead of time and don't commit to one way only to find out too late you made a mistake. There are many CM issues that have to be addressed, and they have to be addressed objectively by looking at the

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

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

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