4. 常见的CI工具简介

做CI这么多年，我先后用过Jenkins、GitLab CI、GitHub Actions，还有Travis CI、CircleCI这些。说实话，每个工具都有自己的脾气。选对了，事半功倍；选错了，天天跟配置打架。这一章，我就聊聊这三款主流工具的核心玩法，以及我个人踩过的坑。

4.1 Jenkins：老当益壮的“瑞士军刀”

Jenkins，老牌CI工具了。它本质就是一个Java Servlet容器，通过插件体系扩展功能。我最早接触CI就是Jenkins，那时候还在用ant脚本打包。
核心特点：插件丰富（超过1500个）、高度可定制、支持分布式构建（Master/Agent模式）。

它的问题也很明显：配置繁琐，每个任务的参数散落在UI里，很难做到“配置即代码”。后来大家用Jenkins Pipeline（Declarative或Scripted）才稍微好点。

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                sh 'mvn clean package'
            }
        }
        stage('Test') {
            steps {
                sh 'mvn test'
            }
        }
        stage('Deploy') {
            steps {
                sh 'scp target/*.war user@host:/deploy'
            }
        }
    }
}

避坑指南：我曾经在一个Jenkins Master上装了150个插件，结果启动慢得吓人，动不动OOM。后来我学乖了——只装真正需要的插件，而且定期清理不用的。另外，Jenkins的凭证管理要用Credentials插件，别把密码写在Jenkinsfile里。

4.2 GitLab CI：一体化DevOps平台

GitLab CI把CI/CD深度集成到了代码仓库里。你只要在项目根目录放一个.gitlab-ci.yml，定义几个Stage，GitLab就能自动帮你跑起来。我特别喜欢它的Runner架构——可以共享Runner，也可以自己注册专用Runner。

说实话，GitLab CI的配置文件比Jenkins Pipeline更简洁。它采用Pipeline → Stage → Job三层模型，天然适合微服务场景。

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  script:
    - mvn clean package

test-job:
  stage: test
  script:
    - mvn test

deploy-job:
  stage: deploy
  script:
    - scp target/*.war user@host:/deploy
  only:
    - main

另外，GitLab CI的Runner需要提前配置好executor。我推荐用Docker executor，每次构建都从干净环境开始，避免“在我的机器上好好的”这种尴尬。

4.3 GitHub Actions：开源社区的“新宠”

GitHub Actions是后来者，但发展速度惊人。它的核心概念是Workflow，一个Workflow包含多个job，每个job在独立的runner中运行。事件驱动机制非常灵活——你可以指定在push、PR、issue comment甚至定时触发。

为什么我喜欢它？因为Actions Marketplace里有大量现成的action，比如checkout、setup-node、upload-artifact。你根本不用自己写安装脚本，直接引用就行。

name: CI Workflow
on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Build
        run: mvn clean package
      - name: Test
        run: mvn test
      - name: Upload artifact
        uses: actions/upload-artifact@v3
        with:
          name: package
          path: target/*.war

还有个细节：Actions的日志搜索比Jenkins弱，排查失败时最好在step里加--verbose或set -x。

4.4 如何选择？一张表说清楚

这三款工具没有的好坏。我一般这么看——

你想想看，如果你的团队已经深度使用GitLab仓库，那就没必要硬上Jenkins。反过来，如果要做跨仓库、按需定制的复杂流水线，Jenkins还是不可替代的。GitHub Actions则最适合在GitHub上做开源项目，或者配合GitHub Pages、Release等功能一气呵成。

4.5 我最推荐的实践路线

1. 如果团队小、仓库少：直接用GitLab CI或GitHub Actions，省去维护Jenkins Master的精力。
2. 如果历史包袱重、已有Jenkins：别急着全盘迁移，先用Pipeline做配置即代码，再考虑逐步替换。
3. 关键指标：每次构建的时间、失败率、平均修复时长。工具只是手段，目标是快速反馈。