Why multi repo is better than monorepo
There are many articles on advantages of monorepo. There are few practical constrains with Monorepo. Usually these pain points become evident once the projects gets deeply invested in the mono repo idea. Then it becomes a decision to either go back all the way or try to live with it.
Don’t go with Multi-repo just because Google / Facebook does it
Many a times, multi repo advocates just press on the point “If they can successfully do multi repo and do 50 releases a week, why can’t we”.
- We know our project, problem that it solves, skillset of the team, test coverage that we currently have, release cycles, deployment flow etc., If all the above exactly matches with Google or Facebook., please ignore this article and go for Multi repo.
- Each of the giants who follow Multi repo has developer workflows, testing workflows, deployment workflows intertwined and it works best for them to have a mono-repo based on their release management.
- For the following pain paints, they have in-house tools which they don’t open source or the tools are not in a state to be open sourced
Pain points of Monorepo
CI/CD tooling support
Most of the CI/CD tools like Gitlab, CircleCI, Shippable, Jenkins, TravisCI etc., including hosted / self hosted solutions (free / paid) — has no support or limited support for monorepo.
This results in running complete build / test / deploy pipeline flow for any code change in one micro service. I should admit there are hacks and different tweaks to achieve desired outcomes. But I would like to spend time on solving business needs than solving problems that we introduced just because we believe in monorepo.
Hosted Code coverage tooling
Hosted code coverage solutions are made with single repository — single project in mind, as of now. I found it very challenging (many times impossible) to make them work with Monorepo. We need to come up with work arounds or use code coverage libraries within our build process. This might change in future as they start supporting monorepo. Even if they do, it will take time to mature.
Projects which has too many sub projects
Let’s say we have a project where there are too many micro services. As the size of the project increases, it becomes too hard to checkout the whole project and work on a too big code base. This defeats the purpose of micro services and individual teams focusing on it’s specific needs. Of course, Google, Facebook, twitter works with Monorepo containing huge set of micro services. The reality is that they have many in-house tools, devOps teams, processes, etc, which are not yet open sourced. The support that we see for monorepo in the developer community keeps stressing that monorepo is best because many big companies already do this successfully. It is not necessary that if some big companies follows something it is the right way to do for all software projects.
Related good reads
Alternatives, if you really need a consolidated repo
There are ways to group related projects into a namespace to ensure ease of use. For example, With GitLab Groups you can assemble related projects together and grant members access to several projects at once. Groups can also be nested in subgroups. Other best fit repositories might start supporting project groups. It is much simpler for them to support project grouping than monorepo.
Conclusion
Though I like the simplicity of having all related sub projects under on repository, I feel more comfortable working with dedicated repositories for different responsibilities, let’s say at a micro service level.
