Developer Productivity Engineering Blog

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. 

Develocity 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 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:

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 Develocity. 

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 Develocity 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.

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+.

Season 1 of DevProdEng Showdown is well underway with three episodes that have been viewed live or on-demand by over 6,000 viewers since our pilot episode aired in January. You can register for Episode 4 which takes place Wednesday, May 26, 2021 (10am SF, 1pm NY, 6pm London, 7pm Berlin). The topic is “Android Architecture and Developer Productivity Engineering at Scale.”

In this guest post, Roger Taracha, senior Android engineer at Premise Data, shares his company’s experience using build-cache node replication to serve their distributed teams across the globe. Roger begins with a conceptual recap of the Gradle Build Cache, its benefits, and general installation/configuratIon considerations. He then outlines the key benefits of node replication and the setup and configuration process (including connecting to Develocity). Roger closes by sharing the inner workings of the Gradle build script solution that optimizes replicated node selection for local developer performance.