oleg494 Shipping and Launch
Overview
Ship with confidence. 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
- Opening a beta or early access program
The 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
- No
console.logdebugging statements in production code - Error handling covers expected failure modes
Security
- No secrets in code or version control
- Dependency audit shows no critical or high vulnerabilities
- Input validation on all user-facing endpoints
- Authentication and authorization checks in place
- Security headers configured (CSP, HSTS, etc.)
- Rate limiting on authentication endpoints
Performance
- Core Web Vitals within "Good" thresholds
- No N+1 queries in critical paths
- Images optimized
- Bundle size within budget
- Database queries have appropriate indexes
Infrastructure
- Environment variables set in production
- Database migrations applied
- DNS and SSL configured
- Health check endpoint exists and responds
- Logging and error reporting configured
Feature Flag Strategy
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, latency, feedback
5. CLEAN UP → Remove flag within 2 weeks of full rollout
Rules:
- Every feature flag has an owner and expiration date
- Clean up flags within 2 weeks of full rollout
- Don't nest feature flags
- Test both flag states in CI
Staged Rollout
1. DEPLOY to staging → full test suite + manual smoke test
2. DEPLOY to production (flag OFF) → verify health check, error monitoring
3. ENABLE for team (24h monitoring window)
4. CANARY rollout (5% of users) → 24-48h monitoring
5. GRADUAL increase (25% → 50% → 100%)
6. FULL rollout → monitor 1 week → clean up flag
Rollout Decision Thresholds
| Metric | Advance (green) | Hold (yellow) | Roll back (red) |
|---|---|---|---|
| Error rate | Within 10% of baseline | 10-100% above | >2x baseline |
| P95 latency | Within 20% of baseline | 20-50% above | >50% above |
| Client JS errors | No new error types | <0.1% of sessions | >0.1% of sessions |
Rollback Strategy
Every deployment needs a rollback plan:
- Trigger: Error rate > 2x baseline, P95 latency spike, user-reported issues, data integrity issues
- Steps: Disable feature flag OR deploy previous version → verify → communicate
- Time to rollback: Feature flag < 1 min, Redeploy < 5 min, DB rollback < 15 min
Post-Launch Verification (first hour)
- Check health endpoint returns 200
- Check error monitoring dashboard (no new error types)
- Check latency dashboard (no regression)
- Test the critical user flow manually
- Verify logs are flowing
- Confirm rollback mechanism works (dry run)
Red Flags
- Deploying without a rollback plan
- No monitoring or error reporting in production
- Big-bang releases (everything at once)
- Feature flags with no expiration or owner
- "It's Friday afternoon, let's ship it"