Blue Green Deployment

---
name: blue-green-deployment
enabled: true
description: |
  Use when performing blue green deployment — blue-green deployment template
  covering environment preparation, parallel stack deployment, traffic
  switching, validation gates, and cleanup. Use for zero-downtime releases with
  instant rollback capability.
required_connections:
  - prefix: aws
    label: "AWS (or cloud provider)"
config_fields:
  - key: service_name
    label: "Service Name"
    required: true
    placeholder: "e.g., checkout-service"
  - key: version
    label: "New Version"
    required: true
    placeholder: "e.g., v3.2.0"
  - key: active_environment
    label: "Currently Active Environment"
    required: true
    placeholder: "e.g., blue, green"
features:
  - DEPLOYMENT
---

# 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:
1. **Deployment summary** (service, version, environments, timestamps)
2. **Pre-switch validation** results
3. **Traffic switch** execution log with exact timing
4. **Post-switch metrics** comparison (before vs after)
5. **Final status** (SUCCESS / ROLLED BACK) with next steps