交付流水线图在持续交付中表达什么：阶段、环境与状态

交付流水线图把一次代码变更从提交到上线所经过的环节画在同一张图上，让团队看清它当前走到哪一步、在哪个环境验证、处于什么状态。读图时要同时看阶段顺序、环境归属和状态标注三层信息；工具链对接配置和发布审批决策属于相邻范畴，不在图中表达。

要点总览（TL;DR）

• 交付流水线图把一次代码变更从提交到上线经过的环节画在一张图上，同时呈现阶段顺序、环境归属和执行状态三层信息。
• 常见阶段包括代码检出与构建、自动化测试、部署到各环境、验证与确认、生产部署与上线后观察，团队可按风险裁剪，不要求固定数量。
• 环境通常分为开发、测试、预发、生产，以泳道、列或节点标注呈现，同一类阶段可能在不同环境重复执行。
• 状态包括等待、运行中、成功、失败、已取消、已回滚，需与阶段、环境组合起来读，才能定位问题位置和影响范围。
• 流水线图表达执行过程，流水线配置定义执行规则，发布看板关注发布批次与审批进度，三者职责不同，不能互相替代。

交付流水线图表达的核心对象

交付流水线图是持续交付管理中对一次交付从代码变更到上线所经过环节的图形化表达。它描述的对象是交付流的执行路径：代码从哪个提交进入、依次经过哪些验证和部署动作、最终到达哪个运行环境。

这张图同时承载三类信息，并且强调它们之间的对应关系。阶段回答“做了什么”，例如构建、测试、部署；环境回答“在哪里做”，例如测试环境、预发环境、生产环境；状态回答“做得怎么样”，例如等待、运行中、成功、失败。三者叠加后，读者不需要逐个打开日志，就能判断一次变更的位置和结果。

它服务于持续交付管理中的可视化与判断：评审一张流水线图，实质是检查交付路径是否覆盖了必要的验证环节、环境推进顺序是否合理、失败时能否快速定位。图中呈现的是执行过程，组织架构、人员分工和职责归属由其他管理视图承载。

交付流水线图的范围与边界

流水线图聚焦交付流的执行环节，把“变更经过了什么、结果如何”画清楚。它与工具链集成、发布审批共享同一批交付数据，但各自承担不同的表达任务。划清边界，可以避免把配置问题或审批问题误读成流水线图的问题。

维度	属于流水线图的表达范围	不属于流水线图的表达范围
核心内容	阶段顺序、环境归属、每个环节的执行状态	流水线与外部平台的对接配置，归研发工具链集成
判断类型	某环节是否执行、是否成功、卡在哪里	发布准入规则与审批结论，归发布审批与质量门禁
数据性质	执行结果与状态变化	审批人、审批意见与决策记录
使用目的	定位交付路径上的阻塞点	决定某次发布是否被批准

需要说明的是，图中状态反映执行结果，审批决策记录的是人的判断。一次构建显示成功，只说明该环节执行通过；是否允许进入生产，仍取决于团队设定的准入条件和审批结论。把两者混为一谈，容易在评审时遗漏真正的放行依据。

流水线图一般包含哪些阶段

阶段按交付顺序排列，每个阶段承担一类验证任务。常见划分如下，团队可依据技术栈和风险程度裁剪，不要求固定数量。

1. 代码检出与构建：拉取指定提交的代码，编译打包，产出可部署的制品。这一阶段确认代码能形成可运行产物。
2. 自动化测试：通常先跑单元测试，再跑集成测试，必要时补充接口测试或端到端测试。测试层级越靠后，耗时越长，覆盖的交互越接近真实使用。
3. 部署到各环境：把制品依次部署到测试、预发等环境。部署本身也是一次验证，确认制品在目标环境中能正常启动和运行。
4. 验证与确认：部署后执行冒烟测试、健康检查或人工验收，确认环境中的服务可用，再决定是否推进到下一环境。
5. 生产部署与上线后观察：制品进入生产环境，随后观察关键指标和错误率，必要时触发回滚。

阶段划分的作用是让验证责任分段落地：构建阶段暴露编译问题，测试阶段暴露逻辑问题，部署阶段暴露环境差异问题。阶段过少会让问题集中到后期暴露，阶段过多则拉长反馈时间，取舍依据是团队对哪类风险的承受能力更低。

环境在流水线图中的表达方式

环境是叠加在阶段之上的维度。常见层级为开发、测试、预发、生产，越往后越接近真实用户，验证成本也越高。同一类阶段可能在不同环境重复执行，例如“部署”在测试环境和预发环境各出现一次，“自动化测试”也可能在多个环境分别运行。

在图形呈现上，环境通常以泳道、列或节点标注体现。以泳道呈现时，横向读是阶段推进，纵向读是同一环境内的动作；以列呈现时，每一列对应一个环境，从左到右体现推进方向；以节点标注时，环境写在阶段节点旁，适合阶段较少、路径单一的流水线。

环境与阶段的对应关系决定读图方式。读图时先确认环境推进顺序是否符合团队约定，再检查每个环境内是否配置了应有的验证动作。若某环境只有部署没有验证，图中会表现为该列动作稀疏，这往往是评审时需要追问的地方。

状态信息如何标注在流水线图上

状态标注在阶段与环境的交叉点上，回答“这个环节现在怎么样”。常见状态及含义如下。

状态	含义	读图时的判断
等待	环节已排入队列，尚未开始执行	检查是否存在前置依赖未完成或资源排队
运行中	正在执行	结合耗时判断是否异常偏长
成功	执行完成且结果符合预期	确认是否满足进入下一环节的条件
失败	执行完成但结果不符合预期	定位失败环节，查看日志与触发来源
已取消	执行被主动终止	确认取消原因，判断是否需要重新触发
已回滚	已部署的版本被撤回	核对回滚范围与当前实际运行版本

状态需要与阶段、环境组合起来读。例如“预发环境—部署—失败”指向制品在预发环境部署受阻，“生产环境—验证—已回滚”说明上线后发现问题并撤回。单看一个状态词无法定位问题，组合后才能确定位置和影响范围。

状态变化的时间与触发来源同样重要。时间信息帮助判断环节是否卡住，触发来源说明这次执行由哪次提交或哪次手动操作引起。团队在评审流水线时，通常先看失败或回滚状态，再回溯触发来源，确认问题是否已修复。

当流水线与项目管理工作项关联时，状态信息还能回到需求或迭代上下文中查看。ONES DevOps 解决方案支持集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步编排的流水线数据，更新执行状态和日志；并将流水线与项目关联，在项目、迭代、需求中可视化代码提交、流水线构建、产品发布等过程，便于团队结合工作项判断阻塞位置。这一衔接的前提是已完成相应集成配置，具体同步时效与状态字段以实际集成为准。

与相邻概念的区别：流水线图、流水线配置与发布看板

三个概念常被混用，区别在于各自回答的问题不同。

概念	回答的问题	信息形态	主要使用者
流水线图	这次变更走到哪、结果如何	阶段、环境、状态的执行视图	开发、测试、值班人员
流水线配置	流水线应该按什么规则执行	定义阶段与步骤的规则文件	维护流水线的工程人员
发布看板	哪些发布批次待批、批到哪一步	发布批次与审批进度视图	发布负责人、审批人

流水线图是执行过程的可视化表达，反映已经发生和正在发生的事；流水线配置是规则定义，决定图会长成什么样；发布看板侧重发布批次与审批进度，关注放行决策。三者信息可以互相引用，例如从发布看板跳转到对应流水线图查看执行结果，但职责不同，不能用其中一张视图替代另外两张。

一个具体例子与常见误解

以下为演示情景，用于说明读图方法。某次提交进入流水线后，图中依次呈现：构建阶段成功；单元测试与集成测试成功；部署到测试环境成功，冒烟验证成功；部署到预发环境时状态变为失败，后续生产部署环节停留在等待。读图时可以得出三个判断：变更已通过代码级验证，问题出在预发环境的部署环节，生产环节尚未开始。此时应查看预发部署的日志与触发来源，确认是配置差异还是制品问题，修复后重新触发，而不是直接推进生产。

常见误解有三类。其一，把流水线图当成审批记录，看到某环节成功就认为已获得上线许可，实际上放行仍需依据准入条件和审批结论。其二，把绿色状态当成已上线，成功只代表该环节执行通过，生产环境是否已运行新版本要结合部署与验证状态确认。其三，认为阶段越多越好，阶段数量应与风险匹配，冗余阶段会拉长反馈周期，反而降低交付节奏。

评审自己团队的流水线图时，可以按三步检查：先看环境推进顺序是否与团队约定一致，再看每个环境内是否都有对应的验证动作，最后看失败和回滚状态是否有明确的处理去向。三步都能说清楚，这张图才真正起到支撑持续交付判断的作用。

常见问题

流水线图上的状态显示成功，是否意味着这次变更可以上线？

不代表。图中的成功状态只说明该环节执行完成且结果符合预期，例如构建通过、测试通过或部署完成。是否允许进入生产，取决于团队设定的准入条件和审批结论，这部分信息属于发布审批与质量门禁的范畴，不在流水线图中表达。

读图时可以把成功状态理解为“该环节没有阻塞”，把上线许可理解为另一个判断。两者混在一起看，容易在评审时遗漏真正的放行依据。

团队阶段数量不一致时，流水线图还能横向比较吗？

可以比较，但需要先对齐口径。不同团队因技术栈和风险偏好不同，阶段划分会有差异，例如有的团队把单元测试和集成测试合并为一个测试阶段，有的团队拆成两个。

横向比较时，建议按验证目的归类：代码能否形成制品、逻辑是否正确、环境是否可用、上线后是否稳定。按目的对齐后再看各团队在哪个环节投入更多验证动作，比直接数阶段个数更有意义。

流水线图与发布看板在发布过程中如何配合使用？

两者回答的问题不同。流水线图回答“这次变更走到哪、结果如何”，发布看板回答“哪些发布批次待批、批到哪一步”。实际发布时，通常先在发布看板上确认批次和审批进度，再跳转到对应流水线图查看执行结果，确认各环境验证是否通过。

配合使用的关键是明确各自的责任人：流水线图由开发和测试人员关注执行细节，发布看板由发布负责人和审批人关注放行决策。信息可以互相引用，但判断依据要分开记录。

流水线图中出现失败或回滚状态后，团队一般怎么处理？

先定位再决定。失败状态需要结合阶段和环境确认问题位置，例如“预发环境—部署—失败”指向制品在预发环境部署受阻，此时查看该环节日志和触发来源，判断是配置差异、制品问题还是环境资源问题。

回滚状态则需要核对回滚范围和当前实际运行版本，确认生产环境已恢复到哪个版本，再决定修复后重新走流水线还是调整发布计划。处理完成后，建议在图中保留这次失败或回滚的记录，便于后续复盘时追溯。

把流水线数据接入项目管理工作项后，读图方式会有什么变化？

接入后，流水线状态可以回到需求或迭代上下文中查看，读图时多了一个关联维度：不仅知道某次构建失败，还能看到它对应哪个需求、哪个迭代，从而判断影响范围。

以 ONES 为例，ONES DevOps 解决方案支持集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步编排的流水线数据，更新执行状态和日志；并将流水线与项目关联，在项目、迭代、需求中可视化代码提交、流水线构建、产品发布等过程。这一衔接的前提是已完成相应集成配置，具体同步时效与状态字段以实际集成为准。