交付流水线图把一次代码变更从提交到可发布所经过的阶段、运行环境、执行状态和卡点条件画在同一张视图上，回答“变更走到哪、卡在哪、下一步做什么”。它通常包含构建、测试、部署验证、发布观察等阶段，覆盖开发到生产的环境序列，并标注排队、运行中、成功、失败、等待审批等状态。下面按概念、边界、阶段、环境、状态和常见误解逐项说明。
要点总览（TL;DR）
- 交付流水线图以一次代码变更为对象，把阶段顺序、环境归属、执行状态和卡点条件画在同一张视图上，回答“变更走到哪、卡在哪、下一步做什么”。
- 常见阶段包括代码提交与构建、自动化测试、部署与验证、发布与观察，阶段之间可串行也可并行，图中应体现依赖关系。
- 环境维度通常按开发、测试、预发布、生产逐级推进，同一制品跨环境晋级，图中需标注环境专属配置与晋级条件。
- 状态信息包括排队、运行中、成功、失败、已取消等运行状态，等待审批、等待环境空闲等卡点状态，以及失败定位、时间和触发人信息。
- 常见误解包括把图画成工具连接图、只画成功路径、把审批规则写进图里、环境只标名称不标晋级条件。
交付流水线图表达的核心对象
交付流水线图是以一次代码变更为对象的交付路径模型。它从代码提交开始，经过构建、测试、部署验证，直到具备可发布条件或完成生产发布，把这条路径上的关键节点按推进顺序画出来。读图的人不需要翻多个系统，就能判断这次变更当前处在哪个环节。
一张合格的流水线图表达四类信息：
- 阶段顺序：变更依次经过哪些环节，哪些环节可以并行，哪些必须等待前序完成。
- 环境归属：每个阶段在哪个环境执行，制品从哪个环境晋级到哪个环境。
- 执行状态：每个阶段当前是排队、运行中、成功、失败还是已取消。
- 卡点条件：哪些位置需要人工审批、环境空闲或依赖任务完成，条件不满足时流程停在哪里。
这四类信息组合起来，让开发、测试、运维和发布负责人在同一张图上形成对交付进展的共同认知。团队讨论“这次需求能不能今天上线”时，依据的是图上显示的状态和卡点，而不是各自口头同步的进度。
定义与边界：流水线图管什么、不管什么
交付流水线图属于持续交付执行层面的可视化模型，描述的是交付流程的结构和当前进展。它把阶段、环境、状态和卡点放在一张图上，供团队读取和判断。理解它的边界，有助于避免把相邻工作的内容混进图里。
| 事项 | 归属 | 与流水线图的关系 |
|---|---|---|
| 流水线与代码托管、CI 平台的对接配置 | 研发工具链集成 | 图展示集成后的执行结果，不描述接口如何配置 |
| 发布准入判断、审批规则设计 | 发布审批与质量门禁 | 图可标注门禁所在位置和等待状态，规则本身由门禁系统定义 |
| 阶段顺序、环境归属、执行状态 | 交付流水线图 | 本文讨论的核心内容 |
需要说明的是，图中标注“等待审批”只表示此处存在卡点以及当前处于等待状态，审批由谁发起、依据哪些条件通过，属于发布审批与质量门禁的规则范畴。同样，图上显示某个阶段失败，说明执行结果，失败原因和修复动作仍要在具体任务和日志中处理。把规则定义塞进图里，会让图承担它不擅长的职责，也会让规则变更时图频繁失真。
一张流水线图通常包含哪些阶段
阶段划分没有唯一标准，但围绕“产出可部署制品—验证质量—部署到目标环境—发布并观察”这条主线，常见阶段及其输入输出如下：
| 阶段 | 主要动作 | 输入 | 输出 |
|---|---|---|---|
| 代码提交与构建 | 拉取代码、编译、打包、生成制品 | 代码提交记录、构建配置 | 带版本标识的可部署制品 |
| 自动化测试 | 单元测试、集成测试、接口测试等分层校验 | 构建产物、测试用例 | 测试报告与通过/失败结论 |
| 部署与验证 | 向目标环境发布，执行冒烟测试或健康检查 | 制品、环境配置 | 已部署实例与验证结果 |
| 发布与观察 | 灰度放量、运行监控、异常回退判断 | 验证通过的制品、发布策略 | 生产运行状态与发布结论 |
这些阶段可以串行，也可以部分并行。例如单元测试和静态检查可以在构建后同时触发，接口测试则依赖部署到测试环境完成。图中应把依赖关系画清楚：哪些阶段必须等待前序成功，哪些可以并行缩短整体耗时。阶段名称建议与团队日常说法一致，避免同一环节在不同团队有不同叫法，导致读图时反复确认。
环境维度：从开发到生产的逐级推进
环境维度回答“这个阶段在哪里执行”。常见序列是开发、测试、预发布、生产，每个环境承担不同的验证目的：开发环境用于快速联调，测试环境用于功能与集成验证，预发布环境尽量贴近生产配置做最终确认，生产环境承载真实流量。
流水线图表达环境信息时，重点在制品晋级关系。同一个制品从构建阶段产出后，依次进入测试、预发布、生产，每次晋级都对应一次部署动作和一组验证条件。坚持同一制品跨环境流转，可以减少“测试环境能跑、生产环境出问题”这类由构建差异引起的问题。图中可以用泳道或分组把环境标出来，让读者一眼看出某个阶段属于哪个环境。
环境专属配置和数据隔离也应在图上有所标注。例如预发布环境使用独立数据库、生产发布需要切换配置项，这些信息影响读图者对风险的判断。标注方式不必复杂，在环境名称旁注明关键差异即可。晋级条件同样要标：从测试进入预发布，是测试全部通过即可，还是需要额外的人工确认，图上写清楚，读者才知道流程会在哪里停下。
状态信息：图上看得到的执行进展与卡点
状态信息让流水线图从静态结构变成可读的进展视图。常见的状态字段包括：
- 运行状态：排队、运行中、成功、失败、已取消。
- 卡点状态：等待人工审批、等待环境空闲、等待依赖任务完成。
- 失败定位信息：失败发生在哪个阶段、哪个任务，日志入口在哪里。
- 时间与责任人信息：开始时间、已耗时、触发人。
读图时要把状态与阶段、环境组合起来看。同样是“等待”，出现在测试环境部署前，可能是等待环境空闲；出现在生产发布前，通常是等待审批。同样是“失败”，构建阶段失败意味着没有可用制品，预发布验证失败则说明制品已产出但未通过验证，两者的处理路径不同。团队可以据此决定是修复代码重新提交，还是排查环境问题后重跑。
当交付过程需要在项目管理工具中与需求、任务关联时，ONES DevOps 解决方案可整合 DevOps 工具链，集中可视化展现 CI/CD 全过程；集成 Jenkins、GitLab CI 等第三方流水线工具后，会自动同步流水线数据，更新执行状态和日志，并可将流水线与项目关联，帮助识别阻塞。对于希望把代码提交、流水线构建、产品发布与需求交付进度放在同一上下文中追踪的团队，这类关联能减少在多个系统间来回核对状态的成本。
相邻概念区别：流水线图与部署图、发布单、看板
这三个概念常与流水线图同时出现，但描述的对象不同。用同一口径对照，可以避免混用。
| 概念 | 描述对象 | 回答的问题 | 典型内容 |
|---|---|---|---|
| 交付流水线图 | 一次变更的推进过程 | 变更走到哪、卡在哪 | 阶段、环境、状态、卡点 |
| 部署图 | 系统运行时的拓扑结构 | 服务部署在哪些节点、如何连接 | 服务器、容器、网络、依赖关系 |
| 发布单 | 一次发布的内容与审批记录 | 这次发布包含什么、谁批准了 | 变更清单、审批人、发布时间 |
| 任务看板 | 任务的流转状态 | 任务由谁负责、进行到哪一步 | 待办、进行中、已完成等列 |
部署图描述系统“长什么样”，流水线图描述变更“怎么走”。发布单记录一次发布的决策与授权，流水线图记录执行路径与实时状态，两者可以互相引用，但记录的内容不同。任务看板管理的是任务流转，流水线图管理的是制品流转；一个需求可能对应多个任务，一次流水线运行也可能服务多个需求，二者粒度不同，不宜互相替代。
具体例子与常见误解
以下为演示情景，用于说明读图方法，不代表真实项目数据。某次提交触发流水线后，图上依次显示：构建阶段运行中，约两分钟后成功，产出制品 v1.2.3；单元测试与接口测试并行执行，单元测试成功，接口测试失败，图上该阶段标红并给出日志入口；开发修复后重新提交，新一次运行通过测试，进入预发布环境部署，健康检查通过；生产发布前显示“等待审批”，审批通过后进入灰度放量，观察期内状态为运行中，最终标记成功。整个过程在图上可以清楚看到两次运行、一次失败、一次等待审批。
围绕这张图，常见的误读有四类：
- 把流水线图画成工具连接图：图上画满代码托管、CI 平台、制品库之间的箭头，却看不出一次变更走到哪。工具连接关系属于工具链集成视图，流水线图应聚焦变更路径。
- 只画成功路径：忽略失败分支和回滚分支，导致实际失败时团队不知道流程会停在哪、如何退回。失败与回滚是交付过程的正常组成部分，应在图中体现。
- 把审批规则写进图里：在图上详细描述审批条件，代替门禁系统的规则配置。图只需标注门禁位置和等待状态，规则变更应在门禁系统中维护。
- 环境只标名称不标晋级条件：图上写了“测试”“预发布”，却没说明从测试进入预发布需要满足什么，读者无法判断流程会在哪里停下。
把这四类问题改掉，流水线图就能稳定承担它的核心职责：让团队对一次变更的推进路径、所处环境和当前状态形成一致判断，并据此安排下一步动作。
常见问题
交付流水线图和部署图看起来都是“图”，实际使用时怎么区分？
两者描述的对象不同。部署图描述系统运行时的拓扑结构，回答服务部署在哪些节点、彼此如何连接；交付流水线图描述一次变更的推进过程，回答变更走到哪个阶段、在哪个环境执行、当前是什么状态。实际工作中，部署图帮助判断基础设施和依赖关系，流水线图帮助判断交付进展和卡点位置。两者可以互相引用，例如在流水线的部署阶段标注目标环境对应的部署拓扑，但不宜用一张图同时承担两种职责。
流水线图里标注了“等待审批”，是否意味着审批规则也应该画在图上？
不需要。图上标注“等待审批”表达的是此处存在卡点以及当前处于等待状态，审批由谁发起、依据哪些条件通过，属于发布审批与质量门禁的规则范畴。规则写在门禁系统中维护，变更时只需更新规则配置；图只保留门禁位置和等待状态，这样图不会因为审批条件调整而频繁失真。如果团队把详细审批条件画进图里，规则一改图就要跟着改，维护成本高且容易与实际执行不一致。
团队刚开始画流水线图，阶段划分应该照搬行业通用模板吗？
不必照搬。阶段划分围绕“产出可部署制品—验证质量—部署到目标环境—发布并观察”这条主线即可，具体拆成几个阶段取决于团队的实际交付方式。例如测试环节较多的团队可以把单元测试、接口测试、集成测试分成独立阶段，交付频率高的团队可以把部署与验证合并。关键是阶段名称与团队日常说法一致，依赖关系画清楚，让读图的人不用反复确认。阶段过多会增加维护负担，阶段过少则看不出卡点位置，按实际需要取舍。
流水线图中环境只写到“测试”和“生产”两个，是否够用？
取决于验证需要。两个环境可以支撑基本流程，但测试环境与生产环境在配置和数据上差异较大时，容易出现测试通过、生产出问题的情况。增加预发布环境，尽量贴近生产配置做最终确认，可以提前暴露这类差异。环境数量增加后，图中要同步标注每个环境的晋级条件，例如从测试进入预发布需要测试全部通过还是额外人工确认，否则读者无法判断流程会在哪里停下。环境序列按团队实际验证需要设置，不必追求层级齐全。
把流水线数据同步到项目管理工具中，对读图和协作有什么实际帮助？
当流水线执行状态与需求、任务在同一上下文中呈现时，团队查看需求进展就能同时看到对应的构建、测试和发布状态，减少在多个系统间来回核对。ONES DevOps 解决方案可整合 DevOps 工具链，集中可视化展现 CI/CD 全过程；集成 Jenkins、GitLab CI 等第三方流水线工具后，会自动同步流水线数据，更新执行状态和日志，并可将流水线与项目关联，帮助识别阻塞。是否采用这类关联，取决于团队当前是否已经在项目管理工具中追踪需求交付进度。
