Developer Productivity Engineering Blog

In Gradle Enterprise 2020.5 we’ve added the missing piece to our testing product for Maven: Distributed Testing (available for Gradle builds since Gradle Enterprise 2020.2). In this blog post, we’re going to connect the build of the Eclipse Jetty open source project to Gradle Enterprise. We will demonstrate how Distributed Testing and Build Caching – with very little effort – reduce the total build time from over 50 minutes to about 15 minutes for a typical code change. We will also discuss potential options for reducing build time even further by optimizing the build for Distributed Testing.

Gradle Enterprise 2020.2 features Distributed Testing for Gradle builds. We have compiled this list of FAQs to supplement the information shared in our webcast: Gradle Enterprise Unveils Distributed Testing.

Gradle Enterprise 2020.2 introduces a major new feature: Distributed Testing. Gradle Enterprise Distributed Testing executes your existing test suites faster by fanning out test execution to as many machines as you provide.

Just like failing tests, flaky tests indicate that something might be wrong with the user-facing behavior of your product. It is important to track and fix them as soon as possible. Gradle Enterprise 2020.2 features test analysis improvements that streamline test debugging and root cause identification.

Dependency issues are frustrating. The rules are complex and without the right data, determining exactly what caused the issue can take time and energy. The new dependency visualization feature in build scans can help.

Does your team suffer from long feedback times because of slow running tests? Does your CI pipeline spend several hours executing integration and system tests?

Having these tests is important but once running them takes longer than a few minutes, developers will push execution to later stages of the development cycle leading to longer feedback times. Shortening feedback cycles can save teams lots of time because there are fewer interruptions to the creative process, developers spend less time waiting for each individual build, and they spend less time debugging problems that occur from compounding changesets.

A fast and efficient CI pipeline can make or break your team’s developer experience and productivity. But what are the biggest determinants of CI pipeline performance? How do CI platform infrastructure and build/test performance impact each other and where should you focus your efforts?

Gradle 6.0 is the culmination of several years of innovative improvements in Dependency Management. Embracing the idea that there is more to software composition and reuse than just putting a set of jar files on the classpath, Gradle now offers a new metadata format to richly define software components that are often made up of multiple files, different variants and specific constraints on their dependencies.

Testing takes the overwhelming majority of time during software builds. A single test can waste countless hours of building time — a single failure may cause an entire CI pipeline to have to be re-run. Ugh.

In this post, I will show you how to identify slow and unstable tests using the new Tests Dashboard in Gradle Enterprise 2019.4 for Gradle and Maven builds. The dashboard visualizes test results across many builds for tests executed by Gradle’s built-in Test task and Maven’s SureFire plugin.

Although ephemeral builds can be nice to test changes in isolation, there are trade-offs for doing so. One of those trade-offs is dependency download times.

In Gradle Enterprise 2019.3, the dependency download metrics in the performance and trends dashboards can be used to look at dependency download times and debug issues. For example, let’s look at the dependency download times for the Gradle project itself for all builds run in the last four weeks.