Release management entails planning, scheduling, and controlling a software build through different stages and environments. And it comes in many different flavors.
In many cases release managers are the gatekeepers of the change management process, making sure production deployments are well orchestrated and follow all the necessary steps to ensure the proper visibility and approvals are obtained throughout the process. They might also run the various change advisory board meetings and actually run the production implementation events.
In these examples, release managers typically have a project management background. They are experts at process and communication, which makes them a good fit for this flavor of release management.
In some cases, release managers are more like engineers. They have the responsibility and own the deployment process itself by executing deployments on behalf of development teams and playing a role in automating the deployment process.
As companies look to adopt a DevOps philosophy, the role of release management has to shift as well.
In DevOps, we allow teams to have control over production deployments. The team is not just focused on creating working code, but also on the infrastructure, network, and other implementation items necessary to get their code into production. By having this accountability, teams will create code with higher quality, making our production systems more reliable and maintainable. But as my Uncle Ben says, “With great power comes great responsibility.”
So if teams are practicing DevOps, does our existing release management process become obsolete? The answer is no, but it does need to change.
Having change orders or some record of change is still needed in DevOps because it’s not just needed in regulated environments to show traceability from code to deployment; it helps shed light on release volumes and time-to-market metrics, which we know are core to measuring our DevOps maturity. However, what will change is the information captured in a change order and how these change orders are created. You will no longer need to track implementation or back-out plans as part of change orders. You just need to be able to track the application, its components, and its promotion schedule.
As with many things, the key to maintaining these change orders is automation. Your continuous integration pipeline has to have the ability to communicate with your change order system so self-documentation can occur.
Creating communication between your delivery pipeline and your change management system gives you the ability to also prevent releases. I know that might sound strange. You might get to the place where you can deploy without restriction, but that won’t be early on in your DevOps journey. There will be holidays or some other instances when you want to limit the number or type of production releases. Having an automated ability to communicate with your pipelines will allow you to have a way to throttle deployments based on business need. This is done today via freeze windows, change advisory boards, and other go/no-go type meetings, but in a DevOps environment, you need a real-time way of doing this directly with the pipelines that eliminates human interaction.
One of the biggest opportunities with release management being enabled via a tool is that you can integrate your audit and security requirements into your process. For example, many companies have controls around separation of duties, test traceability, and business approval. With a tool, we can automatically ensure that the person checking in the code is different from those who have access to the pipeline or to approve the release. For testing, we can ensure that we have gates for testing coverage and security testing findings. No code would be eligible for promotion if it does not meet those thresholds.
Rather than doing audits of releases after the fact, with a tool, you can integrate these controls as part of the pipeline. Thus, they become first-class citizens and you ensure that risk is actually prevented versus discovered reactively. With DevOps and automated release management, you can build a system that is better managed than how the current audit process works.
Because this is a journey, most likely your newer web and mobile applications will be quicker to get to continuous delivery (CD) than applications built on more traditional platforms. In reality, you will be operating in a mixed model, with both manual and automated deployments, for a while, and you need to have an approach that will work for everyone as well as provide insight into the DevOps maturity of your applications. Continuing to use a production change request (PCR) tool will give your leadership transparency on the success of CD and where the opportunities still exist to improve the delivery process.
For those who still have process-focused release management, you will need to provide a path forward to make a transition to this model. For those who have some technical aptitude, you will want to provide opportunities to learn and experiment so that they can have the option to transition to an engineering role.
You will need to socialize internally and with your customers about the new direction and vision for the team. That will energize those willing to learn and transition, while others who aren’t interested will have opportunities for other roles in your organization. In the end state you might not need as many process-focused team members, but you will need some, as the process will always require some level of oversight.
The role of release management in DevOps needs to focus much more on how to enable automation and integration. For the release management function to stay relevant during and after your DevOps transformation, release managers need to move away from viewing release management as a project management-type role and into a more technical role that builds or configures an API-driven tool that integrates into your pipelines and PCR tool and itself embraces a DevOps approach.
Release management is still critical in a DevOps environment. Its function also has to drive the shift from a service-based organization to an engineering group that enables frictionless flow to production via a kind of virtual air traffic controller for production code. This way, you create a “you build it, you own it” model with a better level of security and oversight.
Hi,Thanks so much for writing this article. This is probably the best one by far. Easy to understand and educate myself on DevOps and how the best way to go about it. Thanks a lot really appreciate you sharing with us. The information you provided is very helpful for DevOps training Learners also.
It shows that the old IT rules should not be forgotten. But with agile it does change, will become faster and more of the processes will be automated.
Pretty good article
Great article. Your readers might also find user reviews for all the major release automation tools on IT Central Station to provide additional insights about the need for release management in DevOps.
As an example, this DevOps Evangelist writes in his review of CA Continuous Delivery Automation, "It gave us the ability to be faster and more flexible. In our first pilot run, we achieved five times faster deployment without human work...We are saving tens of millions of dollars of work from our IT administrators." You can read the rest of his review here.
Excellent article. Provided great insight into the relationship between DevOps and Release Management.
Greatly explained why devops needs release management.