定义交付流水线的阶段交付物与完成标准，可以按三个依据交叉确定：交付物形态、环境层级和风险控制要求。先看每个阶段产出的是源码变更、构建产物、部署单元还是可发布版本，再确定它在开发、测试、预发还是生产环境完成，最后按风险高低设定门槛。每个阶段固定写清四件事：输入是什么、由谁执行什么动作、产出什么交付物、用什么证据判定完成。完成标准要能被观察和自动判定，避免“测试通过”“质量达标”这类无法核对的表述。
要点总览（TL;DR）
- 阶段划分用三个依据交叉确定：交付物形态（源码变更、构建产物、部署单元、可发布版本）、环境层级（开发、测试、预发、生产）和风险控制要求，阶段数量按风险与交付频率增减。
- 每个阶段固定写清四要素：输入交付物（带版本或标识）、执行动作与责任人、输出交付物（制品、报告、记录或审批凭证及存放位置）、完成标准与证据位置。
- 完成标准要可观察、可自动判定、带阈值和证据位置，例如“回归用例通过率100%，报告位于本次构建记录下”，避免“测试通过”“质量达标”这类无法核对的表述。
- 完成标准门槛随风险分级调整：高风险阶段增加多角色确认、留痕和回滚预案演练记录，低风险阶段可简化确认环节和文档量，但代码评审、构建成功、部署后健康检查等基础校验保留。
- 多团队协作需统一阶段命名与边界，交付物产出方与确认方分离，跨团队交接采用移交与签收记录，归档位置统一，保证从版本号反查各阶段证据。
先定阶段骨架：按交付物形态与环境层级划分
阶段划分的起点是交付物形态，因为不同形态对应不同的校验手段和责任人。源码变更靠代码评审和静态检查把关，构建产物靠构建日志和制品校验，部署单元靠环境验证，可发布版本靠发布评审和回滚预案。把形态理清，阶段边界自然浮现。
环境层级决定每个阶段在哪里完成。开发环境承接源码变更与首次构建，测试环境验证部署单元的功能与集成表现，预发环境模拟生产条件做发布前确认，生产环境完成可发布版本的最终交付。多环境场景下，同一形态的交付物可能在不同环境重复验证，阶段定义要写明每个环境各自的完成证据，避免用开发环境的结论代替预发确认。
多团队协作时，阶段命名和边界需要统一。常见做法是由交付流程的牵头团队发布一份阶段清单，各团队在此清单上增减，不自行改名。统一命名后，跨团队的流水线数据才能横向对比，交接时也不会出现“你说的测试阶段和我说的测试阶段不是一回事”。
阶段数量按风险与交付频率取舍。交付频率高、变更影响面小的团队可以合并构建与部署验证；涉及对外发布、监管要求的交付则拆出独立的预发确认和发布审批阶段。固定模板只作为起点，实际阶段数应以每个阶段都能回答“谁在什么环境产出什么、凭什么判定完成”为准。
| 阶段名 | 所处环境 | 输入交付物 | 输出交付物 |
|---|---|---|---|
| 代码提交与评审 | 开发 | 源码变更 | 通过评审的代码分支 |
| 持续构建 | 开发/测试 | 代码分支 | 带版本号的构建产物 |
| 测试环境部署验证 | 测试 | 构建产物 | 部署单元与测试报告 |
| 预发确认 | 预发 | 部署单元 | 预发验证记录与发布候选版本 |
| 生产发布 | 生产 | 可发布版本 | 发布记录与回滚预案 |
每个阶段写清四要素：输入、动作、交付物、完成标准
单阶段定义建议固定四个字段，填写时逐项落到具体对象，不写概括性描述。四要素的价值在于让阶段可执行、可检查、可交接：输入说明前置条件是否满足，动作说明谁做什么，交付物说明产出什么，完成标准说明凭什么放行。
| 字段 | 填写要求 | 常见错误 |
|---|---|---|
| 输入交付物 | 写明上一阶段产出的具体对象及其版本或标识，如“构建号 20240612.3 的镜像” | 只写“代码”或“上一阶段结果” |
| 执行动作与责任人 | 写清由哪个角色执行什么操作，如“测试负责人触发部署并执行回归用例集” | 写“团队完成测试”，无人负责 |
| 输出交付物 | 说明形态：制品、报告、记录或审批凭证，并给出存放位置 | 只写“测试完成”，没有可查对象 |
| 完成标准与证据位置 | 给出可观察的判定条件、阈值和证据所在位置 | 写“质量达标”“测试通过” |
交付物形态要写具体。制品指构建产物、镜像、安装包；报告指测试报告、扫描报告、性能报告；记录指部署记录、变更记录；审批凭证指发布评审结论或签字记录。形态不同，归档方式和确认人不同，定义时一并写明。
完成标准的写法遵循三条：可观察，即有人能直接看到结果；可自动判定，即流水线节点能根据返回码、阈值或报告结论给出通过或失败；带证据位置，即写明报告链接、日志路径或记录编号。例如“回归用例通过率 100%，报告位于测试管理工具的本次构建记录下”，比“测试通过”更可核验。
完成标志要与责任人绑定。每个阶段的完成标准后面注明判定人和判定时点，判定人可以是自动流水线节点，也可以是明确的角色。自动判定覆盖不了的项，指定人工确认人，并在定义中写明确认后留下的记录形式。
按风险控制要求设定完成标准的严格程度
完成标准的门槛应随风险变化，统一高标准会拖慢低风险变更，统一低标准会放过高风险发布。风险分级可从三个维度判断：变更影响面，即改动涉及多少模块和用户；环境敏感度，即目标环境承载的业务重要性；是否涉及对外发布，即是否面向外部用户或合作方。
| 风险等级 | 判断条件示例 | 完成标准严格程度 |
|---|---|---|
| 高 | 涉及对外发布、核心交易链路或生产数据变更 | 多角色确认、完整留痕、回滚预案演练记录、发布评审凭证 |
| 中 | 影响内部多个团队使用的功能，目标环境为预发 | 自动化测试全通过、关键角色确认、部署记录归档 |
| 低 | 局部改动、开发或测试环境内的常规迭代 | 自动化校验通过、构建与部署日志留存 |
高风险阶段增加证据要求的方式包括：要求开发、测试、运维多角色分别确认并留下记录；要求变更留痕，包括变更说明、影响评估和审批凭证；要求回滚预案在预发环境演练并留存结果。这些证据要写进完成标准，而不是作为口头约定。
低风险阶段可以简化标准，但关键校验不能省略。代码评审、构建成功、部署后健康检查属于基础项，任何风险等级都应保留。简化的对象是额外的确认环节和文档量，不是校验本身。
标准需要定期复核。版本节奏变化、业务重要性调整或出现线上问题后，重新评估各阶段的风险等级和对应门槛，把复核安排进流程例行事項，避免标准定完就长期不动。
角色分工与各阶段交付物归属
多团队协作下，交付物归属不清是交接扯皮的常见来源。基本规则是产出方与确认方分离：谁产出交付物，谁就不能单独判定该交付物是否满足完成标准。开发产出代码变更，评审由其他开发者或代码负责人完成；测试产出测试报告，确认由测试负责人或质量角色完成；运维产出部署记录，发布确认由发布负责人完成。
| 阶段 | 产出方 | 确认方 | 归档责任 |
|---|---|---|---|
| 代码提交与评审 | 开发 | 代码评审人 | 开发，归档至代码仓库评审记录 |
| 持续构建 | 流水线执行节点 | 开发负责人 | 流水线维护人，归档构建日志与制品 |
| 测试环境部署验证 | 测试 | 测试负责人 | 测试，归档测试报告与部署记录 |
| 预发确认 | 测试与运维 | 发布负责人 | 运维，归档预发验证记录 |
| 生产发布 | 运维 | 发布负责人与业务确认人 | 运维，归档发布记录与回滚预案 |
跨团队交接采用明确的移交与签收方式。上游团队完成阶段后，把交付物及其证据位置登记到约定的交接记录中，下游团队签收时核对交付物版本与完成标准证据，签收动作留下记录。签收不是形式，它把“我以为你测过了”变成可追溯的责任转移。
归档位置统一约定，按阶段和版本组织，保证任一交付物都能从版本号反查到各阶段证据。归档要求写进阶段定义，与完成标准并列，避免交付完成后证据散落在个人手里。
在工具层面，ONES DevOps 解决方案可集成 Jenkins、GitLab CI 等第三方流水线工具，自动同步流水线数据并更新执行状态和日志，并把流水线与项目关联，便于在项目、迭代、需求中查看代码提交、流水线构建和产品发布过程。阶段定义中的交付物与证据位置可以对应到这些执行记录，跨团队交接时按同一份记录核对，减少口头确认。该能力适用于已集成第三方流水线工具的场景，具体同步范围以集成配置为准。
示例：一条覆盖开发到生产的阶段定义
以下示例设定为多环境、多团队协作的交付场景：两个研发团队共同维护一个业务系统，交付经过开发、测试、预发、生产四个环境，发布负责人由运维团队指定。示例为演示情景，用于说明填写方式。
阶段一：代码提交与评审（开发环境）。输入为需求对应的源码变更；动作为开发提交代码并发起评审，评审人检查变更说明与影响范围；交付物为通过评审的代码分支和评审记录；完成标准为至少一名评审人通过、静态检查无阻断项、评审记录关联到对应工作项，证据位于代码仓库评审页。
阶段二：持续构建（开发环境）。输入为通过评审的代码分支；动作为流水线自动触发构建并生成带版本号的制品；交付物为构建产物与构建日志；完成标准为构建成功、制品版本号唯一、构建日志完整留存，证据位于流水线构建记录。
阶段三：测试环境部署验证（测试环境）。输入为指定版本的构建产物；动作为测试负责人触发部署并执行回归用例集；交付物为部署单元、测试报告和缺陷清单；完成标准为回归用例通过率达到约定阈值、无未关闭的阻断级缺陷、报告关联本次构建号，证据位于测试管理工具与部署记录。
阶段四：预发确认（预发环境）。输入为测试通过的部署单元；动作为运维部署到预发环境，测试与业务方执行关键场景验证；交付物为预发验证记录和发布候选版本；完成标准为关键场景验证全部通过、发布负责人确认、验证记录归档，证据位于预发验证记录。此阶段因涉及对外发布，按高风险处理，增加业务确认人签字和回滚预案检查。
阶段五：生产发布（生产环境）。输入为发布候选版本；动作为运维按发布计划执行发布，发布负责人监控发布过程；交付物为发布记录、监控报告和回滚预案；完成标准为发布后健康检查通过、关键指标在约定范围内、发布记录与回滚预案归档，证据位于发布记录与监控系统。此阶段同样按高风险处理，要求发布负责人与业务确认人双签。
示例中的风险分级体现在预发和生产两个阶段：增加了多角色确认、留痕和回滚预案要求；开发与测试阶段则以自动化校验和单一确认人为主。迁移到其他团队时，可保留字段结构，按自身风险等级调整阈值和确认角色。
落地与完成检查
阶段定义写完后，需要映射到流水线的实际执行节点，否则定义停留在文档里。做法是把每个阶段的完成标准对应到流水线中的检查点：能自动判定的写成节点校验条件，需要人工确认的设置确认环节并记录结果。映射完成后，逐阶段核对执行记录能否支撑完成标准的判定。
落地步骤建议按以下顺序推进：
- 发布统一的阶段清单与四要素模板，各团队按模板填写本团队负责的阶段。
- 把每个阶段的完成标准拆成自动判定项和人工确认项，标注证据位置。
- 在流水线中配置对应的检查节点和确认环节，确保执行时自动留下记录。
- 组织一次跨团队的试运行，按定义走完一个完整交付，检查交接签收是否顺畅。
- 根据试运行结果修订定义，明确生效日期和适用范围。
完成检查清单用于确认定义是否可用：
- 每个阶段的完成标准是否都能指出具体证据位置，且不依赖个人记忆。
- 自动判定项是否已在流水线节点中配置，失败时能否阻断后续阶段。
- 人工确认项是否指定了确认人和记录形式。
- 多团队的阶段命名与边界是否一致，交接签收是否有统一记录。
- 高风险阶段的额外证据要求是否写入标准，低风险阶段的简化是否保留了基础校验。
- 交付物归档位置是否统一，能否从版本号反查各阶段证据。
定义上线后安排复核节奏，例如每季度或在重大版本发布后检查一次：完成标准是否仍可自动判定、风险等级是否与当前业务匹配、交接环节是否出现新的扯皮点。复核结果更新到阶段定义中，保持定义与流水线执行一致。ONES 支持多种数据报表，可追溯团队在 DevOps 工具链中的操作，为复核阶段提供执行数据参考；报表内容取决于已接入的工具链数据。
常见问题
阶段数量应该定几个，有没有通用模板可以直接套用？
没有适用于所有团队的固定阶段数。阶段数量由两个因素决定：交付频率和变更影响面。交付频率高、变更影响面小的团队可以合并构建与部署验证；涉及对外发布或监管要求的交付，则拆出独立的预发确认和发布审批阶段。
判断标准是每个阶段都能回答“谁在什么环境产出什么、凭什么判定完成”。如果两个阶段的责任人、环境和证据位置高度重合，可以考虑合并；如果同一阶段内出现多种交付物形态和不同确认人，说明需要拆分。固定模板只作为起点，试运行一轮后再按实际情况调整。
完成标准里的阈值怎么定，比如回归用例通过率要求100%还是95%？
阈值没有统一数值，取决于变更影响面和目标环境。高风险阶段（涉及对外发布、核心交易链路或生产数据变更）通常要求关键用例全部通过、无未关闭的阻断级缺陷；中低风险阶段可以约定通过率阈值，并把未通过用例的处置方式写进标准，例如必须登记缺陷并评估影响。
阈值要写进阶段定义并与证据位置绑定，例如“回归用例通过率达到约定阈值，报告关联本次构建号”。阈值调整后同步更新流水线节点的判定条件，避免文档与执行不一致。阈值本身建议在复核节奏中定期评估，结合线上问题记录判断是否偏松或偏严。
多团队协作时，上游团队的完成标准和我们不一致，交接时以谁的定义为准？
以交付流程牵头团队发布的统一阶段清单为准，各团队在此清单上增减，不自行改名。交接时，上游团队把交付物及其证据位置登记到约定的交接记录中，下游团队签收时核对交付物版本与完成标准证据，签收动作留下记录。
如果两个团队对同一阶段的完成标准理解不同，先回到四要素字段核对：输入交付物是否带版本标识、证据位置是否明确、确认人是否指定。多数分歧来自字段填写含糊，而不是标准本身冲突。确实需要差异化的，在统一清单中标注适用范围和生效条件，避免同一阶段名对应两套互不兼容的标准。
低风险阶段简化完成标准，哪些校验不能省？
可以简化的是额外的确认环节和文档量，基础校验不能省略。代码评审、构建成功、部署后健康检查属于任何风险等级都应保留的基础项。这些校验直接对应交付物是否可用，省略后问题会推迟到更高环境暴露，修复成本更高。
简化时建议保留自动判定项，减少人工确认项。例如低风险变更可以由流水线节点自动判定构建与健康检查结果，不再要求多角色签字，但构建日志和部署记录仍需留存，以便出现问题时回溯。
阶段定义写完后，怎么确认它真的能在流水线里执行？
把每个阶段的完成标准拆成自动判定项和人工确认项，逐项映射到流水线执行节点：能自动判定的写成节点校验条件，需要人工确认的设置确认环节并记录结果。映射完成后，组织一次跨团队试运行，按定义走完一个完整交付，检查交接签收是否顺畅、证据是否都能在约定位置找到。
试运行中暴露的问题通常集中在两类：自动判定项没有配置阻断，失败后仍能进入下一阶段；人工确认项没有指定确认人和记录形式，执行时靠口头沟通。这两类问题修订后再明确生效日期和适用范围。定义上线后安排复核节奏，例如每季度或在重大版本发布后检查一次，保持定义与流水线执行一致。
