{"id":39921,"date":"2021-09-09T11:33:53","date_gmt":"2021-09-09T09:33:53","guid":{"rendered":"https:\/\/kinsta.com\/?p=100242"},"modified":"2023-09-12T10:09:21","modified_gmt":"2023-09-12T08:09:21","slug":"monorepo-vs-multi-repo","status":"publish","type":"post","link":"https:\/\/kinsta.com\/nl\/blog\/monorepo-vs-multi-repo\/","title":{"rendered":"Mono-repo of multi-repo: voordelen en nadelen van verschillende strategie\u00ebn voor code repositories"},"content":{"rendered":"

Er zijn twee hoofdstrategie\u00ebn voor het hosten<\/a> en beheren van code via Git: mono-repo en multi-repo. Ze hebben allebei voordelen en nadelen.<\/p>\n

Beide strategie\u00ebn zijn te gebruiken voor codebases in alle programmeertalen. Je kan beide strategie\u00ebn toepassen voor projecten die maar een paar libraries<\/a> gebruiken of juist duizenden. Zelfs of het nou gaat om een paar teamleden of complete afdelingen, en of je priv\u00e9 host of een open source aanpak kiest, dan kan je nog steeds kiezen tussen multi-repo en mono-repo.<\/p>\n

Dus wat zijn precies de voordelen en nadelen van beide aanpakken? Wanneer moeten we de ene of juist de andere gebruiken? Laten we daar snel achter komen!<\/p>\n

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

Wat zijn repos?<\/h2>\n

Een repo (de afkorting van repository, oftewel een verzamelplek) is een opslagplek voor alle veranderingen, versies en bestanden van een project, waardoor developers “versiebeheer” kunnen uitvoeren op alle onderdelen van een project tijdens de ontwikkeling.<\/p>\n

We refereren meestal aan Git<\/a>\u00a0repositories (zoals aangeboden door\u00a0GitHub<\/a>,\u00a0GitLab<\/a>, of\u00a0Bitbucket<\/a>), maar het concept is ook toe te passen op andere versiebeheersystemen (bijvoorbeeld Mercurial).<\/p>\n\n

Wat is een mono-repo?<\/h2>\n

De route van een mono-repo gebruikt een enkele repository<\/a> voor alle code van meerdere libraries of diensten waaruit een project of meerdere projecten bestaan. Als je het volledig doorvoert kan de hele codebase van een bedrijf, met verschillende projecten en programmeertalen, zelfs gehost worden in \u00e9\u00e9n enkele repository.<\/p>\n

Voordelen van een mono-repo<\/h2>\n

Het hosten van een gehele codebase in \u00e9\u00e9n repository heeft de onderstaande voordelen.<\/p>\n

Lagere drempels om te beginnen<\/h3>\n

Wanneer nieuwe medewerkers beginnen te werken voor een bedrijf, moeten ze de code downloaden en de vereiste tools installeren om aan de slag te kunnen. Stel dat het project verdeeld is over verschillende repositories, allemaal met eigen instructies voor het installeren en vereiste tools. In dat geval zal de eerste installatie nogal complex worden, en meestal zal de documentatie ook niet helemaal compleet zijn, waardoor de nieuwe teamleden hulp moeten vragen aan collega’s.<\/p>\n

Een mono-repo vereenvoudigt dit allemaal. Aangezien er maar \u00e9\u00e9n locatie is waar alle code en documentatie<\/a> staat, kan je de start van nieuwe leden eenvoudiger maken.<\/p>\n

Centraal codebeheer<\/h3>\n

Door maar \u00e9\u00e9n repository te gebruiken zien alle developers in principe alle code. Dit vereenvoudigt het beheer van code aangezien we een enkele issue tracker kunnen gebruiken voor het bijhouden van alle problemen in de hele levenscyclus van een toepassing.<\/p>\n

Deze voordelen zijn waardevol wanneer een probleem te maken heeft met meerdere onderliggende libraries, waarbij de bug in de afhankelijke library zit. Met meerdere repositories kan het nogal uitdagend worden om het precieze stukje code<\/a> te vinden waar het probleem vandaan komt.<\/p>\n

Daarnaast zouden we moeten uitvogelen welke repository we moeten gebruiken om het probleem op te gaan lossen, en vervolgens alle andere teamleden daarvoor uit te nodigen.<\/p>\n

Maar met een mono-repo is het lokaliseren van problemen in de code en het samenwerken aan een oplossing veel eenvoudiger.<\/p>\n

Eenvoudig refactoren van complete toepassingen<\/h3>\n

Wanneer je de complete code van een hele toepassing gaat refactoren, zullen daar meerdere libraries bij betrokken worden. Als je die op verschillende repositories hebt staan, zal het beheren van alle verschillende pull-request en ze allemaal gesynchroniseerd houden een flinke uitdaging worden.<\/p>\n

Een mono-repo maakt het makkelijker om alle wijzigingen in alle code te synchroniseren en alles in \u00e9\u00e9n pull request te versturen.<\/p>\n

Gerelateerde functies gaan minder snel kapot<\/h3>\n

Met een mono-repo kunnen we de tests voor alle libraries uitvoeren, elke keer wanneer er maar \u00e9\u00e9n library aangepast wordt. Daardoor is de kans veel kleiner dat je een verandering maakt waarvan later blijkt dat het een probleem oplevert in andere libraries.<\/p>\n

Teams delen dezelfde developmentcultuur<\/h3>\n

Met een mono-repo aanpak is het bijna onmogelijk dat er verschillende subculturen ontstaan onder verschillende teams. Aangezien ze allemaal dezelfde repository gebruiken, zullen ze ook meestal dezelfde programmeermethoden<\/a> en beheerstrategie\u00ebn gebruiken en ook dezelfde developmenttools<\/a>.<\/p>\n

Nadelen van een aanpak met een mono-repo<\/h2>\n

Het gebruiken van \u00e9\u00e9n repository voor alle code heeft natuurlijk ook nadelen.<\/p>\n

Tragere developmentcyclus<\/h3>\n

Wanneer de code voor een library blokkerende veranderingen bevat, waardoor ook de tests voor gerelateerde libraries vastlopen, zal de code eerst overal gecorrigeerd moeten worden voordat wijzigingen doorgevoerd kunnen worden.<\/p>\n

Als deze libraries door andere teams gemaakt worden, die met eigen prioriteiten bezig zijn en daardoor moeite hebben om hun code aan te passen om jouw problematische wijzigingen te accommoderen zodat alle tests lukken, kan de ontwikkeling van een nieuwe feature vertraging oplopen.<\/p>\n

Daarmee loop je zo het risico dat het hele project zo snel gaat als het traagste team. Dit kan erg frustrerend zijn voor snellere teams, wat nogal demotiverend is.<\/p>\n

Daarnaast moet een library ook de tests voor alle andere libraries uitvoeren. Hoe meer tests je moet uitvoeren<\/a>, hoe langer ze duren, en hoe minder snel je een cyclus kan afronden.<\/p>\n

Vereist downloaden van gehele codebase<\/h3>\n

Doordat de mono-repo alle code van de organisatie bevat, kan dit een enorme structuur opleveren, van vele gigabytes. Wanneer iemand aan een onderliggende library wil werken, zullen ze de hele repository moeten downloaden.<\/p>\n

Het werken met een grote codebase levert een ineffici\u00ebnt gebruik van opslagruimte op, en betekent ook dat je er minder snel mee kan werken. Zo worden alledaagse acties zoals bijvoorbeeld het uitvoeren van git status<\/code> of zoeken in de codebase met een regex erg traag, waardoor ze wel minuten langer kunnen duren dan wanneer je een opgesplitste codebase had.<\/p>\n

Er worden nieuwe versies aangemaakt van onveranderde libraries<\/h3>\n

Wanneer we de mono-repo taggen<\/a>, krijgt alle onderliggende code een nieuwe tag toegewezen. Als deze actie een nieuwe release veroorzaakt, zullen alle libraries die in de repository gehost worden gereleased worden met het versienummer van de tag, ook al zullen veel van de libraries helemaal geen wijzigingen hebben gehad.<\/p>\n

Forken wordt moeilijker<\/h3>\n

Open source projecten moeten het zo makkelijk mogelijk maken voor bijdragers om met het project mee te doen. Met meerdere repositories kunnen ze meteen naar het specifieke onderdeel van een project gaan waar ze aan willen bijdragen. Maar wanneer een mono-repo meerdere projecten bevat, zullen bijdragers eerst de hele structuur door moeten, en moeten ze begrijpen hoe hun bijdrage invloed heeft op alle andere projecten.<\/p>\n

Wat is een multi-repo?<\/h2>\n

De multi-repo route gebruikt juist meerdere repositories om meerdere libraries of services van een project te hosten. In het meest extreme geval zal elke minimale set van herbruikbare code of onafhankelijke functie (zoals een microservice) in een eigen repository gehost worden.<\/p>\n

Voordelen van een multi-repo<\/h2>\n

Het hosten van elke library onafhankelijk van de anderen biedt allerlei voordelen.<\/p>\n

Onafhankelijk versies maken van libraries<\/h3>\n

Wanneer je een repository tagt, zal de hele codebase de “nieuwe” tag toegewezen krijgen. Aangezien alleen de code voor een specifieke library op de repository zit, zal alleen die library getagd worden en een nieuwe versie krijgen, onafhankelijk van andere libraries.<\/p>\n

Door een onafhankelijk versie te hebben voor elke library kan je de dependency tree voor de toepassing opbouwen, waardoor je kan configureren welke versie van elke library er gebruikt moet worden.<\/p>\n

Onafhankelijke releases van services<\/h3>\n

Aangezien de repository alleen de code voor een bepaalde service bevat en verder niks, kan een onafhankelijke deploymentcyclus gebruikt worden, onafhankelijk van de voortgang op andere onderdelen die er gebruik van maken.<\/p>\n

De service kan daardoor een snelle releasecyclus gebruiken, idealiter zelfs continuous delivery (waarbij nieuwe code meteen wordt ge\u00efmplementeerd zodra alle tests gelukt zijn). Sommige libraries die gebruik maken van de service hebben wellicht een tragere releasecyclus, bijvoorbeeld met slechts \u00e9\u00e9n nieuwe release per week.<\/p>\n

Maakt toegangscontrole binnen de organisatie eenvoudiger<\/h3>\n

Alleen teamleden die werken aan de ontwikkeling van een bepaalde library hoeven toegang te hebben tot de bijbehorende library en de code te downloaden. Daardoor zit er meteen een toegangscontrole op elke laag van de toepassing<\/a>. Iedereen die werkt met de library kan het recht om te wijzigen krijgen, en verder krijgt niemand toegang. Eventueel zou je ook alleen-lezen rechten kunnen geven aan sommige mensen.<\/p>\n

Maakt het mogelijk dat teams onafhankelijk werken<\/h3>\n

Teamleden kunnen de architectuur van een library ontwerpen en de code implementeren, zonder rekening te hoeven houden met andere teams. Ze kunnen beslissingen maken op basis van wat de library doet in het algemeen, zonder na te hoeven denken over de specifieke vereisten van een bepaald ander team of andere toepassing.<\/p>\n

Nadelen van een aanpak met een multi-repo<\/h2>\n

Het gebruiken van meerdere repositories kan natuurlijk ook nadelen opleveren.<\/p>\n

Libraries moeten steeds opnieuw gesynchroniseerd worden<\/h3>\n

Wanneer een nieuwe versie van een library blokkerende wijzigingen bevat, moeten alle afhankelijke libraries aangepast worden aan de nieuwste versie. Als de releasecyclus van de library korter en sneller is dan die van afhankelijke libraries, kan de synchronisatie al snel mis gaan lopen.<\/p>\n

Teams zijn dan vooral bezig met het inhalen van releases van andere teams, in plaats van met hun eigen werk. Aangezien verschillende teams verschillende prioriteiten kunnen hebben, kan dit een uitdagende situatie opleveren.<\/p>\n

En wanneer een team het niet bij kan of wil benen, kan het zijn dat ze uiteindelijk een verouderde versie van een library gaan gebruiken. Dit heeft natuurlijk allerlei gevolgen voor het eindresultaat (qua beveiliging, snelheid en andere factoren), waardoor het gat in de ontwikkeling tussen verschillende libraries nog groter wordt.<\/p>\n

Teams kunnen gefragmenteerd raken<\/h3>\n

Wanneer verschillende teams niet met andere teams hoeven samen te werken, kunnen ze zich terug gaan trekken in hun eigen silo. Op lange term kan dat ervoor zorgen dat je aparte subculturen binnen de organisatie krijgt, zoals het gebruik van verschillende programmeermethoden of zelfs verschillende developmenttools.<\/p>\n

Als een teamlid dan naar een ander team moet overstappen of ermee moet samenwerken, kan dat een cultuurschok opleveren en moeten ze opnieuw leren hoe ze hun werk moeten doen.<\/p>\n

Mono-repo of multi-repo: belangrijkste verschillen<\/h2>\n

Beide aanpakken hebben uiteindelijk hetzelfde doel: de codebase beheren. Daarom moeten beide opties dezelfde uitdagingen oplossen, zoals het beheer van releases, het aanmoedigen van samenwerkingen tussen teams en teamleden<\/a>, het omgaan met probleem, het uitvoeren van tests en nog veel meer.<\/p>\n

Het grootste verschil zit in de kern in de timing van wanneer teamleden beslissingen moeten maken: van tevoren voor een mono-repo of pas later bij een multi-repo.<\/p>\n

Laten we dat verder analyseren.<\/p>\n

Aangezien alle libraries een eigen versie krijgen in een multi-repo, kan een team dat een library met blokkerende wijzigingen releaset dit veilig doen door een nieuw grote releasenummer toe te wijzen aan deze release. Andere teams kunnen er dan voor kiezen om bij de oude versie te blijven en over te stappen wanneer hun code is aangepast.<\/p>\n

Met deze aanpak kan elk verantwoordelijk team zelf kiezen wanneer ze hun libraries willen aanpassen op anderen. Als ze dit te laat doen en er al weer een nieuwe versies is, komt er natuurlijk een steeds groter gat.<\/p>\n

Daardoor kan het ene team heel snel wijzigingen aan het doorvoeren zijn aan hun code, terwijl andere teams het niet kunnen bijbenen, waardoor ze libraries maken die uit elkaar lopen.<\/p>\n

Aan de andere kant kan je in een mono-repo geen nieuwe versie van een library releasen wanneer die een andere library verstoort, aangezien alle tests dan misgaan. In dat geval moet het eerste team eerst overleggen met het afhankelijk team om de wijzigingen te kunnen verwerken.<\/p>\n

Deze aanpak verplicht teams om al hun libraries<\/a> op elkaar aan te passen, elke keer dat er een library gewijzigd wordt. Alle teams moeten daardoor steeds met elkaar communiceren en een gezamenlijke oplossing vinden.<\/p>\n

Daardoor zal het snelle team minder snel wijzigingen door kunnen voeren, maar de code zal ook niet uit elkaar gaan lopen tussen libraries.<\/p>\n

Samenvattend kan de route van de multi-repo dus een cultuur aanmoedigen waarbij iedereen snel werkt, ook al gaat er dan soms iets mis, waardoor de snellere teams ook echt hun maximale output kunnen leveren. Kies je voor de aanpak van de mono-repo, dan krijg je een voorzichtigere cultuur waarbij iedereen met elkaar praat, en er geen team achteropraakt.<\/p>\n

Hybride poly-als-mono aanpak<\/h2>\n

Als je niet kan kiezen tussen de multi-repo of mono-repo aanpak, is er ook nog een middenweg: gebruik meerdere repositories en zet een tool in om ze gesynchroniseerd te houden, waardoor het lijkt op een mono-repo, maar met meer flexibiliteit.<\/p>\n

Meta<\/a>\u00a0is zo’n tool. De tool organiseert meerdere repositories in submappen en biedt een command-line interface<\/a> waarmee dezelfde opdracht tegelijkertijd op alle repositories uitgevoerd wordt.<\/p>\n

Een meta-repository bevat alle informatie over de repositories waar een project uit bestaat. Het klonen van deze repository via meta zal herhalend alle vereiste repositories klonen, waardoor nieuwe teamleden ook sneller aan de gang kunnen met hun projecten.<\/p>\n

Om een meta-repository te klonen inclusief alle gedefinieerde repos eronder, voeren we de volgende opdracht uit:<\/p>\n

meta git clone [meta repo url]\n<\/code><\/pre>\n
Meta zal een git clone<\/code> uitvoeren voor elke repository en deze in een submap plaatsen:<\/p>\n
\"Klonen<\/a>
Klonen van een meta-project. (Afbeelding: github.com\/mateodelnorte\/meta<\/a>)<\/figcaption><\/figure>\n
Vervolgens kan je de meta exec<\/code> opdracht uitvoeren om de opdracht uit te voeren op elke submap. Zo kan je bijvoorbeeld git checkout master<\/code> uitvoeren op elke repository:<\/p>\n
meta exec \"git checkout master\"\n<\/code><\/pre>\n
Hybride mono-als-poly aanpak<\/h2>\n
Een andere mogelijkheid is het beheren van de code via een mono-repo tijdens de development, maar tijdens deployment de code van elke library kopi\u00ebren in een onafhankelijke repository.<\/p>\n
Deze strategie wordt veel gebruikt binnen het PHP ecosysteem omdat Packagist<\/a> (het belangrijkste Composer<\/a> repository) een publieke URL<\/a> voor de repository vereist om een package te kunnen publiceren. Het is daarbij niet mogelijk om aan te geven dat die package te vinden is in een submap van de repository.<\/p>\n
Gezien de beperking van Packagist, kunnen PHP projecten nog steeds een mono-repo gebruiken tijdens development<\/a>, maar moeten ze altijd een multi-repo gebruiken tijdens de deployment.<\/p>\n
Om deze omzetting te realiseren, kunnen we een\u00a0script uitvoeren met git subtree split<\/code><\/a>. Of gebruik \u00e9\u00e9n van de beschikbare tools die dezelfde logica toepassen:<\/p>\n