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
Intro
Deployment Strategies
A deployment moves a software change into an environment. A deployment strategy controls how that change replaces the version already serving users.
The strategy does not make a change safe by itself. It controls exposure while tests, health checks, and operators decide whether the new version should advance.
This course gives you a practical map of the main strategies. You will learn what each strategy optimizes, what it costs, and what evidence you need during a rollout.
The problem: change without uncontrolled impact
Every production change introduces risk. The new version may fail to start, return errors, slow down, or interact badly with shared data.
A useful strategy limits the blast radius. This is the portion of users, requests, or systems affected when a change fails.
Think of a deployment as a controlled transition:
known version -> limited exposure -> health decision -> wider exposure
|
+-> stop and recover
The transition needs more than a traffic mechanism. You also need a defined health model, promotion criteria, and a recovery action.
Separate deployment from release
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
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