Deployment Strategies

Every deployment strategy is an answer to the same question: how much of your user base is exposed to a new version before you know whether it works? The strategies differ in exposure, cost, and how quickly they can undo a mistake.

The four core patterns link

flowchart TB
    subgraph "Rolling"
    R1[v1 v1 v1 v1] --> R2[v2 v1 v1 v1] --> R3[v2 v2 v1 v1] --> R4[v2 v2 v2 v2]
    end
    subgraph "Blue / Green"
    B1["Blue v1 — live"] --- B2["Green v2 — idle, warmed"]
    B2 -->|switch router| B3["Green v2 — live<br/>Blue kept for instant rollback"]
    end
    subgraph "Canary"
    C1["v1: 100%"] --> C2["v1: 95% · v2: 5%<br/>compare metrics"] --> C3["v1: 50% · v2: 50%"] --> C4["v2: 100%"]
    end
    subgraph "Shadow"
    S1["v1 serves all traffic"] --> S2["traffic mirrored to v2<br/>responses discarded"]
    end

Rolling deployments link

The default in most orchestrators. Instances are replaced in batches while the service stays available.

Its two constraints are frequently missed:

• Both versions serve simultaneously. Every change must be backward and forward compatible for the duration of the rollout — API responses, message formats, and cache entries included.
• Rollback is another rolling deployment, so it takes as long as the deploy did. If your recovery objective is “under a minute”, rolling alone will not meet it.

Rolling deployments require correct readiness probes. Without them, the orchestrator routes traffic to instances that have started but cannot yet serve, and the deployment produces a burst of errors while reporting success.

Blue/green deployments link

Two complete environments; only one receives traffic. Deploy to the idle one, verify, then switch.

The strength is rollback: flipping a router back is near-instant and does not depend on rebuilding anything. The costs are real, though:

• Double the infrastructure during the deployment window.
• The database is shared, so schema changes must still be compatible with both versions. Blue/green does not solve data migration; see Release Orchestration and Rollback.
• Long-lived connections (WebSockets, streaming) do not switch cleanly and need a drain strategy.

Canary deployments link

A small traffic percentage goes to the new version while its metrics are compared against the old one. If it behaves, the share increases; if not, it goes to zero.

The essential detail is that the promotion decision must be automatic and metric-driven. A “canary” where a human eyeballs a dashboard for ten minutes is just a slow rolling deploy with extra steps.

flowchart TD
    A[Deploy canary: 5% traffic] --> B[Observation window<br/>e.g. 10 min]
    B --> C{Compare canary vs baseline}
    C -->|"error rate ↑ beyond threshold"| X[Abort: shift to 0%, alert]
    C -->|"P99 latency ↑ beyond threshold"| X
    C -->|"business KPI ↓ beyond threshold"| X
    C -->|all within tolerance| D[Increase to 25%]
    D --> E[Observation window]
    E --> F{Compare again}
    F -->|regression| X
    F -->|healthy| G[100% + retire old version]

Choosing analysis metrics matters more than the traffic mechanics:

• Error rate — the baseline signal, but insufficient alone.
• Latency percentiles (P95/P99, not mean) — averages hide the regression.
• Saturation — CPU, memory, connection pools. Catches leaks that error rates miss.
• A business KPI — checkout completion, search success. This catches the changes that are technically healthy and functionally broken, which are the ones that hurt most.

Canary analysis needs enough traffic for statistical meaning. On a service handling ten requests a minute, a 5% canary sees one request every two minutes, and no amount of analysis will produce a signal. Low-traffic services should use blue/green instead.

Shadow (dark) traffic link

Production traffic is mirrored to the new version, whose responses are discarded. Users are never exposed, so it is the safest way to validate a rewrite or a major dependency upgrade under genuinely realistic load.

Two cautions: mirrored requests must not cause side effects — writes, emails, payments must be stubbed or routed to a sandbox — and the shadow environment consumes real capacity from shared downstream dependencies.

Decoupling deploy from release link

The most important idea in modern deployment practice is that deploying code and releasing a feature are separate events. Feature flags let a change ship to production disabled, then be enabled for internal users, then a percentage, then everyone — without another deployment.

flowchart LR
    A[Merge to main] --> B[Deploy to prod<br/>flag OFF]
    B --> C[Enable for internal users]
    C --> D[Enable for 1% of users]
    D --> E[Enable for 50%]
    E --> F[Enable for 100%]
    F --> G[Remove the flag<br/>and the old code path]
    D -.->|problem found| H[Flip flag OFF<br/>seconds, no deploy]

This makes rollback a configuration change rather than a deployment, which is the fastest recovery mechanism available. It has one hard requirement that teams consistently underestimate: flags must be removed. A codebase with hundreds of stale flags has an untestable combinatorial state space. Give every flag an owner and an expiry date, and treat an expired flag as a build warning.

Choosing per service link

flowchart TD
    A{Recovery objective<br/>under 1 minute?} -->|No| B{Enough traffic for<br/>statistical analysis?}
    A -->|Yes| C{Can you afford<br/>2x infrastructure?}
    C -->|Yes| D[Blue/Green]
    C -->|No| E[Canary + feature flags]
    B -->|Yes| E
    B -->|No| F[Rolling + feature flags]
    E --> G[Add shadow traffic<br/>for major rewrites]
    D --> G

Adoption checklist link

• Every change is backward/forward compatible for the rollout window.
• Readiness probes gate traffic correctly; deploys do not emit error bursts.
• Canary promotion is automatic and metric-driven, including one business KPI.
• Low-traffic services use blue/green rather than statistically meaningless canaries.
• Shadow traffic has all side effects stubbed.
• Feature flags decouple deploy from release, with owners and expiry dates.
• Rollback path is tested regularly, not assumed.