Development
发布与上线
为生产环境上线做准备。在准备部署到生产环境、设置监控、规划分阶段灰度发布或需要回滚策略时使用。
自信地发布。每一次上线都应当是可回滚、可观测且增量进行的。
console.log 调试语句npm audit 未显示严重（critical）或高危（high）漏洞通过功能开关发布，以将部署与发布解耦：
const flags = await getFeatureFlags(userId);
if (flags.taskSharing) {
return <TaskSharingPanel task={task} />;
}
return null;
功能开关生命周期：
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
| 指标 | 推进（绿色） | 暂停并调查（黄色） | 回滚（红色） | |--------|-----------------|-------------------------------|-----------------| | 错误率 | 在基线 10% 以内 | 高于基线 10%-100% | 超过基线 2 倍 | | P95 延迟 | 在基线 20% 以内 | 高于基线 20%-50% | 高于基线 50% 以上 | | 客户端 JS 错误 | 无新增错误类型 | 新增错误占比 <0.1% | 新增错误占比 >0.1% | | 业务指标 | 中性或正向 | 下降 <5% | 下降 >5% |
出现以下情况时立即回滚：
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
上线后第一个小时内：
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
每一次部署都需要回滚计划：
## 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
部署前：
部署后：