Plutora Blog - Release Management
Release Management Best PracticesReading time 8 minutes
In this article I’ve endeavored to highlight the importance of an efficient Release Management process across a wide swath of industries and organizations. I’ve also went to lengths to refine and codify itSMF ITIL V3 compliant best practices for improving the service transition related processes. Please let me know in the comments if you have something to add or if I’ve omitted any best practices.
What is a Release Management Process?
The Release management process is an important component of the service transition process, which is described in the itSMF ITIL v3 framework. The main aim of Release Management is to build, test and deliver the capability to provide the services that are specified by Service Design and that will accomplish the stakeholder’s requirements and deliver the intended objectives.
All new or changed services have to go through a Release Management process to ensure that the capabilities expected by the stakeholder’s are achieved as expected.
For Example: An e-commerce company named XYZ may be adding a new webpage to sell bikes online. Once the development team at XYZ writes the code for the new webpage, it may need to be tested by multiple test teams and across different environments, before it is finally deployed in Production for usage by end users or customers. The company XYZ might be hosting their e-portal on Amazon EC2 Cloud servers. The release process will ensure that the code written by the development team is built using some build tool (such as MS Build by Microsoft, Ant scripts etc.,) which are compatible with Amazon EC2 and are unit tested. Once the testing of the build packet is completed and passed, it can be deployed in environments for testing or live usage.
Therefore, in a way, the Release Management process is a critical bridge between Development and Testing/Production. It is an intermediate step to ensure the integrity of the code and to guarantee that the deployed code will work as per the expectations of stakeholders.
What Are Release Management Best Practices?
Though Release Management is an important component of the Service Transition process, a lot of companies lack the required assets or process steps for achieving successful delivery of components or services. This often results in too many bugs or live system crashes incurring heavy costs both in terms of money and business credibility.
Therefore, it is important to implement an efficient release management process that would rightly fit with a company’s culture and stakeholder requirements.
For Example: An e-commerce company named XYZ may be adding a new webpage to sell bikes online. Once the development team at XYZ writes the code for the new webpage, it may need to be tested by multiple test teams and across different environments, before it is finally deployed in Production, for usage by end users or customers.
A lot of companies lack this process of efficiently deploying the code from development into test environments or production environments, resulting in Production bugs or failures. It should go without saying that it’d be awful if customers are in the middle of an e-commerce transaction and all of a sudden the webpage goes off due to some application software crash!
So the need arises for Release Management best practices. In this case “best practices” refer to the universalized guidelines created by companies who have already implemented ITIL successfully and refined it over a period of time to derive maximum efficiency. These guidelines are officially owned and published by the British Cabinet Office. ITIL Release Management processes have been successfully implemented by organizations such as NASA, UK National Health Service (NHS), HSBC Bank and Disney.
For further instruction, please refer to the official ITIL website.
How Can Organization Implement Release Management Best Practices?
While best practice guidelines are instrumental to a successful process upgrade, these guidelines will have to be tailored by organizations, based on their custom requirements. Please also note that it is not required to implement each and every step suggested in the best practice.
In a nutshell, the table below gives an overview of the various stages of SDLC where Release Management processes are applied.
|SDLC STAGE||RELEASE PROCESS PHASES|
|Development||Release Policy/Planning, SW/HW Design|
|Testing||Build & Configure Release, QA, Release Accepted, Rollout Plan, Communicate & Train|
|Production||Implement Release, Verify Implementation|
Figure 1 below gives an overview of the various stages of SDLC, where release management processes need to be implemented. As depicted below, although release management matters more during the Transition phase and in Operations, the planning of releases need to start during the Development phase itself.
Figure 1 displays the Release Management processes spread across various stages of SDLC:
- Release Policy:
Organizations need to align their strategic goals with the enterprise release. This is the phase in which organizations define the end goals, scope, and principles with regards to adopting the release management processes across the enterprise. The ideal time for charting out a release policy is either before any development activity or during development.
- Release Planning:
Based on the release policy guidelines, enterprise release plans are designed and formally approved by senior management. This not only contains the governance aspects, but also the detailed process designs for implementing releases across the organizations. These plans are generic frameworks that can be tailored by individual Business Units or teams as per their specific requirements.
- Hardware/Software Design:
This is the phase where the actual assets required for a release are designed and configured. This may include the application servers, hardware servers, source control tools, build tools etc. that would be required for the build, test and delivery of code. This needs to be done during the development stage and before the testing stages of SDLC.
- Build & Configure Release:
This is the phase where the code from development is build using build tools, tested internally to ensure build integrity and finally delivered in target environments.
- Quality Review:
During this phase, the quality of the release is assessed by the QA team. This includes checking that the release meets minimum acceptable standards and business requirements.
- Release Accepted:
Once a release has been successfully tested by the QA team, the functional team will validate the results and if everything is good, the release will be approved for deployment in production. Any bugs identified during the QA Review stage will be rejected and sent back to the development team for review and bug fix.
- Rollout Plan:
Once a release has been accepted by the QA team, it is ready for deployment in the Production environment where end-users or customers will be able to access the new capabilities released.
- Communicate and Train:
Communication and training are critical elements of a service delivery or transition. It is a process by which the clients or end-users are communicated about product feature or service releases and train them to use the new releases.
- Implement Release:
In this phase, the release units that were tested in the testing stage of SDLC are deployed in Production environments for live or real time usage.
- Verify Implementation:
It is a good practice to verify a release, each time it is deployed in Production. This is to ensure that the release behaves as expected in the live environment.
Bear in mind these pointers for implementing efficient Release Management processes:
- itSMF ITIL v3 guidelines recommend organizations to implement the above defined phases in a logical and consistent manner across the business units or teams.
- It is necessary to setup a central Change Advisory Board (CAB) who would oversee all the changes across the organization.
- It is essential to design a monolithic release management system that will tightly integrate the various components required for a successful release. Plutora supports an integrated Release Management product that can be utilised by organizations right from the Release planning stages all the way until the production stage of SDLC.
How Can Organization Utilize SaaS Tool to Align with Release Management Best Practice?
Here are five fast facts I’ve put together explaining why Plutora stands apart as the tool best suited to actualize Release Management best practices:
- Plutora supports an end to end Release Management tool which is fully compliant with the itSMF ITIL v3 guidelines. It also has an integrated Change Management component and integrates with third party Service Management tools.
- Plutora is highly scalable and easy to implement as per the dynamic needs of the organization.
- Plutora supports test management & deployment management components that can be configured to create an end-to-end service delivery system.
- Due to the centralized nature of the tool, administration and updates can be extremely simple and easy.
- Plutora is a SaaS (Software As A Service) tool, which means that it can be accessed from any geographic location (with internet access).
Conclusion: Release Management is an important component of the service transition process. If organizations correctly implement the ITIL best practices from this article, they can not only maximize the efficiency of the release processes, but also save a lot of money and improve the business value of services.