跳到主要内容

发布与回滚策略

场景​

线上发布后发现问题，需要快速回滚。如何设计发布流程和回滚机制？

方案设计​

1. 发布流程​

2. 灰度发布实现​

gray-release.ts
// Nginx 层灰度（根据 cookie/header 分流）
// location / {
//   if ($cookie_gray = "1") {
//     proxy_pass http://new_version;
//   }
//   proxy_pass http://stable_version;
// }

// 前端代码层灰度
function shouldUseNewFeature(userId: string): boolean {
  // 方案1：用户 ID hash 取模
  const hash = userId.split('').reduce((a, c) => a + c.charCodeAt(0), 0);
  return hash % 100 < 10; // 10% 灰度

  // 方案2：Feature Flag 服务
  // return featureFlags.isEnabled('new_checkout', { userId });
}

3. 回滚策略​

回滚方式速度适用场景
CDN 回切版本秒级纯前端项目
Docker 镜像回滚分钟级容器化部署
Git revert + 重新部署分钟级需要代码改动
Feature Flag 关闭秒级功能级回滚
cdn-rollback.ts
// CDN 版本管理（示意）
// 部署时保留历史版本
// /v1.0.0/index.html
// /v1.0.1/index.html
// /v1.0.2/index.html (当前)

// 回滚：将 CDN 指向修改为旧版本
// 或通过 Nginx 配置切换版本目录
k8s-rollback (Kubernetes 回滚)
# 查看部署历史
# kubectl rollout history deployment/frontend

# 回滚到上一版本
# kubectl rollout undo deployment/frontend

# 回滚到指定版本
# kubectl rollout undo deployment/frontend --to-revision=3

4. 发布检查清单​

## 发布前
- [ ] Code Review 已通过
- [ ] CI 测试全部通过
- [ ] 预发环境验证完成
- [ ] 关键指标的监控告警已设置
- [ ] 回滚方案已确认

## 发布中
- [ ] 灰度比例逐步提升
- [ ] 关注错误监控和性能指标
- [ ] 核心页面手动验证

## 发布后
- [ ] 全量后持续观察 15 分钟
- [ ] 确认无异常后通知团队
- [ ] 记录发布日志

常见面试问题​

Q1: 线上出问题了，回滚还是热修复（hotfix）？​

答案：

优先回滚，除非：

  • 回滚会丢失重要数据（如数据库 migration 不可逆）
  • 问题很小，修复比回滚更快（1-2 行代码改动）

回滚是确定性最高的操作，hotfix 可能引入新问题。

Q2: 前端灰度发布怎么实现？​

答案：

3 种常见方式：

  1. Nginx 层：根据 cookie、IP、header 等分流到不同版本的静态文件
  2. CDN 层：EdgeWorker/CloudFlare Worker 在边缘节点做分流
  3. 代码层：Feature Flag 服务控制功能开关，通过用户 ID hash 决定是否命中灰度

推荐方案：Nginx/CDN 层做版本灰度 + Feature Flag 做功能灰度。

相关链接​