The world is divided between marmite and vegemite, night owls and early birds, and as it turns out, at least in the software world, mono vs multi-repositories. Once you’ve appropriately dissected the matter, however, it quickly becomes clear that this could only ever be the case.
After all, choosing to switch from one source control pattern to another is a bit like deciding to support a new football team or converting to a different religion — there are strong feelings emanating from both sides of the argument, and to a considerable extent, it requires a leap of faith.
Come Again?
For those of you who are now lost, however, despair not. A monolithic repository, or “monorepo,” as it has swankily become known, is a form of handling source code in which code for multiple projects is stored within a single repository (think Dropbox for techy types). Its older cousin, on the other hand, the multi-repository strategy, favours a different approach altogether — a single repository for every individual project.
By becoming aware of the benefits and drawbacks of both of these approaches, Software Planet believe that not only can you increase your company’s productivity, but also improve upon the quality of your projects. So with this in mind, we would like to shine a light on this very controversial topic.
Mono vs Multi-Repositories in the Real World
Imagine you had an enterprise system that was built around a complex microservice architecture. In this case, you would likely have an onsite team developing some of the modules (also known as microservices) and some other external contractors developing others. Of course, all of these services would share a number of common libraries and dependencies, and by default, each team would be supporting them independently.
But what if you also had a number of internal libraries such as an Employee register or a Payment system gateway that you would like to be able to access from anywhere within the system? Should you keep all your microservices within a single code repository and automatically rebuild their dependencies, or should you separate them? This is the question that we are now trying to answer.
Multi-Repositories
Multi-repo advocates, in their fairly conservative views, are convinced that by allowing different teams to use their own individual repositories and providing them with the flexibility to work in anyway that they choose, productivity will doubtless be maximised.
The likely benefits, they argue, include clear ownership of repository and services, as the codebase will naturally mimic the underlying architecture; better scale and coordination, since smaller codebases are easier to manage and do not tend to create hellish merging scenarios; and — somewhat disputably — greater velocity, because code changes only have to be tested within a single repository.
The flipside, of course, is that anything which hasn’t been developed within a given repository will have to be treated as a third-party library or service — even if it was written by someone working in the same office!
As a result, if you as a developer were to find an error in a library you use, you would first have to fix it in the appropriate codebase before returning to your repository and modifying your own project as well.
From a security perspective, you will have to provide access to your entire source code to all teams involved in the project, so that’s the price for source code consistency and automatically checking dependencies.
Mono Repositories
By contrast, monorepo advocates claim that the friction introduced as a result of multiple repositories is more than enough reason to warrant thinking again. So much so, in fact, that the approach has been embraced by a plethora of large companies today.
You may be surprised to learn, for instance, that despite hosting more than 2 billion lines of code and possessing a long history of over 35 million commits, Google has successfully employed this strategy since at least the year 2000.
And this has certainly not been without its challenges, as over time, maintaining mono repositories requires serious thought and coordination. Because you are unable to split your codebase horizontally, for example, your business will require tools to scale in a vertical fashion.
The advantages, however, according to die-hard converts, are an improvement in work culture, since the business as a whole can work together as a single team; a reduction in code complexity, as all services may be duly standardised; and easier restructuring and refactoring, because everything should — at least in theory — be better organised in the same location.
The Choice Is Yours!
Just as one should never argue about football, politics or religion, when it comes to the mono vs multi-repositories debate, there is really no right or wrong.
Broadly speaking, SPG believe that while larger companies in general have a lot more to gain from the monorepo strategy, as they tend to possess a fair number of shared dependencies, smaller companies for their part would probably be well-advised to stick to the multi-repo approach.
Nonetheless, each strategy will come with its own set of drawbacks and benefits, so it is really up to your company to determine what will serve you the most.
