The way your team organizes code may seem far from being the most important subject for discussion when you’re getting started on a new project. However, the way this is done can have a tremendous effect on how fast you can make and release changes, as well as on the quality of collaboration between developers.
Enter the monorepo debate.
A monorepository is a pretty self-explanatory concept: it means that instead of having separate repos for each project, you group them together within a single repo in whatever way that makes logical sense to you.
There has been a lot of heated talk on whether you should or shouldn’t use this type of architecture to organize code. Even though we don’t think that monorepos are a universal good that fits every project and every team, based on the experience that we’ve had, we can definitely see that they can offer great benefits (if used properly).
We’ll start with taking a closer look at what monorepos are good at, and then consider a few cases in which they’re not an optimal choice.
- Consistency. Thanks to atomic commits, the repository always stays consistent — all project builds will work at any commit.
- Simplified dependency management. No need to specify version numbers for dependencies because there’s just one universal version number for all projects.
- Easier and more frequent deployment. Both front-end code and back-end code are stored in one place, and since they can be deployed simultaneously with a single pull request, deployment takes less time.
- Code reuse. Everyone on the team can see the entirety of the project at all times, so they can easily identify common components and thus share common functionality across monorepo microservices.
- Easier refactoring. A grep command is all you need to refactor something. Restructuring also gets easier with all code being in one place.
- Faster code review. It’s simple to review code and track changes when everything is neatly stored in one code repository.
- Better testing. Because developers can run the whole platform locally, they can better understand how all services work together and thus find more bugs. Plus, if the whole code base uses one programming language, a single test runner will also be enough to check the whole system.
- More efficient collaboration. Provided you’ve established solid processes, cross-team collaboration and onboarding of new team members get a lot smoother and faster.
One frequently cited case against using a single code repository is that it doesn’t scale well. Git performance slows down as the number of commits gets larger and the history deepens. This is, however, only true for giant applications and teams with hundreds of developers who work within the same repo every day.
The way we see it, there’s actually a very limited number of situations in which you should opt out of using a monorepo. Here’s what they are:
- For security reasons or otherwise, you don’t want everyone on the team to be able to view all the code. There’s no way to restrict access to some part of a monorepo.
- You have a large number of projects, and they’re all run by different teams on different technologies. If this is the case, there’s absolutely no need for the teams to store the entire code base locally.
- There’s one part of code that changes frequently, and another part that hardly ever changes. For example, the front-end side of your product changes every month, while on the back-end side, everything stays largely the same. Each deployment is a risk to break something (especially if there are no autotests in place), and you probably don’t want to risk damaging a perfectly functional back-end system on a regular basis. There are a number of monorepo tools that provide workarounds, but we think that for the situation described above, they’re less convenient than having multiple repositories.
All specific benefits aside, a monorepo is ultimately an investment into team culture. It may be harder to set up at the beginning of your project compared to having separate repositories, which is why you need a few experienced developers who would know what they’re doing. But what you get as a result is the type of behavior in your teams that encourages transparency and shared responsibility. This becomes especially important if the teams scale.
When there are multiple repositories with isolated teams working within them, developers don’t feel responsible for issues other teams are dealing with. Within a monorepo, everyone shares responsibility with the rest of the team, so developers have to communicate and collaborate.
And more often than not, monorepos do increase productivity and speed of delivery, which can never be a bad thing.
And if you’re looking to build a team of experienced developers that can help implement your technical solutions, get in touch with Roy Vikovych, our Business Development Manager, to find out more about our services and opportunities for cooperation.