Skip to content
返回质量保障

部署门控与渐进交付

在构建和生产间插批准和验证门控、使部署为有意验证步骤——非合的自动后果。

为什么

每合自动部署到生产的管道快、但把每 bug 变生产事故——'CI 过'和'用户受影响'间无人检查点。部署门控插有意摩擦: 批准门控（人审变更点批准）、金丝雀门控（新版务 1% 流量监错率 10 分钟）、回滚门控（金丝雀错率超 0.5% 部署自动回滚）。这是渐进交付: 部署分阶段（staging → 金丝雀 → 10% → 50% → 100%）、每阶段验证后才下、任阶段可失败不影响全员。权衡是部署速度（分钟变几十分钟）换安全（坏部署影响 1% 用户 10 分钟非 100% 用户一小时）。对面向用户生产系统、此权衡几乎总值得。

何时使用

部署目标是面向用户生产环境时——staging 和预览环境可自动部署、但生产应总有至少一门控（批准或金丝雀）。

如何做

1. 分构建和部署阶段
   - CI 管道: lint → 测试 → 构建 → 发产物（到注册表）
   - 部署管道: 手动或打标签触发、非每合

2. 生产前加批准门控
   - GitHub Environments: 建"production"环境带必需审查者
   - 部署 job 暂停直到审查者在 GitHub UI 点"批准"
   - 这是人检查点: 审查者读 diff、变更日志、测试结果

3. 先部署 staging 再提升
   - 自动部署 staging（无需批准）
   - 对 staging 跑冒烟测试
   - 仅 staging 冒烟过且人批准后提升到生产

4. 高流量服务加金丝雀阶段
   - 1% 流量路由到新版（Istio、Argo Rollouts、Cloudflare Workers）
   - 监错率和延迟 10 分钟
   - 错率 < 0.5% 且 p99 延迟 < 基线时提升到 10% → 50% → 100%
   - 错率 >= 0.5% 时自动回滚并告警

5. 使回滚一键（或零键）操作
   - 保留前版产物 24 小时
   - 回滚重部署前产物——无重建、无重测
   - 金丝雀失败自动回滚；其他情况手动回滚按钮

示例

# .github/workflows/deploy.yml — 门控生产部署
name: deploy
on:
  push:
    tags: ["v*"]
jobs:
  deploy-staging:
    runs-on: ubuntu-latest
    steps:
      - run: ./deploy.sh staging
      - run: ./smoke-test.sh https://staging.example.com

  deploy-production:
    needs: deploy-staging
    environment:
      name: production        # 要求审查者批准
      url: https://example.com
    runs-on: ubuntu-latest
    steps:
      - run: ./deploy.sh production --canary 1%
      - run: ./canary-watch.sh --threshold 0.5% --duration 10m
      - run: ./deploy.sh production --promote 100%

常见问题

  • ⚠每合自动部署生产无批准门控——坏合秒内变生产事故、团队生合恐惧慢开发。
  • ⚠加批准门控但无金丝雀——人批准、部署一次到 100% 流量、人漏的 bug 立即影响全员无自动回滚。
  • ⚠回滚需全重建重部署——回滚 15 分钟（同前部署）、故团队前修部署非回滚、事故持续比应长。
  • ⚠金丝雀监窗太短（1 分钟）——慢烧 bug（5 分钟后崩 pod 的内存泄漏）过金丝雀到 100% 后错率才升。

最佳实践

  • ✓每合自动部署 staging、但生产要求人批准（GitHub 环境带必需审查者）——这给 staging CI 速度和生产检查点安全。
  • ✓用金丝雀阶段（1% → 10% → 50% → 100%）带自动错率监和自动回滚——坏部署影响 1% 用户 10 分钟非 100% 一小时。
  • ✓保留前产物 24 小时使回滚为该产物重部署（无重建）——回滚 30 秒、故团队实际用它非前修。
  • ✓金丝雀监窗至少 10 分钟并监错率和 p99 延迟——这抓 1 分钟窗会漏的慢烧 bug。