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.
although at least one tool has managed to work in a change-based operation around the API.
If your developers complain that CM is too much of an overhead on them, you've got to give them an incentive to make their life easier. Change packages, when properly supported, in an integrated tool (with integrated repository and user interface) will actually decrease the developer's workload. Not just in the long run, but on everyday operations such as delta reporting. The sales job (i.e. selling CM to developers) becomes much easier.
So what is a change package? It packages all changes, both files and directory structure, together along with the reasons for the change (in the form of traceability references), and the integration data, such as product, target release/stream, change status, unit test comments, etc., into a single record. Build managers only have to consider 20 changes instead of 75 files for their incremental build. Team members can stop looking at
revision codes and start looking at changes. Configuration lineup/baseline algorithms can ensure that all file for a change are included as part of the configuration. Some tools will even analyze a workspace and build (and possibly submit) a change package based on the differences with respect to the context view (e.g. CM+).
Change packages make developer's work easy. It also makes it easier for them to trace back through history looking for specific changes. Change packages have been around in some tools for a couple of decades. But in other tools, the "state-of-the-art" is the introduction of new methods and tools which cope with the fact that they don't support
change packages. If you're not using change packages in your CM environment, your CM will be viewed as overhead or heavy-handed process. Your productivity and quality will both be limited.
Perhaps you've had a bad experience using change packages. If so, the problem was not change packages, it was the technology that was trying to deliver this functionality to you. Find a vendor that will show you how easy it should be. Then, use change packages!
Best Practices Summary
So there you have it - the top 10, in fact, the top 20 (or 21).
1. Use of Change Packages
2. Stream-based Branching Strategy - do not overload branching
3. Status flow for all records with Clear In Box Assignments
4. Data record Owner and Assignee
5. Continuous integration with automated nightly builds from the CM repository
6. Dumb numbering
7. Main branch per release vs Main Trunk
8. Enforce change traceability to Features/Problem Reports
9. Automate administration to remove human error
10.Tailor your user interface closely to your process
11. Org chart integrated with CM tool
12. Change control of requirements
13. Continuous Automation
14. Warm-standby disaster recovery
15. Use Live data CRB/CIB meetings
16. A Problem is not a problem until it's in the CM repository
17. Use tags and separate variant code into separate files
18a. Separate Problems/Issues/Defects from Activities/Features/Tasks
18b. Separate customer requests from Engineering problems/features
19. Change promotion vs Promotion Branches
20. Separate products for shared code
Perhaps these best practice descriptions are more detailed than you expected.
Perhaps they don't quite fit into your picture, or you find them too opinionated. Maybe you expected one on how best to do labelling or on how to derive a branching strategy - these would, of course, be incompatible with the best practices that I've mentioned here. Perhaps you have some obvious ones that are missing here - Give me your feedback. I'd love to hear your input. There are many more on the fringes that fall into software engineering, or tool architecture, rather than CM process. What about the order of importance in which I've presented them? That's gotta ruffle some feathers. If not, I'd
love to hear that too.