upgrade
upgrade

🔄DevOps and Continuous Integration

Deployment Strategies

Study smarter with Fiveable

Get study guides, practice questions, and cheatsheets for all your subjects. Join 500,000+ students with a 96% pass rate.

Get Started

Why This Matters

Deployment strategies sit at the heart of everything DevOps practitioners do—they're the bridge between writing code and getting it safely into users' hands. You're being tested on your understanding of risk management, availability patterns, and feedback loops in production systems. Each strategy represents a different trade-off between speed, safety, and complexity, and exam questions will probe whether you understand when to use which approach.

Don't just memorize the names of these strategies—know what problem each one solves and what risks it introduces. The real test is whether you can recommend the right deployment approach for a given scenario, explain why blue-green differs from canary, or identify when feature toggles make more sense than a full redeployment. Master the underlying principles, and you'll handle any question they throw at you.


Zero-Downtime Parallel Environments

These strategies maintain multiple complete environments simultaneously, allowing instant traffic switching. The core principle: eliminate downtime by never modifying the live system directly.

Blue-Green Deployment

  • Two identical environments—one serves production traffic (Blue) while the other sits idle and ready (Green)
  • Instant cutover via load balancer or DNS switch means users experience zero downtime during releases
  • Full rollback capability in seconds if the new version fails, since the previous environment remains untouched

Shadow Deployment

  • Parallel execution without user impact—the new version receives duplicated traffic but doesn't serve responses to users
  • Real production load testing catches performance issues that synthetic tests miss
  • Risk-free validation of new code against actual user behavior patterns before any traffic migration

Compare: Blue-Green vs. Shadow—both maintain parallel environments, but Blue-Green switches user traffic while Shadow never exposes the new version to users. Use Shadow when you need to validate performance under real load without any user risk; use Blue-Green when you're ready to release but want instant rollback.


Gradual Traffic Shifting

These strategies expose new versions to increasing percentages of users over time. The core principle: limit blast radius by controlling who sees changes and when.

Canary Deployment

  • Small subset first—typically 1-5% of users receive the new version while monitoring systems watch for anomalies
  • Progressive rollout expands traffic percentage only after success metrics confirm stability
  • Early warning system catches bugs that affect real users before they impact your entire user base

Rolling Update

  • Instance-by-instance replacement—old containers or servers are replaced incrementally while others continue serving traffic
  • Health checks gate progression—the next instance only updates after the previous one passes readiness probes
  • Resource efficient compared to Blue-Green since you don't need double the infrastructure

Ramped Deployment

  • Time-based traffic increase—new version exposure grows on a schedule (e.g., 10% per hour)
  • Automated progression with configurable gates based on error rates, latency, or custom metrics
  • Predictable rollout timeline helps coordinate with support teams and stakeholders

Compare: Canary vs. Rolling Update—Canary controls which users see changes (percentage-based), while Rolling Update controls which instances run new code. If an FRQ asks about minimizing user impact, Canary is your answer; if it asks about infrastructure updates, think Rolling.


Feature-Level Control

These strategies decouple deployment from release, allowing code to ship without being activated. The core principle: separate the act of deploying code from the decision to expose functionality.

Feature Toggles

  • Runtime switches enable or disable functionality without redeployment using configuration flags
  • Trunk-based development enabler—teams merge incomplete features behind toggles, avoiding long-lived branches
  • Kill switch capability lets you disable problematic features instantly in production without rollback

Dark Launches

  • Hidden feature deployment—new code runs in production but remains invisible to users
  • Backend stress testing validates database queries, API calls, and service dependencies under real conditions
  • Gradual exposure path once validation completes, combine with feature toggles to reveal functionality

Compare: Feature Toggles vs. Dark Launches—toggles control visibility of shipped features, while dark launches specifically test hidden features under production load. Both enable testing in production, but dark launches focus on performance validation before any user sees the feature.


Experimentation and Validation

These strategies focus on gathering data to inform product decisions. The core principle: use production traffic to validate hypotheses about user behavior and system performance.

A/B Testing

  • Controlled experiment splits users into cohorts receiving different versions to measure behavioral differences
  • Statistical significance required—results only matter when sample sizes eliminate random variation
  • Product decision driver determines which features ship based on conversion rates, engagement, or revenue metrics

Compare: A/B Testing vs. Canary—both split traffic, but Canary validates technical stability while A/B Testing measures user behavior. Canary asks "does it work?" while A/B asks "does it perform better?"


Simpler Approaches

These strategies prioritize simplicity over sophistication, accepting trade-offs in availability. The core principle: sometimes the simplest approach is the right one.

Recreate Deployment

  • Full replacement shuts down all instances of the old version before starting the new version
  • Guaranteed clean state eliminates any possibility of version conflicts or mixed traffic
  • Downtime required—only appropriate for non-critical systems or scheduled maintenance windows

Multi-Service Deployment

  • Coordinated releases update multiple interdependent services together to maintain compatibility
  • Dependency management ensures API contracts and data schemas align across service boundaries
  • Higher risk profile because failures can cascade, requiring comprehensive rollback plans

Compare: Recreate vs. Rolling Update—both replace existing instances, but Recreate accepts downtime for simplicity while Rolling maintains availability through incremental replacement. If an exam scenario mentions "acceptable downtime," Recreate is likely the answer.


Quick Reference Table

ConceptBest Examples
Zero-downtime switchingBlue-Green, Shadow
Gradual user exposureCanary, Ramped
Infrastructure-level updatesRolling Update, Recreate
Feature-level controlFeature Toggles, Dark Launches
Data-driven decisionsA/B Testing
Instant rollback capabilityBlue-Green, Feature Toggles
Production load testingShadow, Dark Launches
Multi-component coordinationMulti-Service Deployment

Self-Check Questions

  1. Which two deployment strategies both maintain parallel environments but differ in whether users ever see the new version? Explain when you'd choose each.

  2. A team wants to test whether a new checkout flow increases conversions. Which strategy should they use, and how does it differ from Canary deployment?

  3. Compare and contrast Feature Toggles and Dark Launches—what problem does each solve, and when might you use them together?

  4. Your application can tolerate 30 minutes of downtime during off-peak hours. Which deployment strategy offers the simplest implementation, and what trade-off are you accepting?

  5. An FRQ describes a scenario where a critical bug is discovered 10 minutes after deployment. Rank Blue-Green, Rolling Update, and Canary by how quickly each enables rollback, and explain why.