Rolling, blue-green and canary

Key points

• Rolling replaces pods a few at a time. It is the cheap default, but both versions are live for the whole rollout.
• Blue-green runs a complete second stack and flips traffic in one move. Instant rollback, double the infrastructure while it lasts.
• Canary sends a small share to the new version, watches error rate and latency, then promotes it or sends the share back to zero.
• All three demand backward-compatible changes: additive API fields, and migrations the previous version still tolerates.
• Separate deploy from release with feature flags. Ship the code dark, enable it for 1% of users, disable it without a build.
• Rollback has to be a button, not a rebuild. If reverting takes twenty minutes, your canary window is far too long to be useful.

Example

# Argo Rollouts: the promotion schedule is config, not a runbook.
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: orders
spec:
  replicas: 10
  strategy:
    canary:
      steps:
        - setWeight: 5                 # 5% of live traffic to the new version
        - pause: { duration: 5m }      # watch 5xx and p99 during this window
        - setWeight: 25
        - pause: { duration: 10m }
        - setWeight: 100
      analysis:
        templates:
          - templateName: error-rate   # a bad window aborts and reverts to 0%
  selector:
    matchLabels:
      app: orders
  template:
    metadata:
      labels:
        app: orders
    spec:
      containers:
        - name: app
          image: registry.example.com/orders:1.5.0

Deploy small, watch the new version under real traffic, and keep rollback one step away.