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
Explore agent to review deployment configs, health check definitions, and rollback procedures
- Implement a specific deployment strategy: Use
Task agent to configure blue-green, canary, or rolling deployment for a target platform
- Plan migration from one deployment strategy to another: Use
Plan agent to evaluate current strategy, define migration steps, and identify risks
If the ci-cd-architecture skill 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
References
- Blue-green, canary, rolling, and recreate deployment strategies with configuration examples
- Rollback procedures, health checks, feature flags, and blast radius management
- Environment promotion workflows, configuration management, and secrets handling
1---
2name: deployment-strategy
3description: |
4 Deployment strategy patterns for zero-downtime releases. Covers blue-green, canary, rolling, and recreate strategies with rollback procedures, health checks, feature flags, progressive delivery, and environment promotion workflows.
5
6 Use when choosing a deployment strategy, implementing rollback procedures, configuring health checks, setting up environment promotion pipelines, planning progressive delivery with feature flags, or reducing blast radius during releases.
7license: MIT
8metadata:
9 author: oakoss
10 version: '1.0'
11user-invocable: false
12---
13
14# Deployment Strategy
15
16## Overview
17
18Covers 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.
19
20**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.
21
22**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).
23
24## Quick Reference
25
26| Need | Strategy |
27| --------------------------- | --------------------------------------------------------------- |
28| Instant rollback | Blue-green (swap traffic back to previous environment) |
29| Gradual risk validation | Canary (route 1-5% traffic, monitor, then expand) |
30| Default Kubernetes updates | Rolling (replace pods incrementally with maxSurge/maxUnavail) |
31| Full environment replace | Recreate (stop all old, start all new; accepts brief downtime) |
32| Feature-level control | Feature flags (decouple deploy from release) |
33| Database schema changes | Expand-contract migration (additive first, remove later) |
34| Multi-environment promotion | dev -> staging -> production with gates between each |
35| Blast radius reduction | Canary + feature flags + automated rollback triggers |
36| Health verification | Liveness, readiness, and startup probes at infrastructure level |
37| Rollback without redeploy | Feature flags to disable problematic code paths |
38
39## Common Mistakes
40
41| Mistake | Correct Pattern |
42| ----------------------------------------------------- | --------------------------------------------------------------------------------------- |
43| No rollback plan before deploying | Define rollback procedure and verify it works before every production release |
44| Destructive database migrations alongside app deploy | Use expand-contract: add new columns/tables first, migrate data, remove old later |
45| Canary without automated health monitoring | Set error rate and latency thresholds that auto-halt rollout when breached |
46| Blue-green with shared mutable database | Use backward-compatible schema changes so both versions work against the same database |
47| Feature flags without cleanup lifecycle | Assign an owner and removal date to every flag; treat stale flags as tech debt |
48| Skipping staging and deploying directly to production | Promote through environments with automated gates between each stage |
49| Rolling deploy without readiness probes | Configure readiness probes so traffic routes only to healthy instances |
50| Same environment config across all stages | Use environment-specific configuration with secrets management per environment |
51| Manual rollback procedures in incident response | Automate rollback triggers based on error rate, latency, and health check thresholds |
52| Testing only happy paths before release | Include failure scenario testing: rollback drills, chaos testing, degraded mode testing |
53
54## Delegation
55
56- **Audit deployment safety of existing infrastructure**: Use `Explore` agent to review deployment configs, health check definitions, and rollback procedures
57- **Implement a specific deployment strategy**: Use `Task` agent to configure blue-green, canary, or rolling deployment for a target platform
58- **Plan migration from one deployment strategy to another**: Use `Plan` agent to evaluate current strategy, define migration steps, and identify risks
59
60> If the `ci-cd-architecture` skill is available, delegate CI/CD pipeline setup and GitHub Actions workflow configuration to it.
61> Otherwise, recommend: `npx skills add oakoss/agent-skills --skill ci-cd-architecture`
62
63## References
64
65- [Blue-green, canary, rolling, and recreate deployment strategies with configuration examples](references/deployment-patterns.md)
66- [Rollback procedures, health checks, feature flags, and blast radius management](references/rollback-and-safety.md)
67- [Environment promotion workflows, configuration management, and secrets handling](references/environment-management.md)
oakoss