持续集成与Gradle：CI环境配置、缓存共享、并行构建、Gradle Enterprise集成

聊到持续集成，很多团队其实只做到了「持续编译」。我见过不少项目，CI上跑一次构建要四十分钟，开发等结果等到花儿都谢了。说白了，Gradle在CI环境里的表现，很大程度上取决于你怎么配置它。今天我就把这几年的实战经验掰开揉碎，跟你聊聊CI环境下的Gradle最佳实践。

CI环境的基础配置

先说说最基础的东西。你在本地跑构建和CI上跑构建，其实是两码事。本地有IDE缓存，有Gradle守护进程，有你的个人习惯。但CI环境是干净的，每次都是从头开始。

我个人习惯在CI脚本里这样配置Gradle参数：

# 禁用守护进程，避免CI容器残留
export GRADLE_OPTS="-Dorg.gradle.daemon=false"

# 明确指定JVM参数
org.gradle.jvmargs=-Xmx2048m -XX:MaxMetaspaceSize=512m

# 开启并行构建
org.gradle.parallel=true

# 开启构建缓存
org.gradle.caching=true

嗯，这里要注意：守护进程在CI里一定要关掉。我曾经遇到过CI节点上守护进程没清理干净，导致后续构建使用了错误的缓存状态，排查了半天才发现是这个问题。

缓存共享：别再重复编译了

缓存共享是CI提速的大杀器。你想想看，团队里十个人，每个人都在本地编译同样的依赖库，每次CI也要重新编译——这得浪费多少时间？

Gradle的构建缓存可以跨机器共享。我推荐用以下几种方式：

• 本地文件缓存：适合单机CI，简单直接
• HTTP远程缓存：适合团队共享，用Nginx或Artifactory搭建
• Gradle Enterprise缓存：企业级方案，自带管理界面

配置远程缓存其实很简单：

// settings.gradle
buildCache {
    remote(HttpBuildCache) {
        url = 'https://cache.example.com/cache/'
        push = true
        credentials {
            username = 'cache-user'
            password = 'cache-pass'
        }
    }
}

并行构建：让CPU跑满

Gradle的并行构建分两个层面：项目并行和任务并行。说白了，就是让多核CPU物尽其用。

我一般这样配置：

// gradle.properties
org.gradle.parallel=true
org.gradle.workers.max=4

但并行不是万能的。我遇到过一种情况：项目有几十个子模块，依赖关系错综复杂，并行构建反而因为任务调度开销变慢了。这时候就需要分析依赖图，看看哪些模块可以真正并行。

用这个命令可以查看任务依赖：

gradle build --scan

它会生成一个构建扫描报告，里面清清楚楚地展示了哪些任务在并行执行，哪些在等待。我个人习惯每周跑一次扫描，看看构建效率有没有退化。

Gradle Enterprise：企业级构建管理

说到Gradle Enterprise，它不只是个缓存服务器。它更像是一个构建的「黑匣子记录仪」。我参与过的一个大型项目，构建时间从45分钟优化到12分钟，全靠Gradle Enterprise的分析功能。

它的核心能力包括：

功能	说明	我的使用心得
构建扫描	记录每次构建的详细信息	用来定位性能瓶颈，比如某个task突然变慢
缓存分析	查看缓存命中率	命中率低于80%就要检查配置了
失败分析	自动归类构建失败原因	帮我们发现了测试环境配置不一致的问题
测试分析	追踪测试执行时间和稳定性	Flaky测试一目了然

集成Gradle Enterprise只需要在settings.gradle里加几行配置：

plugins {
    id 'com.gradle.enterprise' version '3.12'
}

gradleEnterprise {
    server = 'https://enterprise.example.com'
    buildScan {
        publishAlways()
        uploadInBackground = false
    }
}

知识体系总览

下面这张图把CI环境下Gradle的核心配置串起来了，你可以对照着检查自己的项目：

你看，这四个方面环环相扣。环境配置是基础，缓存共享解决重复劳动，并行构建压榨硬件性能，Gradle Enterprise提供全局视野。少了任何一个环节，CI体验都会打折扣。

最后说一句：CI配置不是一劳永逸的。项目在变，依赖在变，构建模式也在变。我建议每两个月审视一次CI配置，看看有没有新的优化空间。毕竟，开发者的时间不应该浪费在等构建上。