Deployment & Delivery

Release Strategies

A comparison of rolling update, recreate, blue-green, canary, shadow/dark launch, A/B testing deployment, and ring-based progressive delivery — how to choose the right strategy for each context.

⏱ 10 min read

What it is

Release strategies define how a new version of software is introduced to production users. Each strategy represents a different trade-off between speed, risk, cost, complexity, and observability. Choosing the right strategy is contextual — the correct choice depends on service criticality, traffic volume, team maturity, infrastructure capabilities, and the nature of the change being deployed. Most mature teams use different strategies for different scenarios: rolling updates for routine deployments, blue-green or canary for high-risk changes, and shadow mode for validating new backend logic without user impact.

Recreate: Shut down all old pods, then start new pods. Results in a brief downtime window. Use only for dev/staging or services where downtime is acceptable. Guaranteed no dual-version period simplifies reasoning about backward compatibility. Rolling update (Kubernetes default): Replace old pods incrementally with new pods. No downtime; both versions run simultaneously for the duration of the rollout. Best for routine deployments of stateless services where backward compatibility during the rollout window is guaranteed. Blue-green: Two full environments; instant traffic switch. Zero downtime; instant rollback; high cost. Best for database-heavy changes and services requiring validated pre-production testing at full production configuration. Canary: Gradual percentage-based traffic shift with metric-gated progression. Controlled blast radius; automated rollback; requires mature observability. Best for high-traffic services where real production signal is available at small percentages. Shadow / Dark launch: New version receives a copy of production traffic (or mirrored traffic) but its responses are not returned to users. Allows testing new backend logic, new ML models, or new integrations with zero user risk. A/B testing deployment: Different user segments receive different versions to measure business outcome differences (conversion rate, engagement). Ring-based deployment: Deploy to progressively wider rings — internal users → beta users → 1% → 10% → 100%. Used by large-scale consumer platforms (Microsoft Windows Update, cloud SaaS platforms).

Why it exists

Different deployment scenarios have different risk profiles. A cosmetic UI change in a low-traffic internal tool has minimal deployment risk. A new payment processing integration in a high-traffic e-commerce system has severe risk — a 1% error rate increase affects thousands of transactions per hour. Applying the same deployment strategy to both scenarios is either over-engineered (canary rollout for internal tools) or dangerously under-designed (rolling update for payment systems). Understanding the spectrum of release strategies enables teams to match deployment risk management to the actual risk of each change.

When to use

  • Recreate: Non-production environments; services where brief downtime is acceptable and simplicity is valued.
  • Rolling update: Stateless services with stateless backward-compatible changes; routine deployments; Kubernetes default.
  • Blue-green: Changes requiring database migration; services with strict uptime SLAs needing instant rollback capability.
  • Canary: High-traffic, high-risk changes where production signal at small percentage is available; automated rollback on metrics is required.
  • Shadow: Validating new service implementations, ML models, or integrations before exposing to users.
  • Ring-based: Consumer-facing platforms with millions of users where progressive ring exposure reduces blast radius.

When not to use

  • Rolling updates for changes that break backward compatibility — having old and new versions simultaneously will cause errors; use blue-green instead.
  • Canary for very low traffic services — insufficient traffic for statistically meaningful analysis at small percentages.

Typical architecture

STRATEGY COMPARISON:

Strategy    | Downtime | Rollback  | Cost     | Traffic Split | Complexity
------------|----------|-----------|----------|---------------|----------
Recreate    | Brief    | Redeploy  | Low      | 0%/100%       | Low
Rolling     | None     | Slow      | Low      | Gradual       | Low
Blue-Green  | None     | Instant   | 2x infra | 0%/100%       | Medium
Canary      | None     | Automated | Low+     | 1-99%         | High
Shadow      | None     | N/A       | 2x infra | Mirror only   | High
A/B Test    | None     | Manual    | Low+     | Segment-based | High
Ring-based  | None     | Per ring  | Medium   | 0→5→25→100%  | High

KUBERNETES ROLLING UPDATE CONFIGURATION:
  apiVersion: apps/v1
  kind: Deployment
  spec:
    strategy:
      type: RollingUpdate
      rollingUpdate:
        maxSurge: 1          # Allow 1 extra pod during update
        maxUnavailable: 0    # Never reduce below desired count
                             # Zero downtime rolling update

SHADOW TRAFFIC MIRRORING (Istio):
  apiVersion: networking.istio.io/v1beta1
  kind: VirtualService
  spec:
    http:
    - route:
      - destination:
          host: checkout
          subset: stable
        weight: 100
      mirror:
        host: checkout
        subset: shadow      # New version receives copy of traffic
      mirrorPercentage:
        value: 100.0        # Mirror 100% (or reduce for cost)
  # shadow responses discarded; only stable responses returned to users

RING-BASED DEPLOYMENT PROGRESSION:
  Ring 0: Internal employees        (~100 users)   Week 1
  Ring 1: Beta / early access users (~10,000)      Week 2
  Ring 2: Random 1% of all users                   Week 3
  Ring 3: Random 10% of all users                  Week 4
  Ring 4: All users                                Week 5
  Each ring monitored for stability before advancing

A/B TESTING DEPLOYMENT (header/cookie routing):
  # Route 50% of users to variant B for conversion test
  # User assignment is persistent (same user always sees A or B)
  # Measure conversion rate, session length, etc.
  # Statistical significance required before declaring winner

Pros and cons

Pros (of having a strategy portfolio)

  • Risk-matched deployment: using the appropriate strategy for the risk level of each change prevents both over-engineering (canary for trivial changes) and under-managing (rolling update for critical integrations).
  • Shadow deployments eliminate user impact from testing new implementations — invaluable for ML model validation where correctness of outputs can be compared offline without any user seeing potentially incorrect results.
  • Ring-based deployments for consumer platforms enable early detection of platform-specific issues (browser compatibility, device-specific bugs) before the change reaches the full user population.

Cons

  • Strategy sprawl: teams that apply too many strategies without clear criteria for when to use each create operational confusion — engineers must know which strategy to use and why for each deployment context.
  • Shadow and A/B testing add infrastructure complexity and cost: running shadow versions requires double the compute for the mirrored traffic; A/B test experiments require analytics infrastructure to measure outcomes.
  • Ring-based deployments introduce long lead times from commit to full rollout: a 5-week progression is appropriate for OS updates but unsuitable for services where rapid delivery is essential.

Implementation notes

Document deployment strategy requirements for each service in a deployment runbook or as metadata in the service's CI/CD configuration. A service classification like "critical-payment-service: blue-green required for schema changes, canary for application changes, rolling for config changes" makes the choice explicit and repeatable rather than decided ad-hoc per deployment. Shadow traffic is particularly valuable for ML inference services: run the new model in shadow mode for a week, compare its outputs to the production model's outputs offline, and only promote when quality metrics confirm parity or improvement.

Common failure modes

  • Wrong strategy for the change type: Rolling update applied to a change with a breaking API schema change — old and new pods simultaneously fail to communicate during the rollout window; use blue-green or version-parallel deployment for breaking changes.
  • Shadow traffic causing production side effects: Shadow requests trigger write operations (database inserts, payments, emails) in the new service; shadow is only safe if the shadow service is read-only or explicitly handles mirrored traffic in a no-op fashion.

Decision checklist

  • Is the deployment strategy matched to the risk level of the change?
  • For rolling updates: is the new version backward compatible with the old during the rollout window?
  • For shadow deployments: does the shadow service have write operations that could cause real side effects?
  • Is rollback procedure defined, tested, and documented for each strategy?
  • Are monitoring and alerting in place to detect strategy-specific failure modes?

Example use cases

  • ML model validation via shadow: New recommendation model deployed in shadow mode receiving 100% of mirrored search requests; recommendations logged but not shown to users; data science team compares model outputs to production model offline over 2 weeks; quality confirmed; promoted to 5% canary, then full rollout.
  • Windows-style ring deployment: Consumer SaaS platform uses ring-based strategy; Microsoft Windows Update model adapted for web service: internal ring (100 employees) → early adopters (5,000 opt-in users) → 1% random → 10% → 100%; platform-specific rendering bugs caught in internal ring before reaching general availability.

Further reading