Stash recently deployed Gradle Enterprise and is already seeing benefits. We caught up with Joel Parrish, Principal Engineer at Stash to get the low down and he shared his experience and results to date.
Tell us a little bit about Stash first?
Sure. Stash, is an American financial technology and financial services company that was founded in 2015 and is based in New York, NY. We operate both a web platform and mobile apps that allow users to incrementally invest small amounts. We now have approximately 5 million subscribers that depend on us to unite investing, banking, saving, and learning into one seamless experience. We call it a do-it-all home for your money.
Can you describe your development environment so we can have some context for understanding your Gradle Enterprise deployment?
Yes, we have 15 Android engineers working on the project. The application includes about 100,000 lines of code and roughly 1,500 local builds and 1,100 CI builds per week.
The codebase is a mix of Kotlin and Java and contains about 120 modules. For the most part, the team self-manages enterprise services including DevProd tooling.
What DevProd challenges or pains have you been experiencing that you hoped to address with Gradle Enterprise?
There were several main challenges we were initially looking to solve. First, we often were experiencing slow builds with no insight into what the bottleneck could be. Having a multi-module repository only exacerbated this problem as the bottleneck could have existed in any of the modules.
Second, we were experiencing slow configuration times. This was one of the first benefits we realized by leveraging Gradle Enterprise as it allowed us to immediately see that one of our custom tasks was being initialized and configured with every single module that existed in our app.
Within the first month of using Gradle Enterprise we started experiencing crashes that were difficult to pinpoint with CI logs, but became more apparent with Gradle Enterprise Build Scan root cause analysis data. By using the Build Scan comparison feature, we were able to discover that a layout dependency change was breaking a screen on our app. This really sold us on the power of Build Scans, as this type of issue could have taken us months to discover without the Build Scans.
Finally, builds that should have been cached were having large miss rates, leading to the discovery of some core tasks that changed resources on every build causing consistent misses.
It sounds like you have already leveraged Gradle Enterprise Build Cache for both local and CI builds, Build Scans, including Build Scan Comparisons for root cause analysis, and Trend Dashboards to support failure analysis.
That is correct and we plan to experiment with Flaky Tests Management in the near future.
Besides the benefits you already mentioned, are there any other benefits or results that you have experienced?
We have also seen a reduction of on average about one hour in the time from issue discovery to fix. This can partly be attributed to quick consistent access to logs and error messages and partly driven by the use of the Gradle Enterprise Build Scan Comparison capability. And besides solving all of the pain points I just outlined, we have been able to instantly reduce local build times marginally, but that has not been our initial focus and we are just getting started.
I should also mention that one of the simplest and most helpful tools that can be easily overlooked by users is the support for custom tags. Custom tags allow us to tag valuable information that is extremely useful in managing our project—anything from low-level network configurations to direct Github PR links.
What are your next steps with respect to Developer Productivity Engineering?
We plan to hone and improve the Build Cache mechanisms between android variants to improve build times substantially. This includes exploring cache misses and cleaning up tasks that shouldn’t have been missed. We also plan to add test repeat logic to start detecting flaky tests.
Do you have any parting words of advice for Android developers interested in making their builds faster and troubleshooting more efficient?
Gradle Enterprise takes an end-to-end approach to developer productivity engineering with build acceleration technologies like Build Cache for remote and CI builds, Build Scans for efficient debugging, and Failure Analytics and Trends dashboards to increase build and test reliability and manage performance regressions. We are just scratching the surface of Gradle Enterprise and are already seeing results. So I definitely encourage my peers in the industry to check out this kind of tooling.