Your Microservices May Need A Monorepo For Quality At Speed

QE Unit
5 min readMar 24, 2022

“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.

Figure 1: The initial Multirepo for the back-end.

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.
Figure 2: The branching model for projects in Multirepo.

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.



QE Unit

The Quality Engineering Unit is a community dedicated to improving our software quality practices through transversality — for more