Release management strategy and framework

Release management is the process of managing, planning, scheduling, and controlling a software build through different stages and environments, including testing and deploying software releases. (Source Wikipedia)

Release management provides a governance framework for delivering large, highly integrated software changes within complex organizations. It includes the synchronization and orchestration of an organization’s portfolio across multiple releases. Each change delivered to the production system can disrupt the IT service and negatively impact the business operations. Therefore, release management protects the production asset while providing value to the customer.

Organizations need to tailor the release strategy to meet their needs guided by best practices. There is no one size fits all. The strategy should define release types, standards, and governance requirements for an organization. Where an organization used multiple deployment methodologies from a waterfall, agile, and Scaled Agile Framework (SAFe), the release strategy needs to accommodate each of these, and all deployment methodologies need to follow the release strategy.

 

Release train strategy (an example of one strategy)

• The 'train' may release weekly, monthly, or quarterly. The weekly release may be a minor release, while a monthly release/quarterly release could be a major release.
• Every team associated with the release train has the same cadence with clear guidance on the key milestones per release.
• The strategy is well suited to large complex changes where multiple project teams are working as part of a larger release program.
  

 

Major releases

All large projects and programs should be delivered as part of a major release. Additionally, any feature or enhancement that contains a high or critical business impact (including retrofit changes) should be included in a major release. The governance of a major release provides the necessary rigor to ensure any risks are clearly understood and mitigated to protect the production environment and business continuity. 

 

Minor releases

Minor releases should not add new features or enhancements that contain a high or critical business impact. These changes should have no regressive impact, should not require service management knowledge transfer, and should not require any retrofit business communication. A minor release should include business as usual (BAU) and routine changes. Impact assessment tools can be used to ensure all objects included in a minor release are not invasive by nature (e.g., little to no regression risk).

Governance

A clear governance structure needs to be developed to support the release strategy. Before the start of the deployment activities, a Go-No-Go meeting should be convened to approve a major release deployment. Typically, there would be decision-makers from the following areas: product owners/ functional leads; business stakeholders (IT steering leads); regulatory & compliance; IT operations, and portfolio management.

Go-No-Go meetings should review the following key criteria:

• Solution readiness (system, process, and data including testing)
• People and organization (business and IT readiness)
• Release cutover and Go-Live readiness
• Handover to service management
• Operational risks
• Regulatory and compliance

A list of conditions that need to be satisfied (prior to the start of deployment) can be included in a "conditional go" decision to ensure any actions from the Go-No-Go meeting are met before starting the release cutover.

 Testing (regression, functional, E2E, and user acceptance testing)

The major release scope needs to be frozen before moving to the quality assurance (pre-production) environment. Based on the frozen scope of the release, regression testing requirements can be finalized. Typically, a standard regression test pack is supplemented with additional regression test cases depending on the release's scope. Automated impact assessment tools can be used to establish the regression risk related to the impacted objects contained in the release. 

This, in turn, can determine the supplemental regression test cases that are required to mitigate the specific regression risk contained in a release. 

Test management needs to sign off that the regression and all functional and E2E testing has been completed.

Before deployment, any open defects need to be fully impact assessed and discussed as part of the Go-No-Go meeting to determine any risks that may be carried forward into the production landscape. When a defect is moved to production, a business workaround may need to be put in place and communicated to all impacted users. 

Overseeing the deployment (i.e., cutover management)

Complex release deployments with specific sequencing requirements increase the risk of failure. The cutover process should be streamlined and automated as far as possible to reduce error-prone manual activities and accelerate the deployment process. All resources required for the cutover need to be aligned to support the release cutover activities. The deployment into the quality assurance (pre-production) environment should act as a dry run for the later deployment to production.