6 Execution ↑
No. 42 — Configuration Management
As with many safety and quality practices, configuration management is often most visible by its absence.
As in…
What do you mean, you can’t find the source code?
Or…
You know that nasty bug we discovered last week?
Well, that’s been fixed now.
Unfortunately, we’ve also somehow lost the last three enhancements we made.
While the following list of suggested CM practices is not exhaustive, it’s a good place to start.
Make sure you have multiple backups of your source code – in development as well as in production.
Use a version control system that automatically maintains prior versions of all of your programs and modules.
For each release of your application, maintain a complete list of all the application’s components, with the version level of each.
Always create executables to be released via an automated build process using configuration-controlled source code.
Maintain records that always allow you to trace back from any given change in the source code to the original request that provided the rationale for the change.
Always maintain some separation of duties (SoD) between the developers and the folks responsible for implementing a release to production.
Words from Others on this Topic
Chris seems excited. “Brent, if it’s okay with you and everyone else, I’d like to invite you to our team sprints, so that we can get environment creation integrated into the development process as early as possible. Right now, we focus mostly on having deployable code at the end of the project. I propose we change that requirement. At each three-week sprint interval, we not only need to have deployable code but also the exact environment that the code deploys into, and have that checked into version control, too.”
– Gene Kim and Kevin Behr and George Spafford, The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, 2013
Next: Limit Work in Progress