3. CI/CD 基础回顾:Jenkins/GitLab CI/GitHub Actions 核心概念与 Pipeline 即代码

在深入 Helm 与服务网格的集成之前,必须夯实 CI/CD 流水线的基础。本章回顾三种主流 CI/CD 工具的核心概念,并重点阐述 Pipeline 即代码(Pipeline as Code) 这一现代 DevOps 实践。理解这些基础,是后续构建“流量拓扑驱动”交付流水线的关键前提。

3.1 三种主流 CI/CD 工具核心概念对比

Jenkins、GitLab CI 和 GitHub Actions 分别代表了传统自托管、平台原生集成和云原生生态三种范式。下表从关键维度进行对比:

维度 Jenkins GitLab CI GitHub Actions
托管方式 自托管(Master/Agent) SaaS + 自托管 Runner SaaS + 自托管 Runner
Pipeline 定义 Jenkinsfile(Declarative / Scripted) .gitlab-ci.yml .github/workflows/*.yml
触发机制 SCM 轮询 / Webhook / 定时 Push / MR / Tag / 定时 / API Push / PR / Issue / Release / 定时 / 外部事件
执行环境 JVM 节点 / Docker / Kubernetes Shell / Docker / Kubernetes Docker / 虚拟机 / 自托管
插件/市场 超过 1800 个插件 内置集成 + 模板库 Actions 市场(社区 + 官方)
状态反馈 Blue Ocean / 自定义视图 MR Widget / 流水线图 PR Checks / 状态徽章
适用场景 复杂编排、遗留系统、高度定制 GitLab 全生命周期管理 GitHub 生态、开源项目、快速启动
选型建议: 如果你的团队深度使用 GitLab 或 GitHub,优先选择其内置 CI/CD 以减少运维成本。Jenkins 更适合需要高度定制化流水线、多工具链集成或已有大量 Jenkins 资产的企业。

3.2 Pipeline 即代码:核心价值与实现模式

Pipeline 即代码(Pipeline as Code)将流水线配置作为版本控制的一部分,与应用程序代码共存。这带来了以下核心价值:

  • 版本化与可追溯: 每次流水线变更都记录在 Git 历史中,支持回滚和审计。
  • 一致性: 开发、测试、生产环境使用相同的流水线定义,消除“在我机器上能跑”的问题。
  • 代码审查: 流水线变更可以通过 Merge Request / Pull Request 进行审查,提升质量。
  • 可复用性: 通过模板、函数、共享库实现流水线组件的复用。

下图展示了 Pipeline 即代码在 CI/CD 流程中的核心位置与数据流:

Pipeline 即代码:核心数据流与组件 代码仓库 (含 .gitlab-ci.yml / Jenkinsfile) 触发事件 Push / PR / Tag / 定时 CI/CD 引擎 解析 Pipeline 定义 Webhook / 轮询 事件负载 Stage: Build Stage: Test Stage: Package Stage: Deploy 编排执行 产物(Artifacts) 反馈(状态/日志) Pipeline 定义文件与代码同仓库管理,实现“配置即代码、过程可审计、环境可复现”

3.3 三种 Pipeline 定义示例

以下分别展示三种工具中一个典型“构建-测试-部署”流水线的核心定义片段。注意其语法差异与设计哲学。

3.3.1 Jenkins Declarative Pipeline (Jenkinsfile)

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                sh 'mvn clean compile'
            }
        }
        stage('Test') {
            steps {
                sh 'mvn test'
            }
            post {
                always {
                    junit 'target/surefire-reports/*.xml'
                }
            }
        }
        stage('Deploy') {
            when {
                branch 'main'
            }
            steps {
                sh 'mvn deploy'
            }
        }
    }
    post {
        failure {
            mail to: 'team@example.com', subject: 'Pipeline Failed'
        }
    }
}

3.3.2 GitLab CI (.gitlab-ci.yml)

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  script:
    - mvn clean compile
  artifacts:
    paths:
      - target/

test-job:
  stage: test
  script:
    - mvn test
  artifacts:
    reports:
      junit: target/surefire-reports/TEST-*.xml

deploy-job:
  stage: deploy
  script:
    - mvn deploy
  only:
    - main

3.3.3 GitHub Actions (.github/workflows/ci.yml)

name: CI Pipeline
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up JDK 17
        uses: actions/setup-java@v4
        with:
          java-version: '17'
      - name: Build
        run: mvn clean compile
      - name: Test
        run: mvn test
      - name: Deploy
        if: github.ref == 'refs/heads/main'
        run: mvn deploy
关键差异总结:
  • Jenkins 使用 Groovy 语法,支持声明式和脚本式两种风格,灵活性最高但学习曲线较陡。
  • GitLab CI 使用 YAML,强调阶段(stages)和作业(jobs)的并行与依赖,天然支持环境与制品管理。
  • GitHub Actions 使用 YAML,以事件(on)驱动,作业(jobs)和步骤(steps)结构清晰,市场生态丰富。

3.4 流水线最佳实践与避坑指南

在将 Helm 集成到 CI/CD 之前,请确保你的流水线已经遵循以下实践:

实践 说明 常见误区
快速反馈 流水线应在 10 分钟内提供关键反馈(编译/单元测试) 将耗时操作(如安全扫描)放在前置阶段,阻塞开发反馈
幂等性 相同输入应产生相同输出,避免依赖外部状态 使用全局变量或共享文件系统传递状态
制品管理 构建产物应版本化并存储到制品仓库(如 Nexus, Artifactory) 依赖 Git 仓库存储二进制文件
环境隔离 开发、测试、生产环境使用独立的配置和凭证 在流水线中硬编码环境地址或密钥
失败快速 使用 fail-fast 策略,一旦关键阶段失败立即终止 忽略测试失败继续部署