Release Strategies

Release Strategies refer to the techniques and approaches teams use to deploy new changes into production in a controlled, low-risk, and user-sensitive way.
These include practices like blue/green deployments, canary releases, feature toggles, progressive rollouts, and dark launches — all aimed at reducing blast radius, enabling faster feedback, and improving customer experience.

Level 1 – Initial (Ad Hoc)

Releases are manual, infrequent, and high-risk.
There is no structured strategy or mechanism for controlling or minimising the impact of new changes.

  • Deployments happen after long cycles of change
  • Rollbacks are manual and error-prone (if possible at all)
  • All users are affected by changes immediately upon release
  • Downtime or service degradation is common during releases
  • Releases are scheduled around low-usage periods to avoid impact

Level 2 – Managed (Emerging Practice)

Some release patterns begin to emerge, typically in teams seeking to reduce risk or improve control, but practices are not consistent or scalable.

  • Feature toggles or conditional logic may be used in code
  • Canary or blue/green deployments may be attempted manually
  • Some environments are used for early testing, but promotion is manual
  • There is little to no telemetry to support decision-making during release
  • Rollbacks may require re-deployment or hotfix patches

Level 3 – Defined (Standardised)

Modern release strategies are adopted consistently across teams and environments.
They are codified into pipelines and infrastructure.

  • Feature toggles, canary releases, or blue/green deployments are used systematically
  • Rollback strategies are tested, documented, and automated
  • Releases are decoupled from deployments (e.g. through toggles or API versioning)
  • Teams use observability tools to monitor new features post-release
  • Release strategies are embedded in CI/CD and environment provisioning

Level 4 – Quantitatively Managed (Measured & Controlled)

Release strategies are optimised using data and feedback loops.
The team proactively monitors performance and user experience before, during, and after releases.

  • Metrics include deployment frequency, change failure rate, time-to-recovery, and feature adoption
  • Progressive rollouts are informed by telemetry (e.g. error rate, latency, user behaviour)
  • Release decisions are based on risk scoring and real-time insights
  • Feature toggles are governed (e.g. lifecycle management, cleanup policies)
  • Teams use feedback from early adopters to validate new changes before full rollout

Level 5 – Optimising (Continuous Improvement)

Release strategies are advanced, automated, and continuously evolving.
They enable experimentation, innovation, and confident delivery at scale.

  • AI/ML-assisted anomaly detection halts or rolls back risky deployments automatically
  • Teams run dark launches or A/B tests in production to evaluate features
  • Developers can release features independently via self-service mechanisms
  • Feedback loops are integrated into product and engineering decisions
  • Releases drive learning, customer insights, and competitive advantage