In the world of enterprise application development and delivery, release management was born from the operations team attempting to reduce risk in the delivery pipeline. It’s the operations team’s job to ensure all production runs are stable, while the development team focuses on creating and shipping new products and applications.
While this seems well-defined, integrated DevOps teams are left to wonder if they need release management, and how it fits into their processes. The answer is a resounding yes–release management is a crucial aspect of continuous delivery. Enterprises that fail to implement faster and carefully coordinate release cycles, will ultimately fail to keep up with their competitors.
What is Release Management?
The aim of release management is to consider the bigger picture, and to view software not only in relation to how the technology works in its production and during development, but also how it relates to the overall business objectives. It’s about much more than coordinating the creation of new and improved software–it’s also about coordinating all of the resources required, the features and the testing, and understanding how applications progress through the lifecycle. Essentially, true release management is not just about risk. It involves everything required to facilitate software moving into production while coordinating all of the different teams to ensure every release follows company procedures. It also makes sure all of the stakeholders are in communication to understand how the outputs of each individual team work together in the production environment.
For a DevOps team to fully embrace release management, there needs to be a change in the traditional structure that the teams are used to. Product managers need to take ownership of the deployment process with the ultimate goal to ship finished software. They should own the entire process from start to finish, and thereby become the connection between the business, the customer and the development team. However, product managers are unlikely to be experts at release management, so they need help to fulfill this role effectively. This is where the product-oriented team comes in. As DevOps adoption matures, release management responsibilities need to be transferred to the product-oriented team, though there may still be guidance from a release management group.
Why Does Release Management Still Exist?
For businesses that either don’t have a release management system in place, or that struggle with how to make it work effectively, they may question why release management is still a concept, and whether it still needs to be one. Release management is necessary for teams to manage the complex amalgamation of DevOps and distributed microservice-based architectures.
Businesses today frequently still have monolithic applications, independent from all other applications. Having these monoliths means there are dependencies, and dependencies are the death of anyone trying to run autonomously, as you still have to connect these applications with all of the others. Teams also tend to still have more stable systems of record, including ERP (Enterprise Resource Planning) applications, which are more complex to manage, particularly when changes are being made and if there is a hybrid environment involved with both on-premises and cloud. If DevOps teams do not integrate a suitable release management strategy to cope with this landscape, there can be potentially severe disruptions to day-to-day business processes.
Where Do Autonomous Teams Fit in?
Though autonomous teams are becoming increasingly self-sufficient, aspects of the business such as accessibility, security, usability and architecture reviews will never be 100% autonomous. Therefore, these teams will still require some level of guidance. Release managers are beneficial here because they have an overview of the entire process to see how every tool operates individually and alongside others, and can easily spot where bottlenecks are occurring so they can be resolved.
Not only this, but as mentioned, release management accounts for all of the areas that can’t be automated for one reason or another. To make this work efficiently, businesses will ideally introduce either a coach for the product manager, or a part-time release manager in the product team.
Whenever people are not available, there are also tools that can be implemented to make this process easier. Having a virtual release manager tool spans all of the delivery teams–it’s a combination of release process orchestration matched up with templatized and standardized releases approved by the release management team. The templates are like the blueprints for the release–they provide an example of how the release should look, creating a foundation that developers can then build on with the specifics of the desired release.
In addition to templatized releases, you should shift left governance, risk and compliance requirements left in the development and delivery. Create a series of non-functional requirements that help ensure development performs necessary tasks during the development cycle. Tasks such as accessibility reviews of the design, threat modelling or architecture review performed early can reduce risk later on, since any problems to those areas have the potential for large changes.
So, is release management dead? The answer is no. Though some businesses may be struggling to find a way to implement or adapt this methodology to fit around their existing teams, having the support and visibility of release management and any tools that are introduced can enable applications and the teams working on them to work in harmony, and ultimately improve the value that is delivered to customers.
