cloudthinker-ai Blue-Green Deployment Skill
Execute blue-green deployment of {{ service_name }} {{ version }}. Currently active: {{ active_environment }}.
Workflow
Step 1 — Environment Identification
ENVIRONMENT MAP
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Active (serving traffic): {{ active_environment }}
- Version: [current version]
- Instances: [count]
- Target group / endpoint: [identifier]
Inactive (deployment target): [opposite of active]
- Version: [to be deployed: {{ version }}]
- Instances: [count]
- Target group / endpoint: [identifier]
Step 2 — Prepare Inactive Environment
ENVIRONMENT PREPARATION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Inactive environment infrastructure is running
[ ] Inactive environment matches active environment spec:
- Same instance types / pod resources
- Same replica count
- Same autoscaling configuration
- Same network configuration
[ ] Database migrations applied (must be backward-compatible)
[ ] Environment variables and secrets updated for {{ version }}
[ ] Feature flags configured for {{ version }}
Step 3 — Deploy to Inactive Environment
DEPLOYMENT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Deploy {{ version }} to inactive environment
[ ] Wait for all instances/pods to be healthy
[ ] Health check endpoints returning 200
[ ] Application version endpoint confirms {{ version }}
[ ] All instances registered in target group
Step 4 — Pre-Switch Validation
PRE-SWITCH TESTING
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Smoke tests pass against inactive environment (direct access)
[ ] Integration tests pass against inactive environment
[ ] Performance baseline captured:
- P50 latency: ___ms
- P95 latency: ___ms
- P99 latency: ___ms
- Error rate: ___%
[ ] Database connectivity verified
[ ] Downstream dependency connectivity verified
[ ] Log output reviewed for unexpected errors
[ ] Security scan passed (if required)
GO / NO-GO DECISION: ___
Approved by: ___
Step 5 — Traffic Switch
TRAFFIC SWITCH
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Notify on-call team of switch
[ ] Record timestamp of switch: ___
Switch method (choose one):
[ ] Load balancer target group swap
[ ] DNS weighted routing (0% -> 100%)
[ ] Service mesh traffic shift
[ ] Kubernetes service selector update
[ ] Execute traffic switch
[ ] Verify traffic arriving at new ({{ version }}) environment
[ ] Verify no traffic on old environment (within TTL window)
Step 6 — Post-Switch Validation
POST-SWITCH MONITORING (30 min window)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
T+5min:
[ ] Error rate within baseline (< +1%)
[ ] Latency within baseline (< +20% on P95)
[ ] No new error types in logs
[ ] Key user journeys working
T+15min:
[ ] Error rate stable
[ ] No memory leaks or resource exhaustion
[ ] Downstream services healthy
[ ] No customer complaints
T+30min:
[ ] All metrics stable and within SLO
[ ] Deployment marked as SUCCESSFUL
[ ] Stakeholders notified
Step 7 — Rollback (if needed)
ROLLBACK
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Trigger: error rate >5% OR P95 latency >2x baseline for 5 min
[ ] Switch traffic back to {{ active_environment }} (instant)
[ ] Verify traffic on original environment
[ ] Verify error rates return to baseline
[ ] Notify stakeholders of rollback
[ ] Create incident ticket to investigate
Rollback time: ~seconds (just a traffic switch)
Step 8 — Cleanup
CLEANUP (after stabilization period, typically 24-48h)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Old environment scaled down or updated to standby
[ ] Old version available for emergency rollback (24h retention)
[ ] Deployment record logged
[ ] Infrastructure-as-code updated to reflect new active environment
[ ] Monitoring updated: new environment is now primary
[ ] Cost optimization: scale down inactive environment
Counter-Rationalizations
| Shortcut | Counter | Why |
|---|---|---|
| "We can skip some steps for this case" | Adapt the workflow steps, don't skip them | Skipped steps are where incidents and oversights originate |
| "The user seems to already know what to do" | Complete all workflow phases with the user | The workflow catches blind spots that experience alone misses |
| "This is a minor case, full process is overkill" | Scale the process down, don't turn it off | Minor cases become major when unstructured; the process scales, not disappears |
| "I'll fill in the details later" | Complete each section before moving on | Deferred details are forgotten; real-time capture is more accurate |
| "The template output isn't necessary" | Always produce the structured output format | Structured output enables comparison, audit trails, and handoff to other teams |
Output Format
Produce a deployment execution report with:
- Deployment summary (service, version, environments, timestamps)
- Pre-switch validation results
- Traffic switch execution log with exact timing
- Post-switch metrics comparison (before vs after)
- Final status (SUCCESS / ROLLED BACK) with next steps