4.1 全自动部署条件

4.1 全自动部署条件

本节摘要：持续部署（CDP）要求每次通过门禁的 main 合并自动触达生产。本节给出六项前提 checklist——测试覆盖率、flaky 率、MTTR、Feature Flag、可观测性、文化授权——并附去掉 manual gate 的 GitHub Actions 示例。

本节目标

阅读完本节，你应当能够：

1. 用 checklist 评估团队 CDP 就绪度
2. 列举 CDP 相对 CD 的额外风险与控制
3. 配置无 manual 的 prod deploy job
4. 解释为何监管行业通常停在 CD

一、CDP readiness checklist

六项全绿才考虑去掉 environment: production 的 required reviewers。

# CDP: main 合并即 prod（无 manual）
on:
  push:
    branches: [main]
jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test && npm run build
  deploy-prod:
    needs: ci
    runs-on: ubuntu-latest
    steps:
      - run: kubectl set image deploy/app app=registry/app:${{ github.sha }}
      - run: kubectl rollout status deploy/app --timeout=300s
      - run: ./scripts/smoke-prod.sh
​

二、CDP 挑战与应对

来源 SOURCE：CDP 定义与挑战

持续部署将自动化延伸到生产——每一次通过测试的变更都自动上线。挑战包括：

• 测试必须极其可靠：flaky test 在 CDP 下直接变成 prod incident
• 监控必须实时：无人 approve，靠 metrics 发现异常
• 回滚必须自动化：人不能 3am 起床点 rollback
• 文化变革：Dev 对 prod 负责，非「扔给 Ops」

Feature Flag 作为 CDP 安全网

即使 CDP，也应用 flag 控制暴露：

# 代码已 deploy，flag 默认 off
if unleash.is_enabled("new-payment", context):
    charge_v2()
else:
    charge_v1()
​

Deploy ≠ Release——CDP 自动 deploy，product 手动/渐进 release flag。

⚠️ 常见坑：schema breaking migration 随 CDP 自动执行——旧版 pod 未摘完即读新 schema，500 雪崩。用 expand-contract 迁移模式。

💡 关键直觉：Etsy 早期 CDP 论文强调 dark launch——新代码 prod 跑但不接流量，只打日志验证。

数据库迁移 expand-contract

1. Expand：加 nullable 列，双写
2. Migrate：后台填数据
3. Contract：删旧列

三步跨多个 deploy，单次 CDP 只走一步——migration 脚本须 idempotent。

监管行业为何停 CD

SOX、HIPAA、PCI-DSS 要求职责分离——写代码的人不能独自上生产。CD + 双人 approve 是合规最小集，CDP 需额外 automated control 审计证明。

四、CDP 组织与文化前提（SOURCE 4.1 扩展）

测试金字塔在 CDP 下的要求

CDP 要求 E2E 虽在 CD 阶段跑，但通过率须接近 100%——flaky 容忍度接近零。Google 内部测试分级：small（PR）、medium（CI）、large（CD）、enormous（ nightly）——CDP 只依赖 small+medium 全绿，large 在 merge 前也必须绿。

监控与 SLO

CDP 团队须定义 SLI/SLO：可用性 99.9%、P99 latency < 300ms。Error budget 耗尽时冻结 feature deploy，只收 reliability fix——SRE 与 CDP 的衔接点。

渐进式 CDP adoption

1. 先对内部工具 CDP（blast radius 小）
2. 再对只读 API CDP
3. 核心写路径最后——期间保持 CD manual

Stripe 曾分享：支付核心路径长期 CD，周边 dashboard CDP——按业务风险分级，非一刀切。

数据库与 CDP

Expand-contract 迁移跨多个 deploy；单次 CDP 只 deploy 一步 migration script。Flyway/Liquibase 在 pipeline 跑 migration 须 backward compatible——add column nullable 先于 populate 先于 set NOT NULL。

重点提炼

• CDP checklist 六项 全绿才去掉 manual gate
• CDP yaml 无 environment reviewers
• Flaky test 是 CDP 第一杀手
• Feature Flag 分离 deploy 与 release
• expand-contract 数据库兼容 CDP
• 监管行业 多数停 CD + 审批
• dark launch 降低首次 CDP 风险

下一节 4.2 蓝绿与金丝雀——CDP 下的低风险发布策略。

CDP 的渐进式落地

全自动部署不应一步到位。推荐的路径是：先对非关键服务（内部工具、管理后台）启用 CDP，验证监控与回滚机制可靠后再扩展到核心服务。每个服务 CDP 前都要过六项 checklist，且 checklist 不是「一次通过永远通过」——测试覆盖率会随新代码下降，flaky 率会随季节波动，应定期复查。

CDP 的另一个前提是数据库与部署解耦：schema 变更必须向后兼容（expand-contract），应用回滚时数据库不能回滚。Flyway/Liquibase 脚本要满足「旧版本代码 + 新 schema 仍能运行」。此外，CDP 团队必须接受「失败是常态」：部署频率越高，单次部署风险越低，但总失败次数会上升，监控与回滚能力决定了团队能否承受这个频率。

自动化验证的分层

CDP 的自动化验证要分层部署：构建后跑单元与集成测试，部署后跑 smoke test 验证基本可用，随后由监控持续观察错误率与时延。每层都有独立触发与失败动作——测试失败阻断部署，smoke 失败触发回滚，监控异常触发告警或自动回滚。分层设计的目的是让「能发现问题」与「能自动恢复」在不同阶段都有兜底，而不是把所有验证压在一个环节上。

部署成功判定的工程化

全自动部署的「成功」不能只看 kubectl 返回成功，而应定义为一系列可观测条件的集合：新 pod 进入 Ready 状态、健康检查连续通过、错误率保持在阈值以下、smoke 关键路径返回预期结果。把这些条件写成一个 deploy guard 脚本，作为流水线最后一步，任何一个条件不满足都触发回滚。工程上常犯的错误是只看 rollout status 而忽略业务健康——应用进程活着不等于业务可用。

CDP 部署成功判定清单（示意）
1. kubectl rollout status 通过
2. /health 返回 200
3. 5xx 错误率 < 1%（部署后 2 分钟内）
4. smoke 脚本断言关键接口响应
5. 数据库连接池正常、无迁移报错
任一项失败 → 自动回滚 + 告警
​

把判定清单固化成脚本而非人工检查，是 CDP 区别于「自动化部署」的关键——自动化部署只是把按钮自动化，CDP 把「验证与恢复」也自动化了。