Attention Maven and Gradle Users: The Next Introduction to DevPod Engineering Workshop is on September 30 (9:00AM-12:30PM PT). Register Now!
Reduce Build & Test Times
Up to 90% Instantly with
Build Cache & Distributed Testing
Up to 90% Instantly with
Gradle Enterprise build and test acceleration technologies address the pain of unnecessary developer idle time waiting for builds and tests to complete. This results in happier, more productive developers, and faster feedback cycles.
Benefits of Faster Feedback Cycles
Increased Developer Productivity
Fast feedback cycles are important to productivity since developers spend less idle time waiting for builds to complete. There is also less impact to the creative process. This means that since builds complete quickly, developers are less tempted to pay the context-switching cost of starting and stopping other tasks and activities.
Less Difficulty Troubleshooting
Faster feedback cycles will change developer behavior in other positive ways, including encouraging developers to run builds and tests more often rather than pushing quality checks to later stages of the development cycle. Building more often means developers spend less time debugging problems that occur from compounding changesets. Another benefit of smaller changesets is the lower likelihood of merge conflicts and stale feature branches and pull requests.
Higher Quality Software
Building and testing more often is also safer because there is less chance of defects passing through quality gates, and companies aren’t tempted to cut corners like turning off tests and other safety measures in order to ship faster.
Build Cache allows you to share and reuse unchanged build and test outputs across the team. This speeds up local and CI builds since cycles are not wasted re-building components that are unaffected by new code changes. Gradle Enterprise Build Cache supports both Gradle and Maven build tool environments.
Auto-provision multiple cache nodes with replication for distributed teams.
Out of the Box
Set up remote caches quickly with self-management capabilities.
Leverage aggregate data insights to operationalize build at scale.
Auditing & Tuning
Use in combination with Build Scans to audit and tune builds continually.
Access and export cache activity for every build with a complete API.
Set specific team action control, cache eviction policies and more.
Often when developers say their builds are slow, they really mean their tests are slow or they believe their builds are fine, but their tests are slow. Either way test time is often the key driver of build times. There are many factors that contribute to test time including the growing number of integration and functional tests to cover a wide range of inputs, running tests sequentially, and dependencies on expensive external services.
Distributed Testing is an approach that accelerates test execution and complements build caching while addressing many of the limitations of single-machine parallelism and CI fanout. And it gets around limitations in the number of parallel forks dictated by a single machine’s CPU and memory resources. It does this by extending test parallelism by fanning out test execution to remote executors.
The Gradle Enterprise extension for the Maven & Gradle build tool coordinates partitioning of the test set and collection of results, while Gradle Enterprise requests and caches test inputs, executes tests, and reports results back to the build tool for storage, all that with a low overhead that allows for fine-grained distribution.
- Build Caching is great in many cases but doesn’t help when test inputs have changed.
- Single machine parallelism is limited by that machine’s resources.
- CI fanout does not help during local development, is inefficient (in particular on ephemeral CI agents or without build cache), requires manual setup and test partitioning, and causes disjoint test reporting.
Uses single-machine parallelism when no agents are available or in combination with remote agents (ensures distributed testing will never be slower)
Requires a simple change to the build configuration to enable
Partitions test sets automatically
Works for local and CI builds
Shows the results of all tests via test reports and build scans
Makes Information about used agents available in the build scan
Transfers and merges outputs back to the build automatically (e.g. JaCoCo)
Allows running a subset of tests on specific agents based on requirements specified in the build configuration (e.g. certain tests should only run on agents with a specific OS)
Runs on-premise inside your own network infrastructure
Performance Profiling is the analytics capability associated with the Gradle Enterprise Build Cache and Distributed Testing solutions. It sets up easily and scales to the largest builds on the planet.
It leverages Build Scans and the Build & Test Performance Trends dashboard to give build engineers the insights to continually audit and tune build and cache performance.
For example, the Build & Test Performance Trends dashboard allows you to filter for and discover builds with specific performance characteristics or anomalies like builds with slow dependency download times, bad parallelism or low cache effectiveness. The associated Build Scan then allows you to determine the root cause of these anomalies. For example, the build scan can help you determine whether a high dependency download time is caused by a network bandwidth constraint or a high level of data traffic.
Use the trends to know when your Maven or Gradle builds are slow and the performance dashboard to understand why.