制定持续集成触发规则，核心是把“什么变更、在哪个分支、触发哪条流水线、跑到什么程度、失败谁来处理”写成一张可执行、可检查的规则表。先按分支层级和事件类型划分变更，再为每类确定触发条件、执行内容、并发与取消策略、失败处置和责任人，最后用一段时间的运行数据校验规则是否过密或过松。
要点总览（TL;DR）
- 触发规则先按分支层级和事件类型划分变更，明确哪些进入CI、进入后跑到什么程度，再写成规则表。
- 规则表应包含规则编号、适用分支、触发事件、过滤条件、执行流水线、并发策略、超时、失败处置和责任人，便于评审与版本管理。
- 执行内容按影响面分三级：快速校验、完整构建与测试、发布级验证，主干与发布分支从严，特性分支以反馈速度为先。
- 规则要有明确责任人：规则Owner维护版本，模块负责人确认范围，提交者处理本人失败，值班角色处理主干与发布分支的阻断失败。
- 上线前检查覆盖与重复触发，运行一个观察周期后依据触发频次、构建时长、失败率和漏检情况判断规则过密或过松并调整。
先定触发对象：哪些变更需要进入持续集成
触发规则的第一步是划定范围。持续集成的资源有限，把每一次提交都送进完整流水线，会让构建队列长期拥堵，反馈速度下降；反过来，只对少数事件触发，又容易让问题在合并后才暴露。合理的做法是先按分支层级和事件类型两个维度，把变更分成几类，明确每类是否进入CI、进入后跑到什么程度。
按分支层级划分
分支层级反映变更的稳定程度和影响范围，是决定触发强度的主要依据。常见划分如下：
- 主干分支：团队共享的集成分支，任何进入主干的变更都会影响所有人，应触发完整构建与测试，失败即阻断。
- 发布分支：面向特定版本冻结的分支，变更频率低但影响交付，触发发布级验证，并保留可追溯的构建记录。
- 特性分支：开发者的日常工作分支，提交频繁，适合触发快速校验，在发起合并请求时升级为完整校验。
- 临时分支：用于验证想法、修复紧急问题或试验性改动，可按需触发或仅手动触发，避免占用共享资源。
按事件类型划分
同一分支上，不同事件代表不同的变更意图，触发内容也应有所区别：
- 提交推送：最频繁的事件，适合触发快速校验，如编译、静态检查、单元测试。
- 合并请求：代表一次准备进入目标分支的变更，应触发完整构建与测试，并把结果作为合并的前置条件。
- 标签：通常对应版本发布，触发发布级验证与制品归档。
- 定时任务：用于夜间全量回归、依赖更新检查等不依赖单次提交的场景。
- 手动触发：用于重跑失败构建、验证特定提交或执行临时任务。
明确不触发的情形
把不触发的情形写清楚，能减少无效构建，也能避免规则被随意绕过。常见情形包括：仅修改文档或注释的提交、纯格式调整、草稿状态的合并请求、以及明确标注为跳过CI的临时提交。这些情形需要通过路径过滤或提交标记来识别，并在规则表中注明判断依据，避免执行时产生歧义。
输出触发对象清单
完成上述划分后，形成一份触发对象清单，作为后续规则表的输入。清单至少包含：分支名称或匹配模式、事件类型、是否进入CI、进入后的校验等级、以及不触发时的判断条件。这份清单需要与各模块负责人确认，确保覆盖团队实际使用的分支和协作方式。
核心答案与操作步骤：把触发规则写成可执行规则表
触发对象清单回答“哪些变更进入CI”，规则表回答“进入后具体怎么执行”。规则表的价值在于把口头约定变成可评审、可版本管理、可交接的文档，任何人拿到表都能判断某次变更会触发什么、失败后该做什么。
规则表字段定义
一张完整的触发规则表建议包含以下字段：
| 字段 | 填写内容 | 作用 |
|---|---|---|
| 规则编号 | 如 CI-MAIN-01，按分支层级加序号 | 便于引用、评审和变更记录 |
| 适用分支 | 分支名或匹配模式，如 main、release/*、feature/* | 确定规则作用范围 |
| 触发事件 | 推送、合并请求、标签、定时、手动 | 确定何时执行 |
| 过滤条件 | 路径包含或排除、提交标记、草稿状态 | 排除不需要执行的变更 |
| 执行流水线 | 快速校验、完整构建与测试、发布级验证 | 确定执行内容和深度 |
| 并发策略 | 取消旧构建、排队、并行上限 | 控制资源占用和结果有效性 |
| 超时 | 单次构建最长执行时间 | 防止卡死占用资源 |
| 失败处置 | 阻断合并、通知责任人、自动重试次数 | 明确失败后的动作 |
| 责任人 | 规则Owner与失败处理角色 | 保证规则有人维护、失败有人跟进 |
按变更影响面分级
规则表的核心设计是按影响面把执行内容分成三级，避免所有变更都跑同一套流水线：
- 快速校验：编译、静态检查、单元测试，目标是在几分钟内给出反馈，适用于特性分支推送和临时分支。
- 完整构建与测试：在快速校验基础上增加集成测试、代码扫描、制品构建，适用于合并请求和主干推送。
- 发布级验证：在完整校验基础上增加端到端测试、安全扫描、制品签名与归档，适用于发布分支和版本标签。
分级的关键是让每一级有明确的准入条件，而不是按心情选择。例如，合并请求默认进入完整校验，只有当变更仅涉及文档路径时才降级或跳过。
并发与取消策略
并发策略决定同一时间有多少构建在跑，以及旧构建是否让位给新提交。常见设置包括：同一分支有新提交时取消正在运行的旧构建，保证结果对应最新代码；跨分支的构建进入队列排队，避免同时占用全部执行资源；对发布分支设置更高的优先级或独立资源池，防止被特性分支的构建挤占。取消策略需要与失败通知配合，被取消的构建不应触发失败告警，否则会产生大量噪音。
路径与标签过滤的写法与边界
路径过滤用于排除文档、配置样例等不影响运行的改动，写法上通常使用包含或排除模式，如排除 docs/ 目录、只包含 src/ 目录。标签过滤用于识别提交意图，如提交信息包含特定标记时跳过CI。过滤的边界要写清楚：过滤规则只影响是否触发，不改变已触发构建的校验内容；被过滤的变更仍需在合并请求阶段接受完整校验，避免通过过滤绕过质量门禁。
填写步骤
按以下顺序完成规则表，每一步都有明确产出：
- 列事件：从触发对象清单中提取所有分支与事件组合，形成规则表的行框架。
- 分等级：为每一行确定执行流水线等级，写明判断依据。
- 定过滤：为需要排除的变更补充路径或标记条件，注明过滤后的兜底校验。
- 定并发：为每一行设置取消、排队或并行上限，说明资源约束。
- 定失败动作：写明失败后是否阻断合并、通知谁、是否自动重试。
- 评审发布：由规则Owner组织评审，确认无遗漏、无冲突后发布，并记录版本。
角色与交付物：谁定规则、谁维护、谁处理失败
规则表如果没有明确的责任人，很快会变成过期文档。制定阶段需要有人对规则的整体结构负责，运行阶段需要有人处理阻断性失败，两者不能混为一谈。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 规则Owner（平台或构建负责人） | 维护规则表版本，组织变更评审，处理规则冲突 | 规则表及变更记录 | 规则发布前评审通过；每次规则调整后更新 |
| 模块负责人 | 确认本模块的触发范围、必跑检查项和过滤条件 | 模块触发范围确认单 | 规则制定阶段；模块新增或拆分时复核 |
| 提交者 | 按规则提交变更，处理本人触发的构建失败 | 修复提交或失败原因说明 | 构建失败通知到达后 |
| 值班或轮值角色 | 处理主干与发布分支的阻断失败，判断是否需要回滚或临时放行 | 失败处理记录与放行审批 | 阻断失败发生后；交接班时同步未闭环问题 |
角色分工的关键是让失败有明确的第一个响应人。特性分支的失败由提交者处理，主干和发布分支的阻断失败由值班角色接手，规则Owner负责判断是否需要调整规则本身。三者职责相邻但不重叠，避免出现“都以为别人会处理”的情况。
规则落地后，触发结果和失败处理需要与研发任务关联起来，否则规则表只是一份静态文档。ONES 支持通过业务需求、研发任务等工作项拉取代码分支，并将代码提交与工作项关联，团队可以在工作项中看到对应的提交和构建进展；集成 Jenkins、GitLab CI 等流水线工具后，ONES 会同步流水线数据、更新执行状态和日志，并把流水线与项目关联，便于识别阻塞。这样，值班角色处理阻断失败时，可以直接从工作项定位到相关提交和流水线记录，失败处置记录也有了归属。
示例：一条主干分支与一条特性分支的触发规则
以下示例演示规则表如何填写，数值和分支名仅作示范，实际使用时按团队情况替换。
| 字段 | 主干分支规则 | 特性分支规则 |
|---|---|---|
| 规则编号 | CI-MAIN-01 | CI-FEAT-01 |
| 适用分支 | main | feature/* |
| 触发事件 | 合并请求、推送 | 推送；合并请求时升级 |
| 过滤条件 | 排除 docs/ 路径；草稿合并请求不触发 | 排除 docs/ 路径；提交信息含跳过标记时不触发 |
| 执行流水线 | 完整构建与测试 | 推送时快速校验；合并请求时完整构建与测试 |
| 并发策略 | 同一分支新提交取消旧构建；跨分支排队 | 同一分支新提交取消旧构建；并行上限2 |
| 超时 | 30分钟 | 10分钟（快速校验）；30分钟（合并请求） |
| 失败处置 | 阻断合并，通知提交者与值班角色 | 通知提交者；合并请求失败阻断合并 |
| 责任人 | 规则Owner；值班角色处理阻断失败 | 规则Owner；提交者处理本人失败 |
从这两条规则可以提炼出可迁移的填写规律：主干分支以稳定为先，推送和合并请求都进入完整校验，失败直接阻断；特性分支以反馈速度为先，推送只跑快速校验，把完整校验留到合并请求阶段；两条规则都设置了取消旧构建，避免同一分支堆积过期构建；过滤条件都保留了兜底校验，被排除的变更在合并请求阶段仍会接受完整检查。
规则上线后的完成检查与调优
规则表评审通过只是开始，是否合理要靠运行数据判断。上线前先做覆盖性检查，运行一个观察周期后再决定是否调整。
上线前检查
- 规则覆盖所有目标分支，主干、发布分支、特性分支均有对应规则，没有分支落在规则之外。
- 同一分支同一事件没有重复触发，避免一次提交启动多条流水线。
- 失败通知可达，提交者和值班角色都能收到对应分支的失败信息。
- 过滤条件有兜底校验，被排除的变更不会绕过合并请求阶段的完整检查。
- 规则表已记录版本，评审意见和确认人可追溯。
运行观察指标
观察周期内重点看四类数据：触发频次，判断是否有分支触发过密；平均构建时长，判断快速校验是否真的快；失败率及失败原因分布，区分真实缺陷与规则导致的误报；漏检情况，即问题在合并后才被发现的比例。这些数据可以从流水线记录中统计，也可以借助 ONES 的数据报表追溯工具链操作，集中查看构建与交付过程。
过密与过松的判断信号
| 信号 | 可能原因 | 调整方向 |
|---|---|---|
| 构建队列长期排队，提交者等待反馈时间明显变长 | 触发过密，低价值变更也进入完整校验 | 补充路径过滤，把部分事件降级为快速校验 |
| 大量构建因新提交被取消，失败通知频繁但无人处理 | 取消策略与通知未配合 | 被取消构建不触发失败告警，收敛通知范围 |
| 问题频繁在合并后或发布后才暴露 | 触发过松，关键分支校验不足 | 提高主干与发布分支的校验等级，补充必跑检查 |
| 同一失败反复出现，修复后仍重复触发 | 过滤条件或重试策略不合理 | 复核过滤边界，限制自动重试次数 |
规则变更与完成标志
任何规则调整都应走评审并记录版本，写明调整原因、影响范围和生效时间，避免规则在无人知晓的情况下被修改。完成标志可以定为：规则表评审通过，覆盖全部目标分支，并在一个观察周期内稳定运行，触发频次、构建时长和失败率处于团队可接受的范围，阻断失败均有明确处理记录。达到这个状态后，规则进入常规维护，按版本迭代而非频繁改动。
常见问题
团队规模较小，是否也需要完整的触发规则表？
规则表的价值在于把约定写清楚，与团队规模关系不大。小团队可以精简字段，例如合并规则编号与责任人、减少分级层级，但适用分支、触发事件、执行内容和失败处置这几项建议保留。规则表可以先从主干和特性分支两条规则起步，随分支数量和协作复杂度增加再补充。
路径过滤排除了文档改动，会不会让文档相关的构建问题漏掉？
路径过滤只影响是否触发构建，不改变已触发构建的校验内容。被排除的变更在合并请求阶段仍应接受完整校验，这是过滤规则的兜底。如果文档改动会影响构建产物（例如文档即站点内容），应把对应路径从排除列表中移出，或为这类变更单独设置一条轻量校验规则。
同一分支新提交取消旧构建后，被取消的构建需要通知吗？
被取消的构建通常不需要触发失败告警，否则同一分支频繁提交会产生大量噪音。建议在规则中明确：取消属于正常调度行为，只记录状态，不通知提交者；只有实际执行失败才按失败处置字段通知责任人。如果团队需要知道某次提交未完成校验，可以在合并请求状态中体现，而不是通过失败告警。
规则制定后，如何判断某个分支的校验等级是否合适？
主要看两类信号：一是问题暴露的时点，如果某分支的变更频繁在合并后或发布后才暴露缺陷，说明校验等级偏低；二是反馈等待时间，如果提交者长时间等不到结果，说明触发过密或执行内容过重。观察一个周期后，结合触发频次、平均构建时长和失败原因分布调整，调整时记录原因和影响范围。
触发规则和流水线工具里的配置是什么关系？
规则表是团队层面的设计与约定，流水线工具中的配置是规则的技术实现。规则表负责说明某类变更应该触发什么、失败谁处理，工具配置负责按这些约定执行。两者需要保持一致，规则调整后应同步更新工具配置，并在规则表中记录版本，避免文档与实际行为脱节。
