Principal software engineer on the platform team at Reddit. Focused on reducing build times, making the app more performant, solving developer pain points, and breaking builds. When not working, I enjoy basketball, Lego, woodworking, and spending time with my wife, 3 kids, and 2 dogs.
Eric Kuck
Android Platform @ Reddit
Goodness, Gracious, Great Builds of Gradle
Let's explore how Reddit's Android team has evolved its Gradle usage in recent history. We'll cover where the team started - hundreds of unique build.gradle files with no centralized control or cacheability - to a full-featured gradle plugin that handles configuration, dependencies, adds helpful tasks, and ensures build times stay reasonable.
Key Points:
We've all worked in projects with difficult to understand build environments. What are the benefits of encouraging conciseness and consistency throughout?
* A single lifecycle issue can cause a damaging ripple effect throughout the entire project
* Most Android engineers are not Groovy or Gradle experts and a lot of Internet advice is wrong or outdated. Make the right path the only path to prevent bugs.
* Unlocks mass-migrations (ex: kapt -> ksp)
Where Reddit's build system started and its pain points. These should be recognizable by anyone who's been doing Android development for long enough.
* Huge copy/pasted blocks of code scattered everywhere
* Several "right" ways to do things
* Decentralized, conflicting dependency management
* Eager evaluations everywhere!
What we've built to solve these pain points and accelerate our cycle times - Reddit Gradle Plugin (RGP).
* Central configuration in settings.gradle
* Different plugins for different project types (JVM, Android Library, Android App, Dynamic Feature, etc)
* Project configuration in a `reddit` block in each project build.gradle files
* Examples - Dagger, Anvil, Apollo, test configuration
* Project build.gradle files consist of nothing other than `projects`, `reddit`, and `dependencies`
What has RGP gotten for us?
* Configuration caching - developers have to go out of their way to break this now
* Improved build times - only doing what we _have_ to be doing for a project
* Mass migration capabilities
* Consistency, low mental overhead
* Machine-optimized JVM args for all
* Helpful built-in tasks (affected module tasks, custom code coverage tooling, etc)
* Observability