4. 门禁机制设计：门禁的定义、门禁触发条件与CI/CD集成点
蓝绿发布门禁是部署流水线中用于控制“何时允许流量切换”的决策关卡。门禁机制的核心目标是在蓝环境（新版本）通过所有验证之前，阻止流量从绿环境（旧版本）切换过去，从而避免有缺陷的版本影响生产用户。
4.1 门禁的定义与组成要素
门禁（Gate）是一个逻辑决策点，它根据一组预定义的规则（条件）输出“通过”或“阻断”的二元结果。在蓝绿发布场景中，门禁通常包含以下三个核心要素：
| 要素 | 说明 | 示例 |
|---|---|---|
| 门禁规则 | 定义“通过”所需满足的具体条件 | 自动化测试通过率 ≥ 99.5% |
| 门禁状态 | 当前门禁的评估结果 | PASSED / FAILED / PENDING |
| 门禁执行器 | 负责执行规则并更新状态的组件 | Jenkins Pipeline 中的 input 步骤 |
关键设计原则：门禁必须是幂等的——即同一版本多次触发门禁评估，结果应保持一致。这要求门禁规则依赖的数据源（如测试报告、审批记录）具有不可变性。
4.2 门禁触发条件
门禁的触发条件分为三类，分别对应不同的验证维度。在蓝绿发布流水线中，这三类条件通常按顺序执行，形成一条完整的门禁链。
4.2.1 自动化测试门禁
自动化测试门禁是流水线中最先触发的门禁，用于快速验证蓝环境的基础功能与回归质量。其触发条件包括：
- 单元测试通过率：要求核心模块单元测试通过率 ≥ 99%，且无 P0/P1 级别失败用例。
- 集成测试覆盖率：新增代码的集成测试覆盖率 ≥ 80%，且关键业务链路（如登录、下单）必须覆盖。
- 性能基线对比：蓝环境的 P99 响应时间不超过绿环境的 110%，且错误率不高于绿环境。
- 安全扫描结果：依赖项漏洞扫描无 Critical 级别漏洞，High 级别漏洞数 ≤ 2。
4.2.2 人工审批门禁
人工审批门禁用于处理自动化测试无法覆盖的决策场景，例如变更风险评估、业务影响确认等。其触发条件通常包含：
- 变更经理审批：确认本次发布的变更范围与变更窗口匹配，且回滚方案已就绪。
- QA 负责人审批：确认自动化测试报告完整，且已执行必要的探索性测试。
- 业务方确认：对于涉及 UI/UX 变更的发布，需业务方确认蓝环境的功能表现符合预期。
最佳实践：人工审批门禁应设置超时机制（例如 24 小时内未审批则自动阻断），避免因审批人缺席导致流水线长时间阻塞。
4.2.3 合规检查门禁
合规检查门禁用于满足监管、安全策略或组织级治理要求。其触发条件包括：
| 检查项 | 检查内容 | 通过标准 |
|---|---|---|
| 代码签名验证 | 所有制品是否经过可信签名 | 签名证书在有效期内且未被吊销 |
| 依赖项许可证合规 | 引入的第三方依赖是否包含禁止使用的许可证 | 无 GPL/AGPL 等传染性许可证 |
| 数据隐私检查 | 日志中是否包含敏感字段（如身份证号） | 敏感字段已脱敏或未出现在日志中 |
| 配置基线检查 | 蓝环境的配置是否与安全基线一致 | 所有配置项均通过基线扫描 |
4.3 门禁与CI/CD流水线的集成点
门禁机制需要嵌入到 CI/CD 流水线的关键阶段中，才能发挥实际作用。以下是蓝绿发布场景中典型的集成点：
- 构建阶段之后：在制品构建完成并推送至制品仓库后，触发自动化测试门禁。此处的门禁用于验证制品本身的质量。
- 蓝环境部署之后：在蓝环境部署完成并完成健康检查后，触发人工审批门禁。此处的门禁用于确认环境就绪。
- 流量切换之前：在即将执行 DNS 或负载均衡器切换前，触发合规检查门禁。此处的门禁用于最终放行决策。
- 灰度验证期间：在流量逐步切换过程中，可设置渐进式门禁（例如每 10% 流量切换后触发一次自动化测试），用于持续验证。
常见陷阱：门禁集成点不宜过多。每增加一个门禁点，流水线的平均执行时间就会增加。建议将门禁点控制在 3~5 个，并优先保证“流量切换前”的门禁质量。
4.4 门禁触发流程示意图
下图展示了蓝绿发布流水线中门禁的触发顺序与决策逻辑：
4.5 门禁与CI/CD工具的集成方式
下表总结了主流 CI/CD 工具与门禁机制的集成方式：
| CI/CD 工具 | 门禁集成方式 | 关键配置项 |
|---|---|---|
| Jenkins | 使用 Pipeline 的 input 步骤实现人工审批；使用 when 条件判断测试结果 |
timeout、submitter、message |
| GitLab CI | 使用 needs 和 rules 控制作业执行顺序；使用 environment 的 on_stop 实现回滚 |
when: manual、allow_failure: false |
| Argo Workflows | 使用 DAG 任务编排，通过 suspend 模板实现人工审批门禁 |
suspend、continueOn、failOn |
| Spinnaker | 原生支持“Manual Judgment”阶段和“Automated Test”阶段 | judgmentInputs、expectedArtifacts |
集成要点：无论使用哪种工具，门禁的执行结果都应持久化到统一的发布记录中（例如发布工单系统或服务目录的发布历史），以便后续审计和复盘。
4.6 门禁的降级与熔断策略
在实际生产环境中，门禁机制需要具备一定的弹性。当门禁依赖的外部服务（如测试平台、审批系统）不可用时，应执行降级策略：
- 降级策略：如果自动化测试平台超时，允许使用上一次通过的测试报告（有效期不超过 2 小时）作为替代依据。
- 熔断策略：如果连续 3 次门禁评估均因外部服务异常而失败，则自动熔断该门禁，并通知 SRE 人工介入。
- 紧急绕过：在 P0 故障修复场景下，允许经过授权的 SRE 管理员临时绕过门禁，但必须记录绕过原因和审批人。
安全提醒：门禁的降级和绕过操作必须记录到不可篡改的审计日志中，且绕过操作应在故障恢复后 24 小时内触发一次强制复盘。