“Microservices = Multirepo”
It seems obvious, why centralize components whose purpose is to be distributed?
However, this is the choice that Theodo had to make for one of its customers in order to be able to continue to develop a growing product.
Darya Talanina shared the reasons for migrating 30 microservices to a Monorepo during a Devoxx conference edition.
This article shares their story illustrating the practices and results obtained through the prism of Quality Engineering.
Follow the QE Unit for more exclusive content of Quality Engineering.
The project starts with one repository per service
Some choices seem to come naturally.
In this case, that of having a repository per back-end project is set up, facing a front-end.
The Multirepo architecture then remains easily understandable.
The branching model is also distributed, based on:
- One to several feature branches per project
- Two stable branches dedicated to the “preprod” and “prod” environments
- A merge-request process by order of deployment.
This model allows developers to release features in their own repositories.
The first problems are starting to materialize
It’s comfortable to develop in your corner, without having to synchronize too much with the rest of the team.
Bad luck, collaboration is necessary to build a properly organized product to satisfy users.
The first need encountered is to centralize common rules in a common project, thus avoiding duplication.
