We’ve run into some nontrivial but totally solvable issues at about 100-200 engineers.
IME, most consternation comes from people adopting a mono repo without adopting a build/dependency graph tool (like Bazel, buck or pants).
An additional source of strain is from people abusing the repo (checking in large binaries, third party dependencies, etc).
A third is when people try to do branch-based feature development, instead of the “correct” practice of only deploying master (or weekly cuts of master).
I think even a simple list of these sort of “gotchas” would be valuable for the aspirational mono repo company.
My impression is that a lot of teams hit these early and painful roadblocks, and imagine that they’ll never go away (they do!!).
IME, most consternation comes from people adopting a mono repo without adopting a build/dependency graph tool (like Bazel, buck or pants).
An additional source of strain is from people abusing the repo (checking in large binaries, third party dependencies, etc).
A third is when people try to do branch-based feature development, instead of the “correct” practice of only deploying master (or weekly cuts of master).
I think even a simple list of these sort of “gotchas” would be valuable for the aspirational mono repo company.
My impression is that a lot of teams hit these early and painful roadblocks, and imagine that they’ll never go away (they do!!).