Skip to content
sec/atlas
back to the map
practice
stage: deliver
2 min read

Release strategies and rollback

Deploying and releasing are different. You can put code in production dark, then turn it on gradually and turn it off in seconds if it misbehaves.

Kubernetes rolling updatesArgo Rollouts / Flaggerfeature flags (OpenFeature, Unleash)load balancersdatabase migrations tools

The strategies

  • Rolling: replace instances a few at a time. Simple and the default in most orchestrators; old and new versions run side by side for a while.
  • Blue/green: keep two full environments and switch traffic from the old (blue) to the new (green) at once. Rollback is switching back; costs double capacity during the switch.
  • Canary: send a small share of traffic to the new version, watch the metrics, then widen. Limits the of a bad release.
  • Feature flags: ship code disabled and enable it per user, percentage or environment. Separates deploy from release and gives an instant off switch.
  • Shadow traffic: copy real requests to the new version without returning its answers, to compare behavior safely.

Rollback is a design decision

  • Keep the previous artifact deployable and deploy by immutable version or digest.
  • Make database changes backward compatible (expand, migrate, contract) so the old code still works with the new schema.
  • Decide in advance what metric triggers a rollback, and automate it where you can.
  • Practice the rollback: an untested rollback is a hope.

Example: a canary rollout

A progressive delivery controller moves traffic in steps and checks metrics between them. The sketch below uses Argo Rollouts syntax.

rollout.yaml (Argo Rollouts)yaml
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: api
spec:
  replicas: 6
  selector:
    matchLabels: { app: api }
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: { duration: 5m }
        - setWeight: 50
        - pause: { duration: 10m }
  template:
    metadata:
      labels: { app: api }
    spec:
      containers:
        - name: api
          image: registry.example.com/api@sha256:<digest>

Choosing

Match the strategy to the risk and the cost. A low-risk internal tool can use rolling updates. A payment path deserves a canary with automatic rollback. A change that touches data needs the compatible-schema discipline whatever the strategy.

Blast radiusblast radiusThe size of the damage when something breaks: one account, an entire region, a tenant. Good cloud design limits the radius through isolation (separate accounts, separate VPCs, narrow roles) so that a failure or an attack does not become a full-blown disaster.see in glossary →

connections on the map

updated on 14/10/2026 · sources to go deeper · report an error

in other domains

Study before

test what you learned

Loading questions…