deployment-strategy

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