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

交付流水线图把一次代码变更从提交到上线的执行路径画成可视结构，用阶段、环境、状态三类信息回答“这次变更走到哪、卡在哪、下一步做什么”。它属于交付流执行层面的表达，发布审批与质量门禁的决策记录另有承载。下面按定义、边界、阶段、环境、状态、相邻概念和读图示例逐项说明。

要点总览（TL;DR）

• 交付流水线图把一次代码变更从提交到上线的执行路径画成可视结构，用阶段顺序、环境归属、执行状态三类信息回答“变更走到哪、卡在哪、下一步做什么”。
• 典型阶段包括代码检出、构建、单元测试、制品打包、部署和验证，阶段之间按依赖关系组织为串行、并行或分支，粒度取决于交付节奏与制品形态。
• 环境通常按开发、测试、预发、生产分层，阶段推进与环境晋级对应；同一环境存在多套实例时应分别标注，避免把环境名当成唯一目标。
• 状态信息需区分运行级、阶段级和步骤级，并挂载时间、触发来源与日志产物入口，读图时先看整体状态，再定位失败环节。
• 流水线图记录执行事实，发布审批、质量门禁、部署拓扑和任务看板分别由其他载体承担；绿灯只代表技术验证通过，不等于可发布。

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

交付流水线图是对持续交付流水线运行过程的可视化呈现。它把代码从提交到部署所经过的构建、测试、打包、部署、验证等环节按执行顺序排列，标注每个环节运行在哪个环境，并实时显示各环节的执行状态。读一张流水线图，相当于看一条变更在交付通道中的当前位置和通行情况。

它主要表达三类信息。第一类是阶段顺序，即各处理环节的先后与并行关系，反映变更需要依次通过哪些处理步骤。第二类是环境归属，即每个阶段落在开发、测试、预发还是生产环境，反映变更已经推进到哪一层运行环境。第三类是执行状态，即当前运行处于排队、运行中、成功、失败还是等待人工等状态，反映这次交付是否顺利、阻塞在哪个环节。

由此，流水线图回答的是执行层面的具体问题：这次提交触发的运行走到哪一步了，卡在哪个阶段，失败原因指向哪段日志，重跑或修复后应从哪个阶段继续。它描述的是变更的流转路径与执行事实，组织架构、人员分工、审批决策不在其表达范围内。

表达对象	对应图元	回答的问题
阶段顺序	按先后排列的阶段节点、并行分支、连线箭头	这次变更要经过哪些处理步骤，哪些可以同时进行
环境归属	阶段节点上的环境标签或按环境分组的泳道	当前推进到哪一层环境，下一站部署到哪里
执行状态	节点颜色与状态图标、耗时、触发来源、日志入口	运行是否通过，失败在哪一环，从何处查看原因

边界：流水线图包括什么、不包括什么

流水线图的表达范围集中在交付流的执行路径与执行状态。它记录“系统实际执行了什么、执行结果如何”，属于事实性视图。发布审批、质量门禁规则、工具链集成配置虽然与流水线紧密相关，但分别属于决策、规则和配置层面，由其他载体承担。

常见的越界理解是把审批节点画进流水线阶段。审批是人对发布是否放行的判断，其结果可以影响流水线是否继续，但审批本身不是构建、测试、部署这类自动化执行动作。把审批混入阶段序列，会让读图者误以为审批通过等同于技术验证通过，也会让失败定位在“执行失败”和“审批未通过”之间变得模糊。更合理的做法是让流水线图呈现执行事实，审批结论作为发布记录单独留存，两者通过发布单或工作项关联。

内容	是否属于流水线图	判断理由
构建、测试、部署等阶段的执行路径	属于	这是流水线图的主体结构，描述变更如何被处理
各阶段的环境归属与执行状态	属于	环境与状态是读图判断进度和阻塞的直接依据
发布审批的签核意见与放行结论	不属于	审批是决策记录，归发布审批流程管理
质量门禁的阈值规则与拦截策略	不属于	门禁规则定义“什么条件算通过”，属于规则配置
代码托管、CI 平台、制品库的对接参数	不属于	集成配置是工具链层面的设置，不构成执行路径
审批节点作为阶段节点绘制	不属于	审批是人工判断，与自动化执行阶段的语义不同

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

典型流水线从代码检出开始，依次经过构建、单元测试、制品打包、部署和验证。每个阶段都有明确的输入、动作和产出物，产出物既是本阶段的结果，也是下一阶段的输入。阶段之间的衔接以制品和环境为核心：同一份制品在不同环境中部署，验证结果回写到对应阶段的运行记录。

阶段之间可以是串行、并行或分支关系。存在强依赖的环节适合串行，例如先构建再打包；互不依赖的检查适合并行，例如单元测试与静态检查同时运行，以缩短反馈时间；分支关系用于按条件选择路径，例如仅当目标环境为生产时才执行额外的冒烟验证。并行与分支的组织方式应以依赖关系和反馈速度为判断依据，不宜为了图形整齐而强行拉平。

阶段划分的粒度受交付节奏、制品形态和团队协作方式影响。交付频率高的团队往往把反馈快的检查前置并拆细，以便尽早暴露问题；制品形态复杂、部署步骤多的系统可能把部署拆成准备、切换、验证多个阶段。粒度没有统一标准，关键是每个阶段都能对应可观察的产出和可定位的失败点。

阶段名	输入	主要动作	产出物	常见失败点
代码检出	代码仓库分支或提交记录	拉取指定版本的源码	工作区源码快照	分支不存在、权限不足、网络中断
构建	源码与依赖清单	编译、依赖安装、生成可执行包	构建产物	依赖下载失败、编译错误、环境版本不一致
单元测试	构建产物与测试用例	执行自动化测试并收集结果	测试报告与覆盖率数据	用例失败、超时、测试环境资源不足
制品打包	构建产物与版本号	生成带版本标识的制品并归档	可部署制品	版本号冲突、归档空间不足
部署	制品与环境配置	将制品发布到目标环境并启动	运行中的服务实例	配置缺失、端口占用、健康检查不通过
验证	运行实例与验证脚本	冒烟测试、接口检查、指标观察	验证结果与运行记录	接口异常、响应超时、关键指标越界

环境维度：流水线图如何标注环境

环境在流水线图中承担“变更推进到哪一层运行条件”的表达职责。常见分层为开发、测试、预发和生产：开发环境用于联调与快速验证，测试环境用于系统级测试，预发环境尽量贴近生产配置用于上线前确认，生产环境承载真实用户流量。阶段推进与环境晋级通常对应，部署到测试环境意味着变更进入系统测试环节，部署到预发意味着进入上线前确认环节。

标注环境时，仅写环境名往往不够。同一环境可能存在多套实例，例如多个测试集群按业务线或版本并行使用，此时应在图上区分实例标识，避免把“测试环境”当成唯一目标。按需创建的环境应在图上标注其来源和生命周期，便于读图者判断该次运行使用的是固定环境还是临时环境。

环境与配置、凭据的关联也应在图上有所体现。部署阶段使用的配置集和访问凭据随环境不同而变化，图上可通过环境标签关联对应的配置说明，使读图者明白同一阶段在不同环境下的行为差异来自配置而非代码。凭据本身不应在图中明文展示，只标注其归属即可。

环境	用途	典型进入条件	对应阶段
开发	联调与快速验证	构建与单元测试通过	部署、基础验证
测试	系统级功能与集成测试	制品打包完成并归档	部署、集成验证
预发	上线前配置与流程确认	测试环境验证通过	部署、冒烟验证
生产	承载真实用户流量	预发验证通过并完成发布决策	部署、上线后观察

状态信息：图上需要呈现哪些执行状态

状态信息让流水线图从静态结构变成可判断的运行视图。单次运行状态通常包括排队、运行中、成功、失败、已取消和等待人工。排队表示已触发但尚未分配执行资源；运行中表示正在执行；成功表示该次运行全部通过；失败表示某个环节未通过；已取消表示运行被主动终止；等待人工表示流程停在需要人确认的节点。阶段级状态描述某个阶段整体的结果，步骤级状态描述阶段内部单个命令或检查的结果。两者结合，才能既看到整体进度，又定位到具体失败命令。

时间信息是读图的重要辅助。开始时间说明运行何时被触发，耗时帮助判断是否存在异常缓慢的环节，触发来源说明这次运行由提交、定时任务还是人工发起。失败定位依赖日志与产物链接的挂载位置：失败阶段应能直接跳转到对应日志，成功阶段应能访问其产出制品，这样读图者无需离开图形就能完成初步排查。

字段	取值	读图时的判断用途
运行状态	排队、运行中、成功、失败、已取消、等待人工	判断这次交付整体是否完成、是否被人为中断
阶段状态	未开始、进行中、通过、失败、跳过	判断变更推进到哪个阶段，哪一段出现阻塞
步骤状态	通过、失败、超时	在失败阶段内定位到具体命令或检查项
开始时间与耗时	时间戳、时长	识别异常缓慢环节，评估反馈周期
触发来源	代码提交、定时触发、人工发起	判断这次运行对应哪次变更或哪项例行任务
日志与产物入口	链接或跳转位置	失败时查看原因，成功时获取可部署制品

当流水线数据与项目管理工作项关联时，读图者可以从需求或任务直接看到对应的构建与部署记录。ONES DevOps 解决方案支持集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步流水线数据并更新执行状态和日志，并在项目、迭代、需求中可视化代码提交、流水线构建和产品发布过程。这种关联让“这次变更走到哪”不仅能在流水线图上看到，也能在需求上下文中追溯，便于在状态异常时快速找到对应的工作项和负责人。

相邻概念区别：流水线图与部署图、发布单、看板

流水线图容易与几种相邻的图形和文档混淆，区别的关键在于各自回答的问题不同。部署图回答“系统运行在什么拓扑上”，发布单回答“这次发布是否被批准”，任务看板回答“人的工作项流转到哪一步”，流水线配置文件回答“流水线如何被定义”。流水线图则回答“这次变更的执行路径和当前状态”。

与部署图相比，流水线图描述的是时间维度上的执行路径，节点是处理步骤；部署图描述的是空间维度上的运行拓扑，节点是服务器、集群、网络等运行单元。与发布单相比，流水线图记录执行事实，发布单记录决策结论，前者说明“跑了什么、结果如何”，后者说明“谁批准、依据什么”。与任务看板相比，流水线图的流转由自动化执行驱动，看板的流转由人工更新工作项状态驱动。与流水线配置文件相比，配置文件是定义源，流水线图是其运行后的可视化呈现，二者可能因运行参数不同而呈现差异。

对比对象	核心差异	判别口诀
部署图	执行路径 vs 运行拓扑	看流程走向找流水线图，看机器分布找部署图
发布单/发布审批	执行事实 vs 决策记录	看跑了什么找流水线图，看谁批准找发布单
任务看板	自动化流转 vs 人工工作项流转	看系统执行找流水线图，看人的进度找看板
流水线配置文件	可视化呈现 vs 定义源	看实际运行找流水线图，看规则定义找配置文件

具体例子与常见误解

假设一次提交触发了从构建到预发的完整运行。读图时先看整体运行状态：若显示运行中，再看当前进行到哪个阶段；若显示失败，直接定位红色阶段节点。假设失败发生在测试环境的部署阶段，步骤级状态指向健康检查超时，日志入口可查看启动日志，产物入口可确认部署的是哪个版本制品。修复后重新触发，图上会出现新的运行记录，与上一次运行并列，便于对比两次差异。若运行顺利推进到预发并完成冒烟验证，图上显示预发阶段通过，此时变更具备进入发布决策的条件，是否上线由发布审批另行判断。

常见误解之一是把绿灯等同于可发布。流水线全部通过只说明技术验证环节通过，配置差异、数据兼容、业务影响等仍需发布决策确认。误解之二是把阶段数量当成质量高低的标志，阶段多不代表验证充分，阶段少也不代表风险高，关键看每个阶段是否覆盖了真实风险点。误解之三是忽略环境差异，把测试环境的通过结果直接套用到生产判断，而两者在配置、数据量和流量特征上可能明显不同。这些误解会导致上线后问题暴露、责任归属不清，或对流水线图产生不切实际的信任。

误解	后果	纠正
绿灯即等于可发布	跳过发布决策，带风险上线	把流水线通过视为技术验证完成，发布与否仍走审批
阶段越多质量越高	堆叠无效检查，延长反馈周期	按风险覆盖判断阶段价值，合并重复检查
忽略环境差异	测试通过但生产失败	读图时确认阶段所在环境，区分各环境验证结论

正确读图可分三步。第一步看整体运行状态和触发来源，确认这次运行对应哪次变更、是否已经结束。第二步沿阶段顺序找到当前或失败节点，结合环境标签判断变更推进到哪一层运行条件。第三步查看该节点的步骤状态、耗时和日志入口，定位具体原因，再决定重跑、修复还是进入发布决策。按这三步读图，流水线图就能稳定地承担“变更走到哪、卡在哪、下一步做什么”的回答任务。

常见问题

流水线图上的阶段划分到什么粒度比较合适？

粒度取决于交付节奏、制品形态和团队协作方式，没有统一标准。判断依据是每个阶段能否对应可观察的产出和可定位的失败点：交付频率高的团队可以把反馈快的检查前置并拆细，尽早暴露问题；部署步骤复杂的系统可以把部署拆成准备、切换、验证多个阶段。如果某个阶段失败后无法从日志或产物判断原因，通常说明粒度还需要调整。

同一环境有多套实例时，流水线图应该怎么标注？

只写环境名容易让读图者误以为“测试环境”是唯一目标。建议在环境标签之外补充实例标识，例如按业务线、版本或集群区分的名称；按需创建的环境还应标注来源和生命周期，说明这次运行使用的是固定环境还是临时环境。这样读图者才能判断验证结论对应的是哪一套运行条件。

流水线全部通过后，是否可以直接上线？

流水线通过说明构建、测试、部署、验证等技术环节已完成，配置差异、数据兼容、业务影响等仍需发布决策确认。发布审批与质量门禁属于决策层面，与流水线图的执行事实分开记录。把两者混在一起，容易让“技术验证通过”被误读为“已获准发布”。

流水线图与流水线配置文件是什么关系？

配置文件是流水线的定义源，规定阶段如何编排、在什么条件下执行；流水线图是运行后的可视化呈现，反映某次实际执行的路径和结果。两者可能因运行参数、分支选择或环境差异而呈现不同内容。排查问题时，先看图确认实际执行了什么，再回到配置文件核对定义是否符合预期。

流水线数据与需求、任务关联后有什么实际用处？

关联后，读图者可以从需求或任务直接看到对应的构建与部署记录，不必在多个系统之间来回查找。ONES DevOps 解决方案支持集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步流水线数据并更新执行状态和日志，并在项目、迭代、需求中可视化代码提交、流水线构建和产品发布过程。当某个阶段失败时，可以顺着关联快速找到对应的工作项和负责人。