Blue/Green & Canary Deployments — Low-Risk Releases

Blue/Green: run old and new in parallel, flip traffic instantly. Canary: gradually shift a percentage of traffic to the new version.

When to use

• Blue/Green: zero-downtime releases with instant rollback capability; backward-compatible schema migrations
• Canary: gradual confidence building — validate on 1% of traffic before full rollout; A/B testing alongside feature flags

Tradeoffs

• Blue/Green doubles infrastructure cost during the deployment window
• Canary needs traffic splitting infrastructure and SLO monitoring to trigger auto-rollback

Blue/Green (K8s)

# Two Deployments — swap the Service selector to flip traffic
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-green          # new version
spec:
  replicas: 3
  selector:
    matchLabels: { app: api, version: green }
  template:
    metadata:
      labels: { app: api, version: green }
    spec:
      containers:
        - name: api
          image: myapp:2.0.0
---
apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector:
    app: api
    version: green         # flip from "blue" to "green" to cut over
  ports:
    - port: 80
      targetPort: 8080

Canary (K8s)

# Canary: run two Deployments, control split via replica ratio
# 9 blue replicas + 1 canary replica ≈ 10% canary traffic
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-canary
spec:
  replicas: 1              # 1 out of 10 total pods = ~10%
  selector:
    matchLabels: { app: api, version: canary }
  template:
    metadata:
      labels: { app: api, version: canary }
    spec:
      containers:
        - name: api
          image: myapp:2.0.0
---
apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector:
    app: api               # routes to BOTH blue and canary pods
  ports:
    - port: 80
      targetPort: 8080

Gotcha: Canary without monitoring is just slow rollout. Wire SLO alerts to auto-rollback: if error budget burn rate spikes on canary traffic, roll back automatically.