Pain points
If the project has a large code base, such as a large Android development project, it takes a long time to build, reaching tens of minutes or even longer, analyze the reasons, and part of the time is spent building superior. In a large-scale development team, such as a development team with hundreds of people, if it takes tens of minutes for each person to build it once, the time that the team wastes every day is very staggering.
In addition to the build time, a large part of the time when executing Gradle Build is spent on the execution of unit test cases. This problem also plagues large-scale Gradle users.
Scheme
In order to increase the speed of the build, Gradle 4.0 and above provides the function of Build Cache, which is the build cache. Note that the build here does not refer to the build output, such as war, jar files, but the bytecode .class files built by Java. By caching the .class files generated by each build, the incremental compilation of Java projects is realized. The Gradle project can create a Key-value key-value pair data after the first build, and index each .class file through a key. These key-value pairs and .class files will be uploaded to a central server (such as Nginx or JFrog Artifactory). When the user builds again, or other members build, the cache file of the central server will be downloaded to the local and then packaged. This can greatly reduce the compilation and build time and achieve incremental compilation.
Note that not only the .class files of software programs can be cached here, but the .class files generated by the corresponding unit test case compilation can also be cached.
Take the open source version of Artifactory as an example, combined with Gradle to achieve incremental compilation:
? Create an example project “gradle-cache-example”
In this Java project, you only need to create some common The Java class is sufficient, we will verify how to cache the corresponding class of this code later to save construction time.
To execute the build before setting the build cache: ./gradlew clean build
BUILD SUCCESSFUL in 11s
13 actionable tasks: 12 executed, 1 up-to-date
You can see the build It took 12 seconds.
? Build an open source version of Artifactory locally as a central server for building cache. The most convenient way to build the open source version of Artifactory is to start it with a container:
docker run –name artifactory -d -p 8081:8081 docker.bintray.io/jfrog/artifactory-oss:latest
? Set the build cache
Set the following configuration in the gradle.properties in the development local project file, and point the build cache to Artifactory.
gradle.properties
artifactory_user=admin
artifactory_password=password
artifactory_url=http://localhost:8081/artifactory
org.gradle.caching=true
gradle .cache.push=false
Set the settings.gradle on the CI server, the following is the Jenkins script:
include “shared”, “api”, “services:webservice”
ext. isPush = getProperty(‘gradle.cache.push’)
buildCache {
local {
enabled = false
}
remote(HttpBuildCache) {
url = “${artifactory_url} /gradle-cache-example/”
credentials {
username = “${artifactory_user}”
password = “${artifactory_password}”
}
push = isPush
}< br>}
Execute ./gradlew clean build -Pgradle.cache.push=true on the CI server. By setting gradle.cache.push=true, the local build cache is pushed to the central server.
BUILD SUCCESSFUL in 1s
13 actionable tasks: 7 executed, 5 from cache, 1 up-to-date
You can see that the build time has been reduced from 12 seconds to 1 second, of which 5 tasks are from the cache .
To confirm that our build acceleration does not come from the local cache, you can check the access log of Artifactory:
20170526153341|3|REQUEST|127.0.0.1|admin|GET|/gradle -cache-example/6dc9bb4c16381e32ca1f600b3060616f|HTTP/1.1|200|1146
20170526153341|4|REQUEST|127.0.0.1|admin|GET|/gradle-cache-example/e5a67dca52dfaea60efd28654eb8ec97|HTTP/1.1|200|1296
You can see the local cache, all from the unified warehouse of Artifactory.
? Cross-departmental, geographically shared build cache
In a large distributed R&D team, the build environment is often distributed in various regions, such as Beijing and Shanghai. In this case, after the build cache is uploaded to the local Artifactory, it cannot be used by the remote build server. This is achieved by using the real-time file copy function of Artifactory Enterprise Edition. 
As shown in the figure above: When a local developer or CI server executes the first build, Artifactory will push the local cache to the remote Artifactory through Push Replication. When the remote user is executing Gradle When building, it can benefit from the existing build cache, which greatly accelerates the speed of the build.
Summary This article shows and explains how to use Gradle and Artifactory open source version to implement the build cache and improve the build speed. Using Artifactory Enterprise Edition can realize cross-regional construction cache sharing and optimize company-level construction speed.