Blue-green and canary deploys from your pipeline

Ship with zero downtime and instant rollback by shifting traffic between versions instead of replacing in place.

Rolling updates replace pods in place — if the new version is bad, part of your fleet is already serving errors before you notice. Blue-green keeps two full versions alive and flips traffic between them; canary sends a slice of traffic to the candidate while metrics decide promotion. Rollback becomes a routing change measured in seconds, not a redeploy praying the old artifact still exists.

You will deploy green beside blue, smoke-test without live traffic, shift the router or Service selector, and automate canary steps with analysis hooks. Budget briefly for double capacity during cutover — the cost of an extra replica set is cheaper than the revenue lost during a bad rolling deploy. The pattern works on Kubernetes Services, load balancers, and GitLab environments — pipeline orchestration details align with Secure CI/CD with GitLab and progressive delivery modules there.

The switch is routing, not redeploy

At its simplest on Kubernetes, blue-green is two Deployments or ReplicaSets behind one Service — flip the selector label and endpoints update. On AWS or GCP the same idea is two target groups behind an ALB or load balancer rule. The pipeline job that matters is the traffic shift, not another kubectl apply under fire. Document the rollback command in the runbook and in the pipeline itself so on-call does not invent flags at 2am.

# green already deployed and smoke-tested
kubectl patch service api -n prod -p \
  '{"spec":{"selector":{"version":"green"}}}'
 
# rollback: patch selector back to version=blue

Canary when all-at-once is too bold

Argo Rollouts (or Flagger) automates weighted traffic shifts and metric analysis — promote 10%, pause, check Prometheus error rate, then 50%, then 100%. A failed analysis at 10% only ever touched 10% of users. Encode steps in the Rollout spec so promotion is policy, not a human remembering to watch Grafana. Wire analysis templates to symptoms users feel — 5xx rate, p99 latency — not cause metrics like CPU that lie during partial outages.

strategy:
  canary:
    steps:
      - setWeight: 10
      - pause: { duration: 5m }
      - analysis:
          templates:
            - templateName: error-rate
      - setWeight: 50
      - pause: { duration: 5m }
      - setWeight: 100

Where this goes next

Traffic shifting only helps when health checks and graceful shutdown drain connections — otherwise the new version drops in-flight requests during the cutover. Wire deploy pipelines to require green CI scans, signed images, and post-promotion smoke tests before the router moves. Pair progressive delivery with review apps so stakeholders validate features in isolation before any percentage of production traffic sees them. Secure CI/CD with GitLab ties environments, progressive delivery, and supply-chain gates into one pipeline story.

Related posts