Gradle Enterprise 2017.7

New build cache replication enables faster builds,
by allowing build cache nodes to be installed closer to developers.
New quick navigation in build scans makes it faster to get to the section you want,
by simply typing where you want to go.

The bandwidth and latency of the network link between a build and a build cache significantly affects build performance.
New replication capabilities allow users to use a cache node that they have a better network link to,
while reusing artifacts from another cache node that is further away.
This is particular effective for geographically distributed teams.

If a cache node receives a request for a cache item it does not have but its replication source does, it will take a copy of it and then serve it.
This initial request may not be faster than using the replication source directly, but subsequent requests by all nodes with the given replication source will be faster.

A typical arrangement is to have continuous integration builds push to a cache node on a local network,
and have other nodes used by developers in different locations,
ideally on their local network,
use it as their replication source.

The potential performance benefits depend considerably on the specific network environment and build.
Using a cache node via a local network connection is profoundly faster than via an Internet connection.
Just using a cache node over the Internet that is physically closer can be a significant improvement,
due to the decreased latency.

The performance section of a build scan illuminates different aspects of the build that contribute to the speed of the build,
and is particularly useful when optimizing or debugging performance problems.
Optimizing and debugging are often collaborative endeavors and it is helpful to share the performance information within a build scan with others.

In order to make this more efficient, it is now possible to focus on any item within this section,
by clicking the icon displayed when hovering over an item.

Focussing visually highlights the item, and updates the browser's location to convey this focus.
When sharing the current page URL with colleagues, they will see the same focus upon following the link
and immediately see exactly what it was you wanted them to see.

If upgrading from a version of Gradle Enterprise prior to 2017.6,
be sure to also consult the release notes for all interim versions.

Post install downtime

This release includes database migrations that may take some time to perform when restarting Gradle Enterprise for the first time after upgrading.

All large installations should plan a downtime of between 15 and 30 minutes.
Moderately sized installations will require less downtime.
Users making heavy use of the build cache should plan for a longer downtime, of up to 1 hour.

Upgrading remote cache nodes

This version of Gradle Enterprise adds support for version 3.0 of the remote cache node.
While existing remote cache nodes will continue to function,
upgrading all existing remote nodes is strongly recommended.