Dude, Where's My Build? Android CI/CD
summary
Hundreds of developers push hundreds of changes a day to a large monorepo, causing frequent CI breakage until Uber moves to Buck, Linux build farms, artifact caching and a queue called submit Q that runs builds plus UI tests in order to prevent merge-time failures; the system reports inline errors by parsing logs and uses violations-lib and PMD for static checks, enforces SLOs (aiming for <5% non-actionable failures and capped retries), and runs release APK builds under an hour to a store called Metro.
AI-written summary · about
chapters (18)
- 0:00Why CI matters
- 1:10Android CI at scale
- 3:14From Mac Mini to racks
- 5:39Gradle struggles at scale
- 7:44Ideal CI characteristics
- 9:08Switching to Buck
- 10:11Submit Q for master stability
- 11:55Developer experience focus
- 15:47Inline code comments
- 17:32Tracking CI errors
- 18:34Handling flakiness
- 21:22Android CD introduction
- 23:27Continuous delivery setup
- 25:55Release schedule improvements
- 26:17Gradle error interception
- 28:23Inline reporting with GitHub
- 29:25Measuring CI improvements
- 30:48Enforcing CI guardrails
related talks
41mDude, Where's My Build? Android CI/CD at Uber
43mBetter, Faster, and Stronger CI/CD Pipeline
28mBuilding at Uber Scale
48mMobile Developer Productivity at Scale
41mHow Are Other Teams Doing It? Lessons in CI/CD from 3500 Android Teams
36mAndroid like a (reliable) Rock Star - All About Android Continuous Integration
32mBuilding Quality Android Apps for the Future with Continuous Integration
01h 00mAndroid builds