Code Review Overhead in Manyrepos

“Ask HN: What are the pros / cons of using monorepos? Having experienced both the monorepo approach (at Google and Lyft&#x27;s L5 autonomous division) the and manyrepo approach (at Lyft&#x27;s main rideshare division), my conclusion is that keeping as much code in a single repository as possible (i.e. a monorepo) is generally the best approach.<p>The downside of manyrepos is that you often have to merge multiple changes into different repos in order to achieve a single logical change, and each of these changes requires a code review, waiting for CI, etc. For example, you may have a library that is shared by several services that your team owns. If you want to change some logic that lives in the library and propagate that change to a service, you have to make the change in the library and then bump the library version in the service. The latter change, while simple, is pure busywork, and at Lyft this second step easily adds 1-2 hours of overhead between waiting for code reviews and waiting for CI. Monorepos therefore make it much easier to share code and meaningfully reduce overhead for your team.<p>One of the cited downsides of monorepos, VCS scalability, only really kicks in for very large teams. At Lyft L5, we have a single shared Git monorepo hosted on GitHub that hundreds of engineers contribute to daily, and to my knowledge we haven&#x27;t hit serious problems with Git itself (although I last worked in that org about a year ago). We did run into a few peripheral issues though:<p>- People kept inadvertently merging things that broke master. This would happen when two incompatible changes were merged at nearly the same time, or two incompatible changes were merged a few days apart but the second change was based off a stale master from before the first change, so tests pass on the branch but not after merge. We ended up solving this by having &quot;deliver&quot; branches that are basically master branches for a single team; if you break the deliver branch the only people you have to answer to are your immediate teammates, and it doesn&#x27;t stop all other merges across the org. Deliver branches are periodically merged into master by a release manager who handles merge conflicts.<p>- CI got progressively slower. We addressed this by making improvements to the build system, optimizing tests, granularizing dependency graphs, using C++ idioms like forward declarations and PImpl to reduce dependency chains, and so on.<p>If you have a monorepo, you probably want to use a tool like Bazel. And since Bazel is, to my knowledge, the best tool in the world for doing what Bazel does, that means you probably want to use Bazel. Bazel has you specify your dependency structure as a DAG, and then allows you to quickly re-run tests on PRs based only on the code that changed. It also makes builds for C++ and other compiled languages blazingly fast, and if you&#x27;re building C++ I don&#x27;t think there&#x27;s a better build system out there, monorepo or no. Bazel is a complex tool though so I&#x27;d encourage you to read through its highly detailed user manual, and if you have any questions ask on Stack Overflow where you&#x27;ll often get a response directly from one of the core maintainers.”