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.
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 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).
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.