In the arena of software development, every metric has its role to play. Among these, local build times hold a position that’s often undervalued. This critical performance indicator may have been sidelined as we transitioned to remote work. It’s time we bring it back into focus, explore its significant impact on the development process, and take action, as necessary, to improve it.
James Ward, Google Developer Advocate at the time, and Mark Vieira, a Principal Software Engineer at Elastic, co-presented a Webinar on how Elastic saves time and spends less on their Google Cloud infrastructure by leveraging Develocity.
Discover ‘Build Rot’, the hidden technical debt in Maven and Gradle builds. This post explores the impact of Build Rot on build speed and test times, offering strategies for enhanced observability and Developer Productivity Engineering to optimize build processes.
Since 2018, GitHub Actions has emerged as a great choice for Continuous Integration (CI) due to its proximity to your code. Develocity is a popular technology for speeding up builds and gaining insights that can be used to make troubleshooting more efficient and toolchains more reliable. This post will explain how to integrate these technologies. Specifically, we will walk you through how to set up your Maven project builds using GitHub Actions and Develocity.
Gradle recently had an opportunity to optimize the cloud storage layer used for Build Scan®, a feature of Develocity. In this article, we’ll deep dive into the challenge we faced with inefficient cloud storage, our decision to migrate to Amazon S3, and the remarkable result: a 75% reduction in data storage costs.
Flaky tests may seem like a minor inconvenience—we often learn to identify which tests occasionally (or frequently) fail for no good reason and pay them less attention. However, it’s crucial to understand their impact on the broader development process, because a flaky test both consumes valuable developer time and creates a sense of uncertainty around the testing suite.
The SPACE framework provides a comprehensive model for defining developer productivity drivers. This article explores how the practice of Developer Productivity Engineering (DPE) aligns with these drivers. It concludes that SPACE and DPE need each other. SPACE defines the “what” for improving developer productivity and DPE defines the “how”.
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.
Accelerate
Troubleshoot
Observe
