Deployment Strategies
Deployment strategies determine how new software versions reach production: all-at-once, rolling, blue-green, canary, or feature-flag based. Each trades off between speed, risk, rollback capability, and infrastructure cost.
itDevOps and software delivery | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic — Deployment Strategies
A deployment strategy is the arrangement for replacing software that is already serving people. It exists because changing every instance at once is a remarkably efficient way to discover a mistake at full volume. The useful question is not which pattern has the most reassuring name. It is how much exposure a change gets before the evidence tells you to continue or stop.
The three pieces are exposure, a health gate, and recovery. Exposure decides who receives the new version: every target, a batch of instances, a separate green environment, a small canary population, or an ordered ring of users. A health gate decides whether the next stage is allowed. Recovery is the particular escape route when the gate says no. These are one system wearing three hats, which is already plenty of hats for a production change.
A rolling update trades spare capacity for overlap. Old and new instances live together while batches change, so their APIs, queues, caches, sessions, jobs, and database schema must tolerate each other. Blue-green keeps two environments and switches traffic after green is ready. That can reverse traffic quickly, but only while blue remains healthy and understands the current data. The database, naturally, has opinions about this.
A canary sends a small production population to the new version while a control stays on the current one. It is not a tiny permission slip. It is an experiment: compare version-specific request failures, latency, crashes, or critical completion during the same period, then keep absolute service limits as well. Partial traffic without evaluation is only partial risk, which is less poetic than it first appears.
Feature flags add another lever. Deployment places code or configuration into an environment; release exposes behavior to users. A flag can keep deployed behavior dormant until a selected cohort receives it. That gives rings more precision, along with two flag states to test and one more thing to remove later.
For a dense reference, open the Cheatsheet: it has the strategy comparison, mixed-version checklist, and data-change sequence. The slides show the flows and decision points. The practice reference turns the idea into a rollout contract, and the exercise asks you to halt a synthetic canary using an explicit limit. The point is not to memorize a list of patterns. It is to make exposure, evidence, and recovery agree before they meet production.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/deployment-strategies.html
Supports
- Deployment strategy as the method used to deliver software
- In-place deployment behavior and availability tradeoff
- Blue-green traffic shifting between separate environments
- Canary as incremental exposure to reduce deployment risk
- Linear and all-at-once traffic-shift definitions
- https://learn.microsoft.com/en-us/azure/well-architected/operational-excellence/safe-deployments
Supports
- Small, incremental, quality-gated releases and progressive exposure
- Health checks before each exposure phase
- Immediate halt and recovery after issue detection
- Feature flags for targeting behavior to canary users
- Automation, consistency, and explicit safe-deployment standards
- https://sre.google/workbook/canarying-releases/
Supports
- Canary as a partial and time-limited deployment with evaluation
- Required targeting, evaluation, and release-process integration capabilities
- Use of representative and attributable canary metrics
- Risks of before-and-after evaluation
- Gradual stages, concurrent control comparison, and absolute service measures
- Shared dependencies and special concerns for noninteractive systems
- https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/introduction.html
Supports
- Blue as the current environment and green as the staged new environment
- Validation before traffic cutover
- Traffic reversal to blue for recovery
- Environment-boundary, capacity, cost, and automation considerations
- https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/best-practices-for-managing-data-synchronization-and-schema-changes.html
Supports
- Need for current data in both blue and green environments
- Additional concerns for structured data and diverging schemas
- Decoupling schema changes from code changes
- Backward-compatible schema-first and schema-last sequences
- Additive changes before removal of obsolete schema
- https://kubernetes.io/docs/tasks/run-application/update-deployment-rolling/
Supports
- Rolling updates gradually replacing old Pods with new Pods
- Availability during a rolling update
- Maximum unavailable and maximum surge controls
- Rollout status, stalled rollout detection, history, and rollback
- https://cloud.google.com/blog/products/gcp/how-release-canaries-can-save-your-bacon-cre-life-lessons
Supports
- Manual review of canary graphs can miss weak error and performance regressions
- Automated evaluation and rollback depend on a safe rollback path
- https://argoproj.github.io/rollouts/
Supports
- Kubernetes canary and blue-green rollout controller capabilities
- https://flagger.app/
Supports
- Metric-driven progressive delivery for Kubernetes
- https://www.spinnaker.io/
Supports
- Continuous delivery platform for deployment pipelines
- https://www.harness.io/products/continuous-delivery
Supports
- Managed progressive delivery and rollback workflows
- https://launchdarkly.com/
Supports
- Feature management for separating deployment from release
- https://cloud.google.com/deploy
Supports
- Managed staged delivery to Google Cloud targets
