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.
Accelerating the Workflow
Implementing Develocity (which supports Maven, Gradle, and Bazel) was a pivotal moment for the Spring Boot team. They started off by adopting Gradle Build Tool to speed up the builds with features like build caching, followed by Develocity, which enabled the team to deeply observe and troubleshoot their build and test processes. As such, build caching and flaky test detection swiftly became integral to their development workflow. When asked about the biggest impact Develocity has had on the team, Wilkinson says, “Without a doubt, it’s the time that it saves us each day.”
Build Scan® from Develocity also proved immensely useful by providing insights into why a specific module’s build failed, the dependencies used in a build, and their origins. This knowledge was vital in fine-tuning their process, leading to a more efficient and streamlined workflow.
Navigating Cache Configuration and Flaky Tests
Setting up caching involved overcoming a few obstacles, particularly ensuring cacheability across different operating systems and working directories. The team could identify and resolve issues by comparing builds through the Develocity UI. Tackling flaky tests was another area of focus. The Spring Boot team opted for a proactive approach, configuring their build to fail when a test was flaky. Regular reviews helped identify consistently flaky tests and remediate the underlying issues.
Celebrating Progress and Looking Forward
The most notable achievement for the Spring Boot team has been the dramatic reduction in build times. Builds that used to take an hour or more now have an average local build time of just seven minutes, and 30 minutes for their CI builds—half of the previous duration. This monumental shift has undeniably resulted in the most significant productivity gain.
Yet, the team is not one to rest on its laurels. They are constantly seeking ways to optimize their build process further, exploring opportunities to make even these impressive seven-minute builds faster.
The Spring Boot team’s journey with Develocity has been transformative. With significantly reduced build times and a deeper understanding of their build process, they have more time and energy to focus on what they do best: creating valuable contributions to the Java ecosystem.
Full Interview with Andy Wilkinson
Brian Demers (BD): What is your project?
Andy Wilkinson (AW): I’m a member of the Spring team at VMware. I work on a few different projects, but most of my time is spent working on Spring Boot.
BD: What build tool are you using? How has the project’s build evolved over the years?
AW: Spring Boot is built with Gradle but that hasn’t always been the case. When work on the project began around 10 years ago we used Maven. It served us well for several years but seeking a faster and simpler build we migrated to Gradle in 2020.
BD: How long were Spring Boot builds before using Develocity?
AW: Our Maven-based builds, both on CI and locally, were taking an hour or more.
BD: What does your test matrix look like? Which OS, Java versions, etc.? How many versions of your project do you maintain?
AW: CI builds run on Windows and Linux. We’re maintaining three versions of Spring Boot at the moment: 2.7.x, 3.0.x, and 3.1.x. 2.7.x is tested using Java 8, 11, 17, and 20. 3.0.x and 3.1.x are tested using Java 17 and 20.
BD: How many individual source repositories/sub-projects does Spring Boot have?
AW: Just the one repository. It contains a single Gradle build that consists of almost 200 projects.
BD: How many contributors does the project have?
AW: The core team is 7 people, although we don’t all work full-time on Spring Boot. We’ve also been fortunate enough to have 1000s of contributions from the community over the years with almost 1000 different people contributing to date.
BD: What is your biggest pain point for developer productivity?
AW: It undoubtedly used to be build time and it probably still is to some extent. For example, when we make a change in a core module that’s near the root of the project’s dependency tree, we really notice how much time GE’s cache normally saves us.
The Spring team has always worked remotely but time zones are still hard. The core members of the Boot team are spread between Europe and the west coast of the United States. That time difference of 9 hours is always something of a challenge, although it does minimize the number of meetings that we can have as there’s little overlap in our working days!
BD: When did Spring Boot start using Develocity?
AW: We started using Develocity in 2020 at the same time as we migrated to the Gradle Build Tool.
BD: What features of Develocity are you using?
AW: Caching and flaky test detection are the two that I think we use most regularly. We’ve also looked at remote test distribution. Its benefits are really compelling but it doesn’t quite fit our Concourse-based CI setup.
The general information that comes from the Build Scan service has also been really helpful. Being able to dig into why a particular module was or wasn’t built, the dependencies that were used in a particular build and where they came from and so on has saved us hours on several occasions.
BD: How long did it take you to see productivity gains after setting up your project with Develocity?
AW: It was pretty much instantaneous. As soon as we started avoiding building various tasks thanks to the remote cache, build times started to drop.
BD: After setting up your project in Develocity, what type of productivity gains do you see?
AW: I think that the reduced build times were the biggest productivity gain. Waiting less time for local builds to complete before pushing and for CI builds to complete before new snapshots are published helped both Spring Boot’s developers and its users.
BD: How long are your builds now (CI & Local)?
AW: In the last 7 days, CI builds have taken 30 minutes on average. That’s less than half the time that our Maven builds used to take 4 years ago and the build’s doing more now. Local builds of the whole project (running the build task) have taken 7 minutes on average. That’s around a tenth of the time they used to take 4 years ago.
BD: What is your favorite thing about Develocity?
AW: Without a doubt it’s the time that it saves us each day.
BD: Did you have any problems getting started with using a build cache?
AW: There was a small learning curve with caching and we still occasionally make mistakes. For example, normalization of inputs is important when building across different OSs and from different working directories. We’ve had cache misses because we haven’t got it right. Thankfully, once you notice the problem, the cause is pretty easy to identify by comparing builds in the GE UI.
We also made a change recently to ensure that snippets of log output in our reference documentation are always up-to-date in terms of their content and timestamps. This came at the cost of the cacheability of some of the documentation-related tasks. It was a bit of a bitter pill to swallow as you get so used to builds being so quick!
BD: Were you able to see a reduction in flaky tests? What does the project do when you encounter a new flaky test?
AW: We don’t really have a fixed process for dealing with flaky tests. We’ve configured our build to fail when a test’s flaky to remove the temptation to ignore them. From time to time we then review the project’s tests in Develocity to identify those that are flaky on a regular basis and see if we can fix them. Sometimes the tests have been faulty, other times the flaky test has been due to a mistake in the main code and we’ve been able to fix an annoying intermittent bug. Occasionally the source of the problem is in code that we don’t maintain. We try to report the problems upstream and then work around them using retries and tools like Awaitility.
BD: If you could change one thing about your build process, what would it be?
AW: It’s difficult not to want it to be even faster. We can see in Develocity that we have some tasks, particularly test tasks, that are outliers in terms of how long they take. There may be some more low-hanging fruit there.
BD: What is up and coming for you that you want to plug?
AW: We’ve just released Spring Boot 3.1 with a first maintenance release due on 22 June. If folks haven’t yet upgraded or they’re new to Spring Boot, now’s a great time to give the 3.1 release a try.
Docker’s becoming an ever-more-popular tool when developing and testing applications and we’ve spent a lot of time in this release improving our support for Testcontainers and providing integration with Docker Compose. Making SSL easier to set up and configure, for both clients and servers, was also a big focus of the 3.1 release.
Beyond 3.1, we’re excited about some new JVM features and supporting them in Spring Boot. Java 21’s release later this year should bring with it support for virtual threads. We’re also following the Coordinated Restore at Checkpoint project with interest as it promises to bring vastly reduced startup times to a broad audience.
Learn more about Developer Productivity Engineering
Develocity is a technology-enabling platform for the practice of Developer Productivity Engineering (DPE). DPE focuses on delivering engineered solutions to common development bottlenecks and points of friction and pain like slow builds, inefficient troubleshooting, and a general lack of confidence in the reliability of your toolchain.
If you want to make your builds faster and earn Gradle swag, don’t miss out on the free Gradle and Maven Build Speed Challenge!
To learn more about Develocity and Developer Productivity Engineering, read these posts:
- CI Build and Test Observability
- Is Developer Productivity Engineering the Next Big Thing in Software?
- Developer Productivity Handbook (PDF)
For more exciting content, follow us on Twitter, LinkedIn, or subscribe to our YouTube channel.