如何依据交付物形态和环境层级划分流水线阶段

划分交付流水线阶段时，需要同时回答三个问题：每个阶段产出什么交付物、在哪些环境执行、哪些环节必须设门禁。本文按“交付物形态定内容、环境层级定顺序、风险控制定门禁”的顺序给出划分方法，并附阶段交付物与完成标准对照表、门禁与回退规则、多团队协作分工以及一份完整示例，帮助多环境、多团队协作的团队把阶段设计落到可执行、可验证的程度。

要点总览（TL;DR）

• 划分流水线阶段按固定顺序推进：先用交付物形态确定每个阶段产出什么、怎么验证，再按环境层级排定阶段顺序与验证强度，最后用风险控制要求叠加门禁与回退条件。
• 交付物形态应沿一次交付从提交到上线逐类盘点，源码构建产物、镜像与包、配置与脚本、数据变更、文档与制品清单各自对应独立的构建或验证动作，完成标准写成可判定的条件。
• 环境层级按开发、测试、预发、生产由低到高排列，验证强度按范围扩大、条件趋近真实递增，高层环境只补充低层无法覆盖的检查；多团队共用环境需约定隔离与排队规则。
• 门禁的通过条件与阻断条件成对定义，失败后从失败阶段重跑，生产异常按预案回滚；例外放行须记录原因、范围、批准人与复核要求。
• 每个阶段应有唯一确认人，交付物按“产出即登记、接收即确认”交接，并用完成检查清单核对阶段划分是否可执行、可验证。

先定划分依据：交付物形态、环境层级与风险控制三线对齐

流水线阶段划分的起点是明确三条依据各自回答什么问题，再按固定顺序做决定。交付物形态回答“这个阶段要产出什么、用什么方式验证”；环境层级回答“在哪个环境执行、验证强度递增到什么程度”；风险控制回答“哪些阶段必须卡住、失败后怎么退”。三者对齐后，每个阶段都应能写出输入、动作、交付物和完成标准四要素。

判断顺序建议如下：先盘点交付物形态，列出从源码到上线需要经过的产物类型；再按环境层级把产物放到对应环境上验证，形成阶段序列；最后对高风险环节加设门禁和回退条件。这个顺序的好处是阶段内容先成形，门禁是叠加在已有阶段上的控制点，避免先设门禁再倒推阶段导致职责不清。

三线冲突时的取舍原则可以归纳为三条：交付物形态决定阶段不能合并，例如数据变更与镜像发布验证方式不同，应分阶段；环境层级决定顺序不能颠倒，验证强度高的环境必须排在后面；风险控制决定门禁不能省略，当交付周期紧张时，优先压缩非门禁阶段的等待时间，保留强制检查。

划分依据	回答的问题	对阶段设计的决定	典型决策示例
交付物形态	产出什么、怎么验证	决定阶段内容与阶段交付物	镜像类产物设构建与镜像扫描阶段；数据变更设脚本评审与回滚验证阶段
环境层级	在哪执行、验证多深	决定阶段顺序与验证强度	开发环境跑单元与冒烟，预发环境跑全量回归与性能基线
风险控制	哪里必须卡住、失败怎么退	决定门禁、阻断条件与回退路径	涉及资金或权限的变更在生产前增设人工复核门禁

按交付物形态拆出阶段内容与阶段交付物

识别交付物形态的实用做法是沿着一次交付从提交到上线走一遍，记录中途产生的每一类产物。常见形态包括：源码构建产物（编译后的二进制或前端静态资源）、镜像与安装包、配置与部署脚本、数据变更脚本、文档与制品清单。每类形态的验证方式不同，应各自对应独立的构建或验证动作，而不是笼统合并为一个“构建阶段”。

每种形态对应的动作可以这样安排：源码构建产物在构建阶段完成编译、单元测试和静态检查，产出带版本号的构建包；镜像与包在打包阶段完成镜像构建、依赖锁定和漏洞扫描，产出可追溯的镜像标签；配置与脚本在配置校验阶段完成语法检查、环境差异比对和模板渲染验证；数据变更在数据阶段完成脚本评审、在测试库试跑和回滚脚本准备；文档与制品清单在发布准备阶段汇总变更说明、制品清单和依赖关系。

阶段交付物的命名与存放需要统一约定，否则多团队协作时难以追溯。建议命名包含交付物类型、版本号、构建时间和来源分支，存放位置按环境或按制品库分区，并规定只有通过上一阶段验证的交付物才能进入下一阶段。完成标准要写成可核验的条件，例如“单元测试通过率100%且无阻断级静态检查告警”“镜像扫描无高危漏洞”“数据变更脚本在测试库执行成功且回滚脚本验证通过”，避免写成“构建成功”这类无法判定的表述。

交付物形态	阶段动作	阶段交付物	完成标准示例
源码构建产物	编译、单元测试、静态检查	带版本号的构建包	单元测试全部通过，无阻断级告警
镜像与安装包	镜像构建、依赖锁定、漏洞扫描	可追溯的镜像标签	扫描无高危漏洞，依赖版本与清单一致
配置与部署脚本	语法检查、环境差异比对、模板渲染	各环境配置基线	目标环境渲染结果与基线差异已确认
数据变更脚本	脚本评审、测试库试跑、回滚准备	变更脚本与回滚脚本	试跑成功，回滚脚本验证通过
文档与制品清单	汇总变更说明、制品清单、依赖关系	发布说明与制品清单	清单覆盖本次全部制品，变更说明经确认

按环境层级排定阶段顺序与逐级验证强度

环境层级通常划分为开发、测试、预发、生产四层，各层职责不同：开发环境用于快速反馈，验证单元测试与冒烟用例；测试环境用于功能与集成验证，跑回归用例；预发环境尽量贴近生产配置，验证性能基线、配置正确性和发布流程；生产环境执行灰度发布与线上验证。阶段顺序按环境层级由低到高排列，验证强度逐级增加，低层环境已覆盖的检查不在高层重复全量执行，高层环境补充低层无法覆盖的验证。

验证强度递增可以按“范围扩大、条件趋近真实”来设计：开发层验证单点功能，测试层验证模块间集成，预发层验证全链路与容量，生产层验证真实流量下的表现。每层应明确哪些检查是必跑项、哪些是抽检项，避免高层环境堆积重复用例拖慢交付。

多团队共用环境时，需要约定隔离与排队规则。常见做法包括：按团队划分命名空间或独立测试库实现数据隔离；对预发等稀缺环境采用预约排队，规定单次占用时长和释放条件；共用环境的部署操作记录到共享日历或工作项中，避免两个团队同时部署互相干扰。环境层级与交付物形态的交叉对应也要写清楚，例如镜像类产物在测试层验证功能、在预发层验证启动与配置，数据变更脚本只在测试库试跑、在生产前单独复核。

环境层级	主要职责	验证内容	强度特征
开发	快速反馈	单元测试、冒烟用例、静态检查	范围小、频次高
测试	功能与集成验证	回归用例、接口集成、数据脚本试跑	覆盖主要业务路径
预发	贴近生产验证	全链路回归、性能基线、配置核对、发布演练	条件趋近真实
生产	真实流量验证	灰度观察、线上健康检查、回滚预案确认	以真实指标判定

用风险控制要求设置门禁、回退与例外处理

风险控制落到流水线上，就是把高风险变更识别出来并加严检查。识别方式可以按变更影响面判断：涉及资金、权限、核心链路或数据结构的变更，涉及多团队共享组件的变更，以及首次上线的新服务，都属于需要加严的对象。加严的方式包括增加人工复核、扩大回归范围、要求灰度比例更低、要求回滚演练记录等。

门禁的通过条件与阻断条件要成对定义。通过条件写成可判定的结果，例如“回归用例通过率100%”“性能基线偏差在约定范围内”“变更评审已由负责人确认”；阻断条件写明触发即停的情形，例如“存在未关闭的高危漏洞”“回滚脚本未验证”“关键依赖未就绪”。门禁状态应能被阶段执行人直接看到，避免靠口头确认。

失败后的回退路径与重跑规则需要提前约定：构建或测试失败时，修复后从失败阶段重跑，已通过的阶段不重复执行；预发验证失败时，回退到测试层定位问题；生产发布异常时，按预案回滚到上一稳定版本，并记录回滚原因。例外放行必须有记录和复核要求，包括放行原因、影响范围、批准人、补偿措施和复核时间，事后纳入复盘。

控制项	规则要点	记录要求
高风险变更识别	按影响面、共享组件、首次上线判断	标记变更等级并关联加严检查项
门禁通过条件	写成可判定结果，如通过率、偏差范围、评审确认	门禁结果与执行时间留痕
阻断条件	高危漏洞、回滚未验证、依赖未就绪即停	阻断原因与处理人记录
回退与重跑	从失败阶段重跑，生产异常按预案回滚	回滚版本、原因、时间记录
例外放行	说明原因、范围、批准人、补偿措施	放行记录纳入复盘复核

角色分工与各阶段交付物流转

多团队协作下，每个阶段都要有明确的责任人和交接确认动作。开发负责提交源码、修复构建与测试问题、准备变更说明；测试负责回归用例执行与缺陷跟踪、确认测试层交付物；运维负责环境准备、部署脚本与配置校验、预发与生产环境的发布执行；发布负责人负责门禁判定、例外放行审批和发布窗口协调。角色可以兼任，但每个阶段的确认人必须唯一。

交付物在阶段间的交接采用“产出即登记、接收即确认”的方式：上一阶段完成后登记交付物名称、版本和存放位置，下一阶段接收人核对交付物与完成标准后确认，未确认的交付物不进入下一阶段。跨团队协作时，共用环境的占用、共享组件的变更和依赖就绪状态需要同步到统一的工作项或共享记录中，责任边界以阶段确认人为准，出现争议时由发布负责人裁定。

阶段责任人与完成确认的记录方式建议统一：每个阶段对应一条工作项或记录，包含阶段名称、责任人、输入、交付物、完成标准、门禁结果和确认时间。这样在复盘或审计时可以按阶段追溯，也便于多团队查看彼此进度。在需要把阶段交付物、门禁状态与交接确认集中管理的场景中，ONES 可以通过工作项承载阶段任务、用文档沉淀交付物清单与完成标准，让阶段状态和确认记录在同一处可见。

角色	主要阶段职责	交接确认动作
开发	提交源码、修复构建与测试问题、准备变更说明	确认构建包与变更说明已登记
测试	执行回归用例、跟踪缺陷、确认测试层交付物	确认测试报告与遗留问题清单
运维	准备环境、校验配置与脚本、执行发布	确认环境就绪与发布结果
发布负责人	判定门禁、审批例外、协调发布窗口	确认门禁结果与放行记录

示例：一条覆盖多环境、多团队协作的流水线阶段设计

以下为演示情景，用于说明三线对齐方法如何落地，不代表特定团队的真实配置。假设一个由三个团队协作的订单服务，交付物包括服务镜像、前端静态资源、配置文件和一次数据库字段变更，环境分为开发、测试、预发、生产四层。

按环境层级展开的阶段序列为：构建阶段（开发层）完成编译、单元测试与静态检查，产出构建包；打包阶段（开发层）完成镜像构建与漏洞扫描，产出镜像标签；集成测试阶段（测试层）部署到测试环境，执行回归用例并试跑数据变更脚本；预发验证阶段（预发层）执行全链路回归、性能基线和配置核对；发布阶段（生产层）按灰度比例发布并观察线上指标。

阶段	输入	动作	交付物	完成标准
构建	源码、依赖清单	编译、单元测试、静态检查	构建包	单元测试全部通过，无阻断级告警
打包	构建包、基础镜像	镜像构建、漏洞扫描	镜像标签	扫描无高危漏洞
集成测试	镜像标签、数据变更脚本	部署测试环境、回归、脚本试跑	测试报告、试跑记录	回归通过率达标，回滚脚本验证通过
预发验证	测试通过的制品、生产配置基线	全链路回归、性能基线、配置核对	预发验证报告	性能偏差在约定范围，配置差异已确认
发布	预发通过的制品、发布预案	灰度发布、线上健康检查	发布记录	灰度指标正常，回滚预案就绪

门禁设置上，打包阶段设漏洞扫描门禁，集成测试阶段设回归通过率与回滚验证门禁，预发验证阶段设性能基线与配置核对门禁，发布阶段设灰度指标门禁。多团队协作处理上，三个团队共用测试环境时按命名空间隔离，预发环境采用预约排队，共享组件的变更需在集成测试阶段前同步给相关团队并确认依赖就绪，例外放行由发布负责人审批并记录。

落地检查：阶段划分是否可执行、可验证

阶段设计完成后，用以下清单逐项核对，任何一项不满足都应回到对应章节修正，而不是带着缺口进入执行。

• 每个阶段是否都写明了输入、动作、交付物和完成标准，完成标准是否可判定。
• 交付物形态是否都有对应的构建或验证动作，是否存在两类形态被强行合并到一个阶段。
• 环境层级与验证强度是否匹配，高层环境是否只补充低层无法覆盖的验证。
• 门禁的通过条件与阻断条件是否成对定义，门禁结果是否对执行人可见。
• 回退路径与重跑规则是否明确，生产异常是否有可执行的回滚预案。
• 例外放行是否有记录、批准人和复核要求。
• 每个阶段是否有唯一确认人，交付物交接是否有登记与确认动作。
• 多团队共用环境的隔离、排队与冲突处理是否有书面约定。
• 阶段记录是否可按阶段追溯，能否支撑复盘与审计。

清单全部满足后，阶段划分即可进入试运行；试运行期间重点观察门禁误阻断和排队等待时长，据此微调验证范围与门禁条件，使阶段设计在可控风险下保持可执行。

常见问题

交付物形态和环境层级发生冲突时，应该先满足哪一个？

先满足交付物形态，再排环境层级。交付物形态决定阶段能否合并：数据变更脚本与镜像发布的验证方式不同，即使两者都要在测试环境执行，也应各自保留独立阶段。环境层级决定顺序：验证强度高的环境排在后面，这个顺序在形态拆分完成后自然成立。若为了压缩环境占用想把两类形态合并到一个阶段，通常会导致完成标准无法写成可判定的条件，应优先保留形态拆分。

多团队共用预发环境时，排队规则至少要写清哪些内容？

至少写清四项：可预约的时间粒度与单次占用时长上限、占用到期后的释放条件、预约冲突时的优先级判定依据、以及部署操作在共享记录中的登记方式。规则还应说明紧急发布如何插队，以及插队后对其他团队预约的补偿安排。规则落到书面并让各团队确认后，预发环境的等待时间才可预期，也便于在试运行阶段观察排队时长并调整。

阶段完成标准写成“构建成功”“测试通过”为什么不够？

这类表述无法判定是否真正达标，不同执行人可能给出不同结论。可核验的完成标准应包含判定对象、判定方式和阈值，例如“单元测试全部通过且无阻断级静态检查告警”“镜像扫描无高危漏洞”“数据变更脚本在测试库执行成功且回滚脚本验证通过”。写成可判定条件后，门禁才能自动或人工明确判定，交接确认也有据可依。

例外放行后，后续需要补做哪些动作？

例外放行应记录放行原因、影响范围、批准人、补偿措施和复核时间。放行后按补偿措施补齐被跳过的检查，或在约定时间内完成补测；复核时间到达时由发布负责人确认补偿是否完成，未完成的纳入复盘并评估是否影响后续发布。例外记录本身也应作为阶段记录的一部分保留，便于审计时按阶段追溯。

阶段划分完成后，试运行期间重点观察什么？

重点观察两类信号：门禁误阻断和排队等待时长。门禁误阻断说明通过条件写得过严或判定口径不清，需要调整阈值或补充判定说明；排队等待过长说明环境容量或预约规则需要调整。试运行期间不宜频繁改动阶段结构，优先微调验证范围与门禁条件，待信号稳定后再固化阶段设计。