Developer Productivity Engineering Blog

Gradle is happy to announce a technical partnership with GitHub focusing on multiple areas, starting with supply chain security and developer experience. With this partnership, we establish a direct connection between organizations and plan to cooperate on integrations between GitHub and Gradle to promote best security practices among Gradle users.

Connecting hundreds or thousands of projects to Develocity (formerly Gradle Enterprise) for the first time can be challenging. The canonical way requires modifying the existing build configuration settings, which is not easily done at scale. This document explains how to use OpenRewrite from Moderne to create pull requests that will update all repositories at once.

Develocity provides a complete look at the build system, its performance, and individual build details. We recently had a build cache node crash that was impacting build times. In this post, we’ll go through the information Develocity generated before, during, and after the build cache node crash that made it easy to determine this was the cause of the slow build performance problem.

Earlier this year, Aurimas Liutikas from the Google AndroidX team joined our DPE Lowdown webcast to talk about how Develocity has helped them troubleshoot build and test failures faster in their GitHub Actions CI environment. Since then, we’ve heard from many companies that already use or plan to adopt GitHub Actions as their CI solution and want to understand how Gradle Build Tool and Develocity fit into the CI build experience. In this post, we will cover the official Gradle Build GitHub action that the AndroidX team is using to integrate with Develocity and some of the build troubleshooting best practices Aurimas shared in his talk.

Each Develocity engineering project team is responsible for monitoring their own flaky tests. When enough flaky tests have accumulated in the test suite, the team meets for a ‘Flaky Test Day’ to identify and fix flaky tests. In this post, we explain the importance of having flaky test days, when to schedule them and some of the Develocity development team’s favorite best practices for identifying, prioritizing and fixing flaky tests.

The software landscape is fragmented and specialized and will continue to remain so.  Developers have their own beloved tools for development, builds, testing, and so on. Often referred to as a tyranny of choice, this fragmentation is becoming increasingly intentional, especially among the ever-blooming open source development landscape.

Fighting this trend is more often than not a boondoggle for organizations, and ultimately, standardization can even lead to anti-patterns.  Realizing this, how can you promote developer productivity in your company if you have the common pattern of a polyglot build system environment?  Our own Develocity Front End team has implemented both the practice and toolchain, and have seen impressive results:

A test is “flaky” whenever it can produce both “passing” and “failing” results for the same code. Test flakiness is a bit like having diabetes. It’s a chronic condition you can never fully cure and put behind you. Even if only 0.1% of your tests are flaky, with thousands of tests you can have problems with a considerable portion of your builds. This is common to even medium-sized development teams. Left unmanaged flaky tests can render a body (or body of tests) severely damaged. But your prognosis is good if you continually measure and act on the relevant health indicators.

Develocity Trends & Insights allows dev teams to respond proactively to systemic problems and longer-term performance regressions. It does this by providing a Trends Dashboard that makes key metrics and KPIs more observable and actionable. In this post, I share two simple but powerful tips for using trend data to interpret and evaluate build performance. I then demonstrate these principles by analyzing trends from an actual Develocity customer.

Did you know that Develocity Maven Build Scans now offers a Dependencies section that visualizes the resolved dependency graph used to form the classpaths for each module. It is available for every Maven captured build, without the need to invoke a specific Maven goal. Maven dependency resolution visualization requires Develocity Maven extension 1.4+.