Monorepo & Codebase Organization
Keeping many projects in one versioned repository: shared tooling, a single history, atomic cross-project changes, and the ownership and scaling problems that come with a large repo. Expect to be asked to compare it with separate repos rather than to advocate for one.
part ofSoftware design & architectureoverview, primer and where to startread it →on this pageshowhide
explore
- Monorepo vs Polyrepo5 questions
- Shared Dependency Coordination5 questions
- Build Scoping & Affected Detection5 questions
- Code Ownership & Project Boundaries6 questions
- Monorepo Build Tooling6 questions
- Incremental Builds & Build Caching6 questions
questions
page 2 of 2Large organizations like Google enforce a strict 'one version of everything, everyone builds at HEAD' policy across a single enormous monorepo. What makes that policy tractable at their scale, and under what organizational conditions would adopting the same strict single-version policy be the wrong call for a smaller company?
basics
~20 sGoogle can enforce "one version for everyone" because they built huge tooling (fast builds, automated migrations, dependency-graph analysis) to make it manageable. A smaller company without that tooling, or with teams that genuinely need to move at different speeds, would just get stuck constantly blocking on each other.
In a monorepo with thousands of projects and hundreds of teams, what typically causes ownership metadata like CODEOWNERS entries and project tags to decay over time, and what governance practices keep it trustworthy?
basics
~20 sAs teams reorganize, merge, or disband, nobody remembers to update who owns old code, so some folders end up owned by teams that no longer exist or by nobody at all. Regular audits and automated checks catch this before it causes stalled reviews or unfixed security issues.
As a principal engineer deciding whether to migrate a 500-engineer monorepo from framework-native build scripts to a strict tool like Bazel purely for hermetic, remote-executed builds, how would you actually evaluate the ROI, and what organizational failure modes should you watch for during the migration itself?
basics
~20 sYou weigh the ongoing CI-time and developer-hours saved against the real cost of migration and the ongoing tax of maintaining strict build declarations. Big or fast-growing polyglot orgs usually win; migrations commonly fail not from the tech but from teams not budgeting real time for it and reverting under deadline pressure.
showing 31–33 of 33