Monorepo or Multirepo? Role-Based Repositories

The main driver of success in either model is in the tooling and practices invested in it to make it work in an organization. Google is successful with their monorepo because they have invested in building (blaze), source control (piper, code search), and commit to always developing on HEAD. Multirepo is currently easier for most companies because most public tooling (git, package manager) is built around multirepos. One place I see multirepos fall over is awful dependency management practices internally and in open source. Many dependencies quickly become outdated and are not updated in cadence, slowing down writers and consumers. Better tooling can help here but an organization needs real discipline to stay on top of things.

Monorepo shortcomings 1 and 2 seem like bullshit to me. Perforce, the popular monorepo at most companies I&#x27;ve worked at, supports access control. Monorepos do not prevent you from segmenting your code into modules and pushing binary&#x2F;source packages into source control so that builds can avoid compiling everything(TiVo used to do this, and it worked well when you got the hang of it).<p>I feel like these debates are often fueled by false arguments. Either way you go, you&#x27;re going to want to build support tools and processes to tailor your VCS to your local needs.

I regularly join projects where someone has decided to place the project&#x27;s code in half a dozen different repositories.<p>Even though it&#x27;s one project.<p>Even though they refuse to allow a release of a single component - it must all be released together without forwards&#x2F;backwards compatibility.<p>I think most of of the time, the mono&#x2F;multi debate is spoiled by people who feel they can have their cake and eat it too.

One of the things I&#x27;ve done at a couple companies now is flatten multi into mono - it just simplifies everything, it&#x27;s all deployed as one unit, so easier to track and do changes across different parts of the code base in unison.<p>I have typically left mobile iOS&#x2F;Android in separate repos however - they have a different deployment cadence, so you need to manage breaking changes differently anyway.

There&#x27;s a lot of people on here defending their current workflow, whatever that is.<p>I for one find it refreshing that people are willing to think about different workflows, even if they are different.<p>It feels like what is described is a cross between a good language package manager and git submodules. It&#x27;s an interesting space to explore, because a lot of nice things come out of submodules, but it&#x27;s not a proper package manager.<p>A <i>proper</i> dependency manager that puts code in a workspace and manages it as you are working on it in a non clunky way is not something we have right now and may be a game changer. Thanks for sharing to the authors.

I&#x27;m curious: how would most people here define monorepo vs multirepo?<p>On the surface, most people seem to think of a monorepo as a source control management system that exposes all source code as if it&#x27;s a traditional filesystem accessed through a single point of entry. Multirepo, in contrast, seems to be about multiple points of entry.<p>But that&#x27;s a superficial and uninteresting distinction. All the hard parts of managing code remain for both and, for a sufficiently large organization, you&#x27;ll still need multiple dedicated teams to build tooling to make either work at scale. All the pros listed in the article need a team to make them work for either approach, and all the cons are a sign that you need a team to be make up for that deficiency for either approach.<p>Aesthetically a single point of entry appeals to me, in that it allows for a more consistent interface to code. But I&#x27;d go for good tooling above that in a heartbeat.

Why not both? I&#x27;ve been using <a href="https:&#x2F;&#x2F;github.com&#x2F;mateodelnorte&#x2F;meta" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mateodelnorte&#x2F;meta</a> and having a great time so far, it&#x27;s just that GitHub (and others) don&#x27;t have a simple way to bundle multi-repo commits in pull requests.

Whats the current state of git submodules? It seems like you could get some of the benefits of mono-repos in that you can reference dependency projects directly like a mono-repo. You can, in theory, treat many projects like a single code base.<p>I don&#x27;t see it used very often though. Why not?

In one of my first jobs like 15 years ago at a large software company we had just moved to a monorepo.<p>It was introduced to counterbalance what many saw as a big mess. Result was a lot of process being introduced which slowed everything down, but that was probably necessary at that stage. To my knowledge the company keeps switching back and forth- but new projects that need to move fast typically are done independently still.

I bet you could address this with a third approach: metarepo. The metarepo is a repo that uses sub modules to combine your multi repo ecosystem into a simulated monorepo. The metarepo is what ultimately gets built and deployed—no versioned dependencies to manage. Local development usually happens at the multirepo level, and the metarepo is managed mostly via CI.

For TypeScript&#x2F;JS projects I think NX CLI is pretty awesome as it handles multiple frameworks

So, in a monorepo world, isn&#x27;t it often that you <i>have</i> to deploy components together, rather than &quot;it&#x27;s easy to&quot;? How are services deployed only when there has been a change affecting said service? Presumably monorepo orgs aren&#x27;t redeploying their entire infrastructure each time there&#x27;s a commit? Are we taking writing scripts which trigger further pipelines if they detect change in a path or its dependencies? How about versioning - does monorepo work with semver? Does it break git tags given you have to tag everything?<p>So many questions, but they&#x27;re all about identifying change and only deploying change...

I worked in a big bank in the UK using monorepo &quot;cuz Google uses it&quot;, error number 1, your not Google. The clones were gigantic, Jenkins would timeout cloning the whole project when all it needed was a bunch of files. Merge conflicts all over the place, but the best part, we had scripts on our pipeline literally removing folders after cloning the repo to avoid automatic inclusions of libs etc. In my opinion separation of boundaries is one of those things that should t be mess with.

I don&#x27;t understand the isolation difference. You can hide, protect and branch code in a monorepo so why is isolation a concern?

We do multi-repo. It makes it a little slower, cause we have to get commits into our common libs repos (there are two) before we can do app&#x2F;product repos updated. Using the environment package manager (composer, nom, yarn) rather than git-sub-module helps a lot.

GoCD provides “fan in” which supports monorepos<p><a href="https:&#x2F;&#x2F;docs.gocd.org&#x2F;current&#x2F;advanced_usage&#x2F;fan_in.html" rel="nofollow">https:&#x2F;&#x2F;docs.gocd.org&#x2F;current&#x2F;advanced_usage&#x2F;fan_in.html</a>

Amazon does multi-repo. I don&#x27;t see what the problem or debate over this is. We seem to be handling it pretty fine despite a massive-scale SOA architecture.

I&#x27;m curious about those who use a monorepo with microservices: how do you solve CD&#x2F;CI? Is Bazel the only solution?

The cons to multi repo are all anti patterns for microservices anyway. If you&#x27;re doing microservices you shouldn&#x27;t have build dependencies on other projects. The should only call eachother at a network level.

I am a big fan of monorepos and I&#x27;ve worked on a few open source projects that have used mutli-repos and at some places that used a hybrid approach. I agree with some of the ideas this article has put into writing but I wanted to provide some pointers from my experience.<p>Some background: at my current place of employment I have 28 services, should be 30 in the next few days, and so I think my use current case is very representative of a small to medium monorepo. At my last job right before this one we had sort of a monorepo that was strung together with git submodules although each project was developed independently with it&#x27;s own git repo+ci.<p>&gt; Isolation: monorepo does not prevent engineers from using the code they should not use.<p>Your version control software does not prevent or allow your developers from using code they should not use. It is trivial to check in code that does something like this:<p><pre><code> import &quot;~&#x2F;company&#x2F;other-repo&#x2F;source-file.lang&quot; as not_mine; </code></pre> Or even worse in something like golang:<p><pre><code> import &quot;github.com&#x2F;company&#x2F;internal-tool&#x2F;...&quot; </code></pre> Because of this it is my opinion that it is impossible to rely solely on your source control to hide internal packages&#x2F;source&#x2F;deps from external consumers. That responsibility, of preventing touching deps, has to be pushed upwards in the stack either to developers or tooling.<p>&gt; So, big projects in a monorepo have a tendency to degrade and become unmaintainable over time. It’s possible to enforce a strict code review and artifact layouting preventing such degradation but it’s not easy and it’s time consuming,<p>I think my above example demonstrates this is something that is not unique to monorepos. The level of abstraction that VCS&#x27; operate at is not ideal for code-level dependency concepts.<p>&gt; Build time<p>Most build systems support caching. Some even do it transparently. Docker&#x27;s implementation of build caching has, in my experience, been lovely to work with.<p>---- Multi repo section ----<p>&gt; In case your release flow involves several components - it’s always a real pain.<p>This is doubly or tripply true for monorepos because the barrier of cross-service refactors is so low. Due to a lack of good rollout tooling most people with monorepos release everything together. I know my CI essentially does `kubectl apply -f`. Unfortunately, due to the nature of distributed compute, you have no guarantee that new versions of your application won&#x27;t be seen by old versions (especially so of 0-downtime deployments like blue-green&#x2F;red-black&#x2F;canary). Because of this you constantly need to be vigilant of backwards compatibility. Version N of your internal protocol must be N-1 compliant to support zero-downtime deployments. This is something that new members of monorepo have a huge huge difficulty working with.<p>&gt; It allows people to quickly build independent components,<p>To start building a new component all one must do is `mkdir projects&#x2F;&lt;product area&gt;&#x2F;&lt;project name&gt;`. This is a far lower overhead than most multi-repo situations. You can even `rm -r projects&#x2F;&lt;product area&gt;&#x2F;&lt;thing you are replacing&gt;` to completely kill off legacy components so they don&#x27;t distract you while you work. The roll out of this new tool whet poorly? Just revert to the commit before hand and redeploy and your old project&#x27;s directories, configs, etc are all in repo. Git repos present an unversioned state that inherently can never be removed f you want a source tree that is green and deployable at any commit hash.<p>--- Their solution ---<p>I accomplish the same tasks as a directory structure. As mentioned before if you just put your code into a `projects&#x2F;&lt;product area&gt;&#x2F;&lt;project&gt;` structure you can get the same effect they are going for by minimizing the directory layout in your IDE&#x27;s file view. The performance hit from having the entire code base checked out is very much a non-issue for &gt;99% of us. Very very few of us have code bases larger than the linux mainline and git works fine for their use cases.<p>Also, any monorepo build tool like Bazel, Buck, Pants, and Please.build will perform adequately for the most common repo sizes and will provide you hermetic, cached, and correct builds. These tools also already exist and have a community around them.<p>[0] - <a href="https:&#x2F;&#x2F;docs.microsoft.com&#x2F;en-us&#x2F;azure&#x2F;devops&#x2F;learn&#x2F;git&#x2F;git-at-scale" rel="nofollow">https:&#x2F;&#x2F;docs.microsoft.com&#x2F;en-us&#x2F;azure&#x2F;devops&#x2F;learn&#x2F;git&#x2F;git-...</a>