Two Reasons To Use A Monorepo
Published on 2016-02-27
What is a monorepo even?!
It is a monolithic repository that typically contain a lot of code that usually have some logical connection but have some properties that would normally have you put them in separate repositories.
A perfect example of this is a service - which is really an awful word to describe what it is. Anyway - this service consist of the following elements:
- Backend (the API)
- Frontend (the client)
- iOS app (the app)
- Android app (the app 2)
- Promotion site (the website)
Let's say that I've just slammed together these parts - they language choice for these is:
- Backend: Node.js
- iOS app: Swift
- Android app: "Java"
- Promotion site: HTML CSS
Ok - I am ready to go - but first I'll put these parts into repositories. I count five repositories here - but as this is a post about why you should use a monorepo I should do that. Here is two immidiate reasons.
Reason 1: Branching, tagging, eg.
If you are harvesting (at least some of) the potential of your version control system you should be using branching and/or tagging when fixing bugs, developing features as making releases.
If you use a monorepo you can branch out all your code and both the backend, frontend, apps and website (from the above example) to make a new version eg. - that way you ensure the consistency in your entire codebase. Your website will surely reflect the product. The apps will implement the correct API and everything will be nice (your mileage may vary).
Reason 2: You have issues
Issues is (at least to some extent) GitHub-speak for everything that needs to be done with the code. New features, bugs etc. - and these have a great advantage if they are associated with your monorepo. When you talk about new features in your service you shouldn't really be concerned where the changes are needed in the code. Nobody (when discussing great ideas and broad product visions) cares what code needs to change. Same goes for bugs - I grab the iOS app and press "update" and nothing happens. I really don't care if the problem is an unwired button, missing handler implementation, error in the network connection, or an error in the backend call - to me (at the point of origin) it is simply an issue.
Bonus Reasons: Searching, testing, deployment, artifacs
Using a monorepo can simplify every one of these steps. Let's say you are managing invoices in your service - crack open the code (or web interface for source control) and search "invoice" - you'll find every piece of code that deals with invoices and everywhere it is mentioned.
Testing - running on local devloper machines - and deployment - all of these can be done by checking out a single codebase. Everything needed is there.
Artifacts - graphics eg. - are often shared in all the parts of the service - it makes perfect sense that these would represent (a sixth) part of the monorepo. Changes in these are tracked like everything else and they are only represented once.
I hope this gives you some sense of why it could be a brilliant idea to switch to using a monorepo instead of splitting your services into several repositores.