CI/CD 基础：概念与常见工具概览

聊日志分析之前，我们得先搞明白 CI/CD 到底是什么。说白了，它就是现代软件开发的“高速公路”。没有它，你每次改代码都要手动打包、手动测试、手动部署——想想就头大。我刚开始带团队的时候，就吃过这个亏，后面会讲到。

持续集成（CI）是什么？

持续集成，就是把代码频繁地合并到主干，然后自动构建、自动测试。目的是尽早发现集成错误。嗯，这里的核心是“频繁”——不是一周一次，而是一天好几次。

我个人习惯是：每完成一个小功能就 push。只要 push 到特定分支，CI 系统就会自动拉代码、编译、跑单元测试。如果红了，马上修，绝不等到下班前。

持续部署（CD）是什么？

CD 分为两层：持续交付和持续部署。持续交付的意思是：代码随时可以部署到生产环境，但需要人工点一下按钮。持续部署更激进——自动化部署，连按钮都省了。

我曾经在一个金融项目里踩过坑：他们搞了持续部署，但没配好回滚机制。有一回新版本上线导致支付接口超时，花了 45 分钟才回滚……那次之后我建议：不管多急，先保证能一键回滚。

CI/CD 流水线的核心要素

一条标准的流水线，至少包含下面几步：

1. 代码提交 —— 开发者推送到 Git 仓库（GitHub、GitLab 等）。
2. 自动触发 —— 工具监听分支变化，启动任务。
3. 构建 —— 编译代码、打包成镜像或 jar。
4. 测试 —— 单元测试、集成测试、代码扫描。
5. 部署 —— 推送到测试环境、预发布环境、生产环境。
6. 通知 —— 把结果发到钉钉、Slack 或邮件。

你想想看，如果哪一步失败了，日志就是唯一的线索。这就是我们后面30章要干的事——从日志里把原因揪出来。

常见 CI/CD 工具概览

市面上工具很多，但我只挑四个最主流的讲。它们各有脾气，选型的时候要掂量清楚。

工具	部署方式	配置文件	核心特点	适合场景
Jenkins	自托管（需服务器）	Jenkinsfile (Groovy)	插件丰富，极度灵活，但维护成本高	传统企业、复杂自定义需求
GitLab CI	托管或自托管	.gitlab-ci.yml (YAML)	与 GitLab 深度集成，内置容器注册表	GitLab 用户、中小团队
CircleCI	托管（SaaS）	.circleci/config.yml	加速并行执行，缓存机制好	快速迭代、频繁部署的团队
GitHub Actions	托管（GitHub 内置）	.github/workflows/*.yml	生态强大，直接连接 GitHub 仓库	GitHub 用户，与社区交互多

各工具使用体验

Jenkins

老牌选手。我最早接触 CI 用的就是 Jenkins。它的插件生态简直乱花渐欲迷人眼——从代码检查到部署到 K8s，几乎啥都能干。但代价是你得自己维护一台服务器，还得折腾插件版本兼容。我记得有一次 Jenkins 主节点挂了，所有下游任务全卡住，项目交付延期两天……后来我果断迁移到了容器化 Jenkins。

配置上 Jenkins 支持两种方式：Pipeline 脚本（Groovy）和声明式 Pipeline。我个人推荐声明式，结构更清晰。看个例子：

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                echo 'Building...'
                sh 'mvn clean package'
            }
        }
        stage('Test') {
            steps {
                echo 'Testing...'
                sh 'mvn test'
            }
        }
        stage('Deploy') {
            steps {
                echo 'Deploying...'
                sh 'scp target/app.jar user@server:/deploy/'
            }
        }
    }
}

GitLab CI

如果你团队用 GitLab 管理代码，那 GitLab CI 几乎是无缝接入。你只需要在仓库根目录放一个 .gitlab-ci.yml。它的 Runner 可以装在你自己机器上，也可以用共享 Runner。

我觉得它最大的优点是“一切都在同一个界面”：代码、CI、制品、容器仓库，全在 GitLab 里。你不用切窗口找日志。看个简单配置：

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  script:
    - echo "Compiling..."
    - mvn compile

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

deploy-job:
  stage: deploy
  script:
    - echo "Deploying..."
    - scp target/app.jar deploy@prod:/opt/

CircleCI

CircleCI 的卖点是速度和并行。它默认提供并行任务，比如你可以在一个 pipeline 里同时跑单元测试和集成测试，互不干扰。缓存机制也很智能——依赖包会缓存起来，下次构建只要几分钟。

我有一回负责一个微服务项目，十几个服务各自一条管线。CircleCI 的并行能力帮了大忙，全量构建从 25 分钟压到了 8 分钟。嗯，这里要注意：免费版有并发限制，超出要付费。

GitHub Actions

GitHub 自家的 CI/CD 方案。它把 Actions 设计成“事件驱动”的：你 push 代码、提 PR、发布 release，都可以触发工作流。它的市场有成千上万个现成的 Action，比如部署到 AWS、发 Slack 通知，一行代码都不用写。

我经常用 actions/checkout 和 actions/setup-java 来配 Java 项目。简单配置示例：

name: CI Pipeline
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up JDK 11
        uses: actions/setup-java@v3
        with:
          java-version: '11'
      - run: mvn clean test

CI/CD 工具的选型建议

我个人的经验是：

• 初创团队、GitHub 重度用户 → 无脑选 GitHub Actions。成本低，集成快。
• 企业内部、已有 GitLab 实例 → GitLab CI。自托管 Runner 安全可控。
• 复杂环境、需要高度定制 → Jenkins + Kubernetes。虽然累，但上限高。
• 追求速度、并行跑任务 → CircleCI。缓存和并行是真香。

工具只是手段，不是目的。我见过有人花一个月折腾 Jenkins 插件，最后发现一个 .gitlab-ci.yml 就搞定了。所以，先想清楚你的痛点再选。

上面的流程图展示了从代码提交到部署的完整链路。注意最右侧的红色虚线回环——当部署失败时，日志分析就会介入。这正是本课程要教你做的事。