Discover the only event dedicated to Developer Productivity Engineering and Developer Experience—September 24-25 in San Francisco.
Reduce build time from 50-90% Instantly with
Build Cache
Build Cache speeds up local and CI builds by allowing you to share and reuse unchanged build and test outputs across the team and ensures your build does not waste cycle time re-building components that are unaffected by new code changes. Develocity Build Cache supports Gradle and Maven build tools.
Build Cache Overview
A build cache client and local build cache was introduced to the Open Source/Java world by Gradle in 2017 to speed up local feedback cycles for developers that use the Gradle Build Tool. Soon after Develocity added support for a remote build cache backend. Since 2019 the Develocity Maven extension has provided a complete Build Cache solution for Maven build tool users (including a Maven client, local build cache, and remote build cache backend). Support for the Google Bazel build system was introduced in 2023. Leveraging the in-depth observability provided by Build Scans, Develocity remote build cache provides an enterprise-grade scalable backend that ensures that the maximum performance benefits of build caching can be realized. Together with Develocity performance profiling and analytic capabilities, it is easy to discover inefficiencies, identify optimization opportunities, and troubleshoot efficiently.
A build cache is very different and complementary to the concept of a binary repository (sometimes referred to as a dependency cache or artifact repository). Whereas a binary repository is for caching binaries that represent dependencies from one source repository to another, a build cache caches build actions, like Gradle tasks or Maven goals. A build cache makes building a single source repository faster.
When the build action inputs have not changed, the output can be reused from a previous run. Build caching can be applied to build actions like compilation, testing, source code generation, Javadoc, checkstyle, PMD. Build caching works out of the box for many standard Gradle tasks and Maven goals. For Maven goals or Gradle tasks that are not pre-configured to be cacheable, there is a cache configuration DSL available. That way custom build actions are also cacheable.
The typical use case is to let CI builds push to a distributed remote build cache, and allow other CI builds as well as developer builds to pull from it. A local build cache is also available to reuse outputs produced earlier on the same machine.
Because Build Cache supports local, remote, and CI builds, it is used to not only improve developer productivity, but also cloud costs and resource consumption efficiency.
Key Build Cache Technology Benefits
Faster build and test feedback cycles
By eliminating redundant work Gradle build times are often cut in half and Maven build times can be reduced by up to 90%.
Improved DevProd and developer experience
Minimizing build and test time makes developers more productive and happier since they spend less idle time waiting for feedback.
Higher quality software
Fast feedback cycles mean developers build more often and more frequently rather than pushing quality checks to later stages of the development cycle.
Key Build Cache Features
 |
 |
 |
| Easy to Deploy | Highly Observable Config and Performance Data | Build Cache Performance Dashboards |
| Deploy and operate a stateless cache with very little effort. Local caching is built into the Gradle Build Tool, and Docker, Kubernetes, and standalone JAR deployment options are available for remote cache nodes. | Use Build Scan to view Build Cache configuration settings and performance data for every local, remote, and CI build, such as cache requests, hits, misses, inputs stored to cache, and configuration settings. | Use Performance and Trends dashboards to continuously observe the Build Cache’s impact on your feedback cycle times and monitor for speed regressions that may require proactive remediation before developers are impacted and start to complain. |
 |
 |
 |
| Local, Remote & CI Builds | Multiple Build Tool Environments | Build Cache Miss Diagnostics |
| The Build Cache can accelerate builds in local, remote, and CI environments. Distributed teams can read from a reliable cache that is constantly being populated by CI. | Build Cache works for Gradle and Maven builds. Any JVM language that can be built by Gradle or Maven can benefit from caching, and task inputs and outputs can be optimized for the best possible performance. | Develocity task inputs comparison visualizes differences in inputs between tasks of two builds which can be used to identify the root cause of a cache miss. |
 |
 |
 |
| Multi-zone Replication | Automated Target Cache Size Management | Data Privacy & Access Control |
| Create highly-available replicating caches close to your distributed developers, optimizing bandwidth for faster access and faster builds. | Configure Build Cache to use as much space as available on the disk to store cache objects, avoiding the need to synchronize the storage volume size with a target cache size. | Transport Build Scan data between the build environment and Develocity using SSL/TLS encryption and use an ACL model to prevent unauthorized access to the cache. |
Build Cache & Binary Repositories
A modern and productive development environment should include both binary repositories and build caches because they are complementary. Because they share the goal of making the build process more efficient and because certain features overlap, it is not uncommon to assume that both address the same issues. Learn more about how Build Cache differs from binary repositories here.
Case Study: Build Cache Results for the Spring Boot Project
Here are the initial results experienced by the Spring Boot project for compile and unit tests after leveraging Build Cache. They have been continuously improved since the early results were reported in a blog published by Andy Wilkinson in 2020. You can monitor the project’s progress in real time by checking out their Develocity public instance.
For this snapshot in time, the Spring Boot project has 270K lines of codes and 86 subprojects. Compiling and running the unit tests with Maven takes 20:25 minutes. With Develocity, out of the box, the build time when fully cached improves by a factor of 6 or to 16.5% of the original build time. With some optimization to the configuration of the build, build time improves further to 13.6% of the original build time. Today, build time savings have been reduced by another order of magnitude.
Combine Build Cache with Other Performance Acceleration Technologies for a Force-Multiplier Effect
- Build Cache. Avoid unnecessarily running components of builds and tests whose inputs have not changed.
- Predictive Test Selection. Run only tests that are likely to provide useful feedback using machine learning.
- Test Distribution. Run the necessary and relevant remaining tests in parallel to minimize build time.
- Performance Continuity. Sustain Test Distribution and other performance improvements over time with data analytic and performance profiling capabilities.
