制定流水线执行规则，要解决的是把“谁在什么条件下触发、按什么顺序执行、失败如何处置、结果如何留痕”写成可执行、可检查的约定。本文围绕交付流执行本身，给出从圈定范围、拆分条款、明确角色到成文复核的落地方法，并附一份可参照的规则片段与完成检查清单。
要点总览（TL;DR）
- 先按交付物类型、分支模型和发布频率盘点交付流，形成纳入与暂不纳入的范围清单，作为规则设计的输入。
- 执行规则拆成六段：触发与分支策略、阶段编排、准入与阻断、失败处置、证据留存、文档化与评审，每段写清输入、动作、输出和完成标志。
- 规则要落到人：规则Owner、流水线维护者、提交者、复核者各有动作和归属交付物，规则变更走评审流程。
- 条款按“条件、动作、责任人”三要素书写，主干分支示例可直接迁移到其他交付流，调整触发事件、阶段构成和严格程度。
- 用完成检查清单逐项核对触发条件、通过标准、阻断情形、回退路径、证据留存和复核周期，发布后在首个复核周期抽查失败处置案例。
先定范围：哪些交付流需要纳入执行规则
执行规则的第一件事是确定覆盖对象。规则写得再细，如果覆盖范围含糊，实际运行中就会出现“这条流水线算不算受管”的争议。建议按交付物类型、分支模型和发布频率三个维度盘点现有交付流，再决定纳入与否。
按交付物类型划分，可以把交付流分为应用服务、公共组件或基础镜像、配置与脚本变更等类别。不同类别的构建产物、测试重点和部署目标不同，执行规则的严格程度也应有所区别。按分支模型划分，主干分支、发布分支、特性分支承担的交付责任不同，通常主干与发布分支需要完整规则，特性分支可以只保留构建与单元测试环节。按发布频率划分，高频发布的交付流更需要自动化阻断和快速回退条款，低频交付流则可以保留更多人工确认节点。
需要说明本文的边界：这里讨论的是交付流执行规则，即触发、阶段编排、准入阻断、失败处置和记录留存；流水线与代码平台、制品库、部署环境的对接配置，以及发布审批与质量门禁的具体设置，属于另外的工作，本文不展开。
盘点完成后形成一份范围清单，逐条写明纳入或暂不纳入及理由。例如：
| 交付流 | 是否纳入 | 理由 |
|---|---|---|
| 核心交易服务主干分支 | 纳入 | 发布频率高，故障影响面大，需要完整阻断与回退条款 |
| 内部管理后台发布分支 | 纳入 | 有固定发布窗口，需要明确触发人与回退责任人 |
| 文档站点构建 | 暂不纳入 | 无生产部署动作，失败影响有限，先按普通构建管理 |
| 实验性特性分支 | 暂不纳入 | 仅用于开发自测，待合入主干时再适用主干规则 |
这份清单是后续条款设计的输入，也是评审时判断规则是否过宽或遗漏的依据。清单应随交付流增减定期更新，避免规则覆盖与实际交付结构脱节。
核心答案与操作步骤：把执行规则拆成六段可执行约定
执行规则的主干可以拆成六段：触发条件与分支策略、阶段编排与依赖顺序、准入与阻断、失败处置、证据留存、文档化与评审。每段都写清输入、动作、输出和完成标志，规则才具备可执行性。下面逐段说明。
第一段：触发条件与分支策略
输入是范围清单中的交付流及其分支模型。动作是逐条写明什么事件触发流水线（如合并请求创建或更新、分支合入、定时任务、人工发起），哪些分支适用哪套规则，以及谁有权发起。输出是一张触发条件对照表。完成标志是：任意一次流水线运行都能在表中找到对应的触发条目，且不存在“任何分支都可触发全部阶段”这类模糊表述。
第二段：阶段编排与依赖顺序
输入是交付流的构建、测试、制品产出和部署需求。动作是确定阶段先后与并行关系，例如构建完成后并行执行单元测试与静态检查，两者通过后再产出制品，制品验证通过才进入部署。输出是一张阶段编排图或阶段顺序表，标明每个阶段的输入来源和产出物。完成标志是：每个阶段都能说清“依赖哪个阶段的什么产出”，并行阶段之间不存在隐式依赖。
第三段：准入与阻断
输入是各阶段的通过标准。动作是为每个阶段定义可判定的通过条件，以及失败即停的阻断条件。通过标准要落到可观察的结果，例如测试全部通过、制品校验值生成、部署后健康检查返回正常。阻断条件要写明哪些失败直接终止整条流水线、哪些只标记告警继续执行。输出是阶段准入与阻断对照表。完成标志是：任一阶段失败时，执行者无需临时讨论就能判断流水线应停还是应继续。
第四段：失败处置
输入是阻断条件清单。动作是规定重试次数与适用阶段、单阶段超时时间、人工介入的触发条件与联系人，以及回退路径。回退路径要写明回退到哪个制品版本、由谁发起、回退后如何验证。输出是失败处置条款。完成标志是：每类失败都有对应的处置动作和责任人，回退操作有明确的前置判断条件。
第五段：证据留存
输入是各阶段产生的执行信息。动作是规定日志、制品版本号、执行记录、审批与人工介入记录的保存位置和保存期限。输出是证据留存清单。完成标志是：给定任意一次发布，能够回溯到当次运行的触发人、各阶段结果、使用的制品版本和处置记录。
第六段：文档化与评审
输入是前五段形成的条款。动作是把规则整理成一份独立文档，明确版本号、生效日期和变更记录，组织提交者代表、流水线维护者和复核者评审后发布。输出是经评审发布的规则文档。完成标志是：文档有明确Owner、有版本记录，且规则变更走同样的评审流程。
这六段构成一份草案的骨架。实际编写时可以先完成触发与阻断两段，因为这两段直接决定日常运行行为，再补齐其余部分。
角色与交付物：谁写规则、谁执行、谁复核
规则无人维护就会迅速失效。制定阶段就应明确四类角色及其动作，并把交付物归属写进规则文档。
| 角色 | 主要职责 | 关键动作 | 归属交付物 |
|---|---|---|---|
| 规则Owner | 对规则整体有效性负责 | 组织编写与评审、处理规则争议、按周期发起复核 | 规则文档及版本记录 |
| 流水线维护者 | 保证流水线按规则运行 | 配置触发与阶段、处理执行异常、提出规则修订建议 | 流水线配置说明、执行异常记录 |
| 提交者 | 按规则发起和跟进执行 | 在允许的分支与时机发起、失败后按条款处置或申请人工介入 | 提交与处置记录 |
| 复核者 | 独立判断规则执行是否合规 | 抽查执行记录、复核回退与人工介入案例、参与规则评审 | 复核记录与改进意见 |
角色划分的关键是让“改规则的人”和“日常执行的人”有明确接口。提交者在执行中发现规则不合理时，向流水线维护者提出，由维护者汇总给规则Owner，再走评审变更。复核者不参与日常配置，以保证抽查的独立性。规则文档、执行记录和变更记录分别归属上述角色，避免出现记录散落、无人对完整性负责的情况。
规则落地后，执行记录与评审流转需要有承载的地方。ONES 提供工作项与文档管理能力，可以把规则文档作为受版本管理的文档维护，把规则变更、人工介入申请和复核任务作为工作项流转，执行记录与工作项状态关联留存，便于复核者按同一口径抽查。这样规则、执行与复核在同一套记录体系中对应起来，减少口头确认和分散表格带来的遗漏。
示例：一条主干分支流水线的执行规则片段
下面以主干分支合并请求为例，示范条款的写法。每条条款尽量包含条件、动作和责任人三个要素。
- 触发条款：当合并请求创建或更新，且目标分支为主干分支时，自动触发主干流水线；提交者可在合并请求页面手动重新触发，其他人员发起需经流水线维护者确认。
- 阶段条款：流水线依次执行构建、单元测试与静态检查（并行）、制品产出、部署到预发环境、预发健康检查；前一阶段未通过时，后续阶段不启动。
- 阻断条款：构建失败、单元测试存在失败用例、制品校验值未生成，任一情况出现即终止流水线并标记合并请求不可合并；静态检查告警不阻断，但需在合并请求中记录处理结论。
- 失败处置条款：构建与测试阶段失败允许自动重试一次，重试仍失败则通知提交者；预发健康检查失败不自动重试，由提交者判断回退到上一制品版本或申请人工介入，回退操作需在合并请求中记录版本号与验证结果。
- 记录条款：每次运行保留触发人、各阶段结果、制品版本号和处置记录，保存期限按团队发布追溯要求执行，由流水线维护者负责完整性。
迁移到其他交付流时，主要调整三处：触发事件（如改为发布分支合入或定时触发）、阶段构成（如增加集成测试或安全扫描）、阻断与回退的严格程度（如低频交付流可保留人工确认节点）。条款结构本身可以沿用，条件、动作、责任人的写法保持一致，便于不同交付流的规则横向对照。
完成检查：规则是否可执行、可验证
规则草案完成后，用下面这份清单逐项核对。每一项都应有明确答案，答不上来的条目就是需要补充的地方。
| 检查项 | 通过标准 |
|---|---|
| 触发与分支条件 | 每个交付流的触发事件、适用分支、可发起人都有唯一表述，无“视情况而定”类模糊措辞 |
| 阶段通过标准 | 每个阶段都有可判定的通过条件，且条件指向可观察的结果 |
| 阻断条件 | 明确列出失败即停的情形，以及仅告警继续的情形 |
| 失败与回退路径 | 重试次数、超时时间、人工介入条件、回退目标版本与责任人、处置时限均已写明 |
| 证据留存 | 日志、制品版本、执行记录、人工介入记录的保存位置与期限明确，可回溯到单次发布 |
| Owner与复核周期 | 规则有明确Owner，复核周期与变更评审流程已写入文档 |
| 范围一致性 | 范围清单中的每个纳入项都能在规则中找到对应条款，暂不纳入项有理由记录 |
清单核对通过后，规则文档即可进入评审发布。发布后建议在第一个复核周期内重点抽查失败处置与回退案例，用实际执行记录检验条款是否被正确理解和执行，再据复核结果修订条款。规则的价值在于持续被使用和被修正，一份写完即归档的文档无法起到约束作用。
常见问题
规则刚发布，团队还没形成执行习惯，怎么推动落地？
建议把落地重点放在第一个复核周期：复核者抽查失败处置和回退案例，对照规则条款判断执行是否到位，把偏差整理成具体问题反馈给规则Owner。同时让流水线维护者在日常处理执行异常时记录“规则未覆盖或表述不清”的情形，作为首轮修订的输入。规则条款本身也可以从触发与阻断两段先行生效，其余段落随复核逐步收紧，降低一次性改变带来的执行阻力。
交付流数量多、差异大，是否要为每条流水线单独写一份规则？
不必逐条流水线各写一份。更实用的做法是先写一份通用规则，覆盖触发、阻断、失败处置、证据留存等共性条款，再为差异明显的交付流写补充条款，例如高频发布的服务增加自动回退要求，低频交付流保留人工确认节点。补充条款只写与通用规则不同的部分，并注明适用对象，这样规则总量可控，横向对照也方便。范围清单中的每个纳入项都应在通用规则或补充条款中找到对应内容。
规则中的阻断条件定得太严会拖慢交付，怎么把握尺度？
判断依据是失败的影响面与可恢复性。构建失败、测试存在失败用例、制品校验值缺失这类问题会直接影响交付物正确性，适合设为失败即停；静态检查告警、非关键路径的覆盖率波动等可以标记告警继续执行，但要求在合并请求中记录处理结论。尺度调整应通过评审进行，并在规则文档的变更记录中写明调整原因和适用范围，避免个别交付流私下放宽阻断条件。
回退条款写到什么程度才算可执行？
回退条款至少要回答四个问题：回退到哪个制品版本、由谁发起、在什么条件下触发回退判断、回退后如何验证。以预发健康检查失败为例，条款应写明由提交者判断回退或申请人工介入，回退目标为上一通过验证的制品版本，回退后在合并请求中记录版本号与验证结果。缺少其中任何一项，执行时就需要临时讨论，回退速度和一致性都会受影响。
规则文档和执行记录放在哪里，复核时怎么保证口径一致？
关键是让规则、执行记录和复核任务在同一套记录体系中对应起来。规则文档作为受版本管理的文档维护，规则变更、人工介入申请和复核任务作为工作项流转，执行记录与工作项状态关联留存。ONES 提供工作项与文档管理能力，可以承载这类规则文档与流转记录，便于复核者按统一口径抽查。具体承载方式按团队现有工具链选择，重点是记录可回溯到单次发布。
