Roberto Perez Alcolea of the Netflix JVM Ecosystem team recently shared some of his team’s use cases and best practices for using Gradle Enterprise to manage Gradle plugins in their builds. The Nebula project itself is a set of Gradle plugins that eliminate boilerplate build logic and provide sane conventions for simplifying build scripts.
At Netflix, improving developer happiness is a goal of paramount importance since it is highly correlated with developer productivity. Netflix Engineering has experienced significant benefits from their investments in improving the developer experience and productivity by using automation, tools and data rather than by management decree and best practices. This article highlights their success using Test Distribution to speed up test cycles by over 12X and provides many other productivity insights.
This summer the Gradle Team provisioned a Gradle Enterprise instance for the Micrometer open-source project and helped us a lot in optimizing our Micrometer build. Micrometer’s build has been enjoying the advantages of the Gradle Build Tool since the inception of the project. Introducing Gradle Enterprise has led to a significant number of improvements to the team’s developer productivity.
Gradle Inc. announced recently that it closed a $27 million Series C funding round doubling its venture capital investment haul to almost $55 million. This round represents a significant endorsement by the venture community of the emerging software practice called Developer Productivity Engineering (DPE). DPE takes an engineering approach — rather than a people management approach — to solving developer productivity challenges and improving the developer experience.
Gradle Enterprise is positioned as a key enabling technology for DPE and the only technology that provides an end-to-end solution. To date venture firms investing in DPE include Bain Capital Partners, DCVC, Harmony Partners, Triangle Peak Partners, StepStone Group, and True Ventures.
What does the smart money see in DPE?
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:
Test Distribution is an approach that accelerates test execution and complements build caching while addressing many of the limitations of single-machine parallelism and CI fanout. It does this by extending test parallelism which farms out test execution to remote executors. Along with Build Cache, it is one of the major build and test acceleration features available in Gradle Enterprise.
We caught up with Cedric Champeau, consulting member of the technical staff at Oracle, a former engineer on the Gradle Build Tool core team and a Groovy committer, to ask him about his experience with Test Distribution (TD) while working on the Gradle Build Tool open source project.
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.
In Gradle Enterprise 2021.2 we’ve added support to auto scale agents when using an elastic compute platform based on demand for how many tests there are to run. In this blog post, we’re going to show you how easy this is to set up in a Kubernetes cluster, and show how test execution times of both Gradle and Maven builds are affected in different usage scenarios.
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.
