We have recently started using the Develocity tool for our builds. I really love it. It is a build acceleration tool made by the company who create Gradle. It was previously called Gradle Enterprise, but has been renamed to make clear that it works for both Maven and Gradle. It offers these features:
- Metrics for every build, showing what tasks were performed and how long each one took.
- Remote caching.
- Test distribution
- Predictive test selection. e.g. only run reduced test set on feature branches
- Test Failure Analytics e.g. dashboard, flaky test auto retrys
It works for BOTH CI and local builds. So if code has previously built on your CI server and the results from each task stored in the remote cache, local dev builds will not have to repeat all tasks! However work may be required for remote caching to be available – tasks results can only be cached if the task has correctly defined inputs. But using Develocity makes it a lot easier to check your tasks and understand if they need changes to make them cacheable.
The front page of Develocity shows your list of builds (click images to expand):
Click on a build to see a summary:
Then you can see a list of tasks, which you can order by longest task, so you can start optimising:
The performance tabs show you cache usage, so you can figure out if tasks aren’t being retrieved from cache correctly:
If you look at the build list, you will see there is a really nice example of a build running quickly because most tasks were retrieved from cache:
The first build took 28 minutes, the second build, which only had to rebuild a couple of modules, took 2 minutes!
For more info on Develocity, see:
Or if you would like to read more about how to fix a Gradle task that cannot be cached, see the post I wrote when we were implementing Develocity. For tasks to be cacheable, they first have to be incremental – have correctly defined inputs and outputs: