Progressive delivery

Blue/green, canary, rolling, auto-rollback.

How you roll out a change determines its blast radius if something goes wrong. Progressive delivery strategies — blue/green, canary, rolling — plus automated rollback let you deploy with minimal risk and recover fast.

Blue/green, canary, and rolling

Blue/green runs a new (green) environment alongside the current (blue) one, then shifts all traffic to green at cutover — giving instant rollback (switch back to blue) and no downtime, at the cost of running two environments briefly. Canary releases the new version to a small subset of users first, watches metrics, and expands gradually only if healthy — limiting the blast radius of a bad release and rolling back before most users are affected. Rolling updates replace instances in batches, keeping the service available throughout. App Service deployment slots make blue/green easy: deploy to a staging slot, warm it, and swap slots for a zero-downtime cutover with instant rollback by swapping back. The right strategy depends on the workload and risk tolerance.

#  STRATEGY     HOW                                    ROLLBACK
#  blue/green   new env beside old, shift traffic      switch back (instant)
#  canary       small % first, watch metrics, expand   stop + revert the %
#  rolling      replace instances in batches           roll batches back
#
# App Service slots = easy blue/green:
az webapp deployment slot swap -g app-rg -n contoso-web --slot staging
#   deploy to staging → warm → swap → (swap back to roll back instantly)

Automated rollback

Progressive delivery only works when paired with monitoring and automated rollback. You define health signals — error rate, latency, failed health checks, a spiking alert — and the pipeline automatically reverts to the last good version when they degrade during or after a deployment, containing a bad release in seconds without waiting for a human to notice. This is why canary and blue/green are watched: the deployment observes metrics and decides to proceed or roll back. Combined with feature flags (turn a bad feature off without redeploying) and deployment slots (swap back), automated rollback means a failed release is a brief, self-correcting event rather than an outage. The engineer builds deployments that are not just automated but self-protecting — they watch their own health and undo themselves when something is wrong.