2. CI/CD 基础回顾：持续集成与持续部署的核心流程、常见CI/CD工具对比

在深入质量门禁与告警降噪之前，必须对齐 CI/CD 的基础认知。本章快速梳理持续集成与持续部署的核心流程，并对 Jenkins、GitLab CI、GitHub Actions 三款主流工具进行横向对比，为后续在流水线中嵌入阈值策略奠定工程基础。

2.1 持续集成与持续部署的核心流程

CI/CD 的本质是通过自动化手段，将代码从提交到生产部署的路径标准化、可重复化。下图展示了从代码推送至生产环境的完整流水线阶段：

上述流程可归纳为以下关键步骤：

1. 代码提交与触发：开发者推送代码至远程仓库，触发 Webhook 或轮询。
2. 静态分析与单元测试：执行 lint、SonarQube 扫描、Jest/JUnit 等，快速反馈代码质量。
3. 构建与打包：编译源码、构建 Docker 镜像、生成制品。
4. 集成测试：运行 API 测试、契约测试、端到端冒烟。
5. 部署至预发环境：模拟生产环境，进行验收与回归。
6. 生产部署：通过审批或自动策略，灰度或全量上线。

2.2 常见 CI/CD 工具对比

Jenkins、GitLab CI、GitHub Actions 是目前市场占有率最高的三款工具。下表从架构、配置方式、可观测性、插件生态、成本等维度进行对比：

2.3 工具选型建议与质量门禁适配

选择 CI/CD 工具时，需结合团队规模、基础设施、质量门禁需求综合判断：

• Jenkins：适合已有 Jenkins 投资、需要高度定制流水线、或运行在私有数据中心的大型企业。质量门禁可通过 Pipeline 脚本调用 SonarQube API、JUnit 结果解析等实现。
• GitLab CI：适合使用 GitLab 作为代码托管与 DevOps 平台的中大型团队。其内置的 CI/CD 分析、合并请求流水线、环境看板天然支持门禁可视化。
• GitHub Actions：适合 GitHub 原生用户、开源项目、或希望快速搭建流水线的团队。通过 statuses 和 checks API 可精确控制 PR 级别的质量门禁。

jobs:
  quality-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: npm test
      - name: Check test threshold
        run: |
          PASS_RATE=$(jq '.pass_rate' test-report.json)
          if (( $(echo "$PASS_RATE < 0.95" | bc -l) )); then
            echo "::error::Test pass rate $PASS_RATE below 95%"
            exit 1
          fi

2.4 流水线中的告警降噪切入点

无论使用哪种工具，告警降噪阈值策略的嵌入点通常集中在以下三个环节：

• 代码质量门禁：SonarQube 或 ESLint 报告中的 blocker/critical 数量超过阈值时，触发流水线失败并发送告警。
• 测试通过率门禁：单元测试、集成测试通过率低于设定值（如 95%）时，阻断部署并通知。
• 性能与安全门禁：基准测试响应时间超过 P99 阈值、或依赖扫描发现高危 CVE 时，自动回退并告警。