CI/CD
Intermediate 16 min read CI/CD

Deployment Strategies

Deployment is the riskiest step in the pipeline. Compare rolling, blue-green and canary strategies, use feature flags to decouple release from deploy, and design for zero downtime with fast, safe rollback.

rollingblue-greencanaryfeature flagszero downtimerollbackreplicaload balancer
Prerequisites: CI/CD Fundamentals Designing Pipelines
Introduction

What is this?

A deployment strategy is how a new version replaces the old one in production. Rolling updates swap instances gradually; blue-green runs two full stacks and switches traffic in one jump; canary routes a small percentage of users to the new version first. Feature flags separate code release from user visibility, enabling deploy-then-enable workflows and instant toggles.

Motivation

Why do you need it?

  • Zero-downtime deployment keeps users served while a new version takes over.
  • Gradual strategies limit blast radius — a bad release affects few users, not everyone.
  • Blue-green and canary give a clean, instant rollback path because the old version stays ready.
  • Feature flags let teams deploy code safely behind a switch and turn features on progressively.
  • The right strategy converts deployment from an incident into an observable, reversible event.
Think about it

Mental model

Imagine

Changing tyres on a moving car

Think of

Zero-downtime deployment

You cannot stop the car (the service) and swap all four wheels at once. Instead you change one wheel at a time (rolling) or keep a second car running alongside and let passengers move over once it is proven (blue-green).

Mechanics

How it works

  • A rolling update creates new replicas and terminates old ones a few at a time while the load balancer keeps serving.
  • Blue-green deploys the new version as a complete 'green' stack beside the 'blue' one, then flips the router in one switch.
  • Canary routing sends a small share of traffic (5-10%) to the new version and watches error rates before ramping up.
  • Feature flags gate behavior behind a runtime toggle, so a release ships without exposing anything until the flag is on.
  • Rollback is strategy-specific: rolling reverses the update, blue-green flips back to blue, canary redirects 100% to the old version.

A canary rollout ramping from 10% to 100% before the old version is removed.

Stable v1
Deploy v2
Canary 10%
Ramp 50%
100% v2
Reference

Key commands

kubectl set image deployment/web web=myapp:1.5.0

Trigger a rolling update of the web deployment.

kubectl rollout status deployment/web

Watch the rollout until it completes or pauses.

kubectl rollout undo deployment/web

Roll back to the previous revision.

kubectl get pods -w

Watch pods being created and terminated during a rollout.

curl -s http://localhost:8080/healthz

Check the health endpoint before directing traffic to a new version.

Hands-on

Examples

A rolling update with health-gated rollout on Kubernetes

A rolling update with health-gated rollout on Kubernetes
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: myapp:1.4.0
          ports:
            - containerPort: 8080

Kubernetes rolls out the new image one pod at a time: at most one pod may be down (maxUnavailable) and one extra may be created (maxSurge). A new pod only counts once its readiness probe passes, so the rollout pauses automatically if the new version cannot serve.

Real world

In production

  • Rolling updates are the default for most stateless services because they are simple and require no extra capacity.
  • Blue-green is chosen for database schema migrations where old and new versions must coexist briefly.
  • Canary deploys give metric-based confidence for high-traffic, high-risk changes.
  • Feature flags let product teams release code on Tuesday and enable it on Friday without a deploy.
  • Incident playbooks pin down the rollback command for each strategy so reverting is one step.
Guidelines

Best practices

  • Always define health checks and readiness probes so the orchestrator can gate the rollout.
  • Keep old capacity around until the new version is verified — blue-green relies on it.
  • Watch error rate, latency and saturation, not just availability, during a canary.
  • Make feature flags short-lived and remove them after the code path is proven.
  • Automate rollback and test it periodically so it works when you need it.
Watch out

Common mistakes

  • Rolling out without health checks, so unhealthy pods get traffic and users see errors.
  • Blue-green sharing the same database, so the 'old' version cannot actually serve a rollback.
  • Canary with no metrics threshold — traffic ramps to 100% regardless of the new version's error rate.
  • Leaving feature flags in the code forever, accumulating untested dead paths.
Root cause analysis

Common issues

Error
Rollout stuck or unavailable replicas
Root cause

The new version fails its readiness probe, so the orchestrator refuses to add it.

Fix

Read kubectl describe deployment for events, fix the app or probe, and restart the rollout.

Error
Users see errors during a rolling update
Root cause

Pods are terminated before they drain in-flight requests, or probes are too lenient.

Fix

Configure a graceful shutdown (SIGTERM handling) and a proper readiness gate before traffic moves on.

Error
Blue-green rollback still hits the bad version
Root cause

The blue and green stacks share state (same DB, cache) that the new version corrupted.

Fix

Ensure old and new versions are isolated or upgrade state schema in a compatible, reversible way.

When things break

Debugging tips

  • Watch the rollout progress with kubectl rollout status and describe to see why it paused.
  • In a canary, compare error rates between the stable and canary pods using the same trace IDs.
  • Verify the old version is truly still healthy before using it as a rollback target.
  • Check readiness probe failures in events — they are usually why a rollout stalls.
Interviews

Interview checkpoint

Practice

Hands-on lab

Model a Blue-Green Switch with Docker
30 min · intermediate
In progress
Objectives
  • Build two versions of the same application
  • Run the old version and verify it serves traffic
  • Deploy the new version as a parallel 'green' stack
  • Switch traffic and verify, then roll back

Model a Blue-Green Switch with Docker

30 min · intermediate

0/6 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/3
1

Which strategy requires running two complete, parallel stacks of the application?

2

A canary deployment sends 100% of traffic to the new version from the start.

3

What is the main advantage of a feature flag compared with a deployment?

Quick reference

Cheat sheet

Strategies at a glance
rollingGradual replica swap, needs no extra capacity
blue-greenTwo full stacks, instant switch + rollback
canarySmall % traffic, ramp on metrics
recreateStop all, start all — downtime, rarely used
Key commands
kubectl set image deployment/web web=myapp:1.5.0Trigger a rollout
kubectl rollout status deployment/webWatch progress
kubectl rollout undo deployment/webRoll back a revision
kubectl get pods -wWatch pod churn
curl -s http://localhost:8080/healthzVerify health before cutover
Go deeper

Official documentation

Kubernetes Deployments
docs
Argo Rollouts documentation
docs
FeatureToggle
docs
Using environments for deployment
docs