流水线执行规则要解决的是“什么时候自动跑、跑到哪一步必须停、失败之后怎么处置”这三个问题。本文面向需要制定或修订规则的团队，给出规则应包含的字段、按顺序推进的制定步骤、角色分工与交付物，并用一条从提交到合并请求的示例说明写法，最后提供上线后的核验清单。
要点总览（TL;DR）
- 流水线执行规则要写成可判定的条目，固定五类要素：触发条件与分支策略、阶段划分与串并行关系、门禁与审批点、失败处置与回退、执行记录与责任人。
- 制定按五步推进：梳理现状交付流、定义触发与分支映射、设置阶段门禁、约定失败重试与回退、发布并纳入变更管理，每步都有输入、输出和完成标志。
- 角色分工按规则 owner、评审人、流水线维护者、门禁审批人、开发测试人员划分，规则变更需留痕并通知受影响方。
- 规则是否生效看证据：触发覆盖率、门禁拦截记录、失败处置日志、变更留痕和定期复盘，缺一项就回到对应步骤修正。
- ONES 可集成 Jenkins、GitLab CI 等第三方流水线工具并同步执行状态与日志，用于支撑执行记录与复盘证据的收集。
一条可执行的流水线规则包含哪些要素
规则要写成可判定的条目，每条都能回答“满足什么条件就做什么、由谁确认、留下什么记录”。只写“加强流水线管理”无法执行，也无法验证。建议把规则拆成五类要素，每类固定字段，避免遗漏。
| 要素 | 说明 | 示例取值 |
|---|---|---|
| 触发条件与分支策略 | 哪些事件、哪些分支、哪些路径变更会触发执行；哪些情况只跑部分阶段 | 推送至 feature/* 触发构建与单元测试；合并请求指向 main 触发全量阶段；仅文档目录变更跳过构建 |
| 阶段划分与串并行关系 | 阶段顺序、哪些阶段可并行、前一阶段什么结果才允许进入下一阶段 | 构建→单元测试→静态检查（后两者并行）→集成测试→制品归档 |
| 门禁与审批点 | 进入下一阶段或合并前必须满足的准入条件，以及需要人工审批的节点 | 单元测试通过率100%、静态检查无阻断级问题；合入 main 需一名模块负责人审批 |
| 失败处置与回退 | 失败后是否自动重试、重试次数、可否跳过、回退到哪个版本、回退由谁发起 | 网络类失败自动重试2次；测试失败不重试直接阻断；已发布版本回退需值班负责人确认 |
| 执行记录与责任人 | 每次执行留存哪些信息、保存多久、异常由谁跟进 | 留存提交号、触发人、各阶段结果与日志；流水线维护者每周检查失败分布 |
五类要素之间存在依赖：触发条件决定了一次执行覆盖哪些分支，阶段划分决定了门禁放在哪里，失败处置又依赖执行记录来判断是偶发问题还是稳定缺陷。写规则时建议按这个顺序填写，前一项确定后再写后一项。
从触发到回退：规则制定的操作步骤
制定规则的过程是把团队现有交付习惯显性化的过程。以下五步按顺序推进，每步都给出输入、动作、输出和完成标志，完成标志用于判断这一步是否可以结束。
第一步：梳理现有交付流与关键节点
输入是当前从提交到发布的实际路径，包括分支模型、环境数量、人工检查环节。动作是画出提交、构建、测试、制品归档、部署各节点的先后关系，标出目前靠人记忆执行的检查。输出是一张现状流程图和一份“隐性规则清单”。完成标志是团队对关键节点没有分歧，且每个节点都能指出对应的执行人或系统。
第二步：定义触发规则与分支映射
输入是现状流程图和分支模型。动作是为每类分支指定触发事件与执行范围，例如长期分支跑全量阶段、短生命周期分支跑快速反馈阶段、发布标签触发制品归档。输出是触发规则表，一行对应一个分支类型。完成标志是任意一次提交都能在规则表中找到对应的执行范围，不存在“看情况跑”的分支。
第三步：设置阶段门禁与准入条件
输入是触发规则表和现有质量检查项。动作是为每个阶段确定进入下一阶段的条件，区分阻断级与提醒级，并为需要人工判断的节点设置审批人。输出是门禁清单，每项写明检查内容、判定标准、阻断或提醒、审批人。完成标志是每条门禁都能被自动判定或由指定角色明确放行，不存在无人负责的检查项。
第四步：约定失败重试、跳过与回退
输入是门禁清单和历史失败记录。动作是按失败类型分类处置：环境或网络类失败允许有限次自动重试，代码或测试类失败直接阻断，跳过某阶段需记录原因和批准人，回退需明确触发条件、回退目标和确认人。输出是失败处置表。完成标志是每种常见失败都能在表中找到对应处置方式，且重试次数、跳过权限、回退确认人都有明确取值。
第五步：发布规则并纳入变更管理
输入是前四步的全部产出。动作是把规则整理成一份可查阅的文档，明确生效日期、适用范围和负责人，并规定修改规则需要谁评审、如何通知。输出是发布后的规则文档和变更记录机制。完成标志是相关角色已收到通知，规则文档有版本号，后续每次修改都有记录可查。
谁定规则、谁执行、谁放行：角色与交付物
规则无人维护就会逐渐失效。建议把规则生命周期拆成四类角色，每类角色对应明确的交付物，避免“大家都负责、实际没人管”。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 规则 owner | 维护规则文档，组织评审，决定规则变更是否生效 | 规则文档及版本记录、变更评审结论 |
| 评审人 | 从开发、测试、运维视角评审规则的可执行性与影响范围 | 评审意见、对门禁与回退条款的确认 |
| 流水线维护者 | 保证流水线按规则运行，处理配置问题，跟踪失败分布 | 流水线配置、失败统计、异常跟进记录 |
| 门禁审批人 | 对需要人工放行的节点做出放行或驳回决定，并说明理由 | 审批记录、驳回原因 |
| 开发与测试人员 | 按规则提交代码、处理失败、发起回退申请 | 提交记录、失败修复说明、回退申请单 |
规则变更需要留痕并通知相关方。变更记录至少包含修改内容、修改原因、生效时间和影响范围；通知对象应覆盖受影响的开发、测试和值班人员。规则 owner 可以兼任流水线维护者，但在规模较大的团队中分开更利于相互校验。
当团队使用 ONES 承载研发过程管理时，可以把规则中的执行记录与工作项关联起来：通过代码提交与业务工作项关联，在需求或任务中查看对应的构建与发布过程，让规则要求的“可追溯”落到具体工作项上，而不是散落在多个系统里。是否采用这种方式取决于团队已有的工具链，规则本身应先独立成立。
示例：一条提交到合并请求的执行规则
以下示例演示如何把前面的要素写成可执行条目，团队可参照结构改写为自己的分支模型和检查项。
触发场景与分支
开发者向 feature/* 分支推送提交时触发快速反馈阶段；创建或更新指向 main 的合并请求时触发全量阶段。仅修改文档目录的提交跳过构建与集成测试，但仍执行链接检查。
阶段与门禁设置
快速反馈阶段包含构建和单元测试，两者并行执行，任一失败即终止并通知提交人。全量阶段依次执行静态检查、集成测试、制品归档；静态检查存在阻断级问题时不得进入集成测试；集成测试通过后才允许合并请求进入待审批状态。合并请求合入 main 需一名模块负责人审批，审批前必须看到全量阶段通过记录。
失败与重试处理
构建阶段因依赖下载失败可自动重试2次；单元测试与集成测试失败不自动重试，由提交人修复后重新触发。跳过集成测试需由模块负责人批准并在合并请求中注明原因。已合入 main 的版本如需回退，由值班负责人确认回退目标版本，并记录回退原因。
执行记录与通知
每次执行记录提交号、触发人、分支、各阶段结果和日志，保留时间与团队审计要求一致。失败通知发送给提交人和模块负责人；门禁拦截记录同步到合并请求，作为审批依据。
规则文本示例
“feature/* 分支推送触发构建与单元测试，失败即通知提交人；指向 main 的合并请求触发静态检查、集成测试与制品归档，静态检查阻断级问题未清零不得进入集成测试；集成测试通过且模块负责人审批后方可合并；依赖下载失败自动重试2次，测试失败不重试；回退由值班负责人确认并记录原因。”这段文本可直接作为规则条目放入文档，后续按变更管理流程修订。
规则上线后的完成检查
规则是否生效要看证据，不看声明。以下检查项建议在上线后第一个迭代周期内完成一次全量核对，之后按固定周期复查。
| 检查项 | 通过标准 | 证据来源 |
|---|---|---|
| 触发覆盖率 | 抽样周期内的每次提交都能对应到一次执行记录，漏跑情况有原因说明 | 提交记录与执行记录的对照清单 |
| 门禁拦截有效性 | 存在被门禁拦截并阻止进入下一阶段的记录，拦截原因与规则条款一致 | 门禁拦截日志、合并请求审批记录 |
| 失败处置执行情况 | 重试、跳过、回退均按规则执行，跳过有批准人，回退有确认记录 | 重试与回退日志、跳过审批记录 |
| 规则变更留痕 | 每次规则修改都有版本记录、评审结论和通知记录 | 规则文档版本历史、通知记录 |
| 定期复盘机制 | 按约定周期复盘失败分布与门禁误拦情况，并形成调整结论 | 复盘会议记录、规则调整记录 |
检查中发现的问题应回到对应步骤修正：触发覆盖率不足通常需要补充分支映射，门禁拦截失效需要检查判定标准是否可自动执行，失败处置偏离规则则要确认处置表是否覆盖了实际失败类型。规则调整后重新走变更管理流程，保持文档与流水线配置一致。
如果团队已经在 ONES 中管理需求与任务，并集成了 Jenkins、GitLab CI 等流水线工具，执行状态和日志会同步到对应工作项，复盘时可以直接查看某次失败关联的需求与提交，减少在多个系统之间核对记录的成本。这一衔接用于支撑检查项的证据收集，规则条款本身仍以团队约定为准。
常见问题
团队规模小、只有一两个人维护流水线时，角色分工可以合并吗？
可以合并，但职责要写清楚。规则 owner 与流水线维护者由同一人担任时，仍建议保留评审环节，由开发或测试负责人从使用视角确认门禁与回退条款是否可执行。门禁审批人不宜与提交人完全重合，否则人工放行容易流于形式。合并角色后，规则文档中要注明各职责的实际承担人，避免规则变更时找不到确认方。
门禁经常误拦，导致开发绕过规则直接合并，怎么处理？
先区分误拦原因：判定标准过严、检查项不稳定、还是规则未覆盖实际场景。对不稳定检查项，可将其从阻断级降为提醒级并记录原因；对标准过严的条款，回到门禁清单修订判定阈值。同时检查绕过路径是否被关闭，例如合并请求必须看到通过记录才能进入审批。规则调整后走变更管理流程，保留修改原因，避免同类问题反复出现。
失败重试次数和跳过权限应该由谁决定？
重试次数属于技术处置策略，建议由流水线维护者根据历史失败分布提出取值，规则 owner 确认后写入失败处置表。跳过权限涉及质量风险，应由门禁审批人或模块负责人掌握，并要求在合并请求中注明原因和批准人。两类取值都应有明确上限和记录要求，规则上线后按复盘结果调整，不临时口头放宽。
规则上线后，怎么判断门禁是真的在起作用？
看是否存在被门禁拦截并阻止进入下一阶段的记录，以及拦截原因是否与规则条款对应。如果一段时间内没有任何拦截记录，可能是门禁判定过松，也可能是检查项未真正执行，需要抽查执行日志确认。拦截记录、合并请求审批记录和跳过审批记录共同构成证据，单看通过率无法说明门禁有效。
ONES 在流水线执行规则落地中承担什么角色？
ONES 可集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步流水线数据，更新执行状态和日志，并把流水线与项目关联，在项目、迭代、需求中可视化代码提交、构建与发布过程。规则中的执行记录与追溯要求可以落到具体工作项上，复盘时直接查看某次失败关联的需求与提交。规则条款本身仍由团队约定，ONES 承载的是记录与查看环节。
