Release management strategy and framework

Release Management

What is release management?

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.

Release management objectives:

  • Deliver value early and often to the business
  • Protect the production asset
  • Minimize business disruption
  • Protect month-end and corporate reporting
  • Ensure the production asset remains validated and supportable

Utilize the release management framework below to meet the above objectives:

  • Release strategy
  • Release scheduling
  • Regulatory compliance & quality management
  • Testing (regression, functional, E2E and user acceptance testing)
  • Overseeing the deployment (i.e., cutover management)
  • Maintaining business alignment (i.e., software retrofit)
  • Handover to service management

Release strategy

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.

Release scheduling

The Release schedule should be developed in conjunction with the organization's portfolio management team to ensure that value is delivered to the customer, based on strategic business priorities and considering the interdependencies between projects and programs. The pipeline of change needs to be managed and scheduled into releases to maximize the value stream. The release schedule needs to be published and visible to ensure everyone is aligned with the release schedule, outage requirements, and any freeze periods (e.g., to protect month-end and corporate reporting).

Regulatory compliance and quality management

For a company working in a regulated industry, the release management process must ensure that the computer systems remain validated. Computer validation is a documented process that provides a high degree of assurance that a facility, laboratory, computer, process, or system will consistently and reproducibly produce a product or perform to a predetermined specification. Computer validation covers all activities from design through to final approval for use.

The following regulatory terminology identifies key aspects of computer validation:

  • Design Qualification (DQ) – Documented evidence that the system's design and/or modification conforms to operational and regulatory expectations.
  • Installation Qualification (IQ) – Documented evidence that the system has been properly installed, configured, and/or modified following the approved system design specification and installation plan.
  • Operational Qualification (OQ) – Documented evidence (e.g., collection of test cases and test results) that verify that the system performs as intended in accordance with the approved system design. 
  • Performance Qualification (PQ) – Documented evidence that the system performs as intended in production by meeting predetermined acceptance criteria.

Releases containing GxP changes need to include the organization's regulatory & compliance team.  

 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.   

Maintaining business alignment (i.e., software retrofit)

Within regulated industries, any new functionality and impacted business processes need to be trained out before the deployment to production. Enough employees need to be trained to ensure business continuity. Any employees that have not completed their training should not have access to the new or updated functionality.  

Clear business communication is required to ensure that the content and timing of a release is visible to the impacted audience. In conjunction with the portfolio management team, the actual value realized from a release should be tracked and communicated back to the key business stakeholders.  

Handover to service management

The Service management team should be engaged for the duration of the release lifecycle to ensure that knowledge transfer and support documentation is in place to support all enhancements, new business acquisitions, and any new geographic region that form part of a release.

As part of the incident management process, any issues stemming from the release should be tagged to allow a review of the release and implement any corrective actions and/or improvements to the Release process that are required.

Conclusion

Your Release management strategy should be robust and closely linked to deployment and test strategies.

At Tenthpin, we offer release management and delivery services, tailored to your project and business needs. We have a highly skilled and experienced team to provide consulting and assurance services and support in release management, test management, tools, and vendor selection.

Contact our industry experts at Tenthpin if you would like to learn more.

Stay up to date with the latest #LifeSciences #Pharma #MedDevices #AnimalHealth #Agriculture #Chemicals #S/4 #Oil & Gas #Diversified Industries news by following us on Twitter @TenthpinMC Instagram #LifeAtTenthpin Facebook Tenthpin and our Tenthpin LinkedIn corporate page.

Robert Augustine

written by

Robert Augustine

Advisor

Michael Tessendorf

Michael Tessendorf

Advisor

We continuously optimize the online experience for our visitors by using cookies. For more information, please view our privacy guideline.