Release & Configuration Management

What is Release Management (and by extension, what is Configuration Management)?… and why is it important? 

This sounds very dry (and maybe scary…) but Release Management lies at the heart of delivering any kind of quality product… we’re talking specifically software systems and products here, although Release management is very widespread in various industries

Anytime a product (perhaps a website, or a front-end interface to an order management tool) is to be changed, a few important questions should be asked:

  • How will it be different from what is in place now?
  • Does the platform it is running on need to change, to support the new release?
  • How will the update be deployed?
  • How will we know the deployment has been successful?
  • Will anything that is not changing break?
  • If something does break, can we get back to the version that was working previously?

To know how something will be different, one must know what is there now; this is where Configuration Management comes in. The configuration of a system is a full description of its components, the environment it runs in and the versions of every component (hardware and software).

To plan a change (typically an upgrade to a product or system), the configuration of the new version must be known; this will be compared to the configuration currently in place to identify the changes being made, any upgrades needed to the environment and any additional components required to support the new version. Once the details of the change are captured, the update process is designed and all tests that are needed to ensure that everything changed works correctly, are identified.

Now comes the next stage of the Release process… ensuring that everyone (and everything) impacted is aware of the change, and, critically, what will be changing. These are the people who must approve the release and deployment; this approval generally comes out of a Change Management meeting where all impacted parties are represented and agree that the deployment can go ahead (or the decision could be to delay if there are outstanding questions).

Once deployment approval is in place, the change can be implemented. Because of the attention each step of this process receives due to a formalised process (as described above), the likelihood of success is much greater… the thinking and analysis have been done ahead of time rather than on-the-fly during a rushed roll-out.

What happens when something goes wrong during the deployment? Again, because the thinking has been done ahead of time, the deployment team knows precisely what to do… roll back the change or fix it in place.

The power of a Release process like I’ve described briefly above is that it can easily accommodate tools such as automated testing, Continuous Integration and even Continuous Deployment; these tools streamline parts of the process, but the foundation remains the same.

I’d like to explore some of these other aspects in more detail in future posts; please contact me with questions, or comments, and I’d love suggestions about other points for discussion… I’m sure there are many!

Author: Bruce Logan