Le débat du monorepo et du multirepo se révèle souvent animé entre les équipes.
Pour complexifier la tâche, des variantes des modèles coeur sont apparues, parfois dans un objectif de vouloir plaire à tout le monde.
La réalité est qu’un repository est uniquement le stockage du code source, se retrouvant structurant dans son intégration et impacts dans le reste des processus.
Cet article a pour but de prendre du recul sur le sujet des repository : leurs caractéristiques, définitions et diverses options.
Rejoignez la QE Unit pour accéder à plus de contenu exclusif de la communauté.
Qu’est-ce qu’un repository ?
Votre repository est le stockage de votre code source.
Un code qui est devenu pour un bon nombre d’entreprises l’un de leur principal actif, sans forcément s’en rendre compte.
Google a par exemple accumulé depuis 2015 l’impressionnant volume de 2 milliards de lignes de code représentant 84 Tb de stockage.
C’est en fait par cette croissance, tendance à l’entropie et à l’extension du code source que nous avons besoin d’en organiser son stockage.
Comme des photos ou des livres que l’on accumule, structurer leur rangement en albums et librairies est nécessaire afin de s’y retrouver.
Nous rencontrons le même défi dans l’industrie du logiciel, y additionnant des composantes technologiques.
Un repository est-il uniquement le stockage du code ?
En tant que tel, oui.
Pour ce qu’il n’est pas, vous pouvez consulter cet article sur les x mythes des repos.
Pourquoi est-ce donc un sujet de choix si important?
Le stockage du code et son organisation reste complexe par son intégration avec le reste de l’écosystème.
L’organisation du stockage du code entre fichiers, projets, librairies va matérialiser les interactions nécessaires à l’évolution du code source.
Sa structuration doit être utilisable par les différentes équipes.
Cette structuration va impacter les mécanismes de communication, processus de développement et j’en passe.
L’accès au code est bien ce qui finit par être utilisé par les développeurs dans leur environnement de développement, téléchargé localement ou configuré dans des pipelines de CI/CD.
Il faut garder en tête qu’un choix d’organisation de repository est structurant pour l’atteinte des objectifs globalement poursuivis.
Quelles options de repos sont possibles ?
Prenons du recul pour avoir une meilleure perspective d’ensemble.
Au cœur du sujet des repository, plusieurs options se dégagent à différents niveaux.
Nous avons 2 options structurantes pour l’organisation du code source :
- Centralisé, connu également sous le terme “monorepo”
- Décentralisé, correspondant au modèle “multirepo”
Ces alternatives sont applicables à plusieurs niveaux dans une architecture logicielle :
- Globalement pour l’entièreté du code source d’une organisation jusqu’au stockage du projet ou d’une fonction isolée
- Transversalement par le stockage de fonctions transverses et partagées entre différents projets
- Tant pour du code d’application métier, de test que d’infrastructure (depuis que géré en As Code) ou d’autres fichiers
Les 4 modèles suivants à l’échelle de l’organisation se dégagent dans l’industrie :
- « Monorepo » (ou “one-repo”, “uni-repo”)
- “Multirepo” (ou “many-repo”)
- “Hybrid-repo”
- “Split-repo”
Cela fait beaucoup de variations ?
Et encore, nous avons évité les diverses variations de “repo”, “-Repo” et “Repository” dans un but de lisibilité.
Qu’est-ce qu’un Monorepo ?
Démarrons par le fameux modèle complètement centralisé, le monorepo.
A monorepo (mono repository) is a single repository that stores all of your code and assets for every project.
C’était historiquement notre seule option dans un monde fait de Mainframes et autres systèmes aujourd’hui devenus legacy.
Les architectures décentralisées de type SOA ou microservices lui ont valu une perte d’intérêt, probablement à tort.
Gardons à l’esprit que le monorepo est l’organisation et le stockage du code, sans directement être l’architecture possible de l’application.
Un monorepo peut donc être composé de plusieurs projets, applications et technologies différentes plus ou moins couplées par des services ou librairies partagées.
Stocker l’entièreté de son code source ne signifie pas que nous devons compiler l’entièreté du projet à chaque changement.
Un couplage fort du cycle de déploiement et du repository se matérialisent dans le cas d’une application en monolith stockée en monorepo.
D’ailleurs, tenter de stocker une application monolith en multirepo ne semble pas le plus adapté à premier abord.
Passons donc à son opposé, le multirepo.
Qu’est-ce qu’un Multirepo ?
Démarrons également par une ligne de définition de ce modèle complètement décentralisé.
Multirepos uses multiple repositories for the source code management version control system.
Une organisation multirepo implique plusieurs éléments :
- L’utilisation de plusieurs repository, souvent un par application
- L’absence de dépendance de code directement entre projets (théoriquement?)
Un mix des technologies du système de versioning est donc possible, par exemple entre Git et SVN, même si cela a d’autres impacts dans la chaîne d’intégration.
C’est un modèle qui a été largement adopté depuis la distribution des applications, sans forcément que ce soit un choix pondéré.
L’organisation interne de chaque repo, projet et ses répertoires reste à structurer.
Gardons en tête qu’un système décentralisé aura tendance à s’optimiser localement, parfois au détriment de votre système global.
Le multirepo n’est pas à confondre avec un autre modèle dit d’”Hybrid repo” ou son mutant, le “Split repo” décrits ci-après.
Qu’est-ce qu’un Hybrid repo?
Un “Hybrid repo” repose sur l’utilisation mixte des modèles de mono et de multirepo.
Hybrid repos use a combination of repositories, some being a monorepo and other being multirepos. At the end, they still store the source code of various projects.
Un “Hybrid repo” peut se limiter au stockage d’une application monolith en monorepo, tandis que des services distribués le seront en multi-repo.
Complémentairement, un repository hybride peut supporter le partage de fonctions et de librairies entre équipes.
On revient donc à un monorepo?
Pas dans ce modèle, les librairies partagées devant rester rapidement compilables et le repository d’une taille modérée, par exemple à la dimension d’une équipe.
Cela vous semble un choix bancal?
Il est vrai que l’on se demande pourquoi choisir du multi-repo pour finalement atteindre l’objectif du monorepo : le partage direct de code.
Le modèle du split-repo est une alternative à ce besoin.
Qu’est-ce qu’un split-repo ?
Nous retrouverons souvent l’acronyme “read-only” associé au split-repo.
A split-repo is a monorepo, used for code storage, that is split into read-only repos for building and releasing project artifacts independently.
Antoine Craske
On comprend que le split-repo est un modèle qui veut combiner les avantages des deux modèles principaux :
- Le monorepo pour un stockage du code centralisé permettant le partage de librairies et intégration au plus tôt
- Le multi-repo afin de réaliser des déploiements plus granulaires, indépendants et plus rapides
Comme pour un SI, on retrouve dans le multi-repo en “ready-only” le concept du propriétaire de la donnée et de divers replicas pour en garantir sa cohérence.
C’est un modèle souvent choisi par des organisations préférant un modèle monorepo mais nécessitant fortement d’isoler des déploiements par technologies.
Que retenir de ces différents modèles de repo ?
L’objectif de cet article était de fournir la perspective globale et description de chacun des modèles.
Les points principaux à retenir :
- Votre repository est le stockage de votre code source
- Votre repository n’est pas votre chaîne de déploiement, modèle de branching, gestion de dépendances, processus de review ou de communication
- Votre choix de modèle de repository est structurant car intimement intégré au processus de développement
- Deux grandes alternatives existent : centralisé et décentralisé
- Quatre choix sont possibles : mono-repo, multi-repo, hybrid-repo, split-repo
Des acteurs à l’échelle tels que Google sont efficaces avec du monorepo, tandis qu’un Netflix l’est sur un modèle multirepo.
Il n’y a donc pas forcément de formule magique, pour par exemple choisir un modèle en fonction de la taille d’entreprises.
Comment choisir entre les différentes options de repos?
Le choix de modèle repository donc être pris en fonction du contexte actuel et futur de chaque organisation, de ses objectifs, tout en s’organisant pour gérer leurs trade-offs.
C’est un bon sujet de réflexion également applicable aux tests : Vous pouvez surmonter le dilemme du repo de tests
Références
https://medium.com/@mattklein123/monorepos-please-dont-e9a279be011b
https://hackernoon.com/mono-repo-vs-multi-repo-vs-hybrid-whats-the-right-approach-dv1a3ugn