交付流水线图把一次代码提交到上线之间的关键环节、执行主体、输入输出和判断条件画在同一张图上，便于团队在评审、交接和排障时对照。本文给出一份可直接照填的演示示例，以“提交—构建—测试—制品—部署—验证”为主干，标注每个环节的负责人、触发条件、产出物和失败去向，并说明工具链集成与发布审批应如何单独表达。示例中的团队、分支、环境均为演示取值，读者可替换为自身情况；ONES 在交付流执行中可承载环节状态与工作项关联，下文在相关位置简要衔接。
要点总览（TL;DR）
- 交付流水线图把一次提交到上线之间的环节、执行主体、输入输出和失败去向画在同一张图上，完成标准是顺序清晰、责任可追溯、失败有去向。
- 示例以“提交—构建—测试—制品—部署—验证”为主干，每个环节填写触发条件、执行主体、输入、产出物和失败去向五列，可直接替换取值照填。
- 换团队时保留字段结构，按发布频率调整环节粒度、按技术栈替换具体动作，质量门禁与审批以独立标注挂在环节旁。
- 工具链对接配置和发布审批规则属于相邻主题，图中只标注不展开；示例数据为演示取值，不作为行业基准。
示例目标：这张交付流水线图要回答什么
这张图要回答的是交付流执行层面的问题：一次提交进入流水线后，依次经过哪些环节，每个环节由谁负责、在什么条件下开始、产出什么、失败后回到哪里。它服务于三类使用时机：新成员了解交付路径、迭代评审时核对环节责任、出现阻塞时定位失败分支的去向。
完成标准可以归纳为三条可核验的观察点：
- 环节顺序清晰：从提交到上线的主干环节能按先后顺序读出，不出现跨环节的跳跃或缺失。
- 责任可追溯：每个环节都有明确的执行主体，读者能判断该找谁确认状态。
- 失败有去向：每个可能失败的环节都标出回退目标或人工介入点，不停留在“失败”二字。
需要说明的是，这张图描述的是执行流本身。工具如何对接、审批规则如何设定，属于相邻主题，图中只以标注形式出现，不展开配置细节。
完整示例：一张从提交到上线的交付流水线图
以下为演示情景：某产品团队采用主干开发、每日多次合并、按周发布的方式，主干环节与字段填写如下表。表中团队名称、分支名、环境名均为演示取值，不代表真实客户案例。
| 环节 | 触发条件 | 执行主体 | 输入 | 产出物 | 失败去向 |
|---|---|---|---|---|---|
| 提交 | 开发者在功能分支完成自测并提交合并请求 | 开发工程师 | 代码变更、关联的工作项编号 | 合并请求、提交记录 | 退回开发者补充修改 |
| 构建 | 合并请求创建或更新时自动触发 | 流水线自动执行，构建负责人值守 | 合并后的代码、依赖清单 | 构建产物、构建日志 | 失败通知开发者，修复后重新触发 |
| 测试 | 构建成功后自动触发 | 测试工程师负责结果判定，自动化用例由流水线执行 | 构建产物、测试用例集 | 测试报告、缺陷记录 | 用例失败退回开发修复；环境问题转测试环境负责人 |
| 制品 | 测试通过后自动归档 | 构建负责人 | 通过测试的构建产物、版本号规则 | 带版本号的制品包、制品清单 | 归档失败回退至构建环节重跑 |
| 部署 | 制品归档完成且发布窗口开启 | 运维工程师执行，发布负责人确认 | 制品包、环境配置 | 部署记录、环境版本信息 | 部署失败回滚至上一稳定版本，记录原因 |
| 验证 | 部署完成后自动触发冒烟检查 | 测试工程师与运维工程师共同确认 | 部署后的环境、冒烟用例 | 验证结论、上线确认记录 | 验证不通过回滚部署，转缺陷跟踪 |
主干之外还有两条需要单独标注的分支：一是测试环节发现严重缺陷时，跳过制品归档直接退回开发，并在图中用虚线标出；二是部署环节遇到发布窗口未开启的情况，制品停留在待发布状态，由发布负责人决定是否顺延。这两条分支体现的是判断条件，而非新增环节。
在工具承载上，这类环节状态与工作项的对应关系可以放到研发管理平台中维护。例如 ONES 支持将流水线与项目关联，在项目、迭代、需求视图中可视化代码提交、流水线构建、产品发布等过程，帮助团队对照图中的环节追踪执行状态（依据 ONES DevOps 解决方案公开资料）。
逐项解释：每个字段为什么这样填
示例中的字段取值不是唯一答案，但每一项都有填写逻辑，理解逻辑比照抄取值更重要。
环节划分的粒度
主干按“提交—构建—测试—制品—部署—验证”划分，依据是每个环节的产出物形态不同：代码、构建产物、测试结论、版本化制品、运行环境、上线确认，各自可以独立判定完成与否。如果两个动作共享同一产出物且失败处理方式一致，可以合并；如果同一环节内存在不同的责任人或不同的失败去向，则应拆开。例如把“测试”拆成单元测试与集成测试，前提是两者的执行主体或失败处理确实不同。
触发条件与准入判断
触发条件写成“什么事件发生后开始”，准入判断写成“满足什么条件才允许开始”，两者相邻填写可以避免歧义。示例中构建的触发条件是合并请求创建或更新，部署的准入是制品归档完成且发布窗口开启。触发条件描述事件，准入条件描述状态，混写会让读者分不清环节是自动开始还是需要人工放行。
产出物与状态衔接
每个环节的产出物应能作为下一环节的输入被引用，形成可核对的链条。示例中构建产出构建产物，测试以构建产物为输入并产出测试报告，制品环节再把通过测试的产物归档为带版本号的制品包。填写时检查相邻两行的“产出物”与“输入”是否对得上，对不上说明中间缺了环节或字段写错。
失败分支与人工介入点
失败去向要写到具体目标，例如“退回开发者补充修改”“回滚至上一稳定版本”，而不是笼统写“处理失败”。人工介入点单独标注，例如测试结果判定、发布窗口确认，让读者知道哪些节点需要人做决定、哪些由流水线自动流转。人工介入点过多会拖慢交付节奏，过少则风险集中在自动化判断上，填写时按团队实际控制要求取舍。
可迁移规律：换一个团队怎么改这张图
示例的字段结构可以保留，取值按团队情况替换。以下调整规则按常见变化维度列出。
- 按发布频率调整环节粒度：每日多次发布的团队可以把部署与验证合并为“部署并冒烟”，减少图中节点；按季度发布的团队可在制品与部署之间增加“发布评审准备”环节，把等待期显性化。
- 按技术栈替换具体动作：构建环节在容器化团队中可能是镜像构建，在移动端团队中可能是打包签名；部署环节可能是容器编排发布或应用商店提审。环节名称与字段结构不变，只替换输入、产出物和执行的具体动作。
- 把质量门禁与审批作为独立标注：覆盖率阈值、安全扫描通过等门禁条件，以及发布审批的签核人，用标注挂在对应环节旁，不并入执行环节本身。这样执行流与管控规则可以分别维护，规则调整时不必重画主干。
- 保持字段结构不变、只替换取值：触发条件、执行主体、输入、产出物、失败去向五列始终保留，团队规模变化时调整的是每列内容，例如小团队中构建与部署可能由同一人负责，大团队则拆分为不同角色。
调整后建议做一次走查：拿最近一次真实交付对照图上的环节，检查是否有环节在图中缺失、是否有失败去向在实际中从未触发。走查结果可以作为下一版图的修订依据。
适用边界：哪些内容不放进这张图
这张图聚焦交付流执行，以下内容属于相邻主题，建议单独成文或在图中以引用方式出现。
- 流水线与平台对接归研发工具链集成：具体 CI/CD 工具的接入方式、凭据配置、数据同步机制，属于集成配置范畴，图中只标注“已接入”或工具名称。ONES 支持集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步流水线数据并更新执行状态和日志，这类配置细节不在本文展开。
- 发布准入归发布审批与质量门禁：审批人、签核顺序、门禁阈值规则的设计，属于发布管控主题，图中以标注呈现，不写规则内容。
- 示例情景与真实案例的区分：本文表格为演示取值，读者替换为自身团队信息后才是可用的团队文档，不应把示例数据当作行业基准。
- 具体工具能力、版本与价格需另行查证：本文不涉及工具选型结论，涉及具体产品的功能范围、兼容版本和报价时，应以官方最新资料为准。
按此边界使用，这张图可以作为交付流执行的共同参照；集成配置与审批规则分别维护，三者通过环节名称和标注相互引用，避免一张图承载过多职责而难以维护。
常见问题
团队规模很小，构建和部署由同一个人负责，这张图还需要分两行写吗？
可以合并，前提是两个动作的失败去向一致。示例中构建失败是修复后重新触发，部署失败是回滚至上一稳定版本，处理方式不同，所以分开写。如果小团队中构建与部署由同一人执行、失败后都走同一条修复路径，合并为“构建与部署”一行不会丢失信息。判断依据是失败去向是否相同，而不是执行人数。
流水线里已经有自动化工具在跑，这张图会不会和工具里的流程重复？
两者用途不同。工具里的流水线定义描述机器如何执行，这张图描述人如何理解和核对交付路径，用于评审、交接和排障时对照。图上的环节名称应与工具中的阶段名称保持一致，便于互相引用。工具接入方式、凭据配置等细节不写进图里，只在对应环节旁标注工具名称。
发布审批的签核人要不要直接写进执行主体一栏？
建议单独标注，不并入执行主体。执行主体指实际执行该环节动作的角色，审批签核属于发布管控规则，规则调整频率通常高于执行流。把签核人写成环节旁的标注，审批顺序变化时只需改标注，主干不用重画。如果团队发布频率很低、审批人长期固定，也可以在执行主体中并列写出，但要注明这是审批角色而非执行角色。
画完之后怎么判断这张图是否还准确？
拿最近一次真实交付对照图上的环节走查一遍：检查实际发生的环节是否都在图上、图上标注的失败去向是否在实际中触发过、执行主体是否与当前分工一致。走查中发现的偏差作为下一版修订依据。团队调整发布节奏或更换技术栈后，建议重新走查一次，重点看环节粒度和具体动作是否需要替换。
ONES 在这张图的执行过程中能承载哪些信息？
ONES 支持将流水线与项目关联，在项目、迭代、需求视图中可视化代码提交、流水线构建、产品发布等过程，团队可以对照图中的环节追踪执行状态。集成 Jenkins、GitLab CI 等第三方流水线工具后，ONES 会自动同步流水线数据并更新执行状态和日志。具体集成配置与兼容范围以官方最新资料为准。
