The core activities of configuration management (i.e. changeset management and release management) are essential to control the changes made to a system and to administer the release of its different versions. However getting it wrong damages your brand, customer confidence and ultimately your business.
Changeset Management
All software systems change but how that change is managed will determine the success of the change. At the simplest level, software is changed to fix bugs and address security vulnerabilities. No new functionality is added but the software is more reliable, more stable and more secure. Tracking these changes (bug fixes) means that at any time the impact (both in terms of functionality and cost) can be monitored and subsequently fed into the release management process.
How changes are managed shouldn’t be decided by which tools are available, but rather tools should be found and used according to the management principles. Although tools can improve efficiency, it’s ultimately the nature of the process that determines the success of change management.
Back in the 1990s Abracadabra Software, a popular accounting software solution company, discovered that it’s the process rather than the tool that’s important. Here’s why: A programmer working on the next version of the AbraPay software made a change to the code without following the change management process. The change was simple – only one line of code. However it introduced a major bug into the software.
Since the change was made just days before the final shipping version of the product was released, it made its way into the release and subsequently broke the software. Hundreds of calls started to flood into the company when the software failed to work as expected. The AbraPay team then had to work all through the night to find, fix, test and release a new version of the software.
The lesson is that changeset management can fail, not because of the tools, but because of the process and the people using that process. Good changeset management needs to be easy to use, efficient but effective. Any process that causes the developers pain will be circumvented. It’s human nature.
Client-server or peer-to-peer
Naturally, the tools used do play important roles and the methodology behind the tools is equally important. In deciding which methodology and tool to use it’s worth noting the difference between two models of revision control. The first and oldest is a client-server model where source code is synchronized with a central repository. How that synchronizing occurs, and if concurrent changes are allowed, depend on the individual software.
The alternative is a peer-to-peer model known as distributed revision control. Here the synchronization of changes is done from peer to peer. This means that there is no central repository but rather many working copies (which also act as backups of the codebase).
Release Management
After changes have been made to a system, a new version of the software needs to be released. Release management is the process of governing the releases and managing what’s included in that release. The input from the changeset management process is used to produce the version for release. Other inputs into this process include the documentation (including release notes) and configuration data when building for multiple platforms.
Conclusion
Manage the changes, monitor the changes, get the releases out with the right code included and your business has a chance at success. Ship the wrong code with unknown, unquantifiable changes and your business is headed for disaster.
