Stratégies de gestion de code : Mono-repo versus Multi-repo
Les approches mono-repo et multi-repo constituent deux méthodes principales pour l’hébergement et la gestion du code via Git. Cet article examine en détail ces stratégies, leurs avantages et leurs inconvénients.
Introduction aux dépôts Git
La majorité des projets contemporains utilisent Git pour la gestion et l’hébergement. Git s’est imposé comme la plateforme de référence pour la gestion distribuée du code source, le contrôle des versions et la collaboration mondiale. Sa rapidité et son efficacité en font un outil privilégié. Il existe deux approches majeures pour organiser et gérer votre code avec Git :
Avant d’examiner ces approches plus en profondeur, il est crucial de comprendre le fonctionnement d’un dépôt.
Comprendre les dépôts
Un dépôt (repo) regroupe tous les dossiers et fichiers d’un projet. Il contient également des informations sur les collaborateurs et leurs ordinateurs.
Les données du dépôt sont soumises au contrôle de version. Un dépôt peut être géré par un individu ou par une équipe.
Git constitue un dépôt en lui-même. Il peut être public, privé ou interne. GitHub est un service d’hébergement de dépôts Git doté d’une interface utilisateur.
Git propose des fonctionnalités de contrôle de version et de partage de code. Sa particularité réside dans la possibilité pour les développeurs de copier l’intégralité du dépôt sur leur système local afin d’apporter des modifications. Cela permet de travailler sur un projet même sans accès en écriture direct (cette action est appelée « forking »).
De plus, si un développeur souhaite partager les modifications locales, il peut soumettre une « pull request » au propriétaire du projet.
Un projet peut se limiter à un seul service. Cependant, les grands projets sont souvent segmentés en services indépendants, chacun avec une ou plusieurs fonctions. Ces services peuvent résoudre divers problèmes métier. Avec l’essor des frameworks sans serveur, ces fonctions sont accessibles en tant que services.
Une fois ces fonctions créées en tant que services et déployées, il faut structurer leur contrôle de version. Vous pouvez soit placer tous les services dans un seul dépôt (approche mono-repo), soit créer un dépôt distinct pour chaque service (approche multi-repo) !
Le Concept du Mono-repo
Dans une stratégie mono-repo, l’ensemble des services d’un projet sont stockés dans un seul dépôt. Chaque service peut être déployé et géré de manière indépendante, tout en partageant des bibliothèques et du code commun.
Des entreprises telles que Facebook, Google et Dropbox ont opté pour cette approche.
Avantages du Mono-repo
L’approche mono-repo présente plusieurs avantages notables :
- Centralisation du code : un point unique pour l’ensemble du code, accessible à tous les membres de l’équipe.
- Réutilisation du code : facilité de partage et de réutilisation du code, favorisant la collaboration.
- Visibilité des changements : compréhension aisée de l’impact des modifications sur l’ensemble du projet.
- Optimisation des refactorings : idéal pour la refactorisation du code et les modifications majeures.
- Vue d’ensemble du projet : les équipes ont une vision globale de la structure du projet.
- Gestion simplifiée des dépendances.
Inconvénients du Mono-repo
Malgré ses avantages, le mono-repo présente des inconvénients, notamment en termes de performances. L’ajout fréquent de fichiers peut ralentir les opérations d’extraction, de récupération, et rendre la recherche de fichiers plus laborieuse.
De plus, l’accès à l’intégralité du code pour des contractants externes peut poser des problèmes de sécurité.
Enfin, la mise en œuvre de déploiements continus (CD) peut s’avérer complexe, car les multiples modifications des différents contributeurs peuvent entraîner des reconstructions fréquentes.
Les grandes entreprises qui utilisent les mono-repos ont généralement des outils personnalisés pour gérer les problèmes de mise à l’échelle. Par exemple, Facebook utilise un système de fichiers et un contrôle de code source adaptés.
Le Modèle Multi-repo
Dans une approche multi-dépôts, les services et bibliothèques d’un projet sont hébergés dans différents dépôts. Lorsqu’un service est modifié, seul celui-ci doit être reconstruit. Les développeurs et les équipes travaillent sur des services spécifiques, avec un accès limité aux autres.
Netflix et Amazon font partie des entreprises utilisant cette approche.
Avantages du Multi-repo
L’approche multi-repo est adoptée par un grand nombre d’entreprises, pour les raisons suivantes :
- Contrôle de version individualisé : chaque service et bibliothèque a son propre cycle de version.
- Performances optimisées : les opérations d’extraction et de récupération sont rapides, même avec la croissance du projet.
- Indépendance des équipes : les équipes travaillent de manière autonome, avec un accès limité au code.
- Développement rapide et flexible.
- Déploiement simplifié : chaque service peut être déployé séparément, facilitant l’intégration continue (CI) et le déploiement continu (CD).
- Contrôle d’accès amélioré : les équipes ont un accès spécifique à certains services et bibliothèques.
Inconvénients du Multi-repo
- Synchronisation des dépendances : une mise à jour régulière des dépendances entre les différents services est nécessaire.
- Culture en silos : un manque de collaboration peut mener à la duplication de code et à des efforts redondants.
- Hétérogénéité des pratiques : différentes équipes peuvent adopter des pratiques de codage différentes, rendant difficile le respect des meilleures pratiques communes.
Comparaison entre Mono et Multi Repo
Voici un résumé des différences entre mono-repo et multi-repo :
| Mono-repo | Multi-repo |
| L’ensemble du code d’une organisation est centralisé dans un seul dépôt. | Chaque service et projet possède son propre dépôt. |
| Les équipes collaborent et peuvent observer les changements mutuels. | Les équipes travaillent de manière autonome, sans être affectées par les modifications des autres équipes. |
| Chaque contributeur a accès à l’ensemble de la structure du projet. | L’accès est contrôlé, limité au projet ou au service auquel le développeur a besoin d’accéder. |
| Les problèmes de mise à l’échelle peuvent survenir si la taille du projet croît rapidement. | Les performances sont généralement bonnes grâce à un code fragmenté et des unités de service réduites. |
| L’implémentation du déploiement continu (CD) et de l’intégration continue (CI) peut être complexe. | Le CD et le CI sont plus faciles à mettre en place, car les services peuvent être construits indépendamment. |
| Le partage de bibliothèques, d’APIs et d’autres codes communs est facilité par la centralisation. | Les modifications apportées aux bibliothèques et au code commun doivent être synchronisées pour éviter des problèmes. |
Conclusion
Les approches mono-repo et multi-repo sont largement utilisées. Le choix de l’une ou l’autre dépend de la taille du projet, de ses exigences, ainsi que du niveau de contrôle de version et d’accès souhaité.
Le mono-repo favorise la cohérence, tandis que le multi-repo privilégie le découplage. Alors que dans un mono-repo, toute l’équipe peut voir les changements effectués par une seule personne, le multi-repo crée un dépôt distinct pour chaque équipe, qui n’a accès qu’aux services requis. Si vous souhaitez combiner les avantages des deux approches, des outils comme meta peuvent vous aider à gérer plusieurs projets et bibliothèques.
Vous pourriez également être intéressé par des ressources gratuites pour apprendre Git.