多环境多团队协作下流水线阶段划分方法

多环境、多团队协作时，流水线阶段划分的关键是先确定交付物形态，再按环境层级确定每段流水线的终点，最后按风险控制要求设置卡点。这样切出的每个阶段都有明确输入、唯一负责人、产出物和完成标志，责任能随产物交接，避免所有团队挤在一条无法归属责任的超长流水线上。本文给出划分依据、操作步骤、阶段定义表模板、角色交接规则与完整示例，适用于开发、测试、预发、生产分层推进的交付场景。

要点总览（TL;DR）

• 阶段划分按三条依据依次取舍：先按交付物形态确定阶段边界，再按环境层级确定每段流水线的终点，最后按风险控制要求设置卡点，不按组织架构切分。
• 划分分五步：盘点交付物与环境、按交付物形态归并环节、为每个阶段指定唯一负责团队与交接产物、在阶段之间设置卡点、定义完成标准与失败回退。
• 完成标准写成可观察结果，如构建成功且制品入库、测试通过率达标、部署后健康检查通过；产出物需写明存放位置与版本标识，便于下游取用和追溯。
• 多团队交接遵循责任随产物转移：上游达成完成标志并交付产物后下游才接续；共用测试与预发环境时，排队顺序与插队规则写入阶段定义表。
• 用八项检查清单核对划分结果，重点确认唯一负责人、无职责空档、标准可判定、回退路径明确、卡点与风险等级匹配。

先定划分依据：交付物、环境层级与风险控制

阶段划分先回答三个问题：交付物在哪个环节改变了形态，环境推进到哪一层，哪些位置必须停下来确认。三条依据有先后顺序，先看交付物，再看环境，最后看风险。按组织架构切分容易产生“每个团队一段、但没人对整段结果负责”的流水线，通常不作为首选依据。

交付物形态决定阶段边界。源码提交、构建产物、部署包、配置与数据变更，这四类对象的验证方式和责任人都不同，形态发生转换的位置天然适合作为阶段分界。例如源码变成可复用的构建产物，意味着编译、单元测试和制品入库已经完成，后续阶段应基于制品推进，而不是重新拉源码。

环境层级决定每段流水线的终点。开发环境验证功能可用性，测试环境验证集成与回归，预发环境验证接近生产的配置与数据，生产环境完成发布与观察。每层环境的职责不同，阶段终点应落在“该环境要验证的内容已经验证完”的位置，而不是简单按环境数量平均切分。

风险控制要求决定卡点位置。涉及数据库变更、对外接口变更、生产配置调整的阶段之间，通常需要人工确认或质量门禁；常规的提交校验和单元测试可以完全自动。卡点数量应与风险等级匹配，高风险环节设卡，低风险环节保持自动流转。

划分依据	回答的问题	典型判断信号	取舍顺序
交付物形态	阶段边界切在哪里	源码→构建产物→部署包→配置与数据变更	第一
环境层级	每段流水线到哪里结束	开发、测试、预发、生产各自的验证职责	第二
风险控制	哪些阶段之间必须停	数据变更、对外接口、生产配置、合规要求	第三

读者可用这张表做一次自检：列出本团队的交付物形态、经过的环境层级和已知风险点，若某一列填不出具体内容，说明该依据尚未梳理清楚，应先补齐再动手切分。

核心答案与操作步骤：把流水线切成可交接的阶段

划分动作分五步完成，每步都有明确输入、动作、输出和完成标志。五步走完后，应得到一份阶段草案和一张阶段定义表初稿，可以直接交给各团队确认。

步骤一：盘点交付物与环境

输入是当前从代码提交到生产发布的全部环节记录，包括人工操作。动作是逐条列出每个环节的输入物、输出物、执行角色和所处环境。输出是一张环节清单。完成标志是清单覆盖了从提交到生产的完整路径，没有“大家都知道但没写下来”的隐性环节。

步骤二：按交付物形态归并环节

输入是步骤一的环节清单。动作是把产出同类交付物、验证方式相近的相邻环节合并，形成阶段草案。例如编译、单元测试、制品打包都产出构建产物，可归为一个阶段。输出是阶段草案，通常为四到七个阶段。完成标志是每个阶段只对应一种主要交付物形态，阶段内部环节的验证目标一致。

步骤三：指定唯一负责团队与交接产物

输入是阶段草案和现有团队分工。动作是为每个阶段指定一个负责团队，并写明该阶段交给下游的产物及其存放位置、版本标识。输出是带责任归属的阶段清单。完成标志是每个阶段有且只有一个负责人，交接产物可以被下游直接取用，不需要口头询问。

步骤四：在阶段之间设置卡点

输入是阶段清单和风险点记录。动作是逐个阶段边界判断：自动校验能覆盖的保持自动流转，涉及高风险变更的设置人工确认或质量门禁。输出是标注了卡点类型和触发条件的阶段清单。完成标志是每个卡点都写明了校验内容、判定人和不通过时的处理方式。

步骤五：定义完成标准与失败回退

输入是前四步的全部产出。动作是为每个阶段写出可观察的完成标准，并定义失败时的回退路径，例如制品回滚到上一版本、环境恢复到基线快照。输出是阶段定义表初稿。完成标志是任意一个阶段都能被第三方依据表格判断“是否完成”，失败时也知道由谁执行回退。

各阶段交付物与完成标准怎么定义

阶段定义表是划分结果的主要载体，字段固定、逐项填写，避免不同团队各写一套。建议包含七个字段：阶段名称、输入、动作、产出物、负责人、完成标准、失败处理。

字段	填写要求	示例
阶段名称	用交付物或验证目标命名，不用团队名	构建与制品
输入	上游交接的具体产物及版本	通过提交校验的代码分支
动作	本阶段执行的主要操作	编译、单元测试、打包、制品入库
产出物	交给下游的产物及存放位置	带版本号的制品，存入制品库
负责人	唯一负责团队或角色	业务团队A的构建负责人
完成标准	可观察、可判定的结果	构建成功且制品入库，单元测试通过率达标
失败处理	失败时的回退动作与通知对象	阻断流转，通知提交人修复后重跑

完成标准要写成可观察结果，避免“已完成”“质量合格”这类无法判定的表述。可用的写法包括：构建成功且制品已入库并带版本标识；测试通过率达到约定阈值且无阻断级缺陷；部署后健康检查通过、关键接口响应正常；生产发布后观察期内错误率未超过基线。每条标准都应能被自动校验或由指定角色在几分钟内人工确认。

多团队交接时，产出物的存放位置和版本标识必须写进表格。下游团队依据版本标识取用产物，出现问题时能追溯到具体版本和对应阶段，责任边界清晰。完成标准的严格程度应与风险等级对应：涉及数据变更和生产配置的阶段，标准应更具体，并配合人工确认；常规构建和测试阶段以自动校验为主。

角色与职责：多团队如何分工与交接

阶段划分要落地，需要明确谁定骨架、谁保质量、谁管环境、争议由谁裁决。角色不清时，阶段表会变成一份没人维护的文档。

角色	主要职责	决策权范围
平台团队	维护流水线骨架与公共阶段模板，保证各团队阶段结构一致	公共阶段的定义与变更
业务团队	负责本团队阶段的产出物质量与完成标准达成	本团队阶段内部的执行方式
测试与环境管理角色	维护环境层级、准入条件与共用环境的排队规则	环境准入与使用顺序
交付协调角色	处理跨团队交接争议，组织升级	交接争议的裁决与升级发起

交接规则的核心是责任随产物转移：上游阶段的完成标志达成、产物按约定位置和版本交付后，下游团队才接续执行，此后的质量问题由下游阶段负责人牵头定位，需要上游配合时按升级路径处理。上游未达成完成标准时，下游不应提前介入“帮忙修”，否则责任边界会迅速模糊。

跨团队争议常见于两类情形：一是完成标准判定不一致，二是共用环境的使用顺序冲突。前者由平台团队依据阶段定义表裁定，后者由环境管理角色按排队规则处理；涉及交付承诺的争议升级到交付协调角色。升级路径应写进阶段定义表附注，而不是留在口头约定里。

阶段交接涉及工作项状态流转和交接记录留存时，可以把阶段定义表、交接产物说明作为项目文档管理，把每个阶段的推进状态挂到对应工作项上。ONES 支持在项目、迭代、需求中可视化代码提交、流水线构建、产品发布等 CI/CD 过程，并可将流水线与项目关联，便于多团队在同一视图下确认阶段进展与阻塞位置；集成 Jenkins、GitLab CI 等第三方流水线工具后，编排的流水线数据、执行状态和日志会同步更新。这类承载方式适合需要把阶段交接记录与需求交付进度对应起来的团队。

示例：一条覆盖开发到生产的阶段划分

以下为演示情景：两个业务团队共用一套测试环境和一套预发环境，各自有独立的开发环境，生产发布按周窗口执行。示例用于说明划分方法，不代表唯一方案。

阶段	输入	产出物	负责人	完成标准
提交校验	代码提交	通过校验的代码分支	提交人所在业务团队	静态检查与单元测试通过，无阻断问题
构建与制品	通过校验的分支	带版本号的制品，入制品库	业务团队构建负责人	构建成功、制品入库、版本标识可追溯
集成测试	指定版本制品	集成测试报告与缺陷清单	测试角色牵头，业务团队配合	回归用例通过率达标，无阻断级缺陷
预发验证	通过集成测试的制品	预发验证记录与发布候选版本	环境管理角色与业务团队共同确认	接近生产的配置下健康检查通过，关键流程验证完成
生产发布	发布候选版本	已发布版本与观察记录	发布负责人	发布完成，观察期内错误率未超基线

卡点设置：提交校验到构建与制品之间保持自动流转；集成测试进入预发验证前设置人工确认，由测试角色确认缺陷清零；预发验证到生产发布之间设置发布确认，核对发布窗口与回滚方案。卡点位置对应风险：预发与生产之间一旦出错影响面最大，因此保留人工确认。

两个团队共用测试和预发环境时，排队规则写进阶段定义表：按制品进入队列的时间排序，紧急修复凭发布负责人确认可插队，插队记录留档。集成测试阶段发现的问题退回对应业务团队的构建阶段修复，重新走后续阶段，不占用其他团队的排队位置。这样处理的好处是环境争用有明确规则，冲突不依赖临时协商。

完成检查：阶段划分是否可运行

阶段划分完成后，用以下清单逐项核对。任一项不满足，回到对应步骤修正，再进入执行。

• 每个阶段有唯一负责人，且负责人清楚自己的完成标准。
• 每个阶段有明确产出物，存放位置和版本标识已写明，下游可直接取用。
• 阶段之间没有职责空档，也没有两个阶段重复执行同一验证。
• 每条完成标准都能被自动校验或由指定角色快速人工判定，没有“质量合格”这类模糊表述。
• 每个阶段的失败处理与回退路径已定义，回退执行人和通知对象明确。
• 多团队共用环境时，排队顺序、优先级和插队规则已写入阶段定义表。
• 高风险环节之间设置了卡点，卡点的校验内容、判定人和不通过处理方式齐全。
• 阶段划分依据可回溯：每个阶段边界能对应到交付物形态变化或环境层级切换。

核对通过后，阶段定义表应作为团队共同维护的文档持续更新；环境层级、交付物形态或风险要求发生变化时，同步修订对应阶段，而不是在执行中临时绕开。需要进一步设计卡点内的审批规则时，可另行参考发布审批与质量门禁主题；流水线与工具平台的技术对接属于研发工具链集成主题，本文不展开。

常见问题

两个团队共用测试环境，阶段划分时最容易出问题的地方是什么？

最常见的问题是环境争用没有规则，导致阶段完成标准形同虚设。集成测试阶段的完成标准依赖环境可用，如果两个团队都按自己的节奏提交，先到先占，排队顺序就变成临时协商，交接责任也随之模糊。

处理方式是在阶段定义表中写明排队规则：按制品进入队列的时间排序，紧急修复凭发布负责人确认可插队并留档，退回修复的制品重新排队时不占用其他团队位置。规则写清楚后，环境冲突按表执行，不需要每次开会协调。

阶段划分完成后，环境层级或交付物形态发生变化，应该怎么调整？

阶段定义表应作为团队共同维护的文档持续更新，环境层级、交付物形态或风险要求变化时同步修订对应阶段，避免在执行中临时绕开。

调整时仍按原取舍顺序进行：先看交付物形态是否新增或改变，再确认环境层级的终点是否移动，最后复核卡点位置是否仍与风险匹配。修订后通知所有相关团队，并更新交接产物的存放位置与版本标识说明，防止下游仍按旧规则取用产物。

完成标准由谁判定，自动校验和人工确认怎么分工？

分工原则是按风险等级决定。常规的提交校验、构建、单元测试等环节以自动校验为主，标准写成系统可直接判定的结果，例如构建成功且制品入库、测试通过率达标。涉及数据变更、对外接口变更、生产配置调整的环节，在阶段之间设置人工确认，由阶段定义表中指定的判定人执行。

无论自动还是人工，每条标准都应能在几分钟内得出结论。判定人不明确或标准需要长时间讨论，说明该阶段的完成标准还没写清楚，应回到定义阶段修正。

上游阶段没达到完成标准，下游团队能不能先介入处理？

通常不建议。交接规则的核心是责任随产物转移：上游达成完成标志并按约定位置和版本交付产物后，下游才接续执行。上游未达标时下游提前介入，责任边界会迅速模糊，后续定位问题难以判断属于哪个阶段。

正确做法是按失败处理字段执行：上游阻断流转，通知指定对象修复后重跑，达到标准再交接。若确需下游协助，通过升级路径由交付协调角色确认，并记录协助范围，避免责任混同。

阶段划分结果如何与需求交付进度对应起来？

可以把阶段定义表和交接产物说明作为项目文档管理，把每个阶段的推进状态挂到对应工作项上，让阶段进展与需求交付进度在同一处查看。ONES 支持在项目、迭代、需求中可视化代码提交、流水线构建、产品发布等 CI/CD 过程，并可将流水线与项目关联，便于多团队确认阶段进展与阻塞位置；集成 Jenkins、GitLab CI 等第三方流水线工具后，编排的流水线数据、执行状态和日志会同步更新。

这种方式适合需要把阶段交接记录与需求交付进度对应起来的团队。具体配置方式与版本要求，建议结合实际环境另行确认。