持续集成触发规则要解决的是：哪些变更值得启动构建、在什么分支上跑、跑多深、失败后由谁处理。本文给出一套可落地的设计方法，包括触发源清单、可填写的规则表模板、快慢流水线分工、角色职责对照，以及一条主干合并请求从触发到反馈的完整示例，最后附上线前核对项与运行期维护机制。规则的具体写法需结合团队所用流水线工具，本文聚焦规则本身的设计与管理动作。
要点总览（TL;DR）
- 先按代码提交、合并请求、标签、定时、手动五类触发源明确验证目的，再决定哪些变更可以合并触发或跳过。
- 规则表固定字段：触发事件、分支匹配、路径过滤、流水线、必跑检查、超时与并发、失败处置，每行一条规则并编号。
- 按风险分快慢两层：特性分支跑快速检查，合并请求与合入主干跑完整验证，标签触发追加发布校验。
- 平台或构建负责人维护规则，提交者处理自身失败，评审者把关合入，值班人接收主干与发布分支失败并按两级路径升级。
- 上线前逐条核对规则覆盖与通知渠道，运行期观察排队时长、失败率与跳过比例，按固定周期评审清理规则。
先定触发源：哪些变更值得启动一次构建
触发源决定规则的覆盖面。先按变更来源把触发分成五类，再为每类明确验证目的，可以避免”所有事件都触发全量流水线”造成的排队与噪声。判断依据是：这次变更可能引入什么风险，需要哪一层检查来兜住。
| 触发源 | 典型事件 | 验证目的 | 是否可合并或跳过 |
|---|---|---|---|
| 代码提交 | 推送到特性分支 | 快速发现编译错误、单元测试失败，给提交者即时反馈 | 同一分支连续推送可合并为最新一次构建，取消中间排队任务 |
| 合并请求 | 创建、更新、重新打开合并请求 | 验证合入后主干质量，作为评审与合入的前置条件 | 同一合并请求的新提交可取消旧构建，只保留最新结果 |
| 标签 | 打版本标签、创建发布标签 | 确认发布物的完整性、版本号一致性与发布前专项检查 | 不建议跳过；标签是发布动作的锚点 |
| 定时 | 每日或每周固定时间 | 发现依赖更新、环境漂移、长期未合并分支的集成问题 | 可按分支范围裁剪，只覆盖主干与活跃发布分支 |
| 手动 | 人工点击触发、带参数重跑 | 排查问题、补跑失败任务、执行特殊验证 | 由有权限的角色发起，需记录触发原因 |
可以合并触发的场景包括：同一分支短时间内的连续推送、同一合并请求的多次更新、仅修改文档或注释的提交。跳过标记的使用要有边界：只允许用于不改变运行行为的变更，例如纯文档、注释、格式化；涉及配置、依赖、构建脚本的改动即使文件很少也应正常触发，因为这类变更最容易引发环境级问题。跳过标记应由提交者在提交信息中显式声明，并在合并请求中可见，便于评审者复核。
触发规则表怎么写：条件、分支、流水线与检查项
规则表是把触发源落成可执行配置的载体。建议用一张表覆盖全部规则，每行一条，字段固定，便于评审和后续清理。下表给出字段结构与填写说明，团队可直接复制为模板。
| 字段 | 填写内容 | 说明 |
|---|---|---|
| 规则编号 | 如 CI-01 | 唯一标识，便于在失败通知和评审记录中引用 |
| 触发事件 | 推送、合并请求更新、标签创建、定时、手动 | 与 S1 的触发源分类对应 |
| 分支匹配 | 如 main、release/*、feature/* | 明确规则生效的分支范围，避免全分支全量触发 |
| 路径过滤 | 如 src/**、docs/** 排除 | 只对影响运行行为的目录触发，排除文档与静态资源 |
| 流水线 | 快速检查流水线、完整验证流水线、发布流水线 | 指向具体流水线定义，与 S3 的分级对应 |
| 必跑检查 | 编译、单元测试、静态扫描、集成测试等 | 列出该规则下不可跳过的检查项 |
| 超时 | 如 15 分钟、45 分钟 | 超时即判失败，防止任务长期占用资源 |
| 并发策略 | 取消旧构建、排队、串行 | 高频分支用取消旧构建，发布分支用串行 |
| 失败处置 | 通知对象、是否阻断合入、是否自动重试 | 与 S4 的责任分工衔接 |
分支策略上，主干与发布分支采用差异化规则：主干分支的合并请求必须跑完整验证并阻断合入；特性分支只跑快速检查，保证提交者几分钟内拿到反馈；发布分支在标签触发时追加发布专项检查，并采用串行执行避免并发发布互相干扰。路径过滤与跳过标记的使用边界与 S1 一致——只排除确定不影响运行行为的路径，任何涉及构建配置、依赖清单的改动都不应被过滤掉。
按变更风险分级：快慢两条流水线怎么分工
分级的目标是让常见变更快速拿到反馈，让高风险变更获得足够深的验证。做法是把检查项按耗时和风险分成两层：快速检查控制在十分钟量级，覆盖编译、单元测试、关键静态规则；完整验证覆盖集成测试、端到端测试、安全扫描等耗时较长的检查。两层不是替代关系，而是按阶段递进。
| 阶段 | 触发时机 | 执行的检查 | 结果作用 |
|---|---|---|---|
| 快速检查 | 特性分支每次推送、合并请求创建与更新 | 编译、单元测试、静态扫描、依赖检查 | 给提交者即时反馈，失败即阻断继续评审 |
| 完整验证 | 合并请求准备合入、合入主干后 | 集成测试、端到端测试、数据库变更校验 | 作为合入门禁，失败阻断合入并通知评审者 |
| 发布校验 | 标签创建时 | 版本号一致性、制品完整性、发布清单核对、回归抽检 | 作为发布门禁，未通过不进入发布流程 |
合并请求阶段与合入主干后的检查差异要明确：合并请求阶段跑完整验证是为了在合入前拦住问题；合入主干后再跑一次是为了确认合并结果本身可构建，因为合并可能引入语义冲突。发布前标签触发的额外校验不可省略，它对应的是”这次发布物是否与预期一致”，与代码质量检查属于不同维度。分级规则应按团队实际耗时调整阈值，若快速检查长期超过十分钟，应拆分检查项而不是简单延长超时。
角色与交付物：谁维护规则、谁处理失败
规则能否落地，取决于维护责任和响应义务是否写清楚。建议至少区分三类角色：平台或构建负责人、提交者、评审者，并为每类角色定义明确的交付物与响应时限。
| 角色 | 职责 | 交付物 | 响应要求 |
|---|---|---|---|
| 平台或构建负责人 | 维护规则表与流水线定义，处理规则冲突与容量问题 | 规则表、流水线配置、变更记录 | 规则变更需评审并通知受影响团队 |
| 提交者 | 保证提交通过快速检查，处理自己引入的失败 | 修复提交、失败原因说明 | 快速检查失败应在当个工作日内处理 |
| 评审者 | 确认合并请求的完整验证结果，判断是否合入 | 评审意见、合入决定 | 完整验证失败时不批准合入 |
| 值班或轮值人 | 接收主干与发布分支的失败通知，判断影响范围 | 失败分级记录、升级工单 | 主干失败按约定时限升级 |
失败通知的接收人要按分支区分：特性分支失败通知提交者本人；主干与发布分支失败通知值班人或构建负责人，并同步到团队频道。升级路径建议设为两级：值班人无法在约定时限内定位原因时，升级到构建负责人；涉及发布阻断时，同步通知发布负责人。规则维护与失败处置如果分散在多个系统里，跟踪成本会明显上升。ONES 支持集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步流水线数据并更新执行状态和日志，团队可以把失败对应的研发任务或缺陷作为工作项跟踪，让规则编号、失败记录与处理状态留在同一处，便于值班人交接和后续复盘。
示例：一条主干合并请求的触发全过程
以下为演示情景，用于串联前文的规则要素，具体配置需按团队工具调整。场景：开发者将特性分支 feature/payment-retry 合入 main，改动涉及支付重试逻辑与一个配置文件。
- 输入条件：合并请求已创建，目标分支为 main，改动路径命中 src/** 与 config/**，未使用跳过标记。
- 触发：合并请求创建事件命中规则 CI-02（分支匹配 main，路径过滤放行 src 与 config），启动完整验证流水线；同一合并请求的后续推送按并发策略取消旧构建，只保留最新一次。
- 构建与检查：流水线依次执行编译、单元测试、静态扫描、集成测试。编译与单元测试在快速阶段完成并回传结果；集成测试耗时较长，在完整验证阶段执行。
- 反馈：检查全部通过后，合并请求页面显示验证结果，评审者据此批准合入；合入主干后自动再触发一次主干构建，确认合并结果可构建。
- 失败处理：若集成测试失败，合并请求被阻断，通知提交者与评审者，失败记录关联到对应研发任务；提交者修复后推送新提交，旧构建被取消，新构建重新执行。若为主干构建失败，通知值班人，按升级路径处理，必要时回滚合入。
这个示例体现了规则表各字段的协同：触发事件决定何时启动，分支匹配与路径过滤决定是否命中，流水线字段决定跑哪一层检查，并发策略决定排队行为，失败处置决定通知与阻断。任何一环缺失，链路都会出现反馈延迟或责任真空。
上线前检查与持续维护
规则上线前先做一轮核对，确认规则可执行、责任可落实、失败可追溯。以下清单可作为上线评审的核对项：
- 每条规则都有唯一编号，且能对应到具体流水线与检查项；
- 主干、发布分支、特性分支的规则均已覆盖，无遗漏分支；
- 路径过滤与跳过标记的适用范围已写入团队约定，并有评审复核机制；
- 每条规则的超时与并发策略已设置，高频分支采用取消旧构建；
- 失败通知接收人与升级路径已明确到人或角色，通知渠道可用；
- 规则变更记录可查，变更前已通知受影响团队；
- 已用一条真实合并请求走通触发、构建、检查、反馈全流程。
运行期需要持续观察三类指标：排队时长反映流水线容量是否够用，若主干合并请求平均排队超过约定阈值，应增加执行资源或拆分检查项；失败率按规则和分支分别统计，某条规则失败率长期偏高，通常说明检查项不稳定或规则范围过宽；跳过比例反映跳过标记是否被滥用，比例异常上升时需要抽查提交内容。规则评审建议按固定周期进行，例如每季度一次，清理长期未命中的规则、合并重复规则、更新分支模型变化后的匹配范围。规则表与流水线定义应纳入版本管理，每次变更留下记录，便于回溯某次失败对应的规则版本。
常见问题
跳过标记在什么情况下可以使用，由谁复核？
跳过标记只适用于不改变运行行为的变更，例如纯文档、注释、格式化。涉及配置、依赖、构建脚本的改动即使文件很少也应正常触发。跳过标记由提交者在提交信息中显式声明，并在合并请求中可见，由评审者复核；团队应把适用范围写入约定，运行期关注跳过比例是否异常上升。
快速检查长期超过十分钟，应该延长超时还是拆分检查项？
优先拆分检查项。快速检查的定位是让提交者在几分钟内拿到反馈，延长超时会让反馈延迟变成常态。可以把耗时较长的检查移到完整验证阶段，或按模块拆分并行执行；只有确认检查本身必要且无法拆分时，才调整超时阈值，并同步更新规则表记录。
主干构建失败但合并请求阶段已全部通过，这种情况怎么处理？
合并请求阶段通过说明合入前的代码本身可构建，主干失败通常来自合并引入的语义冲突或环境差异。处理上由值班人接收通知，先判断影响范围：能快速修复的直接提交修复，影响面大的按升级路径通知构建负责人，必要时回滚本次合入。这类失败应记录到对应研发任务，作为后续调整规则或补充检查项的依据。
规则表需要多久评审一次，清理哪些内容？
建议按固定周期评审，例如每季度一次。清理对象包括长期未命中的规则、与其他规则重复的匹配范围、分支模型调整后失效的匹配条件，以及失败率长期偏高的不稳定检查项。每次变更留下记录并纳入版本管理，便于回溯某次失败对应的规则版本。
失败记录分散在流水线工具和项目管理系统里，怎么减少交接成本？
可以把失败对应的研发任务或缺陷作为工作项跟踪，让规则编号、失败记录与处理状态留在同一处。ONES 支持集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步流水线数据并更新执行状态和日志，值班人交接和复盘时可对照同一份记录。
