What are the pros and cons of the "monorepo" approach?
For further actions, you may consider blocking this person and/or reporting abuse
What are the pros and cons of the "monorepo" approach?
For further actions, you may consider blocking this person and/or reporting abuse
Latest comments (27)
A nice topic!
One thing that I miss somehow more emphasized on the other comments is, that a "monorepo" approach doesn't necessarily mean "Put EVERYTHING you have in one repo".
From what I understood, just put the projects/modules into a monorepo where it makes sense for you.
So even multiple monorepos and mutliple single modules can happily live side by side.
It doesn't have to span across a whole project, but only some dependencies, which is just fine.
I teach three pros to the giant monorepo:
But any of this discussion only really applies to a large repository. Here large refers to at least 500MB of source code, tens of thousands of files. Below that scale there is simply no reason to mess with submodules or anything but a single repository. The pain points you might have from one repository at that size are related to tooling around the repository, such as continuous build or testing. The source control system itself isn't a bottleneck there. Your effort is better spent fixing the tooling, because if it's painful now, it's only going to get worse later. At these scales the only reason to have multiple repositories is to control access to parts of the source code.
Once you get past that size, you pick a direction. If you choose many repositories, you have to build an orchestration system to handle all the interacting versions and getting everyone onto shared tooling can be a lot harder. If you choose a monorepo, you deal with slower and slower operations and lots of hard work on the version control system itself. Both paths work if you put in the engineering effort. Google and Facebook went monorepo. Amazon does multiple repos.
There's an underlying worldview that I need to challenge though. When people start talking about these things, the implicit idea is, "Google/Facebook/Amazon/big company do this, so it must be a good idea." These companies are outliers. Their scale has made working with the systems frankly annoying. What they do is not best practices for anyone without their problems. Giant mining machines have wheels so they can move (measured in meters per minute), but no one would think that the procedures for operating one should be emulated for an articulated bus or tractor trailer.
When someone says, "Yeah, but that's how Google does it," your first response should be, "Why do they do it that way?" In many cases the answer is, "The system got out of control in this particular dimension and it was the only way we could think of to keep it operational."
Very interesting talk about how Google handles a monorepo at stupidly large scale.
Not applicable to every use case (not applicable to a LOT of use cases actually), but it's worth checking out for the concepts behind it.
For a normal project, under 5 devs it may be a good approach.
The cons would be:
Also I see a pro as "atomic updates". I don't think it is a pro, to get into the projects you do not know, just to update how a library is used. I I think a better approach is to use a dependency by version, and let each user of your project to migrate in its own terms and conditions, and sometimes partially and slowly.
Out of the ordinary: Here is a talk by Google about Googles monorepo
Use a meta repo, then you have both!
My take on the monorepo argument after seeing it play out on a few different teams. These experiences are with having 2 - 50 projects in a monorepo, spanning web and mobile dev.
While monorepos make sharing modules, updating dependencies, and working on FE/BE a lot easier, you trade that inconvenience for tooling around your CI/CD system. For example,
A good implemention I saw had the back end, front end, deployment scripts, and infrastructure in the same repo but this was limited to one product so it was just 4 subfolders. That was a pleasant experience. It would have gotten annoying if multiple products were also in this repo though.
Anyway, my 2 cents.
I'm curious about what others have to say about the pros. So far I'm not really convinced except for bundling back and frontend applications of the same web app in the same repo. :-/
I think as software developers we should be striving for modularization and separation of concern. Having everything in the same repository doesn't look like that to me, and it feels a bit odd that there is that big directory of everything which keeps on growing and growing the more projects you add to the mix. Is there an end in sight? What about pull / push performance?
Directory aesthetics aside, one counterargument against monorepo that crosses my mind might be access control.
Probably depends on the situation but not everyone in the organization needs or should have free access to everything. That's easier to control when repositories are separate.
Also if your company works for various clients and one client requests access to their source code (and change history), maybe because they want to take over or hand it over to another software development company, you cannot just give them access to that one project directory of theirs in that big monorepo. That would be awkward. Possibly also causes a whole bunch of contract breaches. And if the commit history contains cross-references to other client's code and source files due to monolithic monorepo commits... that could also cause awkward situations.
Personally I've dealt with monorepos only at a time where SVN didn't make the vast majority of programmers cringe in disgust. It's interesting that this becomes fashionable again.
Very interesting subject.
Everyone here seems to only see pros for using monorepo.
On my side, though I can understand the pros in a project, in a startup or in a little company, I see a lot of cons in other cases.
I work in a huge company with thousands of developers working on a wide variety of projects. Some of them are just for research while some others are for production.
I can't imagine a monorepo in a company where many languages are used.
How do you deal with your git hooks?
How do you deal with your pipeline?
How do you deal with git tags?
There are a lot of situations where monorepo make the life more complex or even impossible.
Imagine the git tree in a company with hundreds of projects!
I would love having feedback from people having used monorepo "in real life".
You don't use them the same way. There is a layer of tooling between your local system and the main line. All the hooks, tags, and the like are local to you. Once your commit has passed code review and automated testing, it gets integrated into the main line by the tooling. You never, ever run a merge to master by hand, nor do you have permission to.
I know Google uses a monorepo, but how they manage all that complexity is something I can't even imagine...
Google doesn't use git, so a lot of the tools and features you might be used to don't work there. That's good, though. Developers and bots make changes to Google's code base at a very fast rate (many changes per second!), so there's no way that a central hook registry would be able to run everything necessary for every change, nor could a central pipeline take care of everything in the repository 😱.
Each directory has the equivalent of hooks (presubmit checks) that are checked using independent microservices (often maintained by independent teams) and must be run before the code is merged in head. There is also infrastructure for watching sub-trees, so tools and pipelines can be triggered when code is updated - often creating a cascade of even more changes!
You can compare such large-scale monorepos to the Internet. It gives us the illusion of having a single domain namespace, but DNS TLDs are responsible for sub-parts of it. Same for IP addresses. In Google's piper, directory trees have their own hooks, ownership and tools. It works beautifully, actually, but there's also a lot of complexity and technical debt to manage since Google isn't that new.
I worked at Google for a number of years and I'm happy to answer questions if you have any. Their source code management practices have been published publicly, so I wouldn't be disclosing anything new. Happy coding!
The point here is having good tooling for a use case. Git isn't the right tool for a monorepo if you want those other features (and most non-small development orgs will probably need). Sorry for all the shoring-up (most, probably). Every use case is different.
This also leads into writing good tools and defining good requirements/use cases but now I'm getting ahead of myself.
Git in this case acts just like a smart file storage. Microsoft and Facebook use git for very large repos and it works for them, for example.
Facebook uses Mercurial. Microsoft did a lot of work in the last year or two to make git work well with big repos.
When you want to setup a new project you need to do several things like set up the CI, configure ACL for various things, etc. With a monorepo you only have one repo to configure.