📚 课程目录第3章 CI/CD基础回顾

CI/CD 基础回顾：流水线核心阶段与工具选型

CI/CD（持续集成/持续交付）是现代 DevOps 实践的基石。在将 Terraform 基础设施即代码纳入发布流程之前，必须清晰理解 CI/CD 流水线的核心阶段以及主流工具的选型逻辑。本章将拆解流水线的四个关键阶段，并通过对比表格与架构图，帮助你在后续章节中精准定位 Terraform 的集成点。

3.1 流水线核心四阶段

一条标准的 CI/CD 流水线通常包含以下四个阶段，它们构成了从代码变更到生产交付的完整链路：

阶段	核心目标	典型产出物	常见失败原因
代码提交 (Commit)	触发流水线，确保代码进入版本控制	Git 提交记录、分支、标签	提交信息不规范、未通过 pre-commit 钩子
构建 (Build)	将源代码编译为可交付的制品	二进制文件、Docker 镜像、JAR 包	依赖缺失、编译错误、环境不一致
测试 (Test)	验证代码质量与功能正确性	测试报告、覆盖率数据、静态分析结果	测试环境不稳定、测试数据污染、超时
部署 (Deploy)	将制品发布到目标环境	部署版本号、环境状态快照、回滚点	配置错误、权限不足、基础设施状态漂移

  关键认知： 在 Terraform 集成场景中，构建阶段通常对应 Terraform 配置的语法校验与格式化检查；测试阶段对应 plan 命令的预演与合规策略扫描；部署阶段则对应 apply 命令的执行与状态锁定。

3.2 流水线阶段流程关系

下图展示了四个阶段在 CI/CD 流水线中的串联关系，以及每个阶段可能产生的反馈回路：

3.3 主流 CI/CD 工具选型对比

GitLab CI、GitHub Actions 和 Jenkins 是目前市场占有率最高的三款 CI/CD 工具。它们在架构、配置方式和生态集成上存在显著差异，选型时需要结合团队规模、平台偏好和运维成本综合考量。

对比维度	GitLab CI	GitHub Actions	Jenkins
配置方式	`.gitlab-ci.yml` 仓库内声明	`.github/workflows/*.yml` 仓库内声明	Jenkinsfile 或 Web UI 配置
运行架构	GitLab Runner（可自托管）	GitHub 托管 Runner / 自托管 Runner	Master-Agent 分布式架构
插件/市场生态	内置功能丰富，插件较少	Marketplace 生态活跃，Action 复用度高	插件数量庞大（1000+），但质量参差
与 Terraform 集成	原生支持 Terraform 模板与状态管理	通过 HashiCorp 官方 Action 或社区 Action	通过 Terraform 插件或 Pipeline 步骤
适用场景	GitLab 全栈用户，单体或微服务	GitHub 重度用户，开源项目	大型企业，复杂流水线，高度定制
运维复杂度	低（SaaS 版本几乎免运维）	低（SaaS 版本几乎免运维）	高（需维护 Master 和 Agent 集群）

选型建议： 如果你的代码仓库已经托管在 GitLab 或 GitHub，优先选择其内置的 CI/CD 工具，可以降低集成成本。Jenkins 更适合需要深度定制流水线逻辑、或已有 Jenkins 基础设施积累的团队。

3.4 工具选型架构对比

下图从架构层面对比三种工具的 Runner/Agent 与代码仓库、制品仓库之间的交互关系：

3.5 流水线配置示例对比

以下分别展示三种工具中实现“代码提交 → 构建 → 测试 → 部署”的最小化流水线配置片段：

GitLab CI (.gitlab-ci.yml)

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  script:
    - echo "Building application..."
    - make build

test-job:
  stage: test
  script:
    - echo "Running tests..."
    - make test

deploy-job:
  stage: deploy
  script:
    - echo "Deploying to production..."
    - make deploy
  only:
    - main

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

name: CI/CD Pipeline

on:
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: make build

  test:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: make test

  deploy:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - run: make deploy

Jenkins (Jenkinsfile)

pipeline {
    agent any

    stages {
        stage('Build') {
            steps {
                sh 'make build'
            }
        }
        stage('Test') {
            steps {
                sh 'make test'
            }
        }
        stage('Deploy') {
            when {
                branch 'main'
            }
            steps {
                sh 'make deploy'
            }
        }
    }
}

注意： 以上示例仅为演示流水线结构，未包含 Terraform 相关步骤。在后续章节中，我们将逐步在 build 阶段加入 terraform fmt 和 terraform validate，在 test 阶段加入 terraform plan，在 deploy 阶段加入 terraform apply。

3.6 选型决策要点

团队规模与技能： 小型团队优先选择 SaaS 化工具（GitLab CI / GitHub Actions），减少运维负担；大型团队可选择 Jenkins 以获得更高的定制自由度。
平台绑定风险： 如果未来可能迁移代码仓库，Jenkins 的仓库无关性更具优势；如果长期锁定单一平台，原生 CI/CD 集成度更高。
Terraform 集成深度： GitLab CI 提供原生 Terraform 模板和状态管理集成；GitHub Actions 通过 HashiCorp 官方 Action 实现；Jenkins 需要额外安装 Terraform 插件或通过 Pipeline 步骤调用 CLI。
成本考量： GitLab CI 和 GitHub Actions 的免费额度对中小项目足够；Jenkins 完全免费但需要自建服务器资源。