Developer Productivity Engineering Blog

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.

Changing one dependency declaration can have unexpected side effects through its transitive dependencies. For an example of tightly-coupled dependencies, let’s look at a simple Spring Boot project with the following build.gradle file.

Have you ever had an infrastructure failure break your build, or perhaps been forced to stop working in order to fix broken build configuration? Changes to development infrastructure often happen unbeknownst to the engineers it serves. Many problems go unreported, but chip away at our productivity much more than we realize. It is important to identify and stop non-verification failures (those not caused by routine development, such as compile and test failures) before they disrupt your organization. To combat this, we are pleased to introduce new failure analysis tools.

Do you ever watch your IDE sync or build run and think to yourself: “This is slow. I think this used to be much faster”? I do, more often than I’d like to admit.

Build logic can grow as complex as application logic and because of that good tooling is key for a productive build-logic authoring and maintenance experience. In this webinar, Paul Merlin and Rodrigo B. de Oliveira from Gradle explain how the Gradle Kotlin DSL leverages the Kotlin language and its great tooling to provide just that.

Whether you use a mono-repository or multi-repository approach for your sources, managing dependencies is central to productivity by reusing artifacts and ensuring a quality build.