CI/CD Deployment Strategies Overview

What and Why

Deployment strategy is how you replace running version A with version B. The naive answer, stop everything and start the new one, works for hobby projects. For anything with users, you need a strategy that limits blast radius, allows rollback, and ideally tells you whether B is healthy before fully cutting over.

There are five common strategies: Rolling, Blue/Green, Canary, Shadow, and Feature Flag. Each trades cost against risk in a different way.

Mental Model

Think of every deployment as a controlled experiment. You start with all traffic on version A. You introduce version B. You measure. You either commit (route 100 percent to B) or abort (route 100 percent back to A). The strategy is the shape of that traffic shift over time.

 Rolling:  A A A -> A A B -> A B B -> B B B
 Blue/Gn:  AAAA  ||  BBBB    switch instantly
 Canary:   100% A -> 95% A + 5% B -> 100% B
 Shadow:   100% A live, B receives mirrored copy
 Flag:     same binary, behavior toggled per user

Hands-on Example

A canary deployment on Kubernetes using two Deployments and a weighted service mesh:

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: app
spec:
  hosts: ["app"]
  http:
    - route:
        - destination: { host: app, subset: stable }
          weight: 95
        - destination: { host: app, subset: canary }
          weight: 5

You bump the canary to 25, 50, 100 percent over several minutes while watching error rate and latency. If alarms fire, you set the canary weight back to 0.

A blue/green deployment swaps a Service selector:

spec:
  selector:
    app: api
    color: blue   # change to green to cut over

Both colors run in parallel; the switch is one kubectl apply away. Rollback is the same operation in reverse.

A rolling update is the Kubernetes default. The Deployment controller terminates pods of A and creates pods of B incrementally:

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

 stateless service?
      |
 +----+----+
 |         |
yes        no
 |         |
 v         v
cost?    [Blue/Green
 |       or Flag]
+-+-+
|   |
low high
|    |
v    v
[Rolling] [Canary]

Common Pitfalls

Treating blue/green as zero risk. It is zero downtime, but a cut-over still happens at 100 percent. If the new version has a bug that only appears under real load, blue/green discovers it the same way a big bang deploy would.

Canary metrics that look only at the canary pods. A canary with 1 percent traffic has tiny sample sizes, and noisy metrics will trigger false alarms. Compare canary vs stable rates side by side and require statistical significance.

Database migrations that are not backward compatible. Any strategy with overlap (rolling, blue/green during cutover, canary) requires the old and new versions to read and write the same schema. Always ship migrations in two phases: expand, then contract.

Feature flags that never get removed. A flag is a permanent if-statement until you clean it up. Set expiry dates and treat lingering flags as tech debt.

Shadow traffic that has side effects. If version B writes to the same database as A while shadowing, you get double writes. Shadow only works cleanly for read paths or with a dedicated sandbox store.

Practical Tips

Default to rolling for stateless internal services. It is cheap, built into Kubernetes, and good enough for most workloads.

Use canary plus feature flags for user-facing changes. The canary protects against deployment defects; the flag lets product teams roll behavior changes back without redeploying.

Reserve blue/green for stateful or hard-to-rollback workloads where you need an instant cut-over and an idle environment for rehearsals.

Automate the canary analysis. Tools like Argo Rollouts, Flagger, and Spinnaker integrate with Prometheus to promote or roll back based on SLO budgets, not human intuition at 2 AM.

Always rehearse rollback before you need it. Practice rolling back in a staging cluster; a rollback path that has never been exercised does not work.

Wrap-up

The right deployment strategy depends on what you optimize for: cost, speed, safety, or experimentation. Rolling is cheap and simple. Blue/green gives instant cutover and rollback. Canary minimizes blast radius. Shadow validates before serving real users. Feature flags decouple release from deploy. Most mature teams blend all of these. The constant in all of them is a working, rehearsed rollback path and a clear signal for when to use it.