Shipping and Launch

Ship with confidence. Deploy safely: monitoring in place, rollback plan ready, clear success criteria. Every launch should be reversible, observable, and incremental.

When to Use

• Deploying a feature to production for the first time
• Releasing a significant change to users
• Migrating data or infrastructure
• Any deployment that carries risk (all of them)

When NOT to Use

• Local development or prototyping
• Pre-production CI/CD setup (use ci-cd-and-automation)

Output Contract

→ See guides/CHECKLIST-GUIDE.md for the complete launch checklist. → See guides/ROLLBACK-GUIDE.md for rollback procedures and decision matrix.

Pre-Launch Checklist

Code Quality

• All tests pass (unit, integration, e2e)
• Build succeeds with no warnings
• Lint and type checking pass
• Code reviewed and approved
• Error handling covers expected failure modes

Security

• No secrets in code or version control
• Input validation on all user-facing endpoints
• Auth and authorization checks in place
• Security headers configured (CSP, HSTS, etc.)
• CORS configured to specific origins (not wildcard)

Performance

• Core Web Vitals within "Good" thresholds
• No N+1 queries in critical paths
• Bundle size within budget
• Caching configured for static assets

Infrastructure

• Environment variables set in production
• Database migrations applied
• Logging and error reporting configured
• Health check endpoint exists and responds

Feature Flags

Ship behind feature flags to decouple deployment from release:

1. DEPLOY with flag OFF     → Code in production but inactive
2. ENABLE for team/beta     → Internal testing in production
3. GRADUAL ROLLOUT          → 5% → 25% → 50% → 100%
4. MONITOR at each stage    → Watch error rates, performance
5. CLEAN UP                 → Remove flag after full rollout

Rules: Every flag has an owner and expiration. Don't nest flags. Test both states in CI.

Staged Rollout

1. DEPLOY to staging → full test suite + manual smoke test
2. DEPLOY to production (flag OFF) → verify health check
3. ENABLE for team → 24-hour monitoring window
4. CANARY (5%) → compare metrics vs baseline, 24-48h
5. GRADUAL (25% → 50% → 100%) → same monitoring each step
6. FULL rollout → monitor 1 week → clean up flag

Rollout Thresholds

When to Roll Back

Roll back immediately if: error rate >2x baseline, P95 latency >50% increase, user-reported spikes, data integrity issues, or security vulnerability discovered.

Monitoring

Per Google SRE Four Golden Signals, monitor these dimensions:

Latency:   response time (p50/p95/p99), health check endpoint
Traffic:   request volume, active users, concurrent sessions
Errors:    error rate (HTTP 5xx, client JS errors), failed requests
Saturation: CPU/memory utilization, DB connection pool, disk, network

Post-Launch Verification (First Hour)

1. Health endpoint returns 200
2. Error monitoring: no new error types
3. Latency dashboard: no regression
4. Critical user flow works manually
5. Logs flowing and readable
6. Rollback mechanism ready

Rollback Plan

Every deployment needs one before it happens:

• Trigger: Error rate >2x, P95 >[X]ms, user reports, data issues
• Steps: Disable flag OR git revert <commit> && git push → verify → notify team
• Timing: Flag <1min, redeploy <5min, DB rollback <15min

TOOL_GAP: When You Can't Verify Deployment

Inspired by Sub-Zero Skill. After deployment, verification requires real-world access:

Examples:

• "Deploy succeeded" but can't reach health endpoint → TOOL_GAP
• "Metrics look good" but monitoring dashboard unavailable → TOOL_GAP
• "Users can access" but no real-user monitoring → TOOL_GAP

Rule: If you can't verify against the real world, say so. The absence of errors is not evidence of success.

Common Rationalizations

Red Flags

• Deploying without a rollback plan
• No monitoring or error reporting in production
• Big-bang releases (no staging, no canary)
• Feature flags with no expiration or owner
• "It's Friday afternoon, let's ship it"

Verification

Before deploying:

• Pre-launch checklist completed
• Rollback plan documented
• Monitoring dashboards set up

After deploying:

• Health check returns 200
• Error rate is normal
• Critical user flow works
• TOOL_GAP check: can you actually verify the real world?