Release Strategy

Origin & evolution

Martin Fowler described blue-green deployment in 2010, building on practice from the continuous delivery movement. Two identical production environments, blue and green, run side by side; you deploy the new version to the idle one, switch routing across, and keep the old one warm as an instant rollback. Canary releases🚢ReleaseProduct SpecificationA shipped version of the productView reference → borrowed their name from the caged bird carried into coal mines: send a small slice of traffic to the new version, watch its health, and widen exposure only if the signals hold.

In 2018 James Governor of RedMonk coined "progressive delivery" as the umbrella term for this family. He grouped canarying, feature flags🎌Feature FlagEngineeringA feature toggle for controlled rolloutView reference →, and A/B testing at scale under one idea: release as a gradual, observable, reversible process governed by real signals rather than a single all-or-nothing cutover. Ring deployment, popularised by Microsoft's internal practice, fits the same shape, expanding from inner rings of staff and early adopters out to the general population.

The strategies diverge on where risk concentrates. Blue-green moves all traffic at once, so its risk is the switch itself, balanced by near-instant rollback. Rolling updates replace instances incrementally with no second environment, trading rollback speed for resource efficiency. Canary and ring keep the old version serving most users while a measured fraction tests the new one. Feature flags decouple the strategy entirely from the deploy, letting code ship dark and activate later by configuration.

How it works in practice

A team ships a rewritten search backend to a service handling 50,000 sessions an hour. A blue-green switch would be all-or-nothing, so they choose a canary. The deployment routes 1% of traffic to the new version and watches error rate and p99 latency against the canary's golden signals for ten minutes.

At 5% the new version's latency holds at 140ms, matching the baseline, and the rollout proceeds to 25%, then 50%, then 100% over an hour. Had errors spiked at 5%, the strategy's exit condition would have pulled traffic back to the old version automatically, capping the damage at a twentieth of users. The release strategy defined those gates and thresholds up front; the deployment merely executed them. The same strategy can govern next week's release of an unrelated component, which is exactly why it is worth naming once and reusing.

Release strategy vs. its neighbours

• Deployment. A deployment📤DeploymentEngineeringA deployment eventView reference → is a single act of pushing a specific version to a specific environment at a specific time. A release strategy is the reusable pattern that act follows. One canary strategy governs hundreds of deployments; the graph links them through release_strategy_used_by_deploymentRelease Strategyused byDeploymentcross-domain so the policy stays distinct from each instance.
• Feature flag. A feature_flag🎌Feature FlagEngineeringA feature toggle for controlled rolloutView reference → toggles a capability💪CapabilityStrategyAn ability that enables value deliveryView reference → at runtime without redeploying. It can be a release strategy in its own right (flagged rollout) or a control used within another, such as gating a canary cohort👥CohortGrowthA group of users sharing a common characteristicView reference →. The flag is the switch; the strategy decides when and for whom to throw it.
• Release. A release🚢ReleaseProduct SpecificationA shipped version of the productView reference → is the versioned bundle of changes being shipped, the what. The release strategy is the how. The same release can go out via blue-green to one component and rolling to another.

In the graph

In the Unified Product Graph a release strategy is a reusable operations entity that products and infrastructure adopt rather than reinvent per deploy. A product connects through product_released_via_release_strategyProductreleased viaRelease Strategyhierarchy, an infrastructure component🖧Infrastructure ComponentDevOps & PlatformAn infrastructure component (server, CDN, etc.)View reference → through infrastructure_component_released_via_release_strategyInfrastructure Componentreleased viaRelease Strategyhierarchy, and individual rollouts attach through release_strategy_used_by_deploymentRelease Strategyused byDeploymentcross-domain. Keeping the strategy separate from the deployment lets a team query, in one place, how every part of the product reaches users, and spot the component still shipping by an unguarded big-bang push.