Jenkins vs GitHub Actions vs GitLab CI：纯 CI 视角的比较

你的 CI 平台是工程速度的心跳。每个提交都会触发它。每个 PR 都依赖它。每个开发者每天都要与它互动多次。 然而，团队选择 CI 工具的原因往往是错误的：

• 「我们已经有 Jenkins 了」（沉没成本谬误）
• 「GitHub Actions 对小团队免费」（直到不是为止）
• 「GitLab CI 是整合的」（但它够好吗？） 这个比较穿透了噪音。没有 CD 偏见。没有供应商行销。只有纯 CI：构建、测试、lint、扫描、打包。 以下是 CI 真正重要的事项，以及每个平台如何交付。

1 什么是「纯 CI」？

持续整合 是一种自动构建和测试每个提交的实践。目标：早期发现错误、确保代码质量，并为开发者提供快速反馈。 纯 CI 范围：

• ❌ 部署到生产环境（那是 CD）
• ❌ 配置基础设施（那是 GitOps/IaC）
• ❌ 管理环境（那是 Environment on Demand）

2 评估标准：什么让 CI 变好？

核心指标

次要考虑因素

3 Jenkins：自托管的可靠选择

架构

Developer → GitHub/GitLab → Jenkins Master → Jenkins Agents → Build/Test
                                    ↓
                              Shared Storage (Artifacts)

部署模型： 自托管（VM、Kubernetes 或裸机）

CI 优势

1. 无限的灵活性

// Jenkinsfile - 完整的程序控制
pipeline {
    agent { label 'linux-large' }
    environment {
        BUILD_ID = "${env.BUILD_NUMBER}"
        REGISTRY = credentials('docker-registry')
    }
    stages {
        stage('Build') {
            steps {
                sh 'docker build -t app:${BUILD_ID} .'
            }
        }
        stage('Test') {
            parallel {
                stage('Unit Tests') {
                    steps { sh 'make test-unit' }
                }
                stage('Integration Tests') {
                    steps { sh 'make test-integration' }
                }
                stage('Security Scan') {
                    steps { sh 'trivy image app:${BUILD_ID}' }
                }
            }
        }
    }
    post {
        always {
            archiveArtifacts artifacts: '**/target/*.jar'
            cleanWs()
        }
    }
}

为什么重要： 你可以实现任何 CI 逻辑——Jenkinsfile 支持 Groovy 脚本、共享库和自定义插件。

2. 成本控制

EC2 上自托管的 Jenkins：
  - Master: t3.medium ($0.0416/小时)
  - Agents: 自动扩展的 spot instances ($0.01-0.03/小时)
  - Storage: EBS volumes ($0.10/GB-月)
5000 次构建的每月成本：~$200-400

可预测的定价： 你支付的是基础设施费用，而不是每次构建的分钟数。

3. Agent 灵活性

# 不同工作负载的 Agent 标签
agents:
  - label: "linux-small"   # 快速 linting、单元测试
  - label: "linux-large"   # 重型构建、整合测试
  - label: "windows"       # .NET 构建
  - label: "gpu"           # ML 模型训练
  - label: "arm64"         # 跨平台构建

自带 runner： 任何机器都可以成为 Jenkins agent——EC2、Kubernetes pods、本地服务器，甚至是开发者的笔记本电脑用于本地测试。

4. 成熟的插件生态系统

CI 弱点

1. Groovy 问题：能力还是负担？

// Jenkinsfile - 你可以撰写完整的程序逻辑
def buildMatrix = [:]
['dev', 'staging', 'prod'].each { env ->
    buildMatrix[env] = {
        node("agent-${env}") {
            try {
                checkout scm
                def config = load "config/${env}.groovy"
                parallel config.steps.collect { step ->
                    { ->
                        timeout(time: config.timeout, unit: 'MINUTES') {
                            sh "${step.command}"
                        }
                    }
                }
            } catch (Exception e) {
                currentBuild.result = 'FAILURE'
                emailext subject: "Build failed: ${env}",
                         body: "Error: ${e.message}",
                         to: config.notifyEmail
                throw e
            }
        }
    }
}
parallel buildMatrix

Groovy 是优势吗？ 取决于情况。

8 人开发团队：
  - 2 人可以从头撰写新的 Jenkinsfiles
  - 4 人可以修改现有的 pipeline
  - 2 人只能阅读/理解它们
当 Sarah 离职时：谁来维护 500 行的共享库？

与基于 YAML 的 CI 比较：

# GitHub Actions - 声明式、受限但可读
jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        environment: [dev, staging, prod]
    steps:
      - uses: actions/checkout@v4
      - run: make build
        env:
          TARGET_ENV: ${{ matrix.environment }}

权衡： 你失去了程序灵活性，但获得了：

• 所有开发者的可读性
• 更容易的入职
• 更低的巴士系数风险 Groovy 的结论： | 情境 | Groovy 是… | |----------|--------------| | 复杂、动态的 CI 逻辑 | ✅ 超能力 | | 标准的构建/测试/部署 | ❌ 过度设计 | | 大型团队有人员流动 | ❌ 负债 | | 小型团队、成员稳定 | ⚠️ 可接受 | | 受监管的行业（审计追踪） | ✅ 可追踪的逻辑 |

2. 维护开销

# Jenkins 现实检查
$ kubectl get pods -n jenkins
NAME                            READY   STATUS    RESTARTS
jenkins-controller-0            1/1     Running   12 last week
jenkins-agent-pool-deployment   3/3     Running   0

你签下的是什么：

2. 配置复杂性

// 共享库 (vars/buildAndTest.groovy)
def call(Map config = [:]) {
    def name = config.get('name', 'default')
    def timeout = config.get('timeout', 30)
    node('linux') {
        timeout(time: timeout, unit: 'MINUTES') {
            try {
                checkout scm
                sh "make build NAME=${name}"
                sh "make test NAME=${name}"
            } catch (Exception e) {
                currentBuild.result = 'FAILURE'
                throw e
            }
        }
    }
}
// 使用共享库的 Jenkinsfile
@Library('my-shared-lib') _
buildAndTest(name: 'backend', timeout: 45)

学习曲线：

• Groovy 语法（大多数开发者不熟悉）
• 共享库模式
• 插件兼容性矩阵
• Agent 标签管理
• 凭证范围划分

3. 反馈时间变异性

Build #101: 8 分钟   (快取暖、agent 可用)
Build #102: 23 分钟  (快取冷、排队等待 agent)
Build #103: 15 分钟  (部分快取、spot instance 抢占)

为什么会变化：

• Agent 可用性（排队时间）
• 快取暖/冷状态
• 共享资源竞争
• 到 artifact 存储的网络延迟 结果： 开发者无法预测 CI 持续时间。

4. UI/UX 债务

Jenkins CI 评分卡

4 GitHub Actions：开发者优先的选择

架构

Developer → GitHub PR → GitHub Actions Runner → Build/Test
                        ↓
                  GitHub Packages (Artifacts)

部署模型： SaaS (github.com) 或自托管 runner

CI 优势

1. 零设置

# .github/workflows/ci.yml
name: CI
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - name: Install dependencies
        run: npm ci
      - name: Build
        run: npm run build
      - name: Test
        run: npm test

就是这样。 没有服务器。没有 agent。没有维护。推送代码 → CI 运行。

2. 紧密的 GitHub 整合

1. 开发者开启 PR
2. CI 自动触发
3. 结果在几秒内出现在 PR 中
4. 绿色勾号 → 准备审查
5. 红色 X → 点击查看失败

无需上下文切换。无需仪表板搜索。

3. Action 市场

# 来自市场的可重用 actions
steps:
  - uses: actions/checkout@v4
  - uses: actions/setup-python@v5
  - uses: aws-actions/configure-aws-credentials@v4
  - uses: docker/setup-buildx-action@v3
  - uses: sonarsource/sonarqube-scan-action@v3

30,000+ actions 可用。最常见的 CI 任务只需一个 uses: 语句。

4. 矩阵构建

strategy:
  matrix:
    os: [ubuntu-latest, macos-latest, windows-latest]
    node: [18, 20, 22]
    exclude:
      - os: macos-latest
        node: 18
runs-on: ${{ matrix.os }}

自动生成 8 个并行作业。非常适合跨平台测试。

5. 内建缓存

- name: Cache dependencies
  uses: actions/cache@v4
  with:
    path: ~/.npm
    key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-npm-

缓存命中： 后续运行可减少 60-80% 的构建时间。

CI 弱点

1. 大规模的成本

GitHub Actions 定价（按量付费）：
  - 免费层：2,000 分钟/月
  - 超额：$0.008/分钟 (Linux), $0.016/分钟 (macOS)
50 人开发团队：
  - 平均 20 次构建/开发者/天 × 10 分钟/构建
  - 1000 次构建/天 × 22 天 = 22,000 次构建/月
  - 22,000 × 10 分钟 = 220,000 分钟
  - 成本：218,000 × $0.008 = $1,744/月

自托管 runner 可降低成本 但会增加维护开销。

2. Runner 限制

• 长时间运行的整合测试（> 6 小时）
• 大型 artifact 存储（> 10GB）
• 有状态构建（增量编译）

3. YAML 复杂性

# 简单的 CI 很快变得复杂
name: CI
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
env:
  NODE_VERSION: '20'
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
  test:
    runs-on: ubuntu-latest
    needs: lint
    services:
      postgres:
        image: postgres:15
        env:
          POSTGRES_PASSWORD: postgres
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
        ports:
          - 5432:5432
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'npm'
      - run: npm ci
      - run: npm run test:integration
        env:
          DATABASE_URL: postgresql://postgres:postgres@localhost:5432/test
  build:
    runs-on: ubuntu-latest
    needs: test
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v5
        with:
          push: true
          tags: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }}

YAML 蔓延： CI workflow 很快增长到 200+ 行。可重用性需要复合 actions 或可重用 workflow（更多的 YAML）。

4. 调试挑战

[CI 失败] 作业 "test" 失败，退出码 1
日志：
> npm run test:integration
> jest --config jest.integration.config.js
FAIL src/integration/payment.test.js
  ● Payment Integration › processes payment successfully
    Error: connect ECONNREFUSED 127.0.0.1:5432
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1141:16)
测试运行完成。1 失败，47 通过。

调试限制：

• 无法 SSH 访问 runner（除非使用调试 actions）
• 事后分析有限
• 日志在保留期后消失（最多 90 天）
• 无法在相同环境下重放失败的作业

5. 供应商锁定

GitHub Actions 评分卡

5 GitLab CI：整合平台

架构

Developer → GitLab Push → GitLab Runner → Build/Test
                        ↓
                  GitLab Registry (Artifacts)

部署模型： SaaS (gitlab.com) 或自管理

CI 优势

1. 单一配置文件

# .gitlab-ci.yml
stages:
  - lint
  - test
  - build
  - security
variables:
  NODE_VERSION: "20"
  DOCKER_REGISTRY: registry.gitlab.com
lint:
  stage: lint
  image: node:${NODE_VERSION}
  script:
    - npm ci
    - npm run lint
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
test:
  stage: test
  image: node:${NODE_VERSION}
  services:
    - postgres:15
  script:
    - npm ci
    - npm run test:unit
    - npm run test:integration
  variables:
    DATABASE_URL: postgresql://postgres:postgres@postgres:5432/test
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
build:
  stage: build
  image: docker:24
  services:
    - docker:24-dind
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
security-scan:
  stage: security
  image: registry.gitlab.com/security-products/semgrep:latest
  variables:
    SEMGREP_RULES: "auto"
  script:
    - /analyzer run
  artifacts:
    reports:
      sast: gl-sast-report.json
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

一切都在一个文件中： linting、测试、构建、安全扫描。不需要单独的 CD 配置。

2. Auto DevOps

GitLab 可以自动检测你的项目并自动配置 CI/CD：
1. 语言检测 (Node.js、Python、Go、Java 等)
2. 框架检测 (React、Django、Spring 等)
3. 数据库检测 (PostgreSQL、MySQL、Redis)
4. 自动生成 CI/CD pipeline
5. 每个 MR 部署到 review apps

零配置 CI： 对于常见技术栈开箱即用。

3. 内建功能

4. Runner 灵活性

# GitLab Runner 配置
[[runners]]
  name = "docker-pool"
  url = "https://gitlab.com/"
  executor = "docker"
  [runners.docker]
    image = "docker:24"
    privileged = true
    disable_cache = false
    volumes = ["/cache"]
    shm_size = 0
  [runners.cache]
    Type = "s3"
    Shared = true

Runner 类型：

• Shared runners： GitLab 管理 (gitlab.com)
• Group runners： 跨项目共享
• Project runners： 专用于特定项目
• Self-hosted： 你自己的基础设施

5. Pipeline 可视化

Pipeline #12345 - main branch
┌─────────┬─────────┬─────────┬─────────┐
│  lint   │  test   │  build  │ security│
│   ✅    │   ✅    │   ✅    │   ✅    │
│  1:23   │  4:56   │  2:34   │  1:45   │
└─────────┴─────────┴─────────┴─────────┘
Total duration: 10:38

清晰的可视化： 在一个视图中查看所有阶段、作业和持续时间。

CI 弱点

1. 紧密耦合

GitLab CI 是为 GitLab 设计的。与 GitHub 或 Bitbucket 一起使用：
  - 需要 webhooks 和 API tokens
  - 失去 MR 整合功能
  - 手动状态检查配置
  - 没有 Auto DevOps

平台锁定： 当你全面使用 GitLab（repo、registry、packages、deploy）时，GitLab CI 表现最佳。

2. YAML 学习曲线

# GitLab CI 有自己的 YAML 语义
job_name:
  stage: build
  image: node:20
  services:
    - postgres:15
  variables:
    DATABASE_URL: "postgresql://postgres:postgres@postgres:5432/test"
  before_script:
    - npm ci
  script:
    - npm run build
    - npm test
  after_script:
    - echo "Cleanup complete"
  artifacts:
    paths:
      - dist/
    expire_in: 1 week
    reports:
      junit: junit.xml
  cache:
    paths:
      - node_modules/
    key: ${CI_COMMIT_REF_SLUG}
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: always
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      when: on_success
    - when: never
  tags:
    - docker
  timeout: 30m
  retry:
    max: 2
    when:
      - runner_system_failure
      - stuck_or_timeout_failure

许多概念需要学习： stages、scripts、artifacts、cache、rules、tags、retry、timeout、services、variables、before/after_script。

3. 大规模成本 (SaaS)

GitLab CI 定价 (gitlab.com)：
  - 免费：400 CI/CD 分钟/月
  - Premium：$19/用户/月（包含 50,000 分钟）
  - Ultimate：$99/用户/月（包含 50,000 分钟）
  - 额外分钟：$0.007/分钟
50 人开发团队 (Premium)：
  - 基础：50 × $19 = $950/月
  - 包含分钟：50,000
  - 使用量：220,000 分钟（与 GitHub 示例相同）
  - 超额：170,000 × $0.007 = $1,190/月
  - 总计：$2,140/月

自管理可降低成本 但会增加基础设施开销。

4. 效能变异性

Shared runners (gitlab.com)：
  - 排队时间：0-5 分钟（高峰时段）
  - 作业持续时间：5-20 分钟
  - 效能：可变（共享资源）
Self-hosted runners：
  - 排队时间：接近零（专用）
  - 作业持续时间：5-15 分钟
  - 效能：一致（你的基础设施）

Shared runner 抽奖： 你的作业可能落在快速或慢速 runner 上。

5. 调试限制

GitLab CI 评分卡

6 一对一比较

反馈时间

维护开销

大规模成本（50 开发者，220k 分钟/月）

开发者体验

灵活性

可扩展性

7 决策框架

选择 Jenkins 如果：

• ✅ 你有专职的 DevOps 工程师（或能力）
• ✅ 成本控制至关重要（自托管基础设施）
• ✅ 你需要复杂的 CI 逻辑（自定义插件、共享库）
• ✅ 需要本地部署或空气隔离环境
• ✅ 你已经投资于 Jenkins 生态系统

选择 GitHub Actions 如果：

• ✅ 你的代码在 GitHub 上
• ✅ 开发者体验是优先事项
• ✅ 你想要零维护开销
• ✅ 你的 CI 需求是标准的（构建、测试、发布）
• ✅ 你重视紧密的 PR 整合

选择 GitLab CI 如果：

• ✅ 你的代码在 GitLab 上
• ✅ 你想要整合的 DevOps 功能（安全扫描、registry、packages）
• ✅ 你偏好单一供应商平台
• ✅ Auto DevOps 对你的团队有吸引力
• ✅ 你愿意学习 GitLab 的 YAML 语义

8 迁移考虑

Jenkins → GitHub Actions

迁移工作：中 - 高
- 将 Jenkinsfiles 重写为 GitHub Actions workflows
- 用复合 actions 替换共享库
- 将凭证迁移到 GitHub Secrets
- 培训团队 YAML 语法
- 更新文档
时间：典型团队 2-4 周

GitHub Actions → GitLab CI

迁移工作：低 - 中
- 将 workflow YAML 转换为 GitLab CI YAML
- 将 GitHub 特定功能映射到 GitLab 对应项
- 更新 runner 配置
- 如果使用 GitHub Packages 则迁移 packages/registry
时间：典型团队 1-2 周

GitLab CI → GitHub Actions

迁移工作：中
- 将 .gitlab-ci.yml 转换为 GitHub workflows
- 替换 GitLab 特定功能（Auto DevOps、内建扫描）
- 如果使用 GitLab Registry 则设置替代 registry
- 将 MR 整合更新为 PR 检查
时间：典型团队 2-3 周

总结：CI 平台决策矩阵

最终建议：

底线

没有普遍「最佳」的 CI 平台。正确的选择取决于你团队的限制：