4、持续集成/持续部署（CI/CD）：Jenkins、GitLab CI、GitHub Actions的配置与优化，流水线并行化

4.1 为什么CI/CD是效率提升的「发动机」

说实话，我见过太多团队把CI/CD当成「自动编译工具」在用。这太可惜了。

CI/CD的核心价值，不是帮你省掉敲命令的时间。它解决的是「反馈延迟」问题。你想想看，一个功能从写完到上线，如果中间要等两天才能知道有没有问题，那开发节奏就彻底断了。

我个人习惯把CI/CD看作「质量门禁」+「自动化流水线」的结合体。它不只是跑个测试，而是让每一次代码提交都能快速得到反馈——哪里错了、性能有没有退化、能不能直接部署。

嗯，这里要注意：工具只是载体，真正提升效率的是流水线的设计思路。

4.2 Jenkins：老牌工具，灵活但需要「伺候」

Jenkins我用了很多年。它最大的优点是插件生态丰富，几乎什么都能做。但缺点也很明显——配置复杂，维护成本高。

4.2.1 Jenkins Pipeline 基础配置

Jenkins支持两种Pipeline写法：Declarative（声明式）和Scripted（脚本式）。我推荐用Declarative，结构清晰，容易维护。

// Jenkinsfile - Declarative Pipeline
pipeline {
    agent any
    
    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }
        stage('Build') {
            steps {
                sh 'mvn clean package'
            }
        }
        stage('Test') {
            steps {
                sh 'mvn test'
            }
        }
        stage('Deploy') {
            steps {
                sh 'scp target/*.jar user@server:/app/'
            }
        }
    }
}

这段代码看着简单，但实际项目中要复杂得多。我建议把每个stage拆成独立的脚本文件，方便复用。

4.2.2 Jenkins 优化技巧

• 使用共享库：把通用的逻辑（比如发通知、打镜像）提取成共享库，避免每个项目重复写
• 限制并发：Jenkins默认不限制并发，容易把服务器跑崩。用throttleConcurrents插件控制
• 清理工作空间：每次构建后清理临时文件，不然磁盘很快会满

4.3 GitLab CI：与代码仓库深度集成

GitLab CI是我现在最常用的工具。为什么？因为它和GitLab仓库是「一家人」，配置都在同一个仓库里，管理起来特别方便。

说白了，GitLab CI的核心就是.gitlab-ci.yml文件。你把它放在项目根目录，GitLab就会自动识别并执行。

4.3.1 GitLab CI 基础配置

# .gitlab-ci.yml
stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  script:
    - echo "Building the application..."
    - mvn clean package
  artifacts:
    paths:
      - target/*.jar

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

deploy-job:
  stage: deploy
  script:
    - echo "Deploying to production..."
    - scp target/*.jar user@server:/app/
  only:
    - main

这里有个关键点：artifacts。它能把构建产物传递给后续的job。我在项目中遇到过一个问题——测试阶段重新编译了一次，导致构建和测试用的不是同一份代码。用artifacts就能避免这个问题。

4.3.2 GitLab CI 优化技巧

• 使用缓存：Maven的.m2目录、npm的node_modules都可以缓存，能省下大量时间
• 并行执行：测试阶段可以拆成多个job并行跑，比如单元测试和集成测试分开
• 使用Runner标签：不同的job可以指定不同的Runner，比如构建用大内存的Runner，测试用普通Runner

4.4 GitHub Actions：云原生时代的CI/CD

GitHub Actions是后来者，但发展很快。它的优势在于「开箱即用」——不需要自己搭建服务器，GitHub帮你托管Runner。

我个人觉得，GitHub Actions最适合开源项目和小团队。配置简单，社区有大量现成的Action可以直接用。

4.4.1 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@v3
    
    - name: Set up JDK 17
      uses: actions/setup-java@v3
      with:
        java-version: '17'
        
    - name: Build with Maven
      run: mvn clean package
      
    - name: Run tests
      run: mvn test
      
    - name: Upload artifact
      uses: actions/upload-artifact@v3
      with:
        name: app-jar
        path: target/*.jar

你看，GitHub Actions的语法很直观。每个step就是一个动作，可以是用社区现成的Action，也可以是自定义的命令。

4.4.2 GitHub Actions 优化技巧

• 矩阵构建：一次跑多个版本的测试（比如Java 11、17、21），用matrix策略
• 缓存依赖：用actions/cache缓存Maven或npm的依赖
• 条件执行：只有特定分支或标签才触发部署，避免误操作

4.5 流水线并行化：让时间「折叠」

流水线并行化是提升效率最直接的手段。说白了，就是把能同时做的事情放在一起做。

举个例子：一个项目有单元测试、集成测试、代码风格检查、安全扫描。如果串行执行，可能要跑30分钟。但如果并行执行，可能只需要10分钟。

4.5.1 并行化的三种模式

模式	说明	适用场景
阶段内并行	同一个stage内的多个job同时执行	测试、代码检查
阶段间并行	不同stage之间部分重叠执行	构建和测试同时进行
矩阵并行	同一份代码在不同环境下同时测试	多版本兼容性测试

4.5.2 并行化的注意事项

嗯，这里要提醒一下：并行化不是万能的。我在项目中遇到过一个问题——并行job太多，把Runner的资源占满了，反而导致每个job都跑得很慢。

• 控制并发数：根据Runner的CPU和内存合理设置
• 避免资源竞争：多个job同时写同一个文件会出问题
• 合理拆分粒度：不是拆得越细越好，太细会增加调度开销

4.6 工具选型建议

最后，我聊聊怎么选工具。其实没有「最好」的工具，只有「最合适」的。

场景	推荐工具	理由
企业内部、已有Jenkins	Jenkins	插件丰富，定制能力强
使用GitLab管理代码	GitLab CI	集成度高，配置简单
开源项目、小团队	GitHub Actions	免费、开箱即用、社区活跃
需要复杂流水线	Jenkins + GitLab CI	Jenkins做编排，GitLab CI做执行

我个人习惯是：新项目优先用GitLab CI或GitHub Actions。只有遇到特别复杂的场景（比如需要自定义插件、对接老旧系统），我才会考虑Jenkins。

记住一点：工具是手段，不是目的。真正提升效率的，是你对流水线的设计和持续优化。