多环境、多团队协作时，流水线阶段划分要解决的是交付物在团队与环境之间如何有序流转。本文给出一套可执行的方法：先按交付物形态、环境层级和风险控制确定阶段边界，再逐步定义各阶段的输入、校验、交付物与完成标准，最后用检查清单确认划分可用。文中附阶段定义表模板与三团队四环境示例，并说明阶段状态与交接记录如何在研发管理工具中承载。
要点总览（TL;DR）
- 先按交付物形态、环境层级、风险控制三个依据确定阶段边界：交付物形态变化节点是候选边界，每个环境至少有一个负责阶段，高风险阶段加严准入与必跑校验。
- 按五步落地：梳理交付物清单、明确环境用途、切分阶段边界、定义准入与完成标准、统一命名与交接字段，每步都有可核对的完成标志。
- 阶段定义表固定七个字段：阶段名称、目标、输入与前置条件、阶段内动作与校验、交付物与存放位置、完成标准、负责人与交接对象，完成标准要能用客观结果判定。
- 多团队协作的关键是交接由客观事件触发、交接字段齐全（版本号、构建号、环境标识、变更单号、验证结论），共享环境用占用登记协调冲突。
- 落地后用检查清单核对边界一致性、完成标志可判定性、命名与字段统一性、风险覆盖和回退路径，条件变化时按同样依据重新评估。
阶段划分的三个依据：交付物、环境层级与风险控制
流水线阶段的数量和边界，由三个依据共同决定：交付物形态、环境层级、风险控制要求。三者各管一件事——交付物决定每个阶段产出什么，环境层级决定阶段骨架，风险控制决定阶段内的校验强度。划分时先分别判断，再合并成阶段清单。
交付物形态决定阶段产出物
流水线本质上是交付物的加工与流转过程。常见的交付物形态有源码提交、构建产物、可部署包、环境配置和发布记录，每经过一次形态转换，通常就是一个阶段边界。例如从源码提交到构建产物，对应提交构建阶段；从构建产物到可部署包，对应打包与制品归档；从可部署包到某个环境上的运行实例，对应部署验证阶段；从部署完成到对外可用的发布记录，对应发布阶段。判断方法很直接：列出交付物清单，标出形态发生变化的节点，这些节点就是候选阶段边界。
环境层级对应阶段骨架
开发、测试、预发、生产各环境的用途不同：开发环境供个人或小组自测，测试环境供集成验证，预发环境模拟生产做最终验证，生产环境承载真实用户流量。阶段数量不必与环境数量一一对应，但每个环境至少要有一个明确负责它的阶段，避免出现“没人管的环境”。如果测试环境同时承担集成验证和回归验证，可以拆成两个阶段，也可以合并为一个阶段加两组校验，取决于验证内容的差异程度。
风险控制要求决定校验点与准入条件
风险越高的阶段，准入条件和必跑校验越严。生产发布阶段通常要求预发验证通过、变更记录完整、回滚方案就绪；提交构建阶段则可以保持轻量，只跑编译和单元测试。风险控制还决定哪些校验是“必跑”、哪些是“可选”：涉及数据变更、权限变更、对外接口变更的交付，应设为必跑项。把所有阶段都设成同等强度，会让流水线变长、反馈变慢；强度不足，则高风险环境失去保护。
三个依据冲突时的取舍顺序
实际划分中三个依据常出现冲突，例如交付物形态提示应拆分阶段，但环境资源有限、团队希望缩短流水线。取舍顺序建议为：第一，保证交付物可追溯，每个阶段的产出物能被下一阶段准确识别和取用；第二，保证高风险环境受控，预发与生产相关的校验不能因合并阶段而省略；第三，在满足前两条的前提下，合并低风险阶段以控制流水线长度。按这个顺序，冲突时先牺牲阶段数量，再牺牲低风险校验的独立性，最后才考虑放宽高风险校验。
从提交到生产：一条可落地的阶段划分步骤
下面五步按顺序执行，每步都给出输入、动作、输出和完成标志。建议由平台团队牵头、各业务团队参与，一次划分覆盖一条主要交付流，再逐步扩展到其他交付流。
第一步：梳理交付物清单与形态
- 输入：现有构建脚本、制品仓库记录、部署脚本、发布记录。
- 动作：列出从代码提交到上线全过程中产生的所有交付物，标注每个交付物的形态（源码、构建产物、可部署包、配置、发布记录）和产生环节。
- 输出：交付物清单，含形态、产生环节、存放位置。
- 完成标志：清单覆盖全部交付物，每个交付物都能对应到具体产生环节，无“来源不明”的交付物。
第二步：确定环境层级与各环境用途
- 输入：现有环境清单、各环境的使用方与访问权限。
- 动作：为每个环境写明用途、使用团队、数据来源（是否脱敏）、是否共享。
- 输出：环境用途说明表。
- 完成标志：每个环境都有明确用途和负责方，共享环境标注了占用规则。
第三步：按交付物流转切分阶段边界
- 输入：交付物清单、环境用途说明表。
- 动作：以交付物形态变化节点和环境切换节点为候选边界，合并或拆分后形成阶段清单，为每个阶段起统一名称。
- 输出：阶段清单，含阶段名称、起止边界、涉及环境。
- 完成标志：每个交付物都有归属阶段，每个环境都有负责阶段，阶段之间无重叠、无空档。
第四步：定义准入条件、必跑校验与完成标准
- 输入：阶段清单、历史缺陷与事故记录、质量要求。
- 动作：为每个阶段写明进入前必须满足的条件、阶段内必须执行的校验项、以及判定阶段完成的客观标准。
- 输出：阶段定义表（字段见下一节）。
- 完成标志：每个阶段的完成标准都能用客观结果判定，例如“集成测试用例通过率100%且无阻断级缺陷”，而非“测试基本通过”。
第五步：约定多团队共用的命名与交接字段
- 输入：阶段定义表、各团队现有工作习惯。
- 动作：统一阶段命名规则，约定阶段交接时必须携带的字段，如版本号、构建号、环境标识、变更单号、验证结论。
- 输出：命名规范与交接字段说明。
- 完成标志：各团队按同一套名称引用阶段，交接记录字段齐全，接收方无需额外询问即可开始本阶段工作。
各阶段交付物与完成标准定义表
阶段定义表是把划分结果固定下来的载体。建议每个阶段一行，字段固定，填写时避免模糊表述。下表给出模板结构与填写要点。
| 字段 | 填写内容 | 填写要点 |
|---|---|---|
| 阶段名称 | 如“提交构建”“集成验证”“预发验证”“生产发布” | 全组织统一命名，不用团队内部简称 |
| 阶段目标 | 一句话说明本阶段要达成的结果 | 目标可验证，如“产出可部署的版本包” |
| 输入与前置条件 | 进入本阶段所需的交付物、上游阶段结论、审批或登记 | 写明来源阶段和具体字段 |
| 阶段内动作与校验项 | 编译、单测、集成测试、安全扫描、配置核对等 | 区分必跑项与可选跑项 |
| 交付物与存放位置 | 构建产物、测试报告、部署包、发布记录及存放路径 | 位置唯一，下一阶段可直接取用 |
| 完成标准与判定方式 | 如“用例通过率100%”“预发验证连续运行24小时无阻断缺陷” | 用客观结果判定，注明由谁判定 |
| 负责人与交接对象 | 阶段负责人、接收方团队或角色 | 负责人为具体角色，不写“相关团队” |
填写时有两个常见问题值得注意。一是完成标准写成主观描述，导致阶段何时结束依赖个人判断；二是交付物存放位置分散在多个系统，接收方需要多方查找。前者应改为可核验的指标，后者应约定统一存放位置并在交接字段中给出准确引用。
多团队协作下的角色分工与交接机制
多团队共用一条流水线时，职责不清和交接断档是主要风险来源。角色分工要落到阶段上，交接机制要落到字段和触发条件上。
三类角色的职责边界
| 角色 | 主要职责 | 在阶段划分中的具体动作 |
|---|---|---|
| 平台团队 | 维护流水线骨架与共享环境 | 定义阶段命名规范、维护流水线配置、管理共享环境占用与排队 |
| 业务团队 | 对交付物质量负责 | 按阶段定义提交交付物、执行本团队负责的校验、填写交接字段 |
| 测试与环境管理方 | 验证与环境保护 | 执行集成与预发验证、判定完成标准、管理环境数据与访问权限 |
阶段交接的触发方式与交接物
交接应由客观事件触发，例如构建成功、集成测试通过、预发验证结论出具、发布审批完成。触发后，上游阶段负责人提交交接物：版本号、构建号、环境标识、变更单号、验证结论和已知风险。接收方核对字段齐全后开始本阶段工作；字段缺失时退回上游补充，不进入下一阶段。交接记录应可查询，便于事后追溯某个版本经过了哪些阶段、由谁确认。
失败回退与责任归属
每个阶段都应写明失败后的回退路径：回到哪个阶段、由谁决策、需要通知哪些团队。责任归属按“谁产出、谁负责修复”的原则确定：构建失败由提交方修复，集成验证失败由引入缺陷的团队修复，预发环境问题由环境管理方与相关团队共同定位。回退决策人应在阶段定义表中明确，避免失败后无人拍板。
共享环境冲突的协调规则
多个团队同时向同一测试或预发环境发布，会互相干扰验证结果。常见做法是建立环境占用登记：发布前登记占用时段与版本，其他团队在该时段内不向同一环境发布；紧急发布需经环境管理方协调并通知受影响团队。占用登记与排队规则应写入环境用途说明表，与阶段定义一并维护。
阶段状态、交付物记录和交接字段需要有承载位置。ONES DevOps 解决方案可集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步已编排的流水线数据、执行状态和日志，并将流水线与项目关联；在项目、迭代、需求中可查看代码提交、流水线构建、产品发布等过程。对于多团队协作场景，这意味着各阶段执行状态和交接记录可以在同一处查询，减少跨系统核对。具体能力以官方资料和实际集成为准。
示例：三个团队共用四层环境的阶段划分
以下为演示情景，用于说明方法如何落地，不代表真实项目数据。
情景设定
- 交付物形态：一个由三个业务团队共同开发的服务端应用，产出可部署包与发布记录。
- 环境层级：开发环境（各团队自用）、测试环境（共享）、预发环境（共享）、生产环境。
- 团队构成：平台团队负责流水线与共享环境，业务团队A、B、C分别负责不同模块，测试团队负责集成与预发验证。
划分出的阶段清单
- 提交构建：代码提交后触发编译与单元测试，产出构建产物。
- 集成验证：三个团队的构建产物合并部署到测试环境，执行集成测试与接口回归。
- 预发验证：可部署包部署到预发环境，执行端到端验证与配置核对。
- 生产发布：预发结论通过后发布到生产，生成发布记录。
填写示例
| 阶段 | 输入与前置条件 | 必跑校验 | 交付物 | 完成标准 | 负责人与交接对象 |
|---|---|---|---|---|---|
| 提交构建 | 代码合并请求已合入主干 | 编译、单元测试 | 构建产物，存入制品库 | 编译成功且单元测试全部通过 | 业务团队提交人，交接至集成验证负责人 |
| 集成验证 | 三个团队构建产物齐全，测试环境已登记占用 | 集成测试、接口回归、阻断级缺陷检查 | 测试报告，存入测试记录 | 集成用例通过率100%，无阻断级缺陷 | 测试团队，交接至预发验证负责人 |
| 预发验证 | 集成验证结论通过，变更单号已登记 | 端到端验证、配置核对、回滚方案确认 | 预发验证结论，存入发布记录 | 端到端用例全部通过，回滚方案经确认 | 测试团队与环境管理方，交接至发布负责人 |
| 生产发布 | 预发验证结论通过，发布窗口已确认 | 发布执行、发布后健康检查 | 发布记录，含版本号与发布时间 | 健康检查通过，无新增阻断级告警 | 平台团队发布负责人，交接至运维监控 |
协作中暴露的问题与调整
运行一段时间后，常见两类问题。第一类是测试环境冲突：三个团队在相近时间发布，集成验证结果互相干扰。调整方式是引入环境占用登记，要求发布前登记时段，平台团队统一协调。第二类是交接字段缺失：业务团队提交构建产物时未附变更单号，预发阶段无法核对变更范围。调整方式是把变更单号设为集成验证的准入条件，缺失即退回。这两类调整都回到阶段定义表中修改字段和准入条件，而不是靠临时沟通解决。
落地后的完成检查
阶段划分完成后，用以下清单逐项核对。每项都应有明确结论，存在未通过项时回到对应步骤修正。
- 阶段边界是否与交付物流转一致：每个交付物形态变化节点都有对应阶段，没有交付物跨越多个阶段却无人负责。
- 每阶段是否有明确输入、输出与完成标志：输入能追溯到上游阶段，输出有唯一存放位置，完成标志可用客观结果判定。
- 多团队阶段命名与交接字段是否统一：各团队引用阶段使用同一名称，交接记录字段齐全且格式一致。
- 风险控制点是否覆盖关键环境：预发与生产相关阶段设有必跑校验和准入条件，高风险变更被识别为必跑项。
- 异常与回退路径是否明确：每个阶段写明失败后回到哪个阶段、由谁决策、通知哪些团队。
- 共享环境是否有占用与排队规则：共享环境的占用登记方式、协调人、紧急发布处理方式已写入环境用途说明。
- 角色职责是否落到阶段：每个阶段都有具体负责人和交接对象，没有“相关团队共同负责”这类模糊表述。
- 阶段状态是否可查询：阶段执行状态、交付物记录和交接字段有统一承载位置，便于跨团队核对与事后追溯。
清单全部通过后，阶段划分即可投入运行。后续交付物形态、环境层级或风险要求发生变化时，按同样的三个依据重新评估边界，并同步更新阶段定义表与交接字段。
常见问题
阶段数量应该和环境数量一致吗？
不必一致。环境层级决定的是阶段骨架，每个环境至少要有一个明确负责它的阶段，避免出现无人管理或无人验证的环境；但一个环境可以对应多个阶段，多个低风险环境也可以合并到同一阶段中处理。判断标准是交付物形态是否发生变化、验证内容是否有实质差异。例如测试环境同时承担集成验证和回归验证时，可以拆成两个阶段，也可以合并为一个阶段加两组校验，取决于两类验证的用例、数据和判定标准差异有多大。
多个团队共用测试环境时，阶段交接经常卡住怎么办？
卡住通常有两个原因：环境被占用导致无法验证，或交接字段缺失导致接收方无法开始。前者可以建立环境占用登记，发布前登记时段与版本，紧急发布由环境管理方协调并通知受影响团队；后者把关键字段设为上游阶段的完成条件，例如变更单号缺失就不允许进入预发验证，退回补充而不是靠临时沟通。两类处理都应写回阶段定义表和环境用途说明，形成固定规则。
阶段划分完成后，交付物形态或环境层级变了怎么调整？
按原来的三个依据重新评估：先看交付物形态是否新增了转换节点，再看环境用途或数量是否变化，最后确认风险控制要求是否提高或降低。调整时优先保证交付物可追溯和高风险环境受控，再考虑合并低风险阶段控制流水线长度。修改后同步更新阶段定义表、交接字段和环境用途说明，并通知所有共用这条流水线的团队，避免各团队按旧名称和旧字段继续操作。
完成标准写成什么样才算可判定？
可判定的完成标准能由客观结果直接得出结论，并注明由谁判定。例如“集成用例通过率100%且无阻断级缺陷”“预发验证连续运行24小时无阻断缺陷”“回滚方案经发布负责人确认”，这些都能核对。相对地，“测试基本通过”“验证没问题”依赖个人判断，容易在交接时产生分歧。填写时可以用一个简单检验：换一个不参与本阶段的团队成员来看这条标准，能否独立判断阶段是否完成。
阶段状态和交接记录放在哪里比较合适？
关键是让各团队在同一处查询阶段执行状态、交付物记录和交接字段，减少跨系统核对。ONES DevOps 解决方案可集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步已编排的流水线数据、执行状态和日志，并将流水线与项目关联；在项目、迭代、需求中可查看代码提交、流水线构建、产品发布等过程。是否满足多团队权限隔离与阶段级完成标准配置等具体需求，需以官方资料和实际集成为准。
