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 平台。正確的選擇取決於你團隊的限制：