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 流程中的核心位置与数据流:
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 策略,一旦关键阶段失败立即终止 | 忽略测试失败继续部署 |