Design a deployment strategy

Every strategy here trades blast radius against cost and complexity. Learn what each one limits.

Strategy	What it does	Limits damage by
Blue-green	Two identical, full-capacity environments; validate green, then route traffic to it at once or progressively	Retained blue pool provides a fast traffic-routing rollback
Canary	Small slice of traffic to the new version, then widen	Fraction of users exposed
Ring / progressive exposure	Successive audiences: internal → early adopters → everyone	Audience, over time
A/B testing	Two versions in parallel to measure behaviour	Primary purpose is comparison — a product experiment
Feature flags	Ship dormant code; enable at runtime	Decouples release from deploy

The distinction that gets tested

A/B testing's primary purpose is comparison, not rollout safety. Canary and ring exist to limit who is hurt by a bad release. A/B testing exists to find out which variant performs better against a business metric. All can allocate exposure, but their primary success criteria differ.

Feature flags can be combined with these deployment strategies. They decouple release from deployment: code ships to production disabled, and you turn it on later without redeploying. If the flagged feature causes trouble, turning it off avoids rebuilding and redeploying the application.

Traffic percentage alone does not distinguish canary from blue-green. Canary is defined by starting with a small population; blue-green is defined by parallel, full-capacity pools and may also shift traffic progressively.

Mapping to Azure Pipelines

Only runOnce, rolling and canary are strategy: keywords. Blue-green and ring are patterns you build from environments, slots, traffic routing and approvals.

Primary sources

Deployment strategies

Design a deployment strategy

The distinction that gets tested

Mapping to Azure Pipelines