Ideas & Insights
With the relentless growth in the number of developers, code bases, and repositories, most organizations—that track build and test performance trends and failure rates—declare victory if their metrics stay flat over time. This is because some level of regression is often the norm. Even more development teams can’t tell you how key metrics are trending over time because they are stuck in reactive mode—troubleshooting the most recent critical bug that is blocking development or mitigating the most impactful flaky test or performance glitch.
As a result, nothing is learned from these relatively tactical failures and little data is collected that would be helpful in resolving similar failures down the road because developers are consumed putting out fires. Thus, the key is to have tools in place that enable you to observe systemic longer-term performance regressions and respond proactively before users or customers start to complain. DPE best practices and tools enable this by providing data and insights that make key metrics and KPIs more observable and actionable. Moving forward these analytic capabilities form a platform for future advancements in DPE that will leverage machine learning and self-healing systems.
Expert Takes
I became frustrated with poor build reliability at a previous company I worked for and set out to do something about it. To start, we didn’t have much in the way of telemetry, especially for local developer environments. So the only signal available for prioritization was the intensity of complaints. But most developers did not complain and suffered in silence.
When I inquired about why this was happening I heard “Builds are slow and unreliable, that’s just how they are.” It was so accepted that the toolchain was going to waste your time and negatively impact your productivity that it wasn’t worth being a squeaky wheel..
The best developers want to be productive and do their best work on your organization’s most challenging problems. They may put up with sub-par tooling for a little while, but eventually they will leave for organizations that provide a more productive environment. Several developers did leave, citing a poor developer experience as one of their motivations. Once we successfully implemented data-driven methods, trust and confidence in the toolchain’s reliability improved markedly. I still wonder if we had started sooner how many of those valued colleagues might have stayed.
Technology News
Speeding up feedback when doing incremental builds, especially in the IDE, has been the key focus of the Gradle Build Tool team in recent months. Gradle 6.6 ships with a highly experimental opt-in for configuration cache. The new performance feature allows Gradle to skip the configuration phase entirely when nothing that affects the build configuration has changed, such as build scripts. It will also allow you to run more work in parallel and take advantage of other performance optimizations.
We’ve seen dramatic improvements in build times for early adopters and we are looking forward to rolling out this improvement more broadly. However, note that many community plugins and a number of core features are yet to be updated to be compatible with configuration cache.
See also the Configuration Caching Deep Dive from Android Studio Team blog posts.
Video of the Month
Maven builds are unnecessarily slow. This video explains in an in-depth, methodical way how the Gradle Enterprise Maven Build Cache speeds up Maven builds and tests up to 90%. It also introduces a mathematical model for quantifying the compelling productivity and financial benefits your organization will realize by achieving faster feedback cycles and more efficient use of compute resources. Finally, it elucidates the beneficial relationship between modularization, build speed and caching. The video is targeted at developers interested in making their teams more productive and for Build/CI engineers interested in using CI resources more efficiently. Even advanced engineers will find this video thought-provoking and well worth their time.
Specifically, this video will walk you through how Maven Build Cache allows you to reuse unchanged output from previous local and remote builds to avoid executing Maven goals unnecessarily since they are unaffected by new code changes. The business case is then developed and evidence is provided for how this could mean giving every developer back half-a-day per week or more in lost productivity. And for your company we explain how this can mean millions of dollars of additional engineering capacity—not to mention increased software quality and faster time-to-market.
Featured Upcoming Event
On September 18, Gradle will host a training where participants will learn the basics and best practices for making the most of caching in Gradle builds. This includes architecture options and how they affect build performance, as well as how Gradle Enterprise can help with Build Cache management, analysis, and troubleshooting. This is a 3-hour training session followed by a 30-minute Q&A. Maven build tool users, as well as Gradle Enterprise users interested in speeding up builds, are encouraged to attend the training. This course assumes a good understanding of the Java language and a working knowledge of the Gradle Build Tool.
After this training the participants will be able to:
- Understand the benefits of using the Gradle Build Cache
- Use and configure the Build Cache
- Optimize build logic for maximum cacheability
- Maximize the benefits of the Build Cache with Gradle Enterprise
|
