交付流水线各阶段交付物与完成标准如何定义

交付流水线的阶段定义要解决两个问题：阶段在哪里切分，以及每个阶段凭什么算完成。可行的做法是按环境层级把交付流切成构建、集成验证、预发布、生产发布四个基本阶段，再为每个阶段锁定交付物形态、可判定的完成标准和失败回退位置。多团队协作时，把交付物命名、版本规则和完成标准写成统一模板，各团队只填内容不改结构，阶段边界就不会随团队习惯漂移。

要点总览（TL;DR）

• 阶段划分以环境层级为主线：构建、集成验证、预发布、生产发布四个阶段，交付物形态变化点即阶段边界，多团队保持阶段数量与顺序统一。
• 交付物写成可交接对象需三要素：形态（产物、报告或记录）、唯一标识（版本号或构建号）、存放位置（制品库、文档库或发布单）。
• 完成标准改写成可判定条件，区分自动判定与人工确认，明确放行角色、交接对象和未达标处理方式。
• 多团队协作时统一命名规则与模板结构，团队差异只体现在阶段内检查项，交接以交付物签收代替口头确认。
• 先用自检清单核对标准可执行性，再选一个团队试运行一到两个版本，发现歧义回到模板层面统一修订。

先定阶段边界：按环境层级切分交付流

阶段划分的主线是环境层级，而不是团队组织架构或功能模块。代码从开发人员的工作区走向用户，每跨一层环境，交付物的形态就发生一次变化：源码变成构建产物，构建产物变成可部署包，可部署包变成线上版本。形态变化点就是阶段边界，这条规则让不同团队对“阶段”的理解保持一致。

按这条主线，一条典型的交付流包含四个阶段：构建环境对应构建阶段，集成测试环境对应集成验证阶段，预发布环境对应预发布阶段，生产环境对应生产发布阶段。每个阶段有明确的进入条件和退出后的交付物形态，如下表所示。

阶段名称	对应环境	进入条件	退出后交付物形态
构建	构建环境	代码合入主干或指定分支，变更说明已提交	带版本号的构建产物与构建日志
集成验证	集成测试环境	构建产物已入库，集成环境可用	测试报告与缺陷清单
预发布	预发布环境	集成验证通过，发布包已生成	发布包与预发布验证记录
生产发布	生产环境	预发布验证通过，发布单已审批	发布单与发布记录

多团队协作时，阶段数量保持统一，团队差异体现在阶段内的检查项。例如支付团队在集成验证阶段增加对账用例，内容团队增加多语言校验，但两者都走同样的四个阶段，交接对象和判定口径一致。风险控制要求高的场景可以增设灰度或回滚验证阶段，此时需要为它定义独立交付物，例如灰度观察记录和回滚演练结果，并明确它插在预发布与生产发布之间还是生产发布之后，避免成为没有交付物的“口头环节”。

每个阶段定义交付物：形态、命名与存放位置

“代码”“测试结果”“发布完成”这类说法无法交接，因为接收方无法确认拿到的是哪一版、放在哪里、是否完整。交付物要写成可交接、可追溯的具体对象，每个交付物至少包含三个要素：形态（产物、报告或记录）、唯一标识（版本号或构建号）、存放位置（制品库、文档库或发布单）。

构建阶段的交付物是带版本号的构建产物和构建日志，版本号建议与代码提交号建立对应关系，便于从线上版本反查代码。集成验证阶段的交付物是测试报告与缺陷清单，报告中注明覆盖范围，包括执行了哪些用例集、覆盖哪些需求、未覆盖部分及原因。预发布与生产阶段的交付物是发布包、发布单与发布记录，发布单承载本次发布的范围、关联需求、回退方案，发布记录承载实际执行时间、执行人和结果。

多团队共用同一套命名与存放规则，是避免“同名不同物”的关键。命名规则应包含项目标识、阶段标识、版本号三段，例如“项目代号-阶段-版本号”；存放位置按交付物类型固定，产物进制品库，报告进文档库，发布单进发布管理入口。下表可作为交付物清单模板直接填写。

阶段	交付物名称	形态	命名规则	存放位置	责任人
构建	构建产物、构建日志	产物、日志	项目-构建-版本号	制品库	开发团队
集成验证	测试报告、缺陷清单	报告、清单	项目-集成-版本号	文档库	测试或质量角色
预发布	发布包、预发布验证记录	产物、记录	项目-预发布-版本号	制品库、文档库	发布负责人
生产发布	发布单、发布记录	单据、记录	项目-生产-版本号	发布管理入口	发布负责人

交付物存放和阶段状态流转需要有承载位置。ONES 支持在项目、迭代、需求中可视化代码提交、流水线构建、产品发布等 CI/CD 过程，集成 Jenkins、GitLab CI 等第三方流水线工具后会自动同步流水线数据、更新执行状态和日志，团队可以把阶段交付物与对应工作项关联，交接时以工作项状态和关联文档作为依据，减少口头确认。

完成标准怎么写：可判定条件与放行角色

“测试通过”“验证没问题”不是完成标准，因为第三方无法据此判断通过与否。可执行的完成标准由三部分组成：阈值或通过项、必须存在的证据、有权判定的人或规则。写法上把每条标准改成一个可以回答“是或否”的句子，例如“阻断级缺陷数量为 0，且测试报告已归档至文档库对应版本目录”。

完成标准分两类。自动判定由流水线检查结果给出，例如编译是否成功、单元测试通过率是否达到约定阈值、静态扫描是否无新增严重问题；人工确认由评审或签字完成，例如发布负责人确认回退方案已演练、质量角色确认测试覆盖范围达标。高风险阶段应增加人工确认项，低风险阶段尽量交给自动判定，减少等待。

每个阶段还要明确放行角色和交接对象：谁有权宣布本阶段完成，完成后交给谁。未达标时的处理方式同样要写进标准，常见做法是阻断流转、有条件放行并记录例外原因与补偿措施。有条件放行的记录位置和审批人必须固定，否则例外会变成常态。下表是完成标准定义表的填写结构。

阶段	判定条件	判定方式	放行角色	未达标处理
构建	编译成功，单元测试达到约定阈值	自动判定	流水线规则自动放行	阻断，通知提交人修复
集成验证	阻断级缺陷清零，覆盖范围达标	自动统计加人工确认	测试或质量角色	阻断，缺陷回流转开发
预发布	关键路径验证通过，回退方案就绪	人工确认	发布负责人	有条件放行需记录例外
生产发布	发布完成，监控指标正常	自动监控加人工确认	发布负责人	触发回退并记录

角色与交付物分工：多团队协作下的责任落点

标准写了却无人执行，通常是因为责任没有落到具体角色和具体交付物上。多团队协作时，每个阶段至少涉及五类角色，各自承担明确的输入和输出。

• 开发团队：提交可构建的代码与变更说明，变更说明需关联需求或任务编号，作为构建阶段的输入。
• 测试或质量角色：基于构建产物执行验证，出具测试报告与缺陷结论，报告需注明覆盖范围和未覆盖原因。
• 发布负责人：确认发布包内容与发布单信息一致，执行放行，对预发布和生产阶段的交接负责。
• 运维或环境负责人：保障各环境可用，记录环境状态与变更，环境异常时及时通知上游。
• 平台或流水线维护角色：维护阶段配置、判定规则和模板版本，规则变更时通知所有使用团队。

交接以交付物签收代替口头确认：上游把交付物放入约定位置并更新状态，下游检查交付物是否齐全、版本是否匹配，确认后在系统中签收。下表是角色-阶段-交付物责任矩阵的填写示例，R 表示负责执行，A 表示负责放行确认。

角色	构建	集成验证	预发布	生产发布
开发团队	R：代码与变更说明	配合缺陷修复	配合问题定位	配合线上问题处理
测试或质量角色	—	R：测试报告与缺陷清单；A：验证结论	参与关键路径验证	参与发布后验证
发布负责人	—	—	R：发布包与验证记录；A：放行	R：发布单与发布记录；A：放行
运维或环境负责人	保障构建环境	保障集成环境	保障预发布环境	保障生产环境与监控
平台维护角色	维护阶段配置与规则	维护判定规则	维护模板版本	维护发布记录字段

测试报告与缺陷清单的产出可以借助 ONES 测试管理：测试用例与需求、任务关联，测试计划与迭代关联，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转，测试报告支持自动生成和自定义模板，便于按统一格式交付给下游阶段。

示例：一条四阶段交付流的交付物与完成标准

以下示例展示四个阶段如何串起来，可直接作为模板改写。示例中的阈值和角色名称需按团队实际情况替换，标注“自动”的条件由流水线判定，标注“人工”的条件需指定角色确认。

阶段	交付物	完成标准	判定方式
构建	构建产物、构建日志	编译成功；单元测试通过率达到约定阈值；构建日志已归档	自动
集成验证	测试报告、缺陷清单	阻断级缺陷清零；覆盖范围达到约定比例；未覆盖部分有书面说明	自动统计加人工确认
预发布	发布包、预发布验证记录	关键路径验证通过；回退方案已就绪；发布负责人确认	人工
生产发布	发布单、发布记录	发布完成；监控指标在约定观察期内正常；回退方案可执行	自动监控加人工确认

以一次版本发布为例：开发团队提交代码并附变更说明，流水线自动完成构建，产物入库后集成验证阶段启动；测试角色执行用例，发现两个阻断级缺陷，创建缺陷任务流转回开发，修复后重新构建并再次验证，缺陷清零后出具测试报告；发布负责人据此生成发布包，在预发布环境验证关键路径并确认回退方案，签署放行；生产发布完成后，监控在观察期内无异常，发布记录归档。整个过程中，每个阶段的交接都有对应交付物和状态记录，失败时回到上一阶段重新执行，回退位置清晰。

完成检查：标准是否可执行的自检清单

定义完成后，用以下清单逐项核对，任何一项无法回答“是”，说明该处标准还停留在描述层面，需要补充具体内容。

• 每个阶段都有唯一交付物，且能定位到具体版本号或构建号。
• 每条完成标准都能被第三方判定通过或不通过，不含“基本”“大致”等模糊表述。
• 每个阶段都有明确的放行角色，且该角色知道自己在什么条件下签字。
• 多团队使用同一套模板，差异只体现在阶段内检查项，阶段数量和顺序一致。
• 失败与回退路径有记录位置，例外放行有审批人和补偿措施记录。
• 标准变更时有版本记录，并通知到所有使用团队。

自检通过后，建议先在一个团队或一条产品线试运行一到两个版本，观察交接是否顺畅、判定是否产生争议，再推广到多团队。试运行期间发现的标准歧义，应回到模板层面统一修订，而不是由各团队自行解释，这样阶段边界和完成标准才能长期保持一致。

常见问题

阶段数量一定要四个吗，团队规模小能不能合并？

四个阶段是按环境层级给出的基本划分，不是固定数量要求。判断能否合并的依据是交付物形态是否发生变化：如果团队没有独立的预发布环境，预发布验证与生产发布共用同一套产物和验证记录，可以把两者合并为一个发布阶段，但合并后仍需保留发布包、发布单和发布记录三类交付物，以及对应的放行角色。

反过来，风险控制要求高的场景可以增设灰度或回滚验证阶段，前提是为它定义独立交付物，例如灰度观察记录和回滚演练结果，并明确它插在哪个阶段之后。阶段数量可以调整，交付物形态变化点作为边界这条规则不变。

完成标准里的阈值由谁定，定多少合适？

阈值属于团队约定，没有统一数值。可行的做法是由质量角色提出初值，发布负责人和开发团队共同确认，写进完成标准定义表并随模板版本记录。初值可以参考历史版本的实际情况，例如近几个版本的单元测试通过率、阻断级缺陷数量，取一个团队能稳定达到又足以拦截风险的水平。

阈值调整要有依据和记录，避免每次发布前临时放宽。高风险阶段可以同时设置自动判定阈值和人工确认项，低风险阶段尽量交给自动判定，减少等待时间。

多团队共用一套模板，但各团队节奏不同，怎么避免互相等待？

关键在于把阶段内的检查项与阶段边界分开。阶段数量和顺序统一，各团队在阶段内增加的检查项由本团队负责执行和判定，不改变交接对象和判定口径。节奏差异通过进入条件管理：上游交付物入库并更新状态后，下游按自己的排期签收，不必实时同步等待。

如果某团队的检查项会影响下游判定，例如新增了一类必须通过的验证，应把它写进模板的公共检查项并通知所有使用团队，而不是只在本地执行。这样既保留团队差异，又不会让下游拿到无法判断的交付物。

有条件放行怎么控制，才不至于变成常态？

有条件放行需要三个固定要素：固定的记录位置、固定的审批人、固定的补偿措施。记录位置建议放在发布单或发布记录中，写明未达标项、放行理由、补偿措施和完成时限；审批人应是该阶段的放行角色，不能由提交人自行决定；补偿措施要可验证，例如补充测试的执行时间与结论。

控制例外变成常态的办法是定期统计有条件放行的次数和原因，如果某一类原因反复出现，说明对应的完成标准或阶段检查项需要修订，应回到模板层面调整，而不是继续逐次审批例外。

交付物存放和阶段状态流转，用文档库加工作项能承载吗？

可以承载大部分场景。产物进制品库，测试报告与验证记录进文档库，发布单与发布记录放在发布管理入口，工作项承载阶段状态和交接签收。ONES 支持在项目、迭代、需求中可视化代码提交、流水线构建、产品发布等 CI/CD 过程，集成 Jenkins、GitLab CI 等第三方流水线工具后会自动同步流水线数据、更新执行状态和日志，团队可以把阶段交付物与对应工作项关联。

测试报告与缺陷清单的产出可借助 ONES 测试管理：测试用例与需求、任务关联，测试计划与迭代关联，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转，测试报告支持自动生成和自定义模板。具体配置方式需结合团队现有工具链确认。