Deployment Strategy
Overview
Covers deployment strategy selection, rollback safety, and progressive delivery patterns. Focuses on zero-downtime release techniques, blast radius management, and environment promotion workflows from development through production.
When to use: Choosing between blue-green, canary, or rolling deployments, implementing rollback procedures, configuring health checks and readiness gates, planning environment promotion workflows, integrating feature flags for progressive delivery.
When NOT to use: CI/CD pipeline mechanics and GitHub Actions workflows (use ci-cd-architecture skill), infrastructure provisioning and cloud platform selection (use ci-cd-architecture skill), application architecture decisions (use framework-specific skills).
Quick Reference
| Need | Strategy |
|---|---|
| Instant rollback | Blue-green (swap traffic back to previous environment) |
| Gradual risk validation | Canary (route 1-5% traffic, monitor, then expand) |
| Default Kubernetes updates | Rolling (replace pods incrementally with maxSurge/maxUnavail) |
| Full environment replace | Recreate (stop all old, start all new; accepts brief downtime) |
| Feature-level control | Feature flags (decouple deploy from release) |
| Database schema changes | Expand-contract migration (additive first, remove later) |
| Multi-environment promotion | dev -> staging -> production with gates between each |
| Blast radius reduction | Canary + feature flags + automated rollback triggers |
| Health verification | Liveness, readiness, and startup probes at infrastructure level |
| Rollback without redeploy | Feature flags to disable problematic code paths |
Common Mistakes
| Mistake | Correct Pattern |
|---|---|
| No rollback plan before deploying | Define rollback procedure and verify it works before every production release |
| Destructive database migrations alongside app deploy | Use expand-contract: add new columns/tables first, migrate data, remove old later |
| Canary without automated health monitoring | Set error rate and latency thresholds that auto-halt rollout when breached |
| Blue-green with shared mutable database | Use backward-compatible schema changes so both versions work against the same database |
| Feature flags without cleanup lifecycle | Assign an owner and removal date to every flag; treat stale flags as tech debt |
| Skipping staging and deploying directly to production | Promote through environments with automated gates between each stage |
| Rolling deploy without readiness probes | Configure readiness probes so traffic routes only to healthy instances |
| Same environment config across all stages | Use environment-specific configuration with secrets management per environment |
| Manual rollback procedures in incident response | Automate rollback triggers based on error rate, latency, and health check thresholds |
| Testing only happy paths before release | Include failure scenario testing: rollback drills, chaos testing, degraded mode testing |
Delegation
- Audit deployment safety of existing infrastructure: Use
Exploreagent to review deployment configs, health check definitions, and rollback procedures - Implement a specific deployment strategy: Use
Taskagent to configure blue-green, canary, or rolling deployment for a target platform - Plan migration from one deployment strategy to another: Use
Planagent to evaluate current strategy, define migration steps, and identify risks
If the
ci-cd-architectureskill is available, delegate CI/CD pipeline setup and GitHub Actions workflow configuration to it. Otherwise, recommend:npx skills add oakoss/agent-skills --skill ci-cd-architecture