“Microservices = Multirepo”
Cela semble évident, pourquoi centraliser des composants dont leur vocation est d’être distribués?
C’est pourtant le choix que Theodo a dû réaliser pour l’un de ses clients pour pouvoir continuer à évoluer un produit en croissance.
Darya Talanina a partagé les raisons motivant à migrer 30 microservices vers un Monorepo lors d’une édition de la conférence Devoxx.
Cet article partage leur histoire illustrant les pratiques et les résultats obtenus sous le prisme du Quality Engineering.
Suivez la QE Unit pour plus de contenu exclusif de Quality Engineering.
Le projet démarre avec un repository par service
Certains choix semblent s’imposer naturellement.
Dans ce cas, celui d’avoir un repository par projet de back-end est mis en place, face à un front-end.
L’architecture en Multirepo reste alors facilement compréhensible.
Le modèle de branching est lui aussi distribué, reposant sur:
- Une à plusieurs branches de feature par projet
- Deux branches stables dédiées aux environnements de “preprod” et “prod”
- Un processus de merge-request par ordre de déploiement.
Ce modèle permet à des développeurs de délivrer des fonctionnalités dans leurs propres repository.
Les premiers problèmes commencent à se matérialiser
C’est confortable de développer dans son coin, sans trop avoir besoin de se synchroniser avec le reste de l’équipe.
Pas de chance, la collaboration est nécessaire pour construire un produit correctement organisé pour satisfaire les utilisateurs.
Le premier besoin rencontré est de centraliser des règles communes dans un projet commun, évitant ainsi la duplication.
Sur le papier, suivre le principe d’éviter la duplication de code semble une bonne idée.
Des premières douleurs se font néanmoins ressentir de la part des développeurs, même pour faire des choses simples.
Chaque changement pour un composant référencé implique d’en faire la mise à jour dans les différents repository concernés.
Cela veut dire plusieurs minutes systématiquement perdues, loin de la création de valeur.
La croissance du produit accélère le point de rupture
Il y a cependant de bonnes nouvelles : le produit trouve son marché et nécessite des développements additionnels.
L’architecture du projet passe de 11 à 31 microservices organisés en Multirepo dans le même standard technologique.
L’équipe commence par contre á être saturée :
- Le build initial de 5 minutes laissant le temps de prendre un café prend maintenant jusqu’á 2h30, de quoi faire une overdose
- Certains pull-requests sont oubliés dans un tel essaim, créant régulièrement des bugs en production
- La mise en place de pratiques communes requiert 30 actions dans des repository différents, que personne n’a envie de réaliser.
Darya résume clairement la situation alarmante.
Heavy git workflow prevents us from improving developer experience and code quality.
Darya Talanina, Fullstack Developer @ Theodo.
En plus des développeurs, ce sont les propriétaires du produit et les clients qui s’impatientent.
Tout ce temps perdu dans des mises à jour sont loin d’apporter la valeur attendue dans les temps.
Les services sont migrés du Multirepo vers un Monorepo
La décision est prise de basculer du Multirepo vers un Monorepo pour l’ensemble des services back-end.
La migration consiste à basculer un à un les projets dans le nouveau repository centralisé.
Cette centralisation pose d’ailleurs la question du build et du déploiement quand plus de changements seront réalisés sur la même base.
Une pipeline d’intégration continue est mise en place pour rapidement donner du feedback sur les push de code.
La pipeline d’intégration continue nécessite des optimisations
Le passage d’un modèle décentralisé à centralisé ne résout pas la problématique du temps de build des projets.
Le Monorepo pose la problématique de savoir quels projets compiler lors d’un changement, et lesquels faire en parallèle.
La première solution est d’utiliser des tags pour spécifier les mises à jour structurantes du repository.
L’explicitation des dépendances permet ensuite de ne compiler que les projets impactés par un changement
La parallélisation est ensuite pris en charge par la pipeline d’intégration continue.
Les développeurs peuvent enfin délivrer la valeur attendue dans les temps.
Le Quality at Speed devient accessible passé la migration
Le Monorepo et sa pipeline d’intégration continue permettent de livrer des changements en 10 minutes.
Le jour et la nuit quand il fallait auparavant des heures.
L’équipe a encore des challenges à résoudre : automatisation de tests et leur intégration dans la pipeline, déploiement progressif, etc.
L’important est qu’á date l’équipe soit capable de délivrer de valeur en flux tendu avec le minimum d’efforts.
Le Quality Engineering n’a pas besoin d’être complexe, il doit contraindre la chaîne logicielle au Quality at Speed avec le minimum de Complexity.
Et vous, avez-vous besoin d’un Monorepo?
Références
Devoxx, Migrating 30 Microservices to a Monorepository https://www.softdevtube.com/2021/10/14/migrating-30-microservices-to-a-monorepository/
Suivez Darya Talanina sur GitHub et Twitter
Plus d’informations sur Theodo.