Why DevOps Still Needs Release Management

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.