面向频繁发布团队的发布管理流程：七个步骤与关键指标
阅读约 1 分钟
发布管理流程，是把一项变更从”已合并”带到”已在生产环境运行，并且向受影响的人解释清楚”的一整套步骤。对于经常发布的团队来说，它归结为七个步骤：规划范围、隔离变更、构建与测试、审批、部署与验证、沟通，以及复盘。每个步骤都需要一位具名的负责人和一条退出标准，否则它就会悄悄地不再发生。
本指南假设团队有 5 到 50 名工程师，每周或每天部署，并且希望流程不要碍事。
| 步骤 | 负责人 | 退出标准 |
|---|---|---|
| 1. 规划范围 | 产品负责人或技术负责人 | 本次发布包含的变更清单已写下，有风险的内容已标出 |
| 2. 分支或开关 | 负责这项变更的工程师 | 工作在一个短生命周期的分支上或藏在开关之后，让主干始终可发布 |
| 3. 构建与测试 | CI，作者在故障时待命 | 即将发布的那个确切提交上，流水线全绿 |
| 4. 审批 | 评审者，有风险的变更再加发布经理 | 评审完成，回滚路径已明确，通过或不通过的决定已记录 |
| 5. 部署与验证 | 发布经理或值班工程师 | 已部署，冒烟检查通过，错误率和延迟与发布前的基线一致 |
| 6. 沟通 | 理解这项变更的人，由不理解的人来编辑 | 发布说明已发布在用户阅读的地方，支持和销售已被告知 |
| 7. 复盘 | 发布经理 | 指标已查看，出过的问题都有负责人和修复方案 |
什么是发布管理流程？
它是一项变更触达用户所经过的、可重复的路径：范围、构建、测试、审批、部署、验证、公告，以及回顾。把它写下来的意义在于，每一次发布都走同一条路径，所以一个正在休假的人、一位新员工，或者凌晨两点的值班工程师，都可以直接执行，而不必去问别人它是怎么运作的。
发布管理有哪些不同类型？
实践中有三种类型：持续部署、定期发布，以及受监管的变更管理。它们的区别在于发布之前要做多少事，以及有多少是自动化的。持续部署会发布每一项已合并的变更，定期发布把变更批量打包成一趟班车，而受监管的变更管理则增加了正式的审批和审计记录。
| 持续部署 | 定期发布 | 受监管或 ITIL 变更管理 | |
|---|---|---|---|
| 发布单元 | 一个已合并的 pull request | 一个批次，每周或每两周 | 一份变更申请 |
| 范围步骤 | 隐含在合并之中，合并就是范围 | 发布规划会议 | 带风险评级的变更记录 |
| 审批 | 代码评审加自动化检查 | 发布经理为整个批次签字 | 变更咨询委员会或被委派的审批人 |
| 风险控制 | 功能开关、金丝雀发布、快速回滚 | 预发布环境浸泡、候选版本 | 书面的回退方案、维护窗口 |
| 典型节奏 | 每天多次 | 每周到每月 | 由变更日历决定 |
| 薄弱环节 | 没有人告诉用户发生了什么变化 | 大批次会掩盖是哪项变更搞坏了东西 | 流程耗时远超变更本身 |
大多数团队是混合的。一个 SaaS 产品可能持续部署，而它的移动应用按每周一趟班车发布，审计人员关心的那个支付服务，则遵循正式的变更记录。按服务来选择类型，而不是按公司。当变更只是逐步暴露时，发布和公告就成了两个独立的事件，这正是 feature flag 发布说明所讨论的情形。
发布经理的职责是什么？
发布经理负责一项变更到达生产环境所经过的路径。他们维护发布日历，判断一项变更是否就绪，执行或监督部署，做出回滚的决定，确保用户被告知，并在事后主持复盘。
发布之前，他们确认范围，并检查每一项有风险的变更都有回滚路径。发布期间，他们执行部署检查清单，盯住生产指标最初的几分钟，并尽早决定回滚。发布之后，他们确认说明已经发出，并记录流程中需要修正的地方。
在小团队里，让这个角色每周轮换，并把检查清单写好，这样就没有人需要依赖口口相传的经验。一个包含许多独立发布的软件包的 monorepo，通常每个软件包都需要一位发布负责人，否则这个角色就会变成瓶颈。
发布管理的关键 KPI 有哪些？
追踪 DORA 的软件交付指标，再加上你自己的一项：用户被告知所需的时间。DORA 的研究确定了五项指标，分为吞吐量（变更前置时间、部署频率、失败部署恢复时间）和不稳定性（变更失败率、部署返工率）两类。
DORA 的指南用平实的语言定义了它们（dora.dev, software delivery metrics）：
| KPI | 它衡量什么 | 需要留意什么 |
|---|---|---|
| 变更前置时间 | 从版本控制中提交，到部署到生产环境的时间 | 数字上升通常意味着评审或审批中出现了排队 |
| 部署频率 | 你多久部署一次，或两次部署之间的时间 | 频率下降意味着批次在变大 |
| 失败部署恢复时间 | 从一次需要立即介入的部署中恢复所需的时间 | 回滚和告警方面的问题会在这里显现 |
| 变更失败率 | 需要回滚或热修复的部署所占的比例 | 批次过大或测试不足时会上升 |
| 部署返工率 | 因生产事故而产生的计划外部署所占的比例 | 说明修复发布的速度快过了吸取教训的速度 |
| 用户被告知所需的时间 | 从生产部署到发布面向用户的说明的分钟数 | 需要自己测量，没有任何框架会提供它 |
较早的资料列出四项关键指标，并把恢复称为”恢复服务时间”。当前的指南使用上面这五项。
同一份指南还提醒不要把这些指标当作目标。设定诸如”到年底所有服务每天部署多次”这样的目标，会诱使团队去操纵数字，而且这些指标应该按应用或服务来解读，而不是在整个公司范围内混在一起。它为改善所有这些指标给出的实用建议，是缩小每次变更的规模，因为更小的变更更容易评审，更容易通过流水线，也更容易恢复。
发布沟通在发布管理流程中处于什么位置？
它是第六步，和其他每一步一样，有负责人，也有退出标准：说明已发布在用户阅读的地方，内部团队已被告知。团队最常跳过的就是这一步，因为部署工具在代码上线的那一刻就报告成功了。
让这一步按时完成，最省事的办法是在变更合并时就写好条目，而不是等发布时才写。pull request 里已经有标题、作者、关联的 issue 和上下文。据此生成的草稿是拿来编辑的，而不是一周之后凭记忆去写。这正是体验日志自动化背后的思路：在合并时生成草稿，留给人批准，然后从同一个来源发布到各处。Changeloop 就是这样工作的，它用 AI 从已合并的 pull request 起草条目，并在任何内容发布之前留给人批准。
有两种变体值得提前计划。支持和销售需要一份与客户不同的说明，这就是内部发布说明的用途。由事故驱动的发布来不及走正常的起草流程，所以要备好一份简短的模板，如紧急发布说明所述。发布说明模板为面向客户的版本提供了一个起步的形状。
如何让流程保持轻量？
把机器能检查的每一条退出标准都自动化，把人留给需要判断的事情。流水线全绿、仪表盘上的部署标记，以及每个已合并 pull request 对应的一条体验日志草稿，都是可以检查的。回滚方案是否可信，或者说明对客户来说是否说得通，则需要人来判断。
要检验这个流程，挑上个月的一次发布，问问团队之外的人，是否仅凭书面记录，就能说出发布了什么、谁批准的、怎样验证的，以及用户是什么时候被告知的。任何缺口，都是你下一个要改进的地方。
FAQ
发布管理和变更管理有什么区别? 发布管理让一组变更得以构建、测试、部署和公告。变更管理（按 ITIL 的含义）则是围绕每项变更的审批和风险流程。经常发布的团队，会把审批并入代码评审和自动化检查。
我们应该多久发布一次? 在你的测试和回滚路径允许的范围内越频繁越好，对许多 Web 团队来说是每天或更多。DORA 的建议是缩小每次变更的规模，因为小的变更更容易评审和恢复。
小团队需要发布经理吗? 他们需要这些职责，但不一定需要这个头衔。让工程师轮流担任这个角色，给轮值的人一份书面的检查清单，并确保七个步骤中的每一步都有人负责。
发布检查清单应该包含什么? 范围已确认，发布的那个提交上流水线全绿，回滚路径已明确，审批已记录，部署后做冒烟检查，指标与基线对比，发布说明已发布，支持已被告知，并安排好复盘。控制在一页之内。
本文的技术内容未经独立审核。如有错误，请告诉我们，我们会更正。