6 years of Gradle at LinkedIn
summary
Gradle becomes LinkedIn’s cross‑stack orchestration: by 2017 most projects build with Gradle, every commit publishes a version, and CI runs downstream dependency testing that rebuilds all dependents. A product spec JSON centralizes first‑level versions and enforces downgrade violation failures during resolution; dependency rules auto‑replace bad versions. Tooling includes composite builds integrated into IntelliJ, an automated push-my-upgrade service to roll versions into client repos, and broken‑up Gradle plugin platform APIs — all deployed and operating at scale.
AI-written summary · about
chapters (18)
- 0:00Start
- 2:40Monolithic codebase
- 3:09Project "Inversion"
- 5:45Perfection?
- 6:14Mono VS Multi
- 6:47Issue with mono repo
- 7:27LinkedIn's Multiproducts
- 8:19Separate codebases
- 8:43versioning
- 14:02How does Gradle help?
- 14:46What happens when...
- 19:15Dependency Rules
- 22:06The year of 2017
- 22:32Gradle is responsible for...
- 24:10Common build platform
- 24:25Gradle Platform API
- 26:01Dependency Engineering tools
- 30:04change == new version
related talks
01h 59mGradle: Give Your Build Some Love and It Will Return It!
02h 49mGradle: Give Your Build Some Love and It Will Love You Back!
38mLevel up your Android build
01h 01mGradle 3.0 and beyond
44mGradle: The Build System That Loves To Hate You
05mOver the Ant Hill to Gradle
44mDeveloping Gradle API
48mWhat's new in Gradle 5?
