3.1 持续交付与持续部署

3.1 持续交付与持续部署

本节摘要：持续交付指每个通过测试的制品都能随时部署到生产，是否发布由人决定；持续部署则更进一步，通过全部关卡后自动发布，无需人工介入。本节讲清两者分界、多环境晋升通道的设计、蓝绿/滚动/金丝雀三种部署策略的机制与选择，以及回滚为何必须与发布同级设计。

学习目标

1. 精确区分持续交付与持续部署，判断团队适合哪个等级
2. 设计一条测试→预发→生产的晋升通道及各关卡
3. 说明三种部署策略的机制、成本与适用条件
4. 把回滚做成分钟级的标准动作而非应急预案

一、CD 的两个 C：分界线在哪里

持续集成解决"代码能不能合并"，持续交付（Continuous Delivery）解决"合并之后能不能随时上线"。它的标准是：主干上的每个制品都处于"随时可发布到生产"的状态——构建过、测过、打包过、部署脚本演练过，发布只是一次执行决策。

持续部署（Continuous Deployment）把最后一步决策也交给机器：制品通过所有关卡后自动推上生产，全程无人值守。两者共用几乎全部的基础设施，唯一差别是生产发布前有没有人工卡点。

这个差别经常被神化——好像上了持续部署才算高级。实际上选择取决于变更的性质。面向消费者的 Web 功能，灰度指标可自动判定，适合持续部署；涉及资金结算、受监管数据、不可逆外部副作用（发短信、扣款）的变更，人工卡点不是落后，是合规与审慎。许多成熟团队的做法是混合式：普通变更全自动，高风险类别走人工批准。

一个有用的类比：持续交付像家里随时备好一辆加满油、检修过的车，想去哪儿随时出发；持续部署则是装了导航的车自己按计划出行。车的准备状态才是本质，自动驾驶只是锦上添花。

二、晋升通道：制品的三级旅程

制品从产出到生产，通常要经过三级环境，每级有各自的使命与关卡。

测试环境：自动进出，验证行为。制品一产生自动部署，跑自动化验收测试、契约测试。这里追求的是速度与确定性，数据可以是脱敏的样本数据。关卡是全自动的：测试不过，晋升终止。

预发环境：最接近生产的彩排场。硬件规格、网络拓扑、依赖的真实程度尽量贴近生产，数据用脱敏的生产副本。这里跑性能压测、最后的人工验收。关卡通常是业务负责人批准——这是持续交付与持续部署的分界点所在。

生产环境：渐进暴露。不追求一步到位，先金丝雀再逐步放量，观察指标后全量。关卡是"客观指标在观察期内正常"。

晋升记录示例（制品 app:3f2a91c）
──────────────────────────────────────────────
10:04  测试环境   部署完成        自动
10:09  测试环境   验收测试 412 项 全部通过
10:11  预发环境   部署完成        自动
10:35  预发环境   压测达标 p99 218ms
11:02  预发环境   业务验收        由 李工 批准
11:05  生产环境   金丝雀 2% 流量  自动
11:35  生产环境   指标观察期通过  错误率 0.01% 基线 0.02%
11:36  生产环境   放量 50%        自动
12:06  生产环境   全量 100%       自动
──────────────────────────────────────────────
全程 2 小时 2 分钟，人工介入 1 次（31 秒的批准）
​

这份记录体现了一个重要原则：部署过程本身要被完整记录，就像发布日志是部署的"飞行数据记录器"。哪一步、什么时间、谁批的、依据什么指标——事后复盘时这些是最硬的证据。

三、三种部署策略

蓝绿部署：双环境切换

准备两套完整环境：蓝（当前版本）与绿（新版本）。新版本部署到绿，验证通过后把流量入口从蓝切到绿——切换是一个原子动作，秒级完成；出问题把入口切回蓝，回滚同样秒级。代价是资源翻倍，且数据库结构变更要格外小心（切换前两套代码连着同一个库，变更必须双向兼容）。

滚动部署：逐台替换

不准备整套新环境，而是把旧实例分批替换成新实例，每替换一批观察一批。资源省，但版本混杂期长（新旧同时服务流量），回滚要把已替换的实例再换回去，比蓝绿的切换慢。适合无状态、横向扩展的服务。

金丝雀部署：先让一小部分用户试

把少量真实流量（比如 2%）导给新版本，观察错误率、延迟、业务指标，正常则逐级放量（2% → 10% → 50% → 100%），异常则立即掐断这部分流量。名字来自矿工带金丝雀下井探测毒气——用最小的代价提前发现危险。它是三种策略里风险控制最精细的，也是今天大规模线上服务的主流选择。

金丝雀判定规则示例（自动化执行）
──────────────────────────────────────────────
观察窗口: 每级放量后 30 分钟
通过条件: 5xx 错误率 < 0.05%
         p99 延迟劣化 < 10%
         核心业务转化率下降 < 3%
失败动作: 自动回切流量到稳定版 + 告警通知负责人
──────────────────────────────────────────────
​

选型的简化口诀：回滚速度要求秒级、资源充足 → 蓝绿；普通无状态服务 → 滚动；高流量高风险、指标体系健全 → 金丝雀。实践中常组合使用：滚动部署新实例，再按金丝雀逻辑放流量。

四、回滚：一等公民，不是应急预案

多数团队对发布的投入远大于对回滚的投入——发布有评审有测试有庆祝，回滚只有一句"出问题就恢复上个版本"。真出事时才发现"恢复上个版本"根本不可执行：上个版本的制品还能拉到吗？配置还匹配吗？数据库结构回得去吗？操作步骤谁记得？

发布之旅的暗线在回滚这里到达关键点：回滚必须在设计发布方案的那一刻同步设计。三个要求。

制品永续。每次发布的制品与配置快照永久留档（制品仓库不清理生产版本），回滚时精确拉取"上上个好版本"，而不是重新构建——重新构建的"同样代码"可能因为依赖漂移已经不同了。

数据库前向兼容。回滚应用容易，回滚数据难。惯用手法是"扩展-收缩"两阶段：先加新列不删旧列（旧代码还能跑），新版本稳定运行数周后确认不再回滚，再在下个版本清理旧列。凡是部署方案里包含不可逆的数据库变更，都必须单独评审。

演练回滚。像演练消防一样定期演练：随机挑一天，把某个非核心服务回滚再滚回，记录耗时。没有演练过的回滚方案，等于没有回滚方案。一个成熟的基准是：单服务回滚在三分钟内完成，且不需要架构师在场。

五、功能开关：部署与发布解耦

发布之旅里还有一个低调但强大的工具：功能开关。它让"部署代码"和"开放功能"变成两个独立动作——带着新功能的代码可以先部署到生产（开关关闭，对用户不可见），业务时机成熟时再远程打开开关。这带来三个自由度：主干开发不再需要长分支等发布窗口；出问题时先关开关（秒级）而不是回滚部署（分钟级）；可以按用户百分比渐进开放，本质上是用开关实现金丝雀。

代价是开关债务：开完不删的开关会越积越多，代码里满是永远为真的判断分支。纪律是给每个开关登记预期寿命（一次性开关、实验开关、长期运营开关），到期的定期清理。

本节要点回顾

• 分界：持续交付=随时可发、人决定何时；持续部署=通过即自动发；基础设施几乎相同
• 选择依据：变更的可灰度性与可逆性，不是团队格调；混合式最常见
• 晋升通道：测试环境全自动验证 → 预发贴近生产、业务卡点 → 生产渐进放量，全程留痕
• 三策略：蓝绿秒级切换资源翻倍、滚动省资源混杂期长、金丝雀按指标逐级放量
• 回滚三要求：制品永续、数据库前向兼容（扩展-收缩）、定期演练——没演练过的回滚方案等于没有
• 功能开关：部署与发布解耦，秒级止血；代价是要管理开关债务