The famous repo’s dilemma.
This subject provokes lively debates in teams defending Mono or Mutirepo as the choice to be made.
This type of exchange may seem endless, and what is more, far from the business need.
The choice of repo model directly impacts the ability of actors to iterate quickly on the software chain.
This article shares how to align your repository according to your context to deliver Quality at Speed.
Follow the QE Unit for more exclusive content from Quality Engineering.
Understand the implications of the alternatives
Having perspective on a problem and its possible solutions gives a better view of the implications specific to each alternative.
In the case of the repo, this allows us to identify the pros and cons while remaining factual.
Quality, Speed, Complexity are the axes of evaluation in Quality Engineering.
Without debating for hours, the Multirepo has a notch of complexity superior to the Monorepo by the distribution inherent in the model.
Distributed architectures – although compatible in both models – have largely contributed to popularizing multirepo for the wrong reasons.
Here’s how to decide.
If you’re starting, use a Monorepo
Use a Monorepo if you’re starting or migrating a project with version control.
The Monorepo is a simple and quickly operable solution allowing the collaboration of a small team.
A Multirepo would just slow everything down.
Your priority is fast end-to-end iterations; so don’t make it more complex with multiple and inefficient branch systems.
The architectural point to secure is to modularize your code to facilitate scalability and possible in-service isolation thereafter.
Keep the Monorepo in a period of growth
In the event that the start-up finds its market, you will enter a period of growth requiring improvement of your product.
You will be challenged to deliver more features with more code and more developers.
At least one of them will push for moving to Multirepo.
The arguments of separation, decoupling and scalability will come into play, without necessarily being very explicit as to the business objectives.
You need to stay the course to avoid creating your own problems with more technology.
Make sure to deploy easily in Monorepo
Regardless of the model, the goal is to maintain a capacity to deliver value just in time, with speed and stability.
Before evaluating any model change, make sure you can deploy several times a day with confidence.
As for children, it is already complicated with one, and even more so with several.
Your repository must be supported by processes and tools aligned with your challenges and organizational models.
It is also only these criteria that could make you change your model.
Consider a Multirepo with maturity and alignment
The switch to a Multirepo must be motivated by a business desire that is then cascaded into the culture and structure of the organization.
Once the previous stages of growth and just-in-time delivery, a Multi repo can support the decentralization of an organization.
Still, it has to be a business choice.
Large companies made a separation of its historical Monorepo into two large repo to isolate the complexity between its front and back office.
Google is on the contrary known to have maintained the repo model for most of its code base.
Choose between Mono and Multirepo for Quality at Speed
Technology remains the way to solve problems for your users, without wanting to complicate their lives.
Maintaining a just-in-time software delivery chain becomes more complex in an environment that is constantly reinventing itself.
The simplest choice reduces complexity and the possibility of inducing additional debt, a differentiating factor of acceleration.
You don’t have time to waste between different repositories as long as the size and the organizational model justify it.
A good number of companies backtrack from Multi to Monorepo when they can no longer deliver changes on time.
This is also the case of Theodo.