Release Management Best PracticesABSTRACT: This article highlights the importance of an efficient Release Management process in any organization. It also suggests itSMF ITIL V3 compliant best practices for improving the service transition related processes.
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 IS RELEASE MANAGEMENT BEST PRACTICES?The previous section gave a brief overview of the release management process and its importance in any organization. Though, it 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 causing heavy damage 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 can be really 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! Best practices are generic 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. Please refer to the official ITIL website here: http://www.itil-officialsite.com/
HOW CAN ORGANIZATIONS IMPLEMENT RELEASE MANAGEMENT BEST PRACTICES?This section will suggest some generic best practices for implementing an efficient release management process in any organization. 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 1 below gives an overview of the various stages of SDLC where Release Management processes are applied.
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|
- 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.
- 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 ORGANIZATIONS UTILIZE PLUTORA TO ACHIEVE RELEASE MANAGEMENT BEST PRACTICE?
- 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 also supports test management and 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).