交付流水线的阶段定义要能直接用于交接和判断，先按交付物形态和环境层级切出阶段，再为每个阶段写清交付物、责任人和可判定的完成标准，最后按变更风险调整严格度。本文面向多环境、多团队协作的交付场景，给出一套可落地的阶段定义方法，包括阶段划分对照表、字段清单、风险分级表和完成检查清单。
要点总览（TL;DR）
- 阶段边界落在交付物形态发生转换的位置：源码、构建产物、测试报告、部署包、运行实例，每一类形态对应一个可确认的交接点。
- 每个阶段用输入、动作、交付物、完成标准、责任人、环境六个字段定义，完成标准要写成换人检查也能给出通过或不通过结论的条件。
- 多团队协作时由统一的流程负责人维护阶段清单和分级标准，交接以交付物和完成标准为凭据，记录随工作项留存。
- 高风险变更在测试与预发阶段增加专项验证、回退演练和负责人签字，低风险变更可在有自动化回归覆盖的前提下简化检查项。
- 落地后用检查清单核对阶段边界、完成标准可判定性、责任人与交接记录、风险分级执行情况和定义维护机制。
先定阶段划分：按交付物形态和环境层级切分
阶段边界应落在交付物形态发生转换的位置。源码变成构建产物、构建产物变成可部署包、部署包变成运行实例，每一次形态转换都意味着责任主体、验证手段和环境条件发生变化，这些变化点就是天然的阶段边界。按这个依据切分，阶段数量由团队的交付物链条决定，不按组织架构或工具菜单来定。
环境层级与阶段大致对应：提交阶段在开发环境完成，构建阶段产出可复用的构建产物，测试阶段在测试环境验证功能与回归，预发阶段在接近生产的预发环境验证部署与配置，生产阶段形成运行实例并进入监控。环境是完成标准的验证场所，阶段是交付物的推进过程，两者一一对应后，交接时“在哪个环境确认什么”就有明确答案。
多团队协作时，阶段边界需要统一口径。常见做法是由一个跨团队的流程负责人维护阶段清单，各团队在同一份清单上补充本团队的交付物细节，阶段名称、环境名称和交付物形态保持全局一致。否则A团队的“测试完成”指单元测试通过，B团队指集成测试通过，交接时就会出现理解偏差。
阶段数量需要取舍。切得过细，每个阶段都要等待确认，交付周期被拉长；切得过粗，中间缺少控制点，问题会推迟到生产才暴露。一个实用的判断是：如果两个相邻阶段使用同一环境、同一批验证手段、交付物形态没有变化，可以合并；如果某个阶段存在独立的验证要求或独立的责任人，就值得单独保留。
| 阶段名称 | 输入 | 环境 | 主要交付物形态 |
|---|---|---|---|
| 提交 | 需求或任务、代码变更 | 开发环境 | 源码、提交记录、分支 |
| 构建 | 源码、构建配置 | 构建环境 | 构建产物（带版本号）、构建日志 |
| 测试 | 构建产物、测试用例 | 测试环境 | 测试报告、缺陷记录 |
| 预发 | 测试通过的构建产物、部署配置 | 预发环境 | 部署包、预发验证记录 |
| 生产 | 预发验证通过的部署包 | 生产环境 | 运行实例、发布记录、监控数据 |
每个阶段写清交付物、责任人与完成标准
阶段定义的最小字段包括：输入、动作、交付物、完成标准、责任人、环境。六个字段缺一不可，其中完成标准最容易写空。判断一条完成标准是否合格，可以问：换一个人来检查，能否给出明确的通过或不通过结论。写成“代码质量良好”无法判定，写成“静态扫描无阻断级问题，且构建产物版本号可追溯至提交记录”就可以判定。
交付物要写清存放位置和追溯要求。构建产物应带版本号并关联到具体提交；测试报告应关联到被测构建产物版本；预发验证记录应关联到待发布的部署包。追溯链完整，后续排查问题时才能从生产实例反查到源码变更。
多团队协作时，每个阶段指定一名确认责任人，交接以交付物和完成标准为凭据。上游团队提交交付物并附完成标准自检结果，下游团队按标准核验后确认接收。确认动作记录在交接记录中，随工作项或文档留存，避免口头交接。
| 字段 | 填写要求 | 示例（测试阶段） |
|---|---|---|
| 输入 | 本阶段开始前必须具备的交付物 | 带版本号的构建产物、测试用例集 |
| 动作 | 本阶段执行的主要活动 | 执行功能测试与回归测试，记录缺陷 |
| 交付物 | 本阶段产出的可核验对象及存放位置 | 测试报告（关联构建版本）、缺陷清单 |
| 完成标准 | 可判定的通过条件 | 用例通过率达到约定阈值，无未关闭的阻断级缺陷 |
| 责任人 | 对本阶段完成确认负责的角色 | 测试负责人 |
| 环境 | 验证发生的环境 | 测试环境 |
阶段定义和交接记录需要有承载位置。ONES 支持通过业务需求、研发任务等工作项拉取代码分支，并将代码提交与工作项关联，使每个阶段的交付物能挂接到对应的工作项上；集成 Jenkins、GitLab CI 等流水线工具后，ONES 会同步流水线数据、执行状态和日志，并在项目、迭代、需求中可视化代码提交、流水线构建、产品发布等过程。这样，阶段完成标准中的“构建产物可追溯”“测试报告已关联”就有了统一的查看入口，多团队交接时也能凭工作项上的记录确认。
按风险等级调整完成标准的严格度
同一阶段对不同变更设置不同严格度，可以避免低风险变更被过度检查拖慢，也避免高风险变更检查不足。风险分级依据三项：变更范围（涉及模块数量与改动量）、影响环境（是否触及生产配置或数据）、是否涉及核心链路（登录、支付、订单等关键路径）。三项中命中核心链路或生产配置的，按高风险处理。
高风险变更在测试阶段增加专项验证项，在预发阶段增加人工确认和回退验证：预发环境完成一次完整回退演练，确认回退后系统状态可恢复；由业务负责人或技术负责人签字确认后再进入生产。低风险变更可以简化检查项，前提是变更仅涉及配置调整或非核心模块，且有自动化回归覆盖，简化后仍需保留构建产物追溯和测试报告关联这两项基础要求。
分级标准由流程负责人维护，与阶段定义放在同一份文档中。复核时机包括：核心链路发生调整、生产事故复盘发现检查缺口、团队交付物形态变化。复核后更新分级表并通知各团队，避免标准长期不更新导致与实际风险脱节。
| 风险等级 | 判定条件 | 测试阶段增加项 | 预发阶段增加项 |
|---|---|---|---|
| 高风险 | 涉及核心链路、生产配置或数据变更 | 专项场景测试、性能验证 | 人工确认、回退演练、负责人签字 |
| 中风险 | 涉及多个模块但不在核心链路 | 扩大回归范围 | 部署验证记录、回退方案确认 |
| 低风险 | 仅配置调整或非核心模块，有自动化回归覆盖 | 基础回归通过即可 | 部署验证记录 |
多环境多团队下的交接与完成确认示例
以下为演示情景：某团队将订单查询接口的筛选条件调整从提交推进到生产，涉及后端团队与测试团队协作。
提交阶段，后端开发在工作项下创建分支并提交代码，交付物为源码和提交记录，完成标准是代码提交已关联工作项、分支命名符合规范。确认责任人为开发本人，环境为开发环境。
构建阶段，流水线触发构建，交付物为带版本号的构建产物和构建日志，完成标准是构建成功、产物版本号可追溯至提交记录。确认责任人为构建执行人，环境为构建环境。若构建失败，退回提交阶段修复，交接记录中注明失败原因。
测试阶段，测试团队接收构建产物，执行功能测试与回归测试，交付物为测试报告和缺陷清单，完成标准是用例通过率达到约定阈值、无未关闭的阻断级缺陷。确认责任人为测试负责人。未达标时退回构建或提交阶段，缺陷修复后重新走构建与测试。
预发阶段，运维或发布负责人将测试通过的部署包部署到预发环境，交付物为部署包和预发验证记录，完成标准是部署成功、核心场景验证通过、回退方案已确认。本次变更涉及订单查询核心链路，按高风险处理，增加回退演练和负责人签字。
生产阶段，发布负责人执行发布，交付物为运行实例、发布记录和监控数据，完成标准是发布后核心指标正常、无异常告警。各阶段交接记录随工作项留存，形成从需求到生产的完整追溯链。ONES 的效能管理可从交付效率、交付质量、资源效率、完成情况四个维度对系统内产生的数据进行分析，团队可据此观察各阶段交接的耗时与退回情况，作为优化阶段定义的依据。
落地后的完成检查
阶段定义写完后，用以下清单逐项核对，确认这套定义可以直接用于日常交付。
- 阶段边界与环境是否一一对应：每个阶段有明确的验证环境，不存在两个阶段共用同一环境且交付物形态相同的情况。
- 每个阶段的完成标准是否可判定：随机抽取三条完成标准，请未参与编写的成员判断能否给出通过或不通过的结论。
- 责任人与交接确认是否明确：每个阶段有指定的确认责任人，交接记录有固定留存位置，且能查到最近一次交接的实际记录。
- 风险分级是否落地：抽查最近若干次变更，确认高风险变更确实执行了增加的确认项，低风险变更的简化有前提记录。
- 定义是否随流程变化维护：确认阶段定义文档有明确的维护人和复核触发条件，最近一次更新有记录。
检查中发现的问题应回到对应阶段修订定义，修订后重新核对相关条目。阶段定义是交付流程的控制基准，保持它与实际交付方式一致，交接和确认才有依据。
常见问题
阶段数量应该切几个，有没有通用标准？
没有固定数量，判断依据是交付物形态是否发生转换、验证环境是否变化、是否存在独立的责任人。两个相邻阶段如果共用同一环境、同一批验证手段、交付物形态没有变化，可以合并；某个阶段如果有独立的验证要求或独立确认人，就值得单独保留。阶段切得过细会增加等待确认的环节，切得过粗会让问题推迟到生产才暴露，按团队实际的交付物链条取舍即可。
完成标准写到什么程度才算可判定？
一个实用的检验方法是：换一位未参与编写的成员来看这条标准，能否直接给出通过或不通过的结论。写成“代码质量良好”“测试充分”无法判定；写成“静态扫描无阻断级问题，且构建产物版本号可追溯至提交记录”“用例通过率达到约定阈值，无未关闭的阻断级缺陷”就可以判定。完成标准尽量指向具体的交付物、记录或数据，避免使用形容词。
低风险变更简化检查项，会不会削弱控制？
简化的前提要写清楚并留痕：变更仅涉及配置调整或非核心模块，且有自动化回归覆盖。满足前提时，可以省去专项场景测试、回退演练等增加项，但构建产物追溯和测试报告关联这两项基础要求仍需保留。抽查时如果发现某次简化缺少前提记录，应视为分级未落地，回到分级表补充判定条件或调整该次变更的风险等级。
多团队各自维护阶段定义，如何避免口径不一致？
常见做法是由一个跨团队的流程负责人维护统一的阶段清单，阶段名称、环境名称、交付物形态全局一致，各团队在同一份清单上补充本团队的交付物细节。交接时上游提交交付物并附完成标准自检结果，下游按标准核验后确认接收，确认动作记录在交接记录中随工作项或文档留存。口径不一致往往出现在“测试完成”这类表述上，统一到具体交付物和判定条件后，理解偏差会明显减少。
阶段定义上线后，什么时候需要复核更新？
建议在几类时机触发复核：核心链路发生调整、生产事故复盘发现检查缺口、团队交付物形态发生变化、集成新的流水线工具。复核内容包括阶段边界是否仍与环境对应、完成标准是否仍可判定、风险分级条件是否覆盖新出现的变更类型。复核后更新文档并通知各团队，避免标准长期不更新与实际交付方式脱节。
