Ship with confidence. The goal is not just to deploy — it's to deploy safely, with monitoring in place, a rollback plan ready, and a clear understanding of what success looks like. Every launch should be reversible, observable, and incremental.
\nconsole.log debugging statements in production codenpm audit, pip-audit, cargo audit, ...) shows no critical or high vulnerabilitiesShip behind feature flags to decouple deployment from release:
\n// Feature flag check\nconst flags = await getFeatureFlags(userId);\n\nif (flags.taskSharing) {\n // New feature: task sharing\n return <TaskSharingPanel task={task} />;\n}\n\n// Default: existing behavior\nreturn null;\nFeature flag lifecycle:
\n1. DEPLOY with flag OFF → Code is in production but inactive\n2. ENABLE for team/beta → Internal testing in production environment\n3. GRADUAL ROLLOUT → 5% → 25% → 50% → 100% of users\n4. MONITOR at each stage → Watch error rates, performance, user feedback\n5. CLEAN UP → Remove flag and dead code path after full rollout\nRules:
\n1. DEPLOY to staging\n └── Full test suite in staging environment\n └── Manual smoke test of critical flows\n\n2. DEPLOY to production (feature flag OFF)\n └── Verify deployment succeeded (health check)\n └── Check error monitoring (no new errors)\n\n3. ENABLE for team (flag ON for internal users)\n └── Team uses the feature in production\n └── 24-hour monitoring window\n\n4. CANARY rollout (flag ON for 5% of users)\n └── Monitor error rates, latency, user behavior\n └── Compare metrics: canary vs. baseline\n └── 24-48 hour monitoring window\n └── Advance only if all thresholds pass (see table below)\n\n5. GRADUAL increase (25% -> 50% -> 100%)\n └── Same monitoring at each step\n └── Ability to roll back to previous percentage at any point\n\n6. FULL rollout (flag ON for all users)\n └── Monitor for 1 week\n └── Clean up feature flag\nUse these thresholds to decide whether to advance, hold, or roll back at each stage:
\n| Metric | \nAdvance (green) | \nHold and investigate (yellow) | \nRoll back (red) | \n
|---|---|---|---|
| Error rate | \nWithin 10% of baseline | \n10-100% above baseline | \n>2x baseline | \n
| P95 latency | \nWithin 20% of baseline | \n20-50% above baseline | \n>50% above baseline | \n
| Client JS errors | \nNo new error types | \nNew errors at <0.1% of sessions | \nNew errors at >0.1% of sessions | \n
| Business metrics | \nNeutral or positive | \nDecline <5% (may be noise) | \nDecline >5% | \n
Roll back immediately if:
\nApplication metrics:\n├── Error rate (total and by endpoint)\n├── Response time (p50, p95, p99)\n├── Request volume\n├── Active users\n└── Key business metrics (conversion, engagement)\n\nInfrastructure metrics:\n├── CPU and memory utilization\n├── Database connection pool usage\n├── Disk space\n├── Network latency\n└── Queue depth (if applicable)\n\nClient metrics:\n├── Core Web Vitals (LCP, INP, CLS)\n├── JavaScript errors\n├── API error rates from client perspective\n└── Page load time\n// Set up error boundary with reporting\nclass ErrorBoundary extends React.Component {\n state = { hasError: false };\n\n static getDerivedStateFromError() {\n return { hasError: true };\n }\n\n componentDidCatch(error: Error, info: React.ErrorInfo) {\n // Report to error tracking service\n reportError(error, {\n componentStack: info.componentStack,\n userId: getCurrentUser()?.id,\n page: window.location.pathname,\n });\n }\n\n render() {\n if (this.state.hasError) {\n return <ErrorFallback onRetry={() => this.setState({ hasError: false })} />;\n }\n return this.props.children;\n }\n}\n\n// Server-side error reporting\napp.use((err: Error, req: Request, res: Response, next: NextFunction) => {\n reportError(err, {\n method: req.method,\n url: req.url,\n userId: req.user?.id,\n });\n\n // Don't expose internals to users\n res.status(500).json({\n error: { code: 'INTERNAL_ERROR', message: 'Something went wrong' },\n });\n});\nIn the first hour after launch:
\n1. Check health endpoint returns 200\n2. Check error monitoring dashboard (no new error types)\n3. Check latency dashboard (no regression)\n4. Test the critical user flow manually\n5. Verify logs are flowing and readable\n6. Confirm rollback mechanism works (dry run if possible)\nYour 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:
\nBudget remaining > 20% → Ship normally; monitor closely\nBudget remaining 0–20% → Slow rollouts only; no high-risk changes\nBudget exhausted → Freeze feature work; focus entirely on reliability\nBudget resets → Resume normal pace; bake in the fix that recovered it\nA 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.
\nEvery deployment needs a rollback plan before it happens:
\n## Rollback Plan for [Feature/Release]\n\n### Trigger Conditions\n- Error rate > 2x baseline\n- P95 latency > [X]ms\n- User reports of [specific issue]\n\n### Rollback Steps\n1. Disable feature flag (if applicable)\n OR\n1. Deploy previous version: `git revert <commit> && git push`\n2. Verify rollback: health check, error monitoring\n3. Communicate: notify team of rollback\n\n### Database Considerations\n- Migration [X] has a rollback: <verified command or runbook link>\n- Data inserted by new feature: [preserved / cleaned up]\n\n### Time to Rollback\n- Feature flag: < 1 minute\n- Redeploy previous version: < 5 minutes\n- Database rollback: < 15 minutes\n../../references/definition-of-done.md../../references/security-checklist.md../../references/performance-checklist.md../../references/accessibility-checklist.mdobservability-and-instrumentation| Rationalization | \nReality | \n
|---|---|
| \"It works in staging, it'll work in production\" | \nProduction has different data, traffic patterns, and edge cases. Monitor after deploy. | \n
| \"We don't need feature flags for this\" | \nEvery feature benefits from a kill switch. Even \"simple\" changes can break things. | \n
| \"Monitoring is overhead\" | \nNot having monitoring means you discover problems from user complaints instead of dashboards. | \n
| \"We'll add monitoring later\" | \nAdd it before launch. You can't debug what you can't see. | \n
| \"Rolling back is admitting failure\" | \nRolling back is responsible engineering. Shipping a broken feature is the failure. | \n
| \"The error rate looks fine, let's keep shipping\" | \nCheck the burn rate, not just the current error rate. Consuming budget faster than baseline is a hold signal even when individual thresholds are green. | \n
Before deploying:
\nAfter deploying:
\nFor every shipped service:
\n