流水线执行规则、发布准入和质量门禁经常出现在同一套持续交付流程里，边界却容易混。执行规则决定流水线在什么条件下启动、按什么顺序运行、失败后怎么处理；质量门禁决定某个环节的质量证据是否达标；发布准入决定这次发布是否获批放行。本文按判断对象、判断时点和失败后果拆开三者，并说明重叠时如何配置。
要点总览（TL;DR）
- 流水线执行规则管流程怎么走：触发条件、串并行与依赖、超时重试、失败处理和人工确认都属于执行层，输出结果是继续、暂停、重试或中断。
- 质量门禁管质量是否达标：在构建、测试、部署等指定环节读取测试报告、扫描结果等证据，给出通过或拦截的结论。
- 发布准入管这次发布能不能放：在发布动作之前依据发布申请、审批意见、放行条件和发布窗口，给出批准、驳回或延期。
- 划分边界可按判断对象、失败后果和责任人三个角度：流程走向归执行规则，质量达标归门禁，发布放行归准入。
- 重叠场景的处理原则是各判断一次、结果引用：门禁结论作为执行分支条件，准入结论作为发布动作前提，避免同一判断在两层重复配置。
一句话说清三者的分工
流水线执行规则管“流程怎么走”：它定义流水线由什么事件触发、阶段之间如何串并行、单步和整体允许运行多久、失败后重试还是中断、哪些位置需要人工确认。它回答的是执行路径问题，输出结果是流水线继续、暂停、重试或终止。
质量门禁管“质量是否达标”：它在构建、自动化测试、部署前检查等指定环节读取质量证据，例如测试通过率、静态扫描结果、构建产物完整性，据此判定该环节通过还是拦截。它回答的是质量判定问题，输出结果是放行到下一环节或阻断当前流程。
发布准入管“这次发布能不能放”：它在发布动作之前收集发布申请、审批意见、放行条件和发布窗口信息，判断本次发布是否获批。它回答的是发布决策问题，输出结果是批准发布、驳回或延期。
| 概念 | 判断对象 | 判断时点 | 输出结论 |
|---|---|---|---|
| 流水线执行规则 | 流程如何触发、编排和结束 | 贯穿流水线运行全程 | 继续、暂停、重试、中断 |
| 质量门禁 | 指定环节的质量证据是否达标 | 构建、测试、部署等指定环节 | 通过或拦截 |
| 发布准入 | 本次发布是否获批 | 发布动作执行之前 | 批准、驳回或延期 |
三者的关系可以串成一条链：执行规则把流水线跑到某个环节，质量门禁在该环节给出通过或拦截的结论，发布准入在部署前决定是否放行，执行规则再根据这些结论决定后续动作。判断对象不同，配置位置和责任人也就不同。
流水线执行规则包含哪些控制要素
执行规则由五类控制要素组成，它们共同决定一条流水线从启动到结束的行为。理解这些要素，有助于判断某个配置究竟属于执行层还是质量层。
触发条件
触发条件定义流水线何时启动，常见方式包括代码提交、合并请求创建或更新、定时调度、手动触发，以及由上游流水线完成后触发。触发条件决定的是“有没有必要跑”，不判断代码质量好坏。配置时应明确分支范围、事件类型和触发频率，避免无关提交反复占用执行资源。
串并行与依赖
阶段顺序、并行任务和跨阶段依赖属于编排规则。例如构建完成后才能进入测试，单元测试与静态检查可以并行，部署到预发环境依赖前序测试阶段成功。编排规则决定任务之间的先后和并发关系，它关心的是执行顺序，不关心测试结果是否达到发布标准。
超时与重试
超时设置分为单步超时和整体流水线超时，用于防止任务长时间挂起。重试规则需要明确重试次数、重试范围（仅当前步骤还是整个阶段）以及哪些失败类型允许重试。网络抖动导致的拉取失败适合重试，编译错误反复重试则没有意义。超时与重试属于执行稳定性控制，不改变质量判定结论。
失败处理
某个步骤失败后，流水线可以中断、跳过后续步骤、继续执行剩余的非依赖任务，或触发通知。失败处理策略决定一次失败对整条流水线的影响范围。需要区分的是：执行失败处理针对的是任务运行结果，质量门禁拦截针对的是质量证据不达标，两者可以触发相同的通知渠道，但判断依据不同。
人工确认
人工确认是在执行过程中设置的暂停点，例如部署到生产环境前需要指定人员确认。它解决的是“流程是否继续推进”的问题，确认人依据的是当前执行状态和上下文信息。人工确认本身不替代质量门禁的证据判定，也不等同于发布审批，除非该确认点被明确定义为发布准入环节。
发布准入和质量门禁各自管什么
质量门禁和发布准入都带有“通过或不通过”的判断，但输入、依据和输出不同。把两者放在同一张表里对照，边界会更清楚。
质量门禁的范围
质量门禁是在构建、测试、部署等环节设置的质量判定点。每个门禁需要明确三件事：判定位置、证据来源和通过标准。判定位置指门禁挂在哪个阶段之后；证据来源指读取哪些结果，例如自动化测试报告、代码扫描结果、构建产物校验；通过标准指达到什么条件才算通过。门禁的输出是二元的：通过则允许进入下一环节，不通过则拦截并保留证据。
质量门禁的关键在于证据。没有明确证据来源的门禁，实际上只是一个需要人工点击的确认点，无法承担质量判定职责。门禁标准应随质量目标调整，例如新项目提高测试覆盖率要求，稳定项目侧重回归通过率。
发布准入的范围
发布准入发生在发布动作之前，处理的是发布申请、审批角色、放行条件和发布窗口。发布申请说明本次发布的范围和变更内容；审批角色决定谁有权批准；放行条件列出批准前必须满足的事项，其中可以包括关键质量门禁已通过；发布窗口限定允许发布的时间段，例如避开业务高峰或变更冻结期。
发布准入的判断依据是发布决策信息，包括变更风险评估、审批意见和窗口约束。它不直接读取测试报告来判断质量，而是把质量门禁的结论作为放行条件之一引用。这样质量判定和发布决策各司其职，避免审批人重复判断技术细节。
与执行规则的衔接位置
质量门禁通常挂在执行规则的某个阶段之后，门禁结论作为执行分支条件：通过则继续，拦截则走失败处理。发布准入位于部署动作之前，准入结论作为发布动作的前提：批准才允许执行部署，驳回则终止本次发布流程。执行规则负责把流程带到这些判断点，并按照判断结果决定下一步走向。
边界怎么划：按判断对象和失败后果区分
划分边界时，先问“这条规则在判断什么”，再问“判断失败会导致什么后果”，最后问“谁对这条规则负责”。三个角度结合，大多数配置都能找到归属。
按判断对象划分
判断流程走向的规则归执行层，包括触发、编排、超时、重试和失败处理。判断质量是否达标的规则归质量门禁，包括测试通过率、扫描结果、产物校验等证据标准。判断发布是否获批的规则归发布准入，包括审批角色、放行条件和发布窗口。遇到一条规则同时涉及多个对象时，看它的主要判断依据：依据执行状态的是执行规则，依据质量证据的是门禁，依据审批意见的是准入。
按失败后果划分
执行规则失败导致流水线中断、重试或跳过，影响的是流程能否继续运行。质量门禁失败导致环节拦截，影响的是代码或产物能否进入下一阶段。发布准入失败导致发布驳回或延期，影响的是本次发布能否对外生效。失败后果不同，处理方式和通知对象也应不同：执行失败通知流水线维护者，门禁拦截通知提交人和质量负责人，准入驳回通知发布申请人和审批人。
按责任人划分
流水线维护者负责触发条件、编排结构、超时重试和失败处理策略，保证流水线稳定运行。质量负责人负责门禁位置、证据来源和通过标准，保证质量判定有据可依。发布审批人负责准入条件、审批意见和发布窗口，保证发布决策符合变更管理要求。责任人清晰，规则调整时才知道该由谁评审。
重叠场景的处理原则
三类规则在实际配置中会重叠，处理原则是各判断一次、结果引用。质量门禁结果作为执行分支条件，执行规则读取门禁结论决定继续或中断，不在执行层重复定义质量阈值。发布准入结论作为发布动作前提，执行规则在部署前等待准入结果，不在流水线里重复实现审批逻辑。同一判断只在一个层次配置，其他层次引用其结果，可以减少规则冲突和排查成本。
| 划分角度 | 执行规则 | 质量门禁 | 发布准入 |
|---|---|---|---|
| 判断对象 | 流程走向 | 质量达标 | 发布放行 |
| 失败后果 | 流水线中断或重试 | 环节拦截 | 发布驳回或延期 |
| 主要责任人 | 流水线维护者 | 质量负责人 | 发布审批人 |
一个具体例子：从提交到发布的规则落点
下面用一条常见的交付链路演示三类规则分别落在哪一步。示例为演示情景，具体阶段名称和审批角色可按团队实际流程调整。
开发人员提交代码并创建合并请求，执行规则的触发条件生效，流水线自动启动。此时判断的是“是否需要运行”，与代码质量无关。流水线进入构建阶段，编译和打包按编排规则执行，单元测试与静态检查可以并行运行。
构建和测试完成后，质量门禁读取测试报告和扫描结果，按预设标准判定通过或拦截。若测试通过率低于阈值或存在阻断级扫描问题，门禁拦截，执行规则按失败处理策略中断后续阶段，并向提交人和质量负责人发送通知。此时流程停在门禁处，证据保留在流水线记录中。
门禁通过后，流水线继续运行到部署前，进入发布准入环节。发布申请人提交发布范围，审批人结合变更内容、门禁结论和发布窗口给出批准或驳回。准入结论作为发布动作的前提：批准则执行规则继续执行部署任务，驳回则终止本次发布并记录原因。
部署完成后，流水线按执行规则结束，各环节的门禁结论和准入结论一并留存在交付记录中。回看这条链路，触发、编排、失败处理和部署执行属于执行规则；测试与扫描的判定属于质量门禁；发布申请与审批属于发布准入。三类规则各判断一次，结果相互引用。
在工具承载层面，ONES DevOps 解决方案可集成 Jenkins、GitLab CI 等第三方流水线工具，同步流水线数据并更新执行状态和日志，把代码提交、流水线构建、产品发布等过程关联到项目、迭代和需求中。流水线编排本身在第三方工具中完成，ONES 侧提供 CI/CD 过程的可视化与追踪。对于需要把门禁结论、发布记录与需求交付情况放在同一视图里核对的团队，这种关联可以减少在多个系统之间来回查找状态的成本。
常见误解与容易混淆的相邻概念
边界混淆往往来自把某一层的职责扩大到另一层。以下三种误解最常见，澄清后有助于正确配置。
误解一：把质量门禁当成流水线的一个阶段配置
质量门禁确实挂在某个阶段之后，但它不是一个普通执行步骤。普通步骤关注任务是否运行成功，门禁关注质量证据是否达到标准。如果只配置了一个阶段而没有定义证据来源和通过标准，这个阶段无法承担门禁职责。正确做法是先明确判定依据，再决定门禁挂在哪个环节。
误解二：把发布准入当成流水线的最后一步自动执行
发布准入包含审批角色和发布决策，涉及人的判断和变更管理要求。它可以由流水线触发申请，但批准与否取决于审批人依据放行条件作出的决定。把准入简化为流水线末尾的自动步骤，会丢失审批记录和发布窗口约束，也无法处理驳回和延期的情况。
误解三：认为执行规则可以替代质量判断
执行规则能控制流水线是否继续、是否重试，但它不定义质量阈值。即使把失败处理配置得很细，也无法回答“测试通过率多少才算达标”。质量判断需要独立的门禁标准，执行规则只负责根据门禁结论决定流程走向。
与研发工具链集成的区别
研发工具链集成解决的是平台之间如何对接、数据如何同步，例如流水线工具与项目管理工具之间的状态回传。执行规则解决的是流水线内部如何触发和编排。两者分属不同主题：集成关注连接是否通畅，执行规则关注流程如何运行。集成完成后，执行规则才在流水线工具中生效。
与发布审批流程的区别
发布审批流程是组织层面的审批制度，规定谁在什么情况下可以批准发布、需要几级审批、保留哪些记录。发布准入是这套制度在具体发布动作前的落地条件，包括放行条件和发布窗口。审批制度决定准入规则的制定原则，准入规则是审批制度在单次发布中的执行表现。两者层次不同，不宜混为一谈。
常见问题
质量门禁已经通过，发布准入是否一定批准？
不一定。质量门禁通过说明指定环节的质量证据达到了预设标准，它是发布准入的放行条件之一，但准入还要看变更风险评估、审批意见和发布窗口。例如门禁全部通过，但发布窗口处于变更冻结期，或者审批人认为本次变更影响面过大，发布仍可能被驳回或延期。反过来，准入批准也不能替代门禁判定，质量证据不达标的环节依然会被拦截。
流水线里已经设置了人工确认点，还需要单独做发布准入吗？
取决于这个确认点被定义成什么。如果人工确认只解决“流程是否继续推进”，确认人依据当前执行状态点击继续，它属于执行规则中的人工确认。如果组织要求记录发布范围、审批角色、放行条件和发布窗口，并保留审批意见与驳回原因，就需要独立的发布准入环节。两者可以并存：人工确认控制流程暂停点，发布准入承载发布决策与记录。
门禁拦截后，流水线应该中断还是继续执行后续非依赖任务？
这属于执行规则的失败处理策略，需要结合门禁结论的性质来定。若门禁拦截意味着产物不可用，后续依赖该产物的部署任务应中断；若后续存在与质量判定无关的独立任务，例如文档归档或通知，可以配置为继续执行。关键是把门禁结论作为执行分支条件读取，而不是在执行层重新定义质量阈值。通知对象也应按失败后果区分：门禁拦截通知提交人和质量负责人。
超时和重试规则应该由谁维护，和质量负责人有关吗？
超时与重试属于执行稳定性控制，主要由流水线维护者负责，包括单步超时、整体超时、重试次数和重试范围的设置。质量负责人关注的是门禁位置、证据来源和通过标准，不直接调整重试策略。需要协同的地方在于：某些质量检查本身耗时较长，超时阈值要与门禁环节的实际运行时间匹配，否则会出现门禁尚未判定就被超时中断的情况。
把门禁结论和发布记录关联到需求上，对划分边界有什么实际帮助？
关联后可以按需求回看整条链路的判断结果：哪次提交触发了流水线、门禁在哪个环节拦截、发布准入是否批准。这样排查问题时能快速定位是执行层中断、质量层拦截还是准入层驳回，避免把三类规则混在一起排查。在工具承载层面，ONES DevOps 解决方案可集成 Jenkins、GitLab CI 等第三方流水线工具，同步流水线数据并更新执行状态和日志，把代码提交、流水线构建、产品发布等过程关联到项目、迭代和需求中；流水线编排本身在第三方工具中完成，ONES 侧提供 CI/CD 过程的可视化与追踪。
