Gradle Enterprise 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 Gradle Enterprise 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 Gradle Enterprise 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 Gradle Enterprise 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 Gradle Enterprise and some of the build troubleshooting best practices Aurimas shared in his talk.
Each Gradle Enterprise 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 Gradle Enterprise 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 Gradle Enterprise 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.
Gradle Enterprise 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 Gradle Enterprise customer.
Did you know that Gradle Enterprise 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 Gradle Enterprise Maven extension 1.4+.
A modern and productive development environment should include both binary repositories and build caches.
So, you have heard a lot of great things about Gradle Enterprise and you are thinking about doing a trial. Now what?
In our recent webcast, a former SoundCloud developer productivity engineer who has been through the trial experience answered your key questions about Gradle Enterprise trials.
Minimizing software build and test feedback cycles has several obvious positive effect on engineering behaviors. This article untangles the cause and effect relationship with other indirect benefits you may have not considered.
