如何找出软件发布流程中的瓶颈
先把发布流程画成流程图，数清每个决策的出口，再用桑基图呈现计数。找出构建失败、被退回或等待最久的那道关卡。
发布瓶颈是工作堆积、失败或被退回的那道关卡。本指南先画出流程，让每道关卡都是带有命名出口的决策，然后统计有多少次发布走了这些出口。
简而言之
- 先把流程画成带标签出口的决策，再开始计数。
- 统计一个周期内每个出口通过的发布（或构建）数。
- 回退分支很宽的关卡就是瓶颈，哪怕它本身很快。
- 用桑基图呈现计数，用流程图解释这些计数。
先看关卡，再看数字
团队通常靠平均耗时来找慢的步骤。这能找到慢的任务，却找不到把工作送回去的关卡。一次发布在测试里只待一天，却仍可能损失一周，因为测试失败会把它退回修复步骤，整个循环重新来过。要看清这一点，办法是把流程连同其中的决策一起画出来，再数有多少次发布走了每个出口。
流程图给出结构：每个决策有带标签的分支，每个分支有一个计数。示例是一个有四个决策的发布流程：自动化测试、放行还是不放行、生产环境是否健康，以及生产环境是否发现缺陷。有了每个分支的计数，桑基图就用宽度把它们呈现出来。构建阶段请看 /zh/sankey/ci-pipeline-outcomes，在它之前的评审阶段请看 /zh/sankey/pull-request-review-flow。
结论要保守。计数显示工作从哪道关卡离开，而不是为什么。原因要靠阅读失败的条目，以及询问负责这道关卡的人。
分阶段搭建的发布流程
二十个步骤和四个决策。每个决策都是桑基图会显示工作向两个方向离开的地方。
构建与自动化测试
流程从代码已可用于发布开始，冻结范围，然后运行自动化测试。第一个决策“自动化测试是否通过？”的“失败”分支会经过一个修复步骤回到构建。这个循环是第一个要统计的地方。
预发布环境、签字确认与放行决定
通过的构建进入预发布环境、回归测试和 UAT，随后汇总并批准发布就绪文档。“放行还是不放行？”的“不放行”分支会回到修复步骤，所以一次发布可能从流程的后半段被退回。
生产环境与回退之路
版本在发布窗口内部署并做冒烟测试。“这个版本是否健康？”分为监控，或回滚后回到修复步骤。回滚是代价最高的出口，所以它的计数最重要。
监控与热修复
观察期结束后，“生产环境是否发现缺陷？”把版本送去热修复（从部署重新进入），或去发布版本说明并结案。统计热修复分支被走了多少次。
运作方式
画出带决策的流程
把每道关卡画成带有标签出口的决策，例如“通过”和“失败”。把关卡画成普通步骤，就藏起了你想统计的那个出口。
选定周期和单位
取上一个季度，统计发布次数；如果发布频繁，就统计构建次数。在数据说明里写明用的是哪个。
统计每个决策的出口
对每个决策，数出有多少条目走了各个出口。数字取自你的 CI 系统、工单或发布日志。
把计数画成桑基图
用决策作为节点，出口作为流。检查进入每个节点的数量等于离开它的数量。
先看最宽的回退分支
最宽的、向后指的分支很可能就是瓶颈。阅读这些条目，找出原因。
应避免的错误
只统计最终结果
如果只数最终发布了什么，循环就消失了。要在每个决策处计数，否则桑基图会显示一个并未发生过的顺畅流程。
混用单位
构建、发布和工单是不同的单位。整张图选一个，并写明。
把计数当作原因
很宽的“失败”分支只说明测试经常失败，而没说为什么。改动流程之前，先看失败的条目。
打开软件发布流程图
打开发布模板，把关卡改成你自己的，然后统计各个出口。
相关指南
常见问题
如果我只想要桑基图，为什么还要画流程图？
因为流程图决定了节点是什么。没有它，桑基图显示的就是你的工具碰巧导出的阶段，而这些往往不是人们做决定的关卡。
我需要多少次发布的数据？
要让每个出口有多于几个条目。少于大约 20 个时，用表格显示计数，而不是图表。
这能代替测量前置时间吗？
不能。前置时间说明花了多久；桑基图说明工作从哪里离开或返回。两者都用，并比较同一个周期。