Is release management a different process from change management? Jan van Bon takes a controversial position. He says they are the same—or should be—in his article, “The One and Only Change Management Process.” (If you’re interested, there’s a LinkedIn group that’s still arguing this question as well as a book by van Bon on the topic.) Can a repeatable, streamlined change management process really drive release management best practices?
First a disclaimer. I’m not at all sure I agree with van Bon, but let’s look at his arguments. He says that release management is one (admittedly more complex) form of change management. After all, he says, releases are really a set of bundled changes.
How are releases and changes similar? Well, both require planning, building, testing, acceptance, implementation and evaluation. By creating a streamlined and repeatable change management process, you can use that process for projects that are large and small. In this sense, change management best practices in fact become release management best practices.
Van Bon comes from the world of integrated service management (ISM) and seeks to simplify ITIL, an ornate framework that will be familiar to many people coming from the enterprise IT ops world. And simplification it certainly needs, in my opinion. Van Bon’s ideas about streamlining change management are interesting for certain, even if he doesn’t connect the dots to DevOps.
Could creating a streamlined repeatable change management process effectively change the way you do release management? It’s an interesting thought, but van Bon posits that release management shouldn’t be a separate discipline. Well, today it certainly is. Change management is what Puppet controls – managing application versions, config files, users, and the like. You might also throw in a few of the manual processes like moving around physical network cables and responding to security events, like having to regenerate all your SSL certificates.
Release management is that much larger process that we go through when we’re rolling out a new Puppet Enterprise release. Can they be the same, even in their shape? Maybe in a webops shop with only one webapp that’s built and deployed using the same tools. This is much easier to do when you are completely cloud-based and have outsourced pretty much everything except the deployment process.
According to van Bon, separating change and release management as disciplines only complicates matters and serves the interests of consultants who love complex frameworks. If we are honest with ourselves, most companies are not in a position to merge change management and release management right now. For that matter, how many companies really understand (or have documented) their current change management or release management processes? Once the processes are well defined and repeatable, then we are in a better position to talk about streamlining them, taking what we learn from change management and applying it to streamlining release management.
In my experience, Puppet goes a long way to helping define the change management process and automating best practices. In fact it’s working so well that people are starting to demand the same from the release management process. Merging the two is possible, but release management is obviously a much harder problem to solve, even from a staffing perspective.
If your environments are complex, you might need to have someone in a release management function to give control over the local details of release management. That release management could still build on the change management process, which should be one and only one process in van Bon’s view.
Given the fact that we are hearing a demand for using Puppet for the release management process, van Bon might be onto something after all. Let me know your thoughts on whether you think that really nailing change management can in effect help drive release management best practices.
Learn More
- Gene Kim’s Why We Need DevOps Now
- Mitch Hashimoto’s Stronger DevOps Culture with Vagrant and Puppet
- VIDEO: Razor = DevOps + Bare-metal Provisioning
No comments:
Post a Comment