Software engineering professionals find me in Google when they’re researching Release Management, and often they will email me questions about how to approach a specific issue or challenge they are facing.
Once such email conversation comes from a new friend in Spain, who has asked for advice on Release Management topics over the past several weeks. Today, he asked about System-level Configuration Management:
How do you control change to the systems that are part of your release process?
I get this question frequently, so I thought I’d share my answer here.
Controlling change to the environment is challenging, no doubt. There are at least a couple approaches that I used to manage this; lately my preferred approach is the use of VMWare server images for each of the systems in my meta-environment. You can easily manage change to those by placing the image file itself into source control.
In absence of VMWare images, you can implement a more basic approach: take a system-level snapshot of a given system that is properly configured, using a blend of commands such as uname (for OS & kernel level), and any other “version” type commands that return version or configuration data about system components that are of interest. Pipe the results of those commands to a file that you call system-configuration-map and then store that file (and the script used to create it) in source control.
Then you can checkout the script & expected results on the target system, run the script & compare it to the expected results and immediately determine if any of those interesting bits have changed with respect to the authoritative map.
You can then write & implement a script that does all this automatically each night & emails you the results. You would know first thing every morning (or immediately on your Blackberry) if one of your important systems has changed.
Tags: release management, configuration management, freepository