CI/CD 工具与架构对比：从 GitHub Enterprise + Jenkins 到 GitLab CI、GitHub Actions 与 Argo CD

1. 为什么要做这次对比？

此前我的主要工作经验来自 GitHub Enterprise + Jenkins 的企业研发环境，涉及 PR 检查、Maven 构建、Artifactory 制品管理、测试环境部署、自动化回归和生产发布流程。

最近又在 WSL2 上搭建 GitLab CE，实践了 Shell/Docker Runner、Docker-in-Docker、Artifact、Cache、Container Registry 和资源并发控制。

在整理这些经验时，一个问题逐渐变得清晰：

GitHub Enterprise、Jenkins、GitHub Actions、GitLab CI/CD、Argo CD 到底是相互替代的工具，还是可以组合使用的不同系统？

答案是两者都有，但首先要明确各自负责的层次。

2. CI/CD 不等于一个工具

从开发提交代码到应用运行，通常可以分成几个阶段：

Source Code
    │
    ▼
Code Review / Merge Gate
    │
    ▼
CI: Build + Static Analysis + Test
    │
    ▼
Artifact / Container Registry
    │
    ▼
CD: Deploy + Verify + Rollback
    │
    ▼
Runtime Environment
    │
    ▼
Observability / Operations

这些职责不一定由同一个产品完成。

例如：

• GitHub Enterprise 可以负责代码、PR 和分支保护。
• Jenkins 可以负责构建、自动化测试和部署。
• Artifactory 可以负责保存构建制品。
• Argo CD 可以负责将 Kubernetes 集群同步到 Git 中声明的目标状态。
• Prometheus/Grafana 可以负责运行时监控。

因此，一套 CI/CD 系统更准确的描述方式应该是工具链架构，而不是只说“我们使用 Jenkins”或“我们使用 GitHub”。

还需要区分两个概念：

Continuous Delivery（持续交付）：软件持续保持可发布状态，生产发布可以有人为审批。

Continuous Deployment（持续部署）：满足自动化门禁后，变更可以自动进入生产环境。

使用了自动化流水线，不代表企业一定采用完全自动化的生产部署。

3. 常见工具的职责分类

工具	主要定位	能否执行 CI	能否执行部署
GitHub Enterprise	企业代码托管与协作平台	通过 Actions 或外部 CI	通过集成工具
Jenkins	通用自动化与 CI/CD 引擎	是	是
GitHub Actions	GitHub 集成式工作流与 CI/CD	是	是
GitLab CI/CD	GitLab 集成式 CI/CD	是	是
Azure Pipelines	Azure DevOps CI/CD 平台	是	是
CircleCI	CI/CD 平台	是	是
Tekton	Kubernetes-native Pipeline 引擎	是	是
Argo CD	Kubernetes GitOps CD Controller	非主要职责	是
Flux CD	Kubernetes GitOps CD Controller	非主要职责	是

这里最容易误解的是 Argo CD。

Argo CD 并不是 Jenkins 或 GitHub Actions 的直接一对一替代品。

Argo CD 主要解决的是 Kubernetes 应用如何持续保持在期望的部署状态。编译 Java、执行单元测试、生成 JAR、构建容器镜像等工作，通常仍由 Jenkins、GitHub Actions、GitLab CI 或 Tekton 承担。

4. Jenkins：独立于代码平台的自动化引擎

Jenkins 的典型架构：

GitHub Enterprise / GitLab / Git
                │
         Webhook / Polling
                │
                ▼
        Jenkins Controller
                │
        Scheduling / Pipeline
                │
       ┌────────┴────────┐
       ▼                 ▼
   Build Agent       Test Agent
       │                 │
   Maven / JDK       Testbed / Tools
       │                 │
       └────────┬────────┘
                ▼
        Artifact Repository
                │
                ▼
           Deployment

Jenkins Controller 负责管理 Job 和调度 Agent；实际工作通常交给 Agent 上的 Executor 执行。

Jenkins 可以通过 Jenkinsfile 实现 Pipeline as Code，例如：

pipeline {
    agent any

    stages {
        stage('Build') {
            steps {
                sh 'mvn clean package'
            }
        }

        stage('Test') {
            steps {
                sh 'mvn test'
            }
        }
    }
}

但并不是所有 Jenkins 环境都使用 Jenkinsfile。传统 Job、Freestyle Job、UI 配置、Groovy 脚本以及多层 Job 调用都可能存在。

优势

• 与代码托管平台解耦。
• 插件和脚本扩展能力强。
• 适合异构构建环境、专用物理机及复杂测试流程。
• 可以集成较老的系统和工具。

代价

• Controller、Agent、插件、凭据和升级需要自行治理。
• 历史 Job 容易积累隐式依赖。
• UI 配置过多会降低版本可追踪性。
• 多个 Pipeline 共用环境时，需要额外管理资源互斥和权限。

对于依赖昂贵物理 Testbed、专用硬件、历史自动化框架的企业，Jenkins 的灵活性具有明显价值。

5. GitHub Enterprise 与 GitHub Actions

GitHub Enterprise 首先是企业级 GitHub 平台，并不等于 GitHub Actions。

需要区分：

• GitHub Enterprise Cloud：GitHub 托管的企业服务。
• GitHub Enterprise Server（GHES）：企业自行部署的 GitHub 实例。
• GitHub Actions：能够在支持的 GitHub 平台上启用的自动化工作流系统。

GitHub Enterprise Server 的 Actions 需要管理员启用和配置，自托管 Runner 是其执行 Job 的主要方式。

典型 GitHub Actions 架构：

GitHub Repository
    │
    ├── Pull Request
    └── .github/workflows/ci.yml
             │
             ▼
       GitHub Actions
             │
             ▼
      Hosted / Self-hosted Runner
             │
        Build / Test / Deploy

最小 Workflow：

name: Java CI

on:
  pull_request:

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: '21'
      - run: mvn clean verify

这里 ubuntu-latest 是 GitHub-hosted Runner 的常见标签；如果运行在 GitHub Enterprise Server，需要使用适当的 self-hosted Runner 配置。

GitHub Actions 的优势在于与 PR、Checks、Secrets、Environments 等 GitHub 功能集成紧密。

但它并不是 GitHub Enterprise 的必选组件。

例如：

GitHub Enterprise
        │
        ▼
      Jenkins
        │
        ▼
   GitHub Commit Status / Checks
        │
        ▼
    PR Merge Gate

同样可以实现“CI 不通过，PR 不允许合并”。

GitHub 的 Required Status Checks 可以接受外部 CI 系统报告的检查状态。这意味着，在 GitHub PR 页面看到 Jenkins 检查结果，并不能据此认定使用了 GitHub Actions。

6. GitLab CI/CD：代码平台与 CI/CD 的集成

GitLab CI/CD 的配置一般位于项目根目录：

.gitlab-ci.yml

架构类似：

GitLab Server
    │
    │ Pipeline / Job Scheduling
    ▼
GitLab Runner
    │
    ├── Shell Executor
    ├── Docker Executor
    └── Kubernetes Executor

与 Jenkins 相比，GitLab CI 的 Pipeline 配置和项目协作工作流集成得更紧密。

例如：

stages:
  - build
  - test

build:
  stage: build
  image: maven:3.9-eclipse-temurin-21
  script:
    - mvn package

test:
  stage: test
  image: maven:3.9-eclipse-temurin-21
  script:
    - mvn test

我在本地实验中进一步验证了：

• Shell 与 Docker Executor 的环境隔离差异。
• Artifacts 与 Cache 的不同生命周期。
• needs 对默认 Stage 顺序的影响。
• Docker Socket Binding 与 DinD 的安全和镜像存储差异。
• GitLab Container Registry 的镜像 Push/Pull。
• resource_group 对有限 Testbed 的互斥控制。

与 Jenkins 一样，GitLab CI 也依赖真实的执行资源。Runner 的容量、网络、镜像仓库可用性、缓存和凭据管理同样会决定 Pipeline 的可靠性。

7. Jenkins、GitHub Actions、GitLab CI 的对应关系

概念	Jenkins	GitHub Actions	GitLab CI
配置	Jenkinsfile / Job Config	.github/workflows/*.yml	.gitlab-ci.yml
顶层编排	Pipeline	Workflow	Pipeline
工作单元	Stage / Steps / Job	Job / Steps	Job / Script
执行节点	Agent / Executor	Runner	Runner / Executor
依赖编排	Stage / Parallel 等	needs	needs / Stages
缓存、制品	插件/外部存储	Cache / Artifacts	Cache / Artifacts
人工发布门禁	Input / 插件等	Environment Approval	Manual Job / 审批功能
资源互斥	Lockable Resources 等	Concurrency Groups	resource_group

这张表是概念对应，不表示这些机制完全等价。尤其是并发范围、权限边界、审批版本限制和执行环境清理方式，都有实现差异。

从 Jenkins 转向 GitLab CI 或 GitHub Actions，最大的困难通常不是 YAML 或 Groovy 语法，而是理解：

谁负责调度？谁实际执行？状态保存在哪里？如何控制共享资源？失败发生在哪一层？

8. Argo CD：从 Push Deployment 到 GitOps Reconciliation

传统的命令式部署通常类似：

CI Pipeline
    │
    ▼
Build Artifact / Image
    │
    ▼
Deploy Command
    │
    ▼
Runtime Environment

例如：

cf push

或：

kubectl apply -f deployment.yaml

执行部署的 Pipeline 或操作人员主动向目标环境提交变更。

Argo CD 采用另一种思路：

Application Repository
        │
        ▼
CI: Build + Test + Push Image
        │
        ▼
Update Deployment Manifest
        │
        ▼
GitOps Repository
        │
        ▼
Argo CD Controller
        │
        ├── Desired State in Git
        └── Live State in Kubernetes
                    │
                    ▼
              Compare / Sync
                    │
                    ▼
             Kubernetes Cluster

Argo CD 以 Git 中的声明式配置为目标状态，持续比较 Kubernetes 当前状态与目标状态，并根据同步策略执行变更。

这个过程通常被称为 Reconciliation（调谐）。

与一次性执行 kubectl apply 相比，GitOps 更强调：

• Git 中的版本化期望状态。
• 对实际状态与期望状态差异的持续检测。
• 声明式变更、审计与回滚。
• 由集群侧控制器执行同步，而不是每次都让 CI 获得直接部署权限。

但 GitOps 并不自动解决所有问题：错误配置同样可能被自动同步，数据库迁移、回滚安全性和环境权限仍然需要单独设计。

关键区别

Jenkins / GitHub Actions / GitLab CI 负责生产可部署制品；Argo CD 负责让 Kubernetes 环境达到声明的部署状态。

它们可以组合使用。

9. Tekton、Flux CD 和其他平台

Tekton

Tekton 是 Kubernetes-native CI/CD 构建组件。它通过 Kubernetes CRD 定义：

Task
TaskRun
Pipeline
PipelineRun

Task 通常在 Kubernetes Pod 中执行。

因此，Tekton 更接近 Jenkins、GitLab CI 的流水线执行层，而不是 Argo CD 的集群持续调谐层。

Flux CD

Flux CD 与 Argo CD 属于更接近的比较对象。

两者都强调声明式状态和 Kubernetes GitOps Reconciliation。

粗略理解：

• Argo CD：提供以 Application 为中心的应用管理与同步模型，带有常用的 Web UI。
• Flux CD：采用可组合的 Kubernetes Controllers 与 CRD，管理 Git、OCI、Helm 等来源及期望状态。

Azure Pipelines 与 CircleCI

Azure Pipelines 使用 YAML 或 Classic Pipeline，支持 Agent、Build、Test、Artifacts 与多环境部署。

CircleCI 使用 .circleci/config.yml，通过 Workflow、Job 和不同类型的 Executor 编排任务。

这两类平台与 Jenkins、GitHub Actions、GitLab CI 更具有直接可比性。

10. 回顾以前使用的 GitHub Enterprise + Jenkins

基于我目前能回忆和确认的流程：

GitHub Enterprise
    │
    ▼
Pull Request
    │
    ▼
Jenkins Precheck / Build / Test
    │
    ├── Maven
    ├── Static Checks
    ├── Regression Jobs
    └── Integration Tests
    │
    ▼
Artifactory / Deployment
    │
    ▼
Cloud Foundry (cf push)
    │
    ▼
Environment Verification
    │
    ▼
Approval / Release Process

其中 Jenkins Pipeline 的执行、Job 调用、回归测试和 Artifactory 集成，是有实际操作经历支撑的部分。

不能据此确认的部分：

• GitHub Actions 是否也承担了部分自动化工作。
• GitHub Checks 是由 Jenkins 插件、Commit Status API 还是其他集成方式更新的。
• 公司其他团队是否使用了 Argo CD。
• 后续 Kubernetes 迁移计划是否引入 GitOps。

尤其是 GitHub Enterprise 本身并不能证明 GitHub Actions 被启用。

另外，我实际接触的 Cloud Foundry cf push 发布流程，并不能直接推断为 Kubernetes + Argo CD 架构。

这段经历本质上更接近：

GitHub Enterprise（SCM / PR） + Jenkins（CI/CD Orchestration） + Artifactory（Artifact Repository） + Cloud Foundry（Runtime）。

11. 如何选择一套 CI/CD 架构？

没有任何一种方案在所有场景下都最好。

场景	值得优先评估的方案
已大量使用 Jenkins、专用 Agent 和物理 Testbed	Jenkins
GitHub 代码托管、希望原生集成 PR 自动化	GitHub Actions
GitLab 承担 SCM、MR、CI 和 Registry	GitLab CI/CD
大量使用 Azure DevOps / Microsoft 生态	Azure Pipelines
希望采用托管 CI 服务	CircleCI 等
CI 工作负载需要 Kubernetes 原生编排	Tekton
Kubernetes 声明式持续部署	Argo CD / Flux CD
企业已有 Jenkins，但计划引入 Kubernetes GitOps	Jenkins + Argo CD / Flux CD

选择时，需要分别考虑：

1. 现有源码平台与权限模型。
2. Runner/Agent 的运行环境和维护成本。
3. 是否依赖物理硬件、GPU、专用工具或不可替代的老系统。
4. 构建制品与镜像仓库的管理方式。
5. 生产审批、审计、安全和隔离要求。
6. Kubernetes 是否已成为主要部署平台。
7. 故障排查、运维团队能力和迁移成本。

尤其不应该因为使用 Kubernetes，就默认所有 Jenkins Pipeline 都应该迁移到 Tekton，也不应该因为采用 Argo CD，就认为 CI 引擎不再需要了。

12. 对下一阶段学习的启示

经过 GitLab CI 实验和这次横向对比，我对整个交付链路的职责边界有了更清楚的认识：

GitHub / GitLab
       │
       ▼
Jenkins / Actions / GitLab CI / Tekton
       │
       ▼
Artifact / Container Registry
       │
       ▼
Argo CD / Flux CD / CI Deployment Job
       │
       ▼
Kubernetes / Cloud Foundry / VM
       │
       ▼
Prometheus / Grafana / Logging

下一步我不打算再增加新的 CI 平台实验，而是进入 Kubernetes 阶段：

• Deployment、ReplicaSet、Pod。
• Service 与网络访问。
• Readiness / Liveness / Startup Probes。
• Rolling Update 与 Rollback。
• Pod 故障、调度和资源限制排查。
• 最终将已完成的 GitLab CI 与 Kubernetes 部署连接起来。

CI/CD 工具的目标不是让 YAML 更复杂，而是让代码到运行环境的交付过程可靠、可重复、可审计、可恢复。

---

参考资料

以下资料以官方文档为主：

• GitHub：从 Jenkins 迁移到 GitHub Actions
• GitHub Enterprise Server：配置 GitHub Actions
• GitHub：Protected Branches
• Jenkins：Pipeline as Code
• GitLab：CI/CD Pipelines
• GitLab：Runners
• Argo CD：Overview
• Tekton：Tasks and Pipelines
• Flux：Core Concepts
• Azure Pipelines：YAML vs Classic
• CircleCI：Configuration Reference