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.
to be done.
Based on your role, you should have a number of in-boxes: documents to be reviewed,
problems assigned to you to be fixed, changes that you need to review, other tasks assigned to you. These should appear in your in-box as a result of status changes and ownership assignment. In some cases assignment is by name. In other cases it's more generic, such as by group function. In the latter case, the in-box is potentially shared
by others. Some people are better communicators than others. If you depend on your staff to keep assignments clear, you'll have hits and misses. If your process and data is doing the job for you, in concert with a decent CM/ALM tool, you'll march along more efficiently, and you'll be able to easily identify your bottlenecks and problem areas.
2. Stream-based Branching Strategy - do not overload branching
Branching provides an effective means for supporting parallel releases. However, most shops use it for various other purposes: change promotion, change packaging, build tracking, variant management, short term parallel changes, feature tracking. I'm sure you can add to the list. The result is that what should be a straightforward two dimensional "tree" structure of revisions (i.e. release stream and revision within a release), turns into a spaghetti maze of branches. Elaborate branching strategies are designed and reviewed intensively to ensure that the team can clearly follow it. Branching, labelling and merging skills are honed to ensure that these can be done effectively.
But try to ask your CM tool to understand what all the branches mean - well that's more of a problem. The result is that an inordinate amount of effort goes into these mazes, unravelling them. And what's worse is that the CM tool can't give the developers guidance. Instead, the onus is on the developers to learn and follow branching strategies. So CM becomes tedious rather than automated. The significant amount of
effort is directed to configuration management, rather than to change management.
Stream-based branching is the only strategy I've seen that eliminates almost all manual CM. It's the only one I've seen that eliminates the need to label (manually). It's the only one I've seen that allows developers to start using the system without training on branching strategies. It's the only one I've seen that truly minimizes branching. It's the only one that can automatically tell developers that they need to branch.
It scales from very small to very large projects extremely well. It does require tools
which deal with change packaging, change promotion, build tracking, etc. without using branches. I'm sure having this as the #2 best practice will raise a few eyebrows, especially among those who have never tried it, but it so dramatically simplifies CM without compromise, that it is a necessary path for any next generation CM.
The Best of the Best Practices
1. Use of Change Packages
This one is obvious. Everyone will agree on it, I hope. It would really be my hope that this is taken as much for granted as is storing file revisions - it shouldn't have to be a best practice - it should be a given.
But although there are several tools which support change packages, and others which at least go half way and tie file revisions to a common task, sadly, many, if not most, projects today do not use change packages. They check in files one at a time. They create delta reports by appending the delta reports of several different files. They promote each file independently, hopefully with some manner of determining which files all have to be promoted together. They merge changes by merging each file separately, relying
again on some virtual container (usually in the developer's head) to identify which files are involved.
Unfortunately, they are supported by industry pseudo-APIs such as the SCC API for IDE
plug-ins. This is a file-based API,