Development
Shipping and Launch
Prepares production launches. Use when preparing to deploy to production, setting up monitoring, planning staged rollouts, or needing a rollback strategy.
Prepares production launches. Use when preparing to deploy to production, setting up monitoring, planning staged rollouts, or needing a rollback strategy.
Ship with confidence. Every launch should be reversible, observable, and incremental.
console.log debugging statements in production codenpm audit shows no critical or high vulnerabilitiesShip behind feature flags to decouple deployment from release:
const flags = await getFeatureFlags(userId);
if (flags.taskSharing) {
return <TaskSharingPanel task={task} />;
}
return null;
Feature flag lifecycle:
1. DEPLOY with flag OFF → Code is 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 and dead code path
1. DEPLOY to staging
└── Full test suite in staging
└── Manual smoke test of critical flows
2. DEPLOY to production (feature flag OFF)
└── Verify deployment succeeded (health check)
└── Check error monitoring
3. ENABLE for team (flag ON for internal users)
└── Team uses the feature in production
└── 24-hour monitoring window
4. CANARY rollout (flag ON for 5% of users)
└── Monitor error rates, latency, user behavior
└── 24-48 hour monitoring window
5. GRADUAL increase (25% -> 50% -> 100%)
└── Same monitoring at each step
6. FULL rollout (flag ON for all users)
└── Monitor for 1 week
└── Clean up feature flag
| Metric | Advance (green) | Hold and investigate (yellow) | Roll back (red) | |--------|-----------------|-------------------------------|-----------------| | Error rate | Within 10% of baseline | 10-100% above baseline | >2x baseline | | P95 latency | Within 20% of baseline | 20-50% above baseline | >50% above baseline | | Client JS errors | No new error types | New errors at <0.1% | New errors at >0.1% | | Business metrics | Neutral or positive | Decline <5% | Decline >5% |
Roll back immediately if:
Application metrics:
├── Error rate (total and by endpoint)
├── Response time (p50, p95, p99)
├── Request volume
├── Active users
└── Key business metrics
Infrastructure metrics:
├── CPU and memory utilization
├── Database connection pool usage
├── Disk space
└── Network latency
Client metrics:
├── Core Web Vitals (LCP, INP, CLS)
├── JavaScript errors
└── Page load time
In the first hour after launch:
1. Check health endpoint returns 200
2. Check error monitoring dashboard
3. Check latency dashboard
4. Test the critical user flow manually
5. Verify logs are flowing and readable
6. Confirm rollback mechanism works
Every deployment needs a rollback plan:
## Rollback Plan for [Feature/Release]
### Trigger Conditions
- Error rate > 2x baseline
- P95 latency > [X]ms
- User reports of [specific issue]
### Rollback Steps
1. Disable feature flag (if applicable)
OR
1. Deploy previous version: `git revert <commit> && git push`
2. Verify rollback: health check, error monitoring
3. Communicate: notify team of rollback
### Time to Rollback
- Feature flag: < 1 minute
- Redeploy previous version: < 5 minutes
- Database rollback: < 15 minutes
Before deploying:
After deploying: