Monorepo or Polyrepo: What's the Right Choice for You?
summary
Monorepo runs 400 monthly contributors, 100,000 CI builds and 3,000 merges per month across over 1,000 projects, so it proves atomic commits work for coordinated changes like a single Spring Boot 2.7→3.2 upgrade and Java-heavy BOMs solve dependency hell. It uses Bazel for caching/parallel builds, Nyx for reproducible dev environments and GKE for scalable CI runners, but needs healthy tests, visibility rules to avoid breaking many services, and upfront work to avoid long builds or secret-code access problems.
AI-written summary · about
chapters (10)
- 0:00Introduction to monorepos
- 2:39What is a monorepo?
- 10:39Solving dependency hell
- 17:51Atomic commits for large changes
- 21:28Consistency and standardization
- 26:49Challenges of monorepos
- 31:35Lessons learned from monorepo
- 36:14Java-specific benefits
- 37:59When to choose monorepo
- 39:51Summary and Q&A
related talks
25mMicroservices, Monorepos, and the Efficient Build Processes
33mThe age of monorepos
15mPanel discussion: Mono-repo Vs. Multi-repo Vs. Hybrid
01h 00mExtracting the monorepo
16mHow We Moved to a Monorepo
29mOne for all, all for one: The Journey to Android Monorepo
49mSBT monorepo and delivery
31mMonorepos, Mainframes, and Modus Operandi Accepted