部署策略：交付 vs 部署 / 蓝绿 / 金丝雀 / 滚动 / 回滚
基于 CI/CD 通用模型 · 核于 2026-07
速查
- 持续交付 vs 持续部署：交付=自动就绪 + 人工放行上生产；部署=通过检查自动上生产。手动审批闸门（environment + required reviewers）是「持续交付」的标志。
- 蓝绿（blue-green）：维护两套对等环境，新版在绿验证通过后整体切流量，蓝留作秒级回滚后备；零停机，代价是双份资源。
- 金丝雀（canary）：先给一小部分流量/用户上新版，观察指标无恙再逐步扩大；重在小流量灰度 + 快速止损。
- 滚动（rolling）：逐批替换旧实例为新实例直到全量；控制同时不可用实例数，平滑但不一定按流量灰度。
- 回滚（rollback）：能快速切回上一个已知良好版本，把 MTTR 压低——与高部署频率相辅相成（发布快 + 恢复快才敢频繁发）。
- 构建一次，到处部署（build once, deploy everywhere）：同一制品晋级到各环境，差异用配置注入而非重新构建——测过的即上线的。
- environment 保护规则：绑定环境专属密钥 + 必需审批人 + 等待/分支限制，让「上生产」可控可审计。
- 幂等部署：同一部署操作执行一次或多次结果一致，失败可安全重试；声明式/按期望状态收敛的部署天然更易幂等。
- 可复现构建：锁依赖版本、固定基础镜像、去除时间/随机等隐性输入，保证相同输入产出相同产物。
一、先定性：这次要「交付」还是「部署」
选部署策略前，先明确团队处在 CD 的哪一层：
- 持续交付：流水线把变更准备到「可发布」，但上生产需人点头。实现靠「环境（environment）+ 手动审批闸门（如 GitHub 的 required reviewers、GitLab 的
when: manual）」。适合合规要求高、或对自动发布还没足够信心的团队。 - 持续部署：去掉人工闸门，通过全部自动检查即上生产。前提是有充分的自动化测试、可靠的监控与快速回滚兜底。
同一套发布策略（蓝绿/金丝雀/滚动）在两层下都能用，区别只在「触发上生产的那一下是人还是机器」。
二、蓝绿部署（blue-green）
维护两套完全对等的生产环境：
- 「蓝」当前承载线上全部流量；「绿」部署新版本并做验证（冒烟、健康检查）。
- 验证通过后，把流量整体切换到绿（改路由/负载均衡指向）。
- 蓝保留一段时间作为秒级回滚的后备——出问题把流量切回蓝即可。
优点：切换/回滚快、几乎零停机、发布与验证解耦。代价：需要双份资源；有状态服务（数据库迁移）需额外设计。
三、金丝雀发布（canary）
先把新版本暴露给一小撮流量/用户（如 1% → 5% → 25% → 100%）：
- 每一档观察关键指标（错误率、延迟、业务转化）；无恙才扩大，异常则快速止损（回退这部分流量）。
- 本质是「用真实小流量验证新版」，把爆炸半径控制在很小范围。
优点：风险可控、能在真实环境早发现问题。代价：需要能按比例切流量的基础设施 + 可观测的指标 + 自动/人工的判定。
四、滚动更新（rolling update）
逐批把运行旧版的实例替换为新版实例，直到全部更新：
- 每次只替换一部分（如 25%），控制「同时不可用的实例数」，保持服务整体可用。
- 与金丝雀的区别：滚动重在「平滑替换实例」，不一定按流量比例做灰度观测；金丝雀重在「小流量验证再扩大」。
K8s 的 Deployment 默认就是滚动更新（maxSurge/maxUnavailable 控制节奏）。
五、回滚：与「发布快」同等重要
高频部署意味着更多变更上线，出问题的绝对次数也可能上升。能快速、可靠地回滚（切回上一个已知良好版本）把故障恢复时间（MTTR） 压到很低，从而让团队敢于频繁发布——高部署频率与低 MTTR 是相辅相成的。没有快速回滚，激进发布就是玩火。
回滚的前提往往是「构建一次，到处部署」与不可变制品：因为你能精确定位并重新指向「上一个测过的产物」。
六、构建一次，到处部署
同一个构建产物（同一制品/镜像，用 digest 锁定）依次晋级到 staging、production，而不是为每个环境各自重新构建：
- 好处：测试过的正是最终上线的那个二进制，消除「各环境构建差异」带来的不确定性；回滚可精确指回某个产物。
- 环境差异（数据库地址、密钥、开关）通过配置/环境变量在运行时注入，而非重新编译进不同产物。
七、幂等与可复现：让部署可信、可重试
- 幂等部署：同一部署操作执行一次和多次，最终系统状态一致。这样部署因网络抖动等中途失败后，安全重跑不会造成重复副作用（重复扩容、重复迁移）。声明式基础设施（按期望状态收敛）天然更易做到。
- 可复现构建：相同输入（同提交、同依赖版本）应产出相同产物——要求锁定依赖（lockfile）、固定基础镜像、避免依赖当前时间/网络的隐性输入。可复现让 CI 结果可信、可审计、便于排障与供应链安全。
八、把环境保护规则用起来
「环境（environment）」是部署目标的抽象，配合保护规则能提供：
- 环境专属的 secrets 与 URL；
- 必需审批人（required reviewers）：上生产前要指定人放行（持续交付的人工闸门）；
- 等待计时 / 只允许特定分支部署：进一步收紧谁能、何时能部署。
这让「部署到生产」这件高风险的事在流水线里变得可控、可审计、可回溯。