CI 流水线结果桑基图：从触发到失败原因
跟踪流水线运行：从触发方式到结果，再到每次失败的原因：不稳定测试、真实回归、配置与环境。
CI 流水线桑基图按触发方式显示构建如何结束，以及为什么失败。它把有意义的失败（回归）和没有意义的失败（不稳定测试）区分开来。
示例有 900 次流水线运行，来自三种触发方式：推送到主分支、拉取请求和夜间构建。760 次通过所有阶段，140 次失败，分别失败于构建（37）、测试（96）或部署（7）。最后一列给出原因：不稳定测试、真实回归、代码错误、依赖或配置，以及测试环境。
通过率掩盖了其中的构成。示例中，96 次测试失败有 35 次是不稳定测试，这是测试套件的信任问题；45 次是真实回归，说明流水线在正常发挥作用。计数是运行次数而不是提交数，所以一次重试就是一次运行。关于之前的评审阶段，请看 /zh/sankey/pull-request-review-flow，更完整的流程请看 /zh/guides/查找软件发布流程瓶颈。
如何阅读此图表
- 900 次运行中有 760 次（84%）通过所有阶段；140 次（16%）失败。
- 测试是最常见的失败点：140 次失败中有 96 次（69%）。
- 35 次失败是不稳定测试，占全部失败的 25%；45 次是真实回归。
- 拉取请求的运行通过率为 82%（500 次中的 410 次），主分支为 90%（300 次中的 270 次）。
图表背后的数据
数字为虚构，仅作说明，并非任何真实机构、团队或系统的数据。单位为流水线运行次数。
| 来源 | 目标 | 数量（次流水线运行） |
|---|---|---|
| 推送到主分支 | 通过所有阶段 | 270 |
| 推送到主分支 | 构建失败 | 8 |
| 推送到主分支 | 测试失败 | 17 |
| 推送到主分支 | 部署失败 | 5 |
| 拉取请求 | 通过所有阶段 | 410 |
| 拉取请求 | 构建失败 | 25 |
| 拉取请求 | 测试失败 | 65 |
| 夜间构建 | 通过所有阶段 | 80 |
| 夜间构建 | 构建失败 | 4 |
| 夜间构建 | 测试失败 | 14 |
| 夜间构建 | 部署失败 | 2 |
| 构建失败 | 代码错误 | 15 |
| 构建失败 | 依赖或配置 | 22 |
| 测试失败 | 不稳定测试 | 35 |
| 测试失败 | 真实回归 | 45 |
| 测试失败 | 环境 | 16 |
| 部署失败 | 依赖或配置 | 3 |
| 部署失败 | 环境 | 4 |
同样的数据（CSV）
source,target,value
推送到主分支,通过所有阶段,270
推送到主分支,构建失败,8
推送到主分支,测试失败,17
推送到主分支,部署失败,5
拉取请求,通过所有阶段,410
拉取请求,构建失败,25
拉取请求,测试失败,65
夜间构建,通过所有阶段,80
夜间构建,构建失败,4
夜间构建,测试失败,14
夜间构建,部署失败,2
构建失败,代码错误,15
构建失败,依赖或配置,22
测试失败,不稳定测试,35
测试失败,真实回归,45
测试失败,环境,16
部署失败,依赖或配置,3
部署失败,环境,4运作方式
导出一个周期的流水线运行
包含触发方式、首个失败的阶段和结果。重新运行算作单独的运行。
标注每次失败的原因
使用一份简短的列表：不稳定、回归、代码错误、配置、环境。没有原因的失败归入“未知”，这值得显示出来。
统计触发、结果与原因
每次运行只算一次，按其首个失败的阶段计。
检查平衡
每个失败阶段流出的运行数必须等于流入的。通过在第二列结束。
常见问题
如何区分不稳定测试和回归？
常见的规则是：没有代码改动，重试后由失败变为通过的测试就是不稳定的。使用你团队已有的规则，并在每个周期保持一致。
为什么按运行次数而不是提交数计？
运行次数是 CI 系统记录的内容。如果想按提交计，就让每个提交按最终结果只算一次，并在数据说明里写明。
编辑这张 CI 流水线桑基图
把示例作为你自己的图表打开，填入你的流水线计数。