A colleague forwarded to me a pointer to the current issue of the ITMPI journal, on Best Practices in Configuration Management. They make an interesting contrast with the best CM practices in the November issue of the CM Journal on “What Best Practice Is Best?”, and specifically the article CM: The Next Generation of Top 10 Best Practices.
The CM Journal article’s list is as follows:
- 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
The ITMPI Journal articles lists just 3 best practices:
- Software Configuration Management Audits (This isn’t really covered well by the 20 practices above, but is somewhat related to practices 5 and 13.)
- Risk-Based Configuration Control – Balancing Flexibility with Stability (This is somewhat related to practices 7, 11, 15, 16, 18a/b, and 19.)
- Bidirectional Requirements Traceability (This is somewhat related to practices 1, 2, 3, 4, 8, and 12.)
The ITMPI Journal article doesn’t really cover the practices 6, 9, 10, 14, 17, and 20, partly because the CM journal article practices are at a lower level of detail and cover a few practical/administrative issues outside of the core of CM theory.
Anyway, the practices in both these lists are all “good” for “most” development groups. They aren’t rocket science, but I’d say there are a fair number of development groups out there that barely do any of them. Although version control is ubiquitous in industry, CM is still very poorly understood by most practitioners.
For what it’s worth, I think that for most commercial software development, the most important practice isn’t about sophisticated version control issues or processes – it’s a simple but critical piece of organisational structure and policy.
All Customer Deliveries Go Through the Release Team
Create a release team that’s different to the development team. Ensure all customer software deliveries happen through the release team. Have the most senior manager you can find declare it a firing offense for a developer to ship code or patches directly from their desktop to the customer. Even in “emergency” situations.
More than once I’ve seen or heard of companies that own high-end commercial SCM tools, but make those tools worthless because developers sometimes email patches directly to the customer. (Sometimes in the rush they also forget to check in their changes to version control, which just makes the nightmare worse.) The developers are usually trying to “get the job done”, and be “helpful” to a customer with a problem. Sadly, they end up causing bigger problems for everyone down the line. If you’re not managing releases properly, you don’t know what code the customer has – you degrade your ability to diagnose faults, you won’t be able to ship working patches in future, and you might easily introduce a regression problem by losing the fix itself.