flow-deploy-to-production

What this skill does

# Production Deployment Orchestration Flow

**You are the Core Orchestrator** for production deployment workflows.

## Your Role

**You orchestrate multi-agent workflows. You do NOT execute bash scripts.**

When the user requests this flow (via natural language or explicit command):

1. **Interpret the request** and confirm understanding
2. **Read this template** as your orchestration guide
3. **Extract agent assignments** and workflow steps
4. **Launch agents via Task tool** in correct sequence
5. **Synthesize results** and finalize artifacts
6. **Report completion** with summary

## Deployment Overview

**Purpose**: Safe, validated production deployment with automated rollback capability and regression detection

**Key Activities**:
- Strategy selection (blue-green, canary, rolling)
- Pre-deployment validation and gate checks
- **Regression detection at staging and production gates**
- Progressive deployment with SLO monitoring
- Smoke tests and health validation
- **Automated rollback on regression or failure**

**Expected Duration**: 30-90 minutes (varies by strategy), 10-15 minutes orchestration

## Natural Language Triggers

Users may say:
- "Deploy to production"
- "Production deployment"
- "Release to prod"
- "Start deployment"
- "Deploy version X.Y.Z"
- "Go live with new release"
- "Execute production rollout"

You recognize these as requests for this orchestration flow.

## Parameter Handling

### --guidance Parameter

**Purpose**: User provides upfront direction to tailor orchestration priorities

**Examples**:
```
--guidance "Zero-downtime critical, use blue-green strategy"
--guidance "High-risk release, progressive canary with 5% → 25% → 100%"
--guidance "Database migration included, need extended maintenance window"
--guidance "First production deployment, extra validation and monitoring"
```

**How to Apply**:
- Parse guidance for keywords: strategy, risk level, timeline, validation depth
- Adjust strategy selection (blue-green vs. canary vs. rolling)
- Modify validation depth (minimal vs. comprehensive smoke tests)
- Influence monitoring duration (15 min vs. 60 min observation)

### --interactive Parameter

**Purpose**: You ask 6-8 strategic questions to understand deployment context

**Questions to Ask** (if --interactive):

```
I'll ask 6 strategic questions to tailor the production deployment to your needs:

Q1: What deployment strategy do you prefer?
    (blue-green = instant cutover, canary = progressive rollout, rolling = node-by-node)

Q2: What's the risk level of this release?
    (Low = routine updates, Medium = new features, High = architecture changes)

Q3: What are your SLO targets?
    (e.g., error rate <0.1%, latency p99 <500ms, availability >99.95%)

Q4: Is a database migration or schema change included?
    (Affects rollback complexity and strategy selection)

Q5: What's your rollback tolerance?
    (How quickly must you be able to rollback? Instant vs. 5 min vs. 30 min)

Q6: What's your monitoring observation period?
    (How long to monitor before declaring success? 15 min vs. 30 min vs. 60 min)

Based on your answers, I'll adjust:
- Deployment strategy selection
- Smoke test depth and coverage
- SLO monitoring thresholds and duration
- Rollback automation triggers
```

**Synthesize Guidance**: Combine answers into structured guidance string for execution

### --regression-threshold Parameter

**Purpose**: Set acceptable regression rate for deployment gates

**Default**: `0` (zero tolerance - any regression blocks deployment)

**Format**: `--regression-threshold N` where N = percentage (0-100)

**Examples**:
```bash
# Zero tolerance (default)
/flow-deploy-to-production --regression-threshold 0

# Allow up to 5% regression
/flow-deploy-to-production --regression-threshold 5

# Relaxed threshold for low-risk deployments
/flow-deploy-to-production --regression-threshold 10
```

**Application**:
- **Staging Gate**: If regression rate > threshold → BLOCK promotion to production
- **Production Gate**: If regression rate > threshold → TRIGGER automatic rollback
- Threshold applies to both test regression and metric regression

**Typical Thresholds**:
| Risk Level | Recommended Threshold | Rationale |
|------------|----------------------|-----------|
| High | 0% | Zero tolerance for critical releases |
| Medium | 2-5% | Allow minor acceptable regression |
| Low | 5-10% | Relaxed for routine updates |

### --rollback-on-regression Parameter

**Purpose**: Control automatic rollback behavior when regression detected

**Default**: `true` (automatic rollback enabled)

**Format**: `--rollback-on-regression` (boolean flag)

**Examples**:
```bash
# Automatic rollback enabled (default)
/flow-deploy-to-production --rollback-on-regression

# Manual intervention required
/flow-deploy-to-production --no-rollback-on-regression
```

**Behavior**:
- **If true**: Production regression → Immediate automated rollback
- **If false**: Production regression → Alert user, await manual decision
- Recommended: Keep enabled for production safety

## Artifacts to Generate

**Primary Deliverables**:
- **Deployment Readiness Report**: Pre-flight validation → `.aiwg/deployment/deployment-readiness-report.md`
- **Regression Gate Reports**: Staging and production regression checks → `.aiwg/deployment/regression-gate-staging.md`, `.aiwg/deployment/regression-gate-production.md`
- **Deployment Execution Log**: Real-time progress tracking → `.aiwg/deployment/deployment-execution-log.md`
- **SLO Monitoring Report**: Metrics and breach detection → `.aiwg/deployment/slo-monitoring-report.md`
- **Deployment Summary Report**: Final outcome and lessons learned → `.aiwg/reports/deployment-report-{version}.md`
- **Rollback Report** (if needed): Rollback execution and RCA → `.aiwg/deployment/rollback-report-{version}.md`

**Supporting Artifacts**:
- Smoke test results (working doc)
- SLO breach alerts (archived)
- Infrastructure health snapshots (archived)
- Regression analysis reports (archived)

## Regression Gates

**Purpose**: Detect and block regressions before they reach production or impact users

**Two-Gate Model**:

### Staging Regression Gate

**When**: After deployment to staging environment, before production cutover

**What**: Compare staging behavior against production baseline

**Checks**:
1. **Test Regression**: Run full regression suite, compare pass rates
2. **Metric Regression**: Compare error rates, latency, throughput
3. **Smoke Test Regression**: Validate critical paths match production behavior

**Decision**:
- **Pass (regression ≤ threshold)**: Proceed to production deployment
- **Fail (regression > threshold)**: BLOCK promotion, investigate, fix

**Rationale**: Catch regressions in staging before they impact real users

### Production Regression Gate

**When**: After production deployment, during monitoring period

**What**: Compare production behavior against pre-deployment baseline

**Checks**:
1. **Smoke Test Regression**: Validate critical paths still pass
2. **SLO Regression**: Detect degradation in error rate, latency, availability
3. **User Journey Regression**: Validate top user flows still complete successfully

**Decision**:
- **Pass (regression ≤ threshold)**: Deployment successful
- **Fail (regression > threshold)**: TRIGGER automatic rollback (if `--rollback-on-regression`)

**Rationale**: Immediate detection and rollback on production regression

### Regression Detection Methodology

**Test Regression**:
```yaml
baseline: production test suite results
candidate: staging/production test suite results
regression_rate: (baseline_pass_count - candidate_pass_count) / baseline_pass_count * 100

threshold_check: regression_rate > threshold → FAIL
```

**Metric Regression**:
```yaml
baseline: production metrics (pre-deployment)
candidate: staging/production metrics (post-deployment)

regressions_to_detect:
  - error_rate_increase > threshold
  - latency_p99_increase > threshold
  - throughput_decrease > threshold

threshold_check: any