{"id":48049,"date":"2021-08-25T17:21:11","date_gmt":"2021-08-25T15:21:11","guid":{"rendered":"https:\/\/kinsta.com\/?p=100242"},"modified":"2023-09-12T15:51:50","modified_gmt":"2023-09-12T14:51:50","slug":"mono-repo-vs-multi-repo","status":"publish","type":"post","link":"https:\/\/kinsta.com\/fr\/blog\/mono-repo-vs-multi-repo\/","title":{"rendered":"Mono-repo vs Multi-repo : Avantages et inconv\u00e9nients des strat\u00e9gies de d\u00e9p\u00f4t de code"},"content":{"rendered":"

Il existe deux strat\u00e9gies principales pour l’ h\u00e9bergement<\/a> et la gestion du code via Git : mono-repo vs multi-repo. Les deux approches ont leurs avantages et leurs inconv\u00e9nients.<\/p>\n

Nous pouvons utiliser l’une ou l’autre approche pour n’importe quelle base de code dans n’importe quelle langue. Vous pouvez utiliser n’importe laquelle de ces strat\u00e9gies pour des projets contenant une poign\u00e9e de biblioth\u00e8ques<\/a> \u00e0 des milliers d’entre elles. M\u00eame si cela implique quelques membres de l’\u00e9quipe ou des centaines, ou si vous souhaitez h\u00e9berger du code priv\u00e9 ou open source, vous pouvez toujours opter pour le mono-repo ou le multi-repo en fonction de divers facteurs.<\/p>\n

Quels sont les avantages et les inconv\u00e9nients de chaque approche ? Quand doit-on utiliser l’une ou l’autre ? D\u00e9couvrons-le !<\/p>\n

<\/div><\/kinsta-auto-toc>\n

Que sont les d\u00e9p\u00f4ts ?<\/h2>\n

Un d\u00e9p\u00f4t (repository ou repo) est un stockage pour toutes les modifications et tous les fichiers d’un projet, permettant aux d\u00e9veloppeurs de \u00ab contr\u00f4ler la version \u00bb des ressources du projet tout au long de sa phase de d\u00e9veloppement.<\/p>\n

Nous nous r\u00e9f\u00e9rons g\u00e9n\u00e9ralement aux r\u00e9f\u00e9rentiels Git<\/a> (tels que fournis par GitHub<\/a> , GitLab<\/a> ou Bitbucket<\/a> ), mais le concept s’applique \u00e9galement \u00e0 d’autres syst\u00e8mes de contr\u00f4le de version (tels que Mercurial).<\/p>\n\n

Qu’est-ce qu’un mono-repo ?<\/h2>\n

L’approche mon-orepo utilise un d\u00e9p\u00f4t<\/a> unique pour h\u00e9berger tout le code des multiples biblioth\u00e8ques ou services composant les projets d’une entreprise. \u00c0 l’extr\u00eame, l’ensemble de la base de code d’une entreprise – couvrant divers projets et cod\u00e9 dans diff\u00e9rentes langues – est h\u00e9berg\u00e9 dans un seul r\u00e9f\u00e9rentiel.<\/p>\n

Avantages de mono-repo<\/h2>\n

L’h\u00e9bergement de l’ensemble de la base de code sur un seul d\u00e9p\u00f4t offre les avantages suivants.<\/p>\n

Abaisse les barri\u00e8res \u00e0 l’entr\u00e9e<\/h3>\n

Lorsque de nouveaux membres du personnel commencent \u00e0 travailler pour une entreprise, ils doivent t\u00e9l\u00e9charger le code et installer les outils n\u00e9cessaires pour commencer \u00e0 travailler sur leurs t\u00e2ches. Supposons que le projet soit dispers\u00e9 dans de nombreux r\u00e9f\u00e9rentiels, chacun ayant ses instructions d’installation et l’outillage requis. Dans ce cas, la configuration initiale sera complexe et, le plus souvent, la documentation ne sera pas compl\u00e8te, obligeant ces nouveaux membres de l’\u00e9quipe \u00e0 demander de l’aide \u00e0 leurs coll\u00e8gues.<\/p>\n

Un mono-repo simplifie les choses. Comme il existe un seul emplacement contenant tout le code et la documentation<\/a>, vous pouvez rationaliser la configuration initiale.<\/p>\n

Gestion de code centralis\u00e9e<\/h3>\n

Avoir un d\u00e9p\u00f4t unique donne une visibilit\u00e9 de tout le code \u00e0 tous les d\u00e9veloppeurs. Cela simplifie la gestion du code car nous pouvons utiliser un seul outil de suivi des probl\u00e8mes pour surveiller tous les probl\u00e8mes tout au long du cycle de vie de l’application.<\/p>\n

Par exemple, ces caract\u00e9ristiques sont pr\u00e9cieuses lorsqu’un probl\u00e8me s’\u00e9tend sur deux (ou plus) biblioth\u00e8ques enfants avec le bogue existant sur la biblioth\u00e8que d\u00e9pendante. Avec plusieurs d\u00e9p\u00f4ts, il peut \u00eatre difficile de trouver le morceau de code<\/a> o\u00f9 le probl\u00e8me se produit.<\/p>\n

En plus de cela, nous aurions besoin de d\u00e9terminer quel r\u00e9f\u00e9rentiel utiliser pour cr\u00e9er le probl\u00e8me, puis d’inviter et de signaler les membres d’autres \u00e9quipes pour aider \u00e0 r\u00e9soudre le probl\u00e8me.<\/p>\n

Avec un mono-repo, cependant, la localisation des probl\u00e8mes de code et la collaboration pour le d\u00e9pannage deviennent plus simples \u00e0 r\u00e9aliser.<\/p>\n

Refactorisations indolore \u00e0 l’\u00e9chelle de l’application<\/h3>\n

Lors de la cr\u00e9ation d’une refactorisation du code \u00e0 l’\u00e9chelle de l’application, plusieurs biblioth\u00e8ques seront affect\u00e9es. Si vous les h\u00e9bergez via plusieurs d\u00e9p\u00f4ts, la gestion de toutes les diff\u00e9rentes demandes d’extraction (pull request) pour les maintenir synchronis\u00e9es les unes avec les autres peut s’av\u00e9rer \u00eatre un d\u00e9fi.<\/p>\n

Un mono-repo permet d’effectuer facilement toutes les modifications de tout le code pour toutes les biblioth\u00e8ques et de le soumettre sous une seule pull request.<\/p>\n

Plus difficile de casser la fonctionnalit\u00e9 adjacente<\/h3>\n

Avec le mono-repo, nous pouvons configurer tous les tests pour toutes les biblioth\u00e8ques \u00e0 ex\u00e9cuter chaque fois qu’une seule biblioth\u00e8que est modifi\u00e9e. En cons\u00e9quence, la probabilit\u00e9 de faire un changement dans certaines biblioth\u00e8ques a minimis\u00e9 les effets n\u00e9gatifs sur d’autres biblioth\u00e8ques.<\/p>\n

Les \u00e9quipes partagent une culture de d\u00e9veloppement<\/h3>\n

M\u00eame si cela n’est pas impossible, avec une approche mono-repo, il devient difficile d’inspirer des sous-cultures uniques parmi diff\u00e9rentes \u00e9quipes. Puisqu’ils partageront le m\u00eame d\u00e9p\u00f4t, ils partageront tr\u00e8s probablement les m\u00eames m\u00e9thodologies de programmation<\/a> et de gestion et utiliseront les m\u00eames outils de d\u00e9veloppement<\/a>.<\/p>\n

Probl\u00e8mes avec l’approche mono-repo<\/h2>\n

L’utilisation d’un d\u00e9p\u00f4t unique pour tout notre code pr\u00e9sente plusieurs inconv\u00e9nients.<\/p>\n

Cycles de d\u00e9veloppement plus lents<\/h3>\n

Lorsque le code d’une biblioth\u00e8que contient des modifications avec rupture, qui font \u00e9chouer les tests des biblioth\u00e8ques d\u00e9pendantes, le code doit \u00e9galement \u00eatre corrig\u00e9 avant de fusionner les modifications.<\/p>\n

Si ces biblioth\u00e8ques d\u00e9pendent d’autres \u00e9quipes, qui sont occup\u00e9es \u00e0 travailler sur une autre t\u00e2che et ne sont pas en mesure (ou ne veulent pas) d’adapter leur code pour \u00e9viter les changements de rupture et r\u00e9ussir les tests, le d\u00e9veloppement de la nouvelle fonctionnalit\u00e9 peut s’arr\u00eater.<\/p>\n

De plus, le projet pourrait bien ne commencer \u00e0 avancer qu’\u00e0 la vitesse de l’\u00e9quipe la plus lente de l’entreprise. Ce r\u00e9sultat pourrait frustrer les membres des \u00e9quipes les plus rapides, cr\u00e9ant des conditions pour qu’ils veuillent quitter l’entreprise.<\/p>\n

De plus, une biblioth\u00e8que devra \u00e9galement ex\u00e9cuter les tests pour toutes les autres biblioth\u00e8ques. Les autres tests \u00e0 ex\u00e9cuter<\/a>, plus le temps qu’il faut pour les faire fonctionner, ce qui ralentit la fa\u00e7on dont nous pouvons rapidement it\u00e9rer sur notre code.<\/p>\n

N\u00e9cessite le t\u00e9l\u00e9chargement de la base de code enti\u00e8re<\/h3>\n

Lorsque le mono-repo contient tout le code d’une entreprise, il peut \u00eatre \u00e9norme, contenant des gigaoctets de donn\u00e9es. Pour contribuer \u00e0 n’importe quelle biblioth\u00e8que h\u00e9berg\u00e9e \u00e0 l’int\u00e9rieur, n’importe qui aurait besoin d’un t\u00e9l\u00e9chargement de l’ensemble du r\u00e9f\u00e9rentiel.<\/p>\n

Traiter avec une vaste base de code implique une mauvaise utilisation de l’espace sur nos disques durs et des interactions plus lentes avec celui-ci. Par exemple, les actions quotidiennes telles que l’ex\u00e9cution git status<\/code> ou la recherche dans la base de code avec une expression r\u00e9guli\u00e8re peuvent prendre plusieurs secondes voire plusieurs minutes de plus qu’avec plusieurs d\u00e9p\u00f4ts.<\/p>\n

Les biblioth\u00e8ques non modifi\u00e9es peuvent avoir une nouvelle version<\/h3>\n

Lorsque nous balisons<\/a> le mono-repo, tout le code est attribu\u00e9 au sein de la nouvelle balise. Si cette action d\u00e9clenche une nouvelle version, alors toutes les biblioth\u00e8ques h\u00e9berg\u00e9es dans le d\u00e9p\u00f4t seront nouvellement publi\u00e9es avec le num\u00e9ro de version de la balise, m\u00eame si nombre de ces biblioth\u00e8ques n’ont subi aucun changement.<\/p>\n

Le fork est plus difficile<\/h3>\n

Les projets open source doivent faciliter au maximum l’implication des contributeurs. Avec plusieurs d\u00e9p\u00f4ts, les contributeurs peuvent se diriger directement vers le d\u00e9p\u00f4t sp\u00e9cifique du projet auquel ils souhaitent contribuer. Avec un mono-repo h\u00e9bergeant divers projets, cependant, les contributeurs doivent d’abord se frayer un chemin dans le bon projet et devront comprendre comment leur contribution peut affecter tous les autres projets.<\/p>\n

Qu’est-ce que le multi-repo ?<\/h2>\n

L’approche multi-repo utilise plusieurs d\u00e9p\u00f4t pour h\u00e9berger les multiples biblioth\u00e8ques ou services d’un projet d\u00e9velopp\u00e9 par une entreprise. \u00c0 son extr\u00eame, il h\u00e9bergera chaque ensemble minimum de code r\u00e9utilisable ou de fonctionnalit\u00e9 autonome (telle qu’un micro-service) sous son d\u00e9p\u00f4t.<\/p>\n

Avantages du multi-repo<\/h2>\n

H\u00e9berger chaque biblioth\u00e8que ind\u00e9pendamment de toutes les autres offre une pl\u00e9thore d’avantages.<\/p>\n

Gestion des versions de biblioth\u00e8que ind\u00e9pendante<\/h3>\n

Lors du balisage d’un d\u00e9p\u00f4t, l’ensemble de sa base de code se voit attribuer la \u00ab nouvelle \u00bb balise. \u00c9tant donn\u00e9 que seul le code d’une biblioth\u00e8que sp\u00e9cifique se trouve dans le d\u00e9p\u00f4t, la biblioth\u00e8que peut \u00eatre balis\u00e9e et versionn\u00e9e ind\u00e9pendamment de toutes les autres biblioth\u00e8ques h\u00e9berg\u00e9es ailleurs.<\/p>\n

Avoir une version ind\u00e9pendante pour chaque biblioth\u00e8que aide \u00e0 d\u00e9finir l’arbre de d\u00e9pendances de l’application, nous permettant de configurer la version de chaque biblioth\u00e8que \u00e0 utiliser.<\/p>\n

Versions de service ind\u00e9pendantes<\/h3>\n

\u00c9tant donn\u00e9 que le d\u00e9p\u00f4t ne contient que le code d’un service et rien d’autre, il peut avoir son propre cycle de d\u00e9ploiement, ind\u00e9pendamment de tout progr\u00e8s r\u00e9alis\u00e9 sur les applications qui y acc\u00e8dent.<\/p>\n

Le service peut utiliser un cycle de publication rapide tel que la livraison continue (o\u00f9 le nouveau code est d\u00e9ploy\u00e9 apr\u00e8s avoir r\u00e9ussi tous les tests). Certaines biblioth\u00e8ques acc\u00e9dant au service peuvent utiliser un cycle de publication plus lent, comme celles qui ne produisent une nouvelle version qu’une fois par semaine.<\/p>\n

Aide \u00e0 d\u00e9finir le contr\u00f4le d’acc\u00e8s dans toute l’organisation<\/h3>\n

Seuls les membres de l’\u00e9quipe impliqu\u00e9s dans le d\u00e9veloppement d’une biblioth\u00e8que doivent \u00eatre ajout\u00e9s au d\u00e9p\u00f4t correspondant et t\u00e9l\u00e9charger son code. Par cons\u00e9quent, il existe une strat\u00e9gie de contr\u00f4le d’acc\u00e8s implicite pour chaque couche de l’application<\/a> . Les personnes impliqu\u00e9es dans la biblioth\u00e8que se verront accorder des droits d’\u00e9dition, et tout le monde n’aura peut-\u00eatre pas acc\u00e8s au d\u00e9p\u00f4t. Ou ils peuvent recevoir des droits de lecture mais pas d’\u00e9dition.<\/p>\n

Permet aux \u00e9quipes de travailler de mani\u00e8re autonome<\/h3>\n

Les membres de l’\u00e9quipe peuvent concevoir l’architecture de la biblioth\u00e8que et impl\u00e9menter son code en travaillant ind\u00e9pendamment de toutes les autres \u00e9quipes. Ils peuvent prendre des d\u00e9cisions en fonction de ce que fait la biblioth\u00e8que dans le contexte g\u00e9n\u00e9ral sans \u00eatre affect\u00e9s par les exigences sp\u00e9cifiques d’une \u00e9quipe ou d’une application externe.<\/p>\n

Probl\u00e8mes avec l’approche multi-repo<\/h2>\n

L’utilisation de plusieurs d\u00e9p\u00f4t peut entra\u00eener plusieurs probl\u00e8mes.<\/p>\n

Les biblioth\u00e8ques doivent \u00eatre constamment resynchronis\u00e9es<\/h3>\n

Lorsqu’une nouvelle version d’une biblioth\u00e8que contenant des modifications de rupture est publi\u00e9e, les biblioth\u00e8ques d\u00e9pendant de cette biblioth\u00e8que devront \u00eatre adapt\u00e9es pour commencer \u00e0 utiliser la derni\u00e8re version. Si le cycle de publication de la biblioth\u00e8que est plus rapide que celui de ses biblioth\u00e8ques d\u00e9pendantes, elles pourraient rapidement se d\u00e9synchroniser les unes avec les autres.<\/p>\n

Les \u00e9quipes devront constamment se mettre \u00e0 jour pour utiliser les derni\u00e8res versions des autres \u00e9quipes. \u00c9tant donn\u00e9 que diff\u00e9rentes \u00e9quipes ont des priorit\u00e9s diff\u00e9rentes, cela peut parfois s’av\u00e9rer difficile \u00e0 r\u00e9aliser.<\/p>\n

Par cons\u00e9quent, une \u00e9quipe incapable de rattraper son retard peut finir par s’en tenir \u00e0 la version obsol\u00e8te de la biblioth\u00e8que dont elle d\u00e9pend. Ce r\u00e9sultat aura des implications sur l’application (en termes de s\u00e9curit\u00e9, de vitesse et d’autres consid\u00e9rations), et l’\u00e9cart de d\u00e9veloppement entre les biblioth\u00e8ques pourrait ne faire que s’\u00e9largir.<\/p>\n

Peut fragmenter les \u00e9quipes<\/h3>\n

Lorsque diff\u00e9rentes \u00e9quipes n’ont pas besoin d’interagir, elles peuvent travailler dans leurs propres silos. \u00c0 long terme, cela pourrait amener les \u00e9quipes \u00e0 produire leurs sous-cultures au sein de l’entreprise, par exemple en utilisant diff\u00e9rentes m\u00e9thodologies de programmation ou de gestion ou en utilisant diff\u00e9rents ensembles d’outils de d\u00e9veloppement.<\/p>\n

Si un membre de l’\u00e9quipe doit \u00e9ventuellement travailler dans une autre \u00e9quipe, il peut subir un choc culturel et apprendre une nouvelle fa\u00e7on de faire son travail.<\/p>\n

Mono-repo vs multi-Repo : principales diff\u00e9rences<\/h2>\n

Les deux approches traitent finalement du m\u00eame objectif : la gestion de la base de code. Par cons\u00e9quent, ils doivent tous les deux r\u00e9soudre les m\u00eames d\u00e9fis, notamment la gestion des versions, la promotion de la collaboration entre les membres de l’\u00e9quipe<\/a>, la gestion des probl\u00e8mes, l’ex\u00e9cution de tests, etc.<\/p>\n

Leur principale diff\u00e9rence concerne le timing des membres de l’\u00e9quipe pour prendre des d\u00e9cisions : soit en amont pour le mono-repo, soit en aval pour le multi-repo.<\/p>\n

Analysons cette id\u00e9e plus en d\u00e9tail.<\/p>\n

\u00c9tant donn\u00e9 que toutes les biblioth\u00e8ques sont versionn\u00e9es ind\u00e9pendamment dans le multi-repo, une \u00e9quipe qui publie une biblioth\u00e8que avec des modifications importantes peut le faire en toute s\u00e9curit\u00e9 en attribuant un nouveau num\u00e9ro de version majeure \u00e0 la derni\u00e8re version. D’autres groupes peuvent faire en sorte que leurs biblioth\u00e8ques d\u00e9pendantes s’en tiennent \u00e0 l’ancienne version et passent \u00e0 la nouvelle une fois leur code adapt\u00e9.<\/p>\n

Cette approche laisse la d\u00e9cision d’adapter toutes les autres biblioth\u00e8ques \u00e0 chaque \u00e9quipe responsable, qui peut le faire \u00e0 tout moment. Si elles le font trop tard et que de nouvelles versions de biblioth\u00e8ques sont publi\u00e9es, il deviendra de plus en plus difficile de combler le foss\u00e9 entre les biblioth\u00e8ques.<\/p>\n

Par cons\u00e9quent, alors qu’une \u00e9quipe peut it\u00e9rer rapidement et souvent sur son code, d’autres \u00e9quipes peuvent s’av\u00e9rer incapables de rattraper leur retard, produisant finalement des biblioth\u00e8ques qui divergent.<\/p>\n

D’un autre c\u00f4t\u00e9, dans un environnement mono-repo, nous ne pouvons pas publier une nouvelle version d’une biblioth\u00e8que qui casse une autre biblioth\u00e8que car leurs tests \u00e9choueront. Dans ce cas, la premi\u00e8re \u00e9quipe doit communiquer avec la deuxi\u00e8me \u00e9quipe pour int\u00e9grer les changements.<\/p>\n

Cette approche oblige les \u00e9quipes \u00e0 adapter compl\u00e8tement toutes les biblioth\u00e8ques<\/a> chaque fois qu’un changement doit se produire pour une seule biblioth\u00e8que. Toutes les \u00e9quipes sont oblig\u00e9es de se parler et de trouver une solution ensemble.<\/p>\n

En cons\u00e9quence, la premi\u00e8re \u00e9quipe ne pourra pas it\u00e9rer aussi vite qu’elle le souhaite, mais le code entre les diff\u00e9rentes biblioth\u00e8ques ne commencera \u00e0 aucun moment \u00e0 diverger.<\/p>\n

En r\u00e9sum\u00e9, l’approche multi-repo peut aider \u00e0 cr\u00e9er une culture de \u00ab aller vite et de casser les choses \u00bb parmi les \u00e9quipes, o\u00f9 des \u00e9quipes ind\u00e9pendantes agiles peuvent produire leur sortie \u00e0 leur vitesse. Au lieu de cela, l’approche mono-repo favorise une culture de sensibilisation et d’attention, o\u00f9 les \u00e9quipes ne doivent pas \u00eatre laiss\u00e9es pour compte pour faire face \u00e0 un probl\u00e8me toutes seules.<\/p>\n

Approche hybride poly-as-mono<\/h2>\n

Si nous ne pouvons pas d\u00e9cider s’il faut utiliser les approches multi-repo ou mono-repo, il y a aussi l’approche interm\u00e9diaire : utiliser plusieurs d\u00e9p\u00f4ts et employer un outil pour les maintenir synchronis\u00e9s, le faisant ressembler \u00e0 un mono-repo mais avec plus de flexibilit\u00e9.<\/p>\n

Meta<\/a> est l’un de ces outils. Il organise plusieurs d\u00e9p\u00f4ts sous des sous-r\u00e9pertoires et fournit une interface de ligne de commande<\/a> qui ex\u00e9cute la m\u00eame commande sur tous simultan\u00e9ment.<\/p>\n

Un m\u00e9ta-repo contient les informations sur les d\u00e9p\u00f4ts qui composent un projet. Le clonage de ce d\u00e9p\u00f4t via m\u00e9ta clonera ensuite de mani\u00e8re r\u00e9cursive tous les d\u00e9p\u00f4ts n\u00e9cessaires, ce qui permettra aux nouveaux membres de l’\u00e9quipe de commencer plus facilement \u00e0 travailler sur leurs projets imm\u00e9diatement.<\/p>\n

Pour cloner un m\u00e9ta-repo et tous ses d\u00e9p\u00f4ts multiples d\u00e9finis, nous devons ex\u00e9cuter les op\u00e9rations suivantes :<\/p>\n

meta git clone [meta repo url]\n<\/code><\/pre>\n
Meta ex\u00e9cutera un git clone<\/code> pour chaque d\u00e9p\u00f4t et le placera dans un sous-r\u00e9pertoire :<\/p>\n
\"Clonage<\/a>
Clonage d’un m\u00e9ta-projet. (Source de l’image : github.com\/mateodelnorte\/meta<\/a>)<\/figcaption><\/figure>\n
A partir de l\u00e0, l’ex\u00e9cution de la meta exec<\/code> commande ex\u00e9cutera la commande sur chaque sous-r\u00e9pertoire. Par exemple, l’ex\u00e9cution degit checkout master<\/code> sur chaque d\u00e9p\u00f4t se fait comme ceci :<\/p>\n
meta exec \"git checkout master\"\n<\/code><\/pre>\n
Approche hybride mono-as-poly<\/h2>\n
Une autre approche consiste \u00e0 g\u00e9rer le code via un mono-repo pour le d\u00e9veloppement, mais en copiant le code de chaque biblioth\u00e8que dans son d\u00e9p\u00f4t ind\u00e9pendant pour le d\u00e9ploiement.<\/p>\n
Cette strat\u00e9gie est r\u00e9pandue dans l’\u00e9cosyst\u00e8me PHP car Packagist<\/a> (le d\u00e9p\u00f4t principal de Composer<\/a> ) n\u00e9cessite une URL<\/a> de d\u00e9p\u00f4t public pour publier un package, et il n’est pas possible d’indiquer que le package se trouve dans un sous-r\u00e9pertoire du d\u00e9p\u00f4t.<\/p>\n
Compte tenu de la limitation de Packagist, les projets PHP peuvent toujours utiliser un mono-repo pour le d\u00e9veloppement<\/a>, mais ils doivent utiliser l’approche multi-repo pour le d\u00e9ploiement.<\/p>\n
Pour r\u00e9aliser cette conversion, nous pouvons ex\u00e9cuter un script avec <\/a>git subtree split<\/a><\/code> Ou utiliser l’un des outils disponibles qui ex\u00e9cutent la m\u00eame logique :<\/p>\n