Monitoring and analyzing build performance though Develocity is crucial for optimizing feedback cycle times. There are cases where it may be desirable to combine Develocity’s build metrics with other datasets and render the results visually. Moreover, it is not always practical to swivel-chair between different dashboards when looking for high-level data.
In the dynamic world of open-source projects, the Spring Boot team, a vital part of the Java ecosystem, grappled with a challenge slowing down their progress: extensive build times. Their build process, both local and on CI, would take an hour or more, affecting their productivity. The turning point? The deployment of Develocity.
In this blog post, I will walk you through the highlights of this journey and provide the transcript of my interview with Andy Wilkinson, staff engineer at VMware and Spring team developer, from which this piece is based.
Develocity automatically observes, records, and reports details about your CI builds. This information provides the basis for generating performance and failure-related insights and developing metrics to make CI pipelines more efficient. This automation allows CI and DevOps Engineers to focus on sustained improvement instead of tech support. In this article, we’ll define some of those key CI metrics and explore real-world examples of Develocity helping teams to optimize CI performance and failure recovery using those metrics.
We’re excited to announce the general availability of Develocity 2023.1.The new release brings many compelling new features and capabilities, but here we highlight a few of the most impactful areas of innovation: deeper insights into artifact transformations, a new query language for advanced Build Scan™ searches, and enhancements to security including automated SCIM-based user management and custom roles for granular access control. Let’s dive into the details.
I’m excited to share the news that today Gradle Inc. announced that it has acquired Triplequote and that both I and my fellow co-founder Mirco Dotta have joined the new Scala team at Gradle! If you are not familiar with Triplequote, our technology speeds up builds for Scala developers with the world’s only parallel compiler for the Scala language, called Hydra.
One of the most powerful features of Develocity is its remote build cache. It allows teams to share the benefits of caching, even for local builds. If you have code that hasn’t changed, there’s no reason to rebuild it.
Here at Gradle, Inc., we don’t just talk about Developer Productivity Engineering (DPE). We practice it every day. We know that companies that make DPE a priority have focused, productive developers who deliver better code faster while experiencing the joy of coding. That’s why Gradle has engineering resources dedicated to ensuring our developers get the same benefits as our customers. And we eat our own dog food. (Or, if you prefer, we drink our own champagne. Then again, not all of our code is written in France, so maybe we’re drinking our own sparkling wine.) That includes using Develocity Test Distribution.
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.
This is a cautionary tale about the consequences of not investing enough in Developer Experience, what to do about it if you find yourself having to address those consequences, and how to avoid getting into this situation in the first place.
The first annual Developer Productivity Engineering Summit will take place on November 2-3 in San Francisco. This two-day, dual-track event features the leading minds in Developer Productivity Engineering (DPE). The theme is “Next Practices for Transforming the Developer Experience.”
Accelerate
Troubleshoot
Observe
