shipping-and-launch Checked

if (flags.taskSharing) {

// New feature: task sharing

return <TaskSharingPanel task={task} />;

}

// Default: existing behavior

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 environment

3. GRADUAL ROLLOUT → 5% → 25% → 50% → 100% of users

4. MONITOR at each stage → Watch error rates, performance, user feedback

5. CLEAN UP → Remove flag and dead code path after full rollout

**Rules:**
- Every feature flag has an owner and an expiration date
- Clean up flags within 2 weeks of full rollout
- Don't nest feature flags (creates exponential combinations)
- Test both flag states (on and off) in CI

## Staged Rollout

### The Rollout Sequence

1. DEPLOY to staging

└── Full test suite in staging environment

└── Manual smoke test of critical flows

2. DEPLOY to production (feature flag OFF)

└── Verify deployment succeeded (health check)

└── Check error monitoring (no new errors)

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

└── Compare metrics: canary vs. baseline

└── 24-48 hour monitoring window

└── Advance only if all thresholds pass (see table below)

5. GRADUAL increase (25% -> 50% -> 100%)

└── Same monitoring at each step

└── Ability to roll back to previous percentage at any point

6. FULL rollout (flag ON for all users)

└── Monitor for 1 week

└── Clean up feature flag

### Rollout Decision Thresholds

Use these thresholds to decide whether to advance, hold, or roll back at each stage:

| 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% of sessions | New errors at >0.1% of sessions |
| Business metrics | Neutral or positive | Decline <5% (may be noise) | Decline >5% |

### When to Roll Back

Roll back immediately if:
- Error rate increases by more than 2x baseline
- P95 latency increases by more than 50%
- User-reported issues spike
- Data integrity issues detected
- Security vulnerability discovered

## Monitoring and Observability

### What to Monitor

Application metrics:

├── Error rate (total and by endpoint)

├── Response time (p50, p95, p99)

├── Request volume

├── Active users

└── Key business metrics (conversion, engagement)

Infrastructure metrics:

├── CPU and memory utilization

├── Database connection pool usage

├── Disk space

├── Network latency

└── Queue depth (if applicable)

Client metrics:

├── Core Web Vitals (LCP, INP, CLS)

├── JavaScript errors

├── API error rates from client perspective

└── Page load time

### Error Reporting

// Set up error boundary with reporting

class ErrorBoundary extends React.Component {

componentDidCatch(error: Error, info: React.ErrorInfo) {

// Report to error tracking service

reportError(error, {

componentStack: info.componentStack,

userId: getCurrentUser()?.id,

page: window.location.pathname,

});

}

render() {

if (this.state.hasError) {

return <ErrorFallback onRetry={() => this.setState({ hasError: false })} />;

}

return this.props.children;

}

}

// Server-side error reporting

app.use((err: Error, req: Request, res: Response, next: NextFunction) => {

reportError(err, {

method: req.method,

url: req.url,

userId: req.user?.id,

});

// Don't expose internals to users

res.status(500).json({

error: { code: 'INTERNAL_ERROR', message: 'Something went wrong' },

});

});

### Post-Launch Verification

In the first hour after launch:

1. Check health endpoint returns 200

2. Check error monitoring dashboard (no new error types)

3. Check latency dashboard (no regression)

4. Test the critical user flow manually

5. Verify logs are flowing and readable

6. Confirm rollback mechanism works (dry run if possible)

## Error Budget Release Gate

Your service's error budget — the fraction of requests or time your SLO allows to fail — determines whether it's safe to ship. Use it as an objective gate — not a negotiation:

Budget remaining > 20% → Ship normally; monitor closely

Budget remaining 0–20% → Slow rollouts only; no high-risk changes

Budget exhausted → Freeze feature work; focus entirely on reliability

Budget resets → Resume normal pace; bake in the fix that recovered it

A high burn rate during a canary (consuming budget faster than the baseline pace) is a **hold** signal in the rollout thresholds table above — treat it the same as an elevated error rate.

## Rollback Strategy

Every deployment needs a rollback plan before it happens:

Rollback Plan for [Feature/Release]

### Trigger Conditions

• Error rate > 2x baseline
• P95 latency > [X]ms
• User reports of [specific issue]

#