What is ERM (Enterprise Release Management)?
Even today, organizations struggle with a product’s release process, which is still considered very complex. This is a governance process for managing software delivery and software change in an enterprise. ERM consists of collaboration, planning, scheduling, and also about controlling the build & testing, the stability of deployed releases, and delivering new functionality required by the business while protecting the integrity of existing services. This process passes through different stages and environments, including testing and deployment.
ERM focuses on the protection of the live environment and its services, by using formal procedures and checks. The primary goal of ERM is to build, test and deliver new or changed features into the production environment within the required timescale and with minimal disruption to existing services. ERM spans various SDLC stages and is responsible for some of the important tasks below:
Identify stakeholders: One of the prime tasks is to identify internal and external key stakeholders who are involved directly and indirectly in this process. This process also involves defining roles (like Release Manager, Release Engineer, and Change Approver).
Release management teams understand the business needs based on customer feedback and they translate them into actionable development plans. Stakeholders need to be communicated about every change during all the release phases of SDLC. For example, providing timely notification to stakeholders on any change in the release schedule along with the change approval board gives an idea of when the product will be released.
Define Release Strategy:
To implement ERM for the entire organization ‘The release strategy’ must be defined and approved by the architectural group. This document must be visited periodically (generally quarterly) and amended based on the lessons learned from previous releases. Release strategy mainly consists of the definition of release types and release approaches. It also consists of details related to release planning and communications to stakeholders.
Release Types:
A release can be a collection of software, hardware, documents, processes, and other relevant components required to implement one or more approved changes to the production.
Releases can be classified into 3 categories:
Major: Releases including software and hardware upgrades/ new feature/data migration, normally containing large areas of new functionality. A major upgrade or release usually supersedes all preceding minor upgrades, releases, and emergency fixes. Infrequent release packages often include many release units with a high or critical business impact.
Minor: Releases including minor enhancements to existing productionized capability/feature or defect fixes, software changes, and hardware upgrades, normally containing small enhancements and fixes, some of which may have already been issued as emergency fixes. A minor upgrade or release usually supersedes all preceding emergency fixes. There are frequent release packages, and few release units do not contain mission-critical components.
Emergency: Emergency software and hardware fixes, normally containing the corrections to a small number of known Problems/Incidents and implemented on a need or ad hoc basis depending on the urgency of the Release. Hot fixes to restore live services impacted due to production high priority incidents. It contains quick fixes for emergency issues.
Release Approaches:
The Release can be delivered by any one of the below mentioned approaches:
Full releases: All components of the release that are implemented, built, and tested together. In this approach, all the affected components, configuration items, and CRs irrespective of whether they are modified or not, are deployed to the production environment. This is typically a major release.
Delta releases: This release includes only those components that have been changed or are new since the last full or delta release. In this release approach, only the modified/impacted CRs are tested and installed. This type of release approach is recommended when there is minimal impact on the changes made in a live environment.
Package releases: Depending on the urgency of the release, emergency software, and hardware updates typically contain the fixes to a few known Problems/Incidents and are implemented as needed or ad hoc. Hot fixes to repair live services are affected by high priority production problems. It has rapid fixes for emergency problems.
Determining the readiness:
For each release, readiness must be determined much before the release date. Readiness for release includes.
Quality of release: The release must pass through various tests like unit test, integrations test, system test, functional test, performance test, and security tests. This makes the quality better for the final release to production. The release teams should also check if the security requirements are met (governance compliance) or not. It is also ensured that verification activities like prerequisites are met before a build or test begins (release plan compliance)
Environment readiness: The environment (production or non-production) must be ready with all prerequisite configurations needed for the product to be released.
Rollout and back-out plans: Rollout and back-out plan must be documented by the release manager, with details like how it will be released, prerequisites for roll out, the impact of release, and the back-out plan in case of failure.
While implementing ERM, the above-mentioned primary tasks need to be considered.
Please watch this space for the next set of blogs in this series.
