What is Release Management in DevOps?
Hope you would have been clear about Configuration Management concept in DevOps from our last tutorial.
As we defined DevOps earlier, DevOps is the entire team owning the software from its inception until it is delivered to the production and ensuring that the application is performing in the production as per the requirements.
Recommended Reading => Best Ever DevOps Training Tutorials
Hence, ‘Release Management’ as we all know is to manage which version of the software is deployed to which environment, when and how is not just the responsibility of the Release Manager, but the responsibility of the entire team in DevOps.
The prime benefits of Release Management in DevOps can be summarized as,
- Faster and consistent deliveries.
- Strong auditing and Traceability of changes.
- Automation of the release process: Higher quality, consistency, confidence.
- Boosts confidence through successful and consistent deliveries.
- Making release – unstressed activity
- No downtime
VIDEO Part4 Block 2: Release Management – 17 minutes 12 seconds
In this block, we will understand the Release Management procedure of DevOps.
What is Release Management in the DevOps context and what are its primary Benefits?
When I think of release management, the various questions that arise in my mind are, which release is running in which environment, and what patches have been applied there? Which are the hotfixes that have been deployed and for which customer it is?
I know, it is the headache of the release manager to keep a track of all these information. We know, earlier, release management neither used to be the responsibility of the Dev or the Ops. It was a separate release management team who used to manage the software release activities.
And a separate board called CCB and CAB, change control board, change approval board, used to handle the responsibility of managing the changes and controlling on what is applied and what is not.
But now things have changed with the DevOps. And it is no more just the responsibility of the release manager but the entire team.
As we defined DevOps earlier, DevOps is an entire team owning the software from the inception until it is delivered to the production and ensuring that the application is performing in the production as per the requirements.
Thus, in DevOps, unless the code is deployed on to the site and is monitored for its performance successfully for over a specific period, the software development task is not complete.
Hence, the responsibility of the software delivery and its performance in live lies with everyone in the team. So does the release management tasks.
We will learn more about Release management aspects in DevOps.
Let us understand What is Release Management?
As we all know, from a broad perspective, release management is managing and maintaining the information’s like, which version of the software or the components are deployed to which environments, when and how it was deployed.
So, this is all about release management.
Let us see how the Release Management Process works.
Unlike earlier, there is no formal CCB’s in DevOps. But it does not mean that there are no approvals made on to the changes.
Approvals also happen via a tool. The change management tools like Jeera and ClearQuest are used to carry out the recording and approval of changes and routing them into the Dev team for building purpose to a backlog as a technical debt or a new requirement.
These changes picked up by the program team are built, tested and get automatically deployed to the production along with the automated delivery pipeline. But every change is getting logged, in the version control and these changes are audited and tested throughout the delivery pipeline.
So, whatever changes are made by the team, are recorded in the version control tool and what successfully got deployed on to the environments and their configurations are available in the configuration tool.
Hence, both version control and configuration management together give us a clear picture of what is being released, when it is released, where it is released and how it is released.
So, in the context of DevOps, it is basically the version control and the configuration management which acts as a release management tool. So, these two processes and tools act as a CCB, which we call in our traditional development method.
Basically, it automates the work of a CCB manager, who ideally verifies each of these changes or releases and certifies to let it go to production.
In case of DevOps, it is not the release that gets certified but the entire delivery pipeline that gets certified in an automated way along with manual gates.
As such release management is not a separate activity as a part of DevOps, but it is built in already as a part of the DevOps pipeline or delivery pipeline along with version control, configuration management, and deployment pipeline.
So, version control when coupled together with configuration management makes the release management.
And while we are moving into the DevOps practice where we are targeting to make deliveries over a period of few hours, practically it is impossible to manage such frequent deployments and its record and maintenance manually by the traditional release management processes where they manage manually with automation to a very little extent.
So, total automation of the release management process is a must.
Also, in DevOps pipeline, we don’t need to control the deployments, if the changes are approved, built, tested and gets into the version control, automatically they get applied to the production. Of course, feature toggles are there to switch on or off to control them in the production.
Auditing and traceability of every change are one of the strongest benefits that we have from the release management perspective. So, when we build the DevOps pipeline or delivery pipeline, we inbuild this logging and auditing within the pipeline, so that the real-time happenings on the environment are recorded and audited.
So, we are going to get the actual happenings that come out due to the action of deploying the application on to the environment. Being shorter and smaller release, it is quite easy to track these changes throughout the pipeline.
We have come to the Tools part of the Release management.
Release Management tools which are available on the market ensure that the automatic deployment of changes is timely and error-free and they target to deliver the maximum value to the users.
Basically, they are the deployment tools, that are used in the delivery pipeline during the automated deployment.
XL Release is one such release management tool which is specific for Continuous Deployment. As I said earlier, these tools help the DevOps teams to design their deployment model and help in monitoring the releases by automating all the tasks related to the deployment and managing the releases.
Plutora is another such robust tool which provides an on-demand Enterprise IT Release Management software toolset that helps in delivering the releases.
BMC Software’s Release Lifecycle Management product is also a release management tool from BMC Software that provides end-to-end visibility of the software release’s progress. It seems, through a central web-based portal, users can track the application development, QA and production to monitor the implications of every change made.
There’s another tool from XebiaLabs. This tool enables to plan, automate and analyze the pipeline for their software releases.
Let us list the benefits of the automated release management system of DevOps.
First of all, the entire release management processes, that is being automated helps the team to have quicker and consistent deliveries made to the customers.
We learned that, whenever any release or change is pushed through a continuous delivery pipeline in DevOps environment, every information of what actually has happened on the environment, would be clearly written down into the logs.
So, we will have actual things or real-time happenings that is written down into the log, as of what happened during the actual deployment of the release on to a particular environment.
So, with this, we have a very very strong auditing and traceability of changes maintained in DevOps.
Any time, anybody makes any changes in any part of the delivery pipeline, will be traced.
We will have in version control, what has been changed, what has been deployed and its respective configurations. So, this, provides a clear visibility on the details about, what has been delivered, to where it has been delivered, when and how, in case of each release.
Automation of the release pipeline is another great feature of the DevOps, that prevents manual intervention as much as possible and it is also very easy to trace back in case of release failures, by comparing the failed release with the successful release.
So, automation of the release pipeline provides us the higher quality of delivery within minutes. Human errors, consistency and obviously greater confidence in the deliveries are made.
This also enables the team to feel that the deployment or ‘release to production’ as a routine or daily schedule, by making them understand the release pipeline and its deployments thoroughly.
No doubt that this comfort and time saving allows the people to focus more on the other important things than the routine stuff.
We know earlier, releases used to happen after hours or early hours and generally on weekends. And the team was required to support these releases on those timings.
Think of all the stressful moments before the release that would happen, being awake in the after hours or early morning to carry out the deployment, ending up in committing human errors, forgetting to make a change, and then praying God to make the release successful and so on.
So now, the current DevOps method of deployment and release management has put a curtain to all our earlier woes of stressful moments.
No more weekend deployments, no more sleepless nights and no more deployment stress. Everything is automated. So, releasing new features or updating changes is no more a stressful activity.
The DevOps method of deployment involves, no downtime or any kind of interruptions to the users as against the earlier case of sending annoying downtime messages to all the customers and asking them to stop using the service or giving them sudden surprises with the unexpected problems that occurred during the upgrade and further extending the downtime.
Ridiculous !! Why should they be bothered about the software upgrades that we are doing or why should they be in trouble with these updates?
Do not disturb the users with whatever updates that the software team is making on to the server. Hence DevOps way of making releases has brought an end to all these problems.
No more overnight deployments, no more patches delivering to the customers, and no more service outage.
With this, we are completing the topic of ‘Release Management in DevOps’.
In our upcoming tutorial, we will learn more about the Application Performance Monitoring process in DevOps.