4. 持续集成工具：Jenkins、GitLab CI、GitHub Actions配置与实战

核心原理：流水线即代码与事件驱动

持续集成（CI）的核心思想是频繁地将代码变更合并到主干，并自动触发构建与测试。现代CI工具普遍采用“流水线即代码”（Pipeline as Code）模式，将构建、测试、部署的步骤以声明式或脚本式代码写入仓库，随版本库一起管理。三者虽实现不同，但底层逻辑一致：监听事件 → 拉取代码 → 执行任务 → 反馈结果。

• Jenkins：基于Master-Agent架构，通过Web界面或Jenkinsfile定义流水线，适合复杂、异构的企业级环境。
• GitLab CI：与GitLab仓库深度集成，使用.gitlab-ci.yml描述流水线，天然支持Merge Request（MR）流水线和多项目管道。
• GitHub Actions：以.github/workflows/*.yml定义工作流，采用事件驱动模型，支持丰富的市场Action复用。

三者的关键差异在于托管方式与生态绑定：Jenkins需自建维护，但插件生态最庞大；GitLab CI与GitLab DevOps平台一体化；GitHub Actions则与GitHub代码托管、Pull Request审查流程无缝衔接。

方法流程：从提交到反馈的标准流水线

无论使用哪种工具，一条成熟的CI流水线通常包含以下阶段：代码检出 → 依赖安装 → 静态检查 → 单元测试 → 构建镜像/制品 → 报告归档。以GitHub Actions为例，一个Node.js项目的核心工作流定义如下：

# .github/workflows/ci.yml
name: CI Pipeline
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18.x, 20.x]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci
      - run: npm run lint
      - run: npm test -- --coverage
      - uses: actions/upload-artifact@v4
        with:
          name: coverage-report
          path: coverage/

GitLab CI的等价配置使用.gitlab-ci.yml，通过stages定义阶段顺序，only/except控制分支规则。Jenkins则推荐使用声明式流水线，将上述步骤封装在pipeline { agent any; stages { stage('Test') { steps { sh 'npm test' } } } }中。关键差异在于触发器的配置方式：Jenkins依赖Webhook或轮询，GitLab CI原生支持Push/MR事件，GitHub Actions则通过on字段精确控制。

案例实战：基于GitHub Actions的微服务CI

假设一个Java Spring Boot微服务需要完成“提交→测试→构建镜像→推送至私有仓库”的完整流程。以下工作流展示了多Job并行与依赖控制的典型用法：

jobs:
  unit-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up JDK 17
        uses: actions/setup-java@v4
        with: { java-version: '17' }
      - run: mvn test

  docker-build:
    needs: unit-test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build & Push Image
        run: |
          docker build -t registry.example.com/app:${{ github.sha }}
          docker push registry.example.com/app:${{ github.sha }}

此案例中needs关键字确保测试通过后才执行镜像构建，github.sha提供不可变的版本标识。对于Jenkins，可通过build步骤的dependencies参数实现类似效果；GitLab CI则使用dependencies关键字控制Job间制品传递。实际项目中，建议将安全扫描（Trivy、SonarQube）插入测试与构建之间，形成更完整的质量门禁。

误区与复盘：流水线设计的常见陷阱