Wordpress

Monorepo versus Multi-Repo: voor- en nadelen van strategieën voor codeopslag

Er zijn twee hoofdstrategieën voor het hosten en beheren van code via Git: monorepo versus multi-repo. Beide benaderingen hebben hun voor- en nadelen.

We kunnen beide benaderingen gebruiken voor elke codebase in elke taal. U kunt elk van deze strategieën gebruiken voor projecten met een handvol bibliotheken tot duizenden. Zelfs als het om een ​​paar teamleden of honderden gaat, of als je privé- of open-sourcecode wilt hosten, kun je nog steeds kiezen voor monorepo of multi-repo op basis van verschillende factoren.

Wat zijn de voor- en nadelen van elke aanpak? Wanneer moeten we het een of het ander gebruiken? Laten we het uitzoeken!

Wat zijn repo's?

Een repo (afkorting van repository) is een opslag voor alle wijzigingen en bestanden van een project, waardoor ontwikkelaars de activa van het project tijdens de ontwikkelingsfase kunnen 'versiebeheer'.

We verwijzen meestal naar Git-repositories (zoals geleverd door GitHub, GitLab of Bitbucket), maar het concept is ook van toepassing op andere versiecontrolesystemen (zoals Mercurial).

Er zijn twee hoofdstrategieën voor het hosten en beheren van onze codebase via Git: de monorepo-benadering en de multi-repo-benadering. 🚀 Ontdek elk in deze gids ⬇️Klik om Tweet

Wat is een Monorepo?

De monorepo-benadering gebruikt een enkele repository om alle code te hosten voor de meerdere bibliotheken of services die de projecten van een bedrijf vormen. In het meest extreme geval wordt de hele codebase van een bedrijf - verspreid over verschillende projecten en gecodeerd in verschillende talen - gehost in een enkele repository.

Voordelen van Monorepo

Het hosten van de hele codebase op een enkele repository biedt de volgende voordelen.

Verlaagt toegangsdrempels

Wanneer nieuwe medewerkers voor een bedrijf gaan werken, moeten ze de code downloaden en de vereiste tools installeren om aan hun taken te beginnen. Stel dat het project is verspreid over vele repositories, die elk hun eigen installatie-instructies en gereedschap hebben. In dat geval zal de initiële installatie complex zijn, en vaker wel dan niet zal de documentatie niet compleet zijn, waardoor deze nieuwe teamleden contact moeten opnemen met collega's voor hulp.

Een monorepo vereenvoudigt de zaken. Omdat er één locatie is met alle code en documentatie, kunt u de initiële installatie stroomlijnen.

Centraal gelegen codebeheer

Het hebben van een enkele repository geeft alle ontwikkelaars zichtbaarheid van alle code. Het vereenvoudigt het codebeheer omdat we één probleemtracker kunnen gebruiken om alle problemen tijdens de levenscyclus van de applicatie te bekijken.

Deze kenmerken zijn bijvoorbeeld waardevol wanneer een probleem twee (of meer) onderliggende bibliotheken omvat met de bug in de afhankelijke bibliotheek. Met meerdere opslagplaatsen kan het een uitdaging zijn om het stukje code te vinden waar het probleem zich voordoet.

Bovendien moeten we uitzoeken welke repository we moeten gebruiken om het probleem te creëren en vervolgens leden van andere teams uitnodigen en cross-taggen om het probleem op te lossen.

Met een monorepo wordt het echter eenvoudiger om codeproblemen te lokaliseren en samen te werken om problemen op te lossen.

Pijnloze toepassingsbrede refactorings

Bij het maken van een applicatiebrede refactoring van de code, worden meerdere bibliotheken beïnvloed. Als je ze host via meerdere repositories, kan het een uitdaging zijn om alle verschillende pull-verzoeken te beheren om ze met elkaar gesynchroniseerd te houden.

Een monorepo maakt het gemakkelijk om alle wijzigingen aan alle code voor alle bibliotheken uit te voeren en deze in te dienen onder een enkel pull-verzoek.

Moeilijker te breken aangrenzende functionaliteit

Met de monorepo kunnen we alle tests voor alle bibliotheken instellen om uit te voeren wanneer een enkele bibliotheek wordt gewijzigd. Als gevolg hiervan heeft de kans op een wijziging in sommige bibliotheken de nadelige effecten op andere bibliotheken geminimaliseerd.

Teams delen ontwikkelingscultuur

Ook al is het niet onmogelijk, met een monorepo-aanpak wordt het een uitdaging om unieke subculturen tussen verschillende teams te inspireren. Aangezien ze dezelfde repository zullen delen, zullen ze hoogstwaarschijnlijk dezelfde programmeer- en beheermethodologieën delen en dezelfde ontwikkelingstools gebruiken.

Problemen met de Monorepo-aanpak

Het gebruik van een enkele repository voor al onze code heeft verschillende nadelen.

Langzamere ontwikkelingscycli

Als de code voor een bibliotheek verbrekende wijzigingen bevat, waardoor de tests voor afhankelijke bibliotheken mislukken, moet de code ook worden hersteld voordat de wijzigingen worden samengevoegd.

Als deze bibliotheken afhankelijk zijn van andere teams, die bezig zijn met een andere taak en niet in staat (of bereid) zijn om hun code aan te passen om de brekende wijzigingen te voorkomen en de tests te laten slagen, kan de ontwikkeling van de nieuwe functie vastlopen.

Bovendien kan het project pas op gang komen met de snelheid van het langzaamste team in het bedrijf. Dit resultaat zou de leden van de snelste teams kunnen frustreren en voorwaarden scheppen voor hen om het bedrijf te willen verlaten.

Bovendien moet een bibliotheek de tests ook voor alle andere bibliotheken uitvoeren. Hoe meer tests er moeten worden uitgevoerd, hoe meer tijd het kost om ze uit te voeren, en hoe sneller we onze code kunnen herhalen.

Vereist download van volledige codebase

Wanneer de monorepo alle code voor een bedrijf bevat, kan deze enorm zijn en gigabytes aan gegevens bevatten. Om bij te dragen aan een bibliotheek die wordt gehost, zou iedereen een download van de hele repository nodig hebben.

Omgaan met een enorme codebasis impliceert een slecht gebruik van de ruimte op onze harde schijven en langzamere interactie ermee. Bijvoorbeeld alledaagse handelingen zoals het uitvoeren van git status of zoeken in de codebase met een regex kan vele seconden of zelfs minuten langer duren dan bij meerdere repo's.

Ongewijzigde bibliotheken kunnen een nieuwe versie hebben

Wanneer we de monorepo taggen, wordt aan alle code binnen de nieuwe tag toegewezen. Als deze actie een nieuwe release activeert, worden alle bibliotheken die in de repository worden gehost, opnieuw vrijgegeven met het versienummer van de tag, ook al hebben veel van die bibliotheken mogelijk geen wijziging ondergaan.

Forken is moeilijker

Open source-projecten moeten het voor bijdragers zo gemakkelijk mogelijk maken om mee te doen. Met meerdere repositories kunnen bijdragers rechtstreeks naar de specifieke repository gaan voor het project waaraan ze willen bijdragen. Met een monorepo die verschillende projecten host, moeten bijdragers echter eerst hun weg naar het juiste project vinden en moeten ze begrijpen hoe hun bijdrage van invloed kan zijn op alle andere projecten.

Wat is multi-repo?

De multi-repo-benadering maakt gebruik van verschillende repositories om de meerdere bibliotheken of services van een door een bedrijf ontwikkeld project te hosten. In het meest extreme geval host het elke minimale set herbruikbare code of zelfstandige functionaliteit (zoals een microservice) onder zijn repository.

Voordelen van Multi-Repo

Elke bibliotheek onafhankelijk van alle andere hosten biedt een overvloed aan voordelen.

Onafhankelijke bibliotheekversies

Bij het taggen van een repository krijgt de hele codebase de tag "new" toegewezen. Omdat alleen de code voor een specifieke bibliotheek zich in de repository bevindt, kan de bibliotheek worden getagd en geversied onafhankelijk van alle andere bibliotheken die elders worden gehost.

Het hebben van een onafhankelijke versie voor elke bibliotheek helpt bij het definiëren van de afhankelijkheidsboom voor de toepassing, zodat we kunnen configureren welke versie van elke bibliotheek moet worden gebruikt.

Onafhankelijke servicereleases

Aangezien de repository alleen de code voor een bepaalde service bevat en niets anders, kan deze een eigen implementatiecyclus hebben, onafhankelijk van de voortgang van de applicaties die er toegang toe hebben.

De service kan een snelle releasecyclus gebruiken, zoals continuous delivery (waarbij nieuwe code wordt geïmplementeerd nadat deze alle tests heeft doorstaan). Sommige bibliotheken die toegang hebben tot de service, gebruiken mogelijk een langzamere releasecyclus, zoals bibliotheken die slechts één keer per week een nieuwe release produceren.

Helpt bij het definiëren van toegangscontrole in de hele organisatie

Alleen de teamleden die betrokken zijn bij het ontwikkelen van een bibliotheek moeten worden toegevoegd aan de bijbehorende repository en de code ervan downloaden. Als gevolg hiervan is er een impliciete strategie voor toegangscontrole voor elke laag in de applicatie. Degenen die bij de bibliotheek betrokken zijn, krijgen bewerkingsrechten en alle anderen krijgen mogelijk geen toegang tot de repository. Of ze kunnen leesrechten krijgen, maar geen bewerkingsrechten.

Stelt teams in staat om autonoom te werken

Teamleden kunnen de architectuur van de bibliotheek ontwerpen en de code implementeren, geïsoleerd van alle andere teams. Ze kunnen beslissingen nemen op basis van wat de bibliotheek doet in de algemene context zonder te worden beïnvloed door de specifieke vereisten van een extern team of externe applicatie.

Problemen met de Multi-Repo-aanpak

Het gebruik van meerdere repositories kan tot verschillende problemen leiden.

Bibliotheken moeten voortdurend opnieuw worden gesynchroniseerd

Wanneer een nieuwe versie van een bibliotheek met belangrijke wijzigingen wordt uitgebracht, moeten bibliotheken die van deze bibliotheek afhankelijk zijn, worden aangepast om de nieuwste versie te gaan gebruiken. Als de releasecyclus van de bibliotheek sneller is dan die van de afhankelijke bibliotheken, kunnen ze snel niet meer synchroon lopen met elkaar.

Teams moeten voortdurend bijpraten om de nieuwste releases van andere teams te gebruiken. Aangezien verschillende teams verschillende prioriteiten hebben, kan dit soms moeilijk te bereiken zijn.

Bijgevolg kan een team dat niet in staat is om de achterstand in te halen, vasthouden aan de verouderde versie van de afhankelijke bibliotheek. Dit resultaat zal gevolgen hebben voor de toepassing (in termen van veiligheid, snelheid en andere overwegingen), en de kloof in ontwikkeling tussen bibliotheken kan alleen maar groter worden.

Mei fragmenteren teams

Wanneer verschillende teams niet met elkaar hoeven te communiceren, kunnen ze in hun eigen silo's werken. Op de lange termijn kan dit ertoe leiden dat teams hun subculturen binnen het bedrijf produceren, zoals het gebruik van verschillende methoden voor programmering of beheer of het gebruik van verschillende sets ontwikkelingstools.

Als een teamlid uiteindelijk in een ander team moet werken, kan het een cultuurschok krijgen en een nieuwe manier van werken leren.

Monorepo versus multi-repo: primaire verschillen

Beide benaderingen hebben uiteindelijk hetzelfde doel: het beheren van de codebase. Daarom moeten ze allebei dezelfde uitdagingen oplossen, waaronder releasebeheer, het bevorderen van samenwerking tussen teamleden, het afhandelen van problemen, het uitvoeren van tests en andere.

Hun belangrijkste verschil betreft hun timing op teamleden om beslissingen te nemen: vooraf voor monorepo of later voor multi-repo.

Laten we dit idee in meer detail analyseren.

Omdat alle bibliotheken onafhankelijk van een versie zijn voorzien in de multi-repo, kan een team dat een bibliotheek met belangrijke wijzigingen vrijgeeft, dit veilig doen door een nieuw hoofdversienummer toe te wijzen aan de nieuwste release. Andere groepen kunnen hun afhankelijke bibliotheken laten vasthouden aan de oude versie en overschakelen naar de nieuwe zodra hun code is aangepast.

Deze aanpak laat de beslissing over wanneer alle andere bibliotheken moeten worden aangepast aan elk verantwoordelijk team, dat dit op elk moment kan doen. Als ze het te laat doen en er nieuwe bibliotheekversies worden uitgebracht, wordt het steeds moeilijker om de kloof tussen bibliotheken te dichten.

Bijgevolg, terwijl het ene team snel en vaak op hun code kan itereren, kunnen andere teams niet in staat zijn om de achterstand in te halen, waardoor uiteindelijk bibliotheken ontstaan ​​die uiteenlopen.

Aan de andere kant kunnen we in een monorepo-omgeving geen nieuwe versie van de ene bibliotheek uitbrengen die een andere bibliotheek verbreekt, omdat hun tests zullen mislukken. In dit geval moet het eerste team communiceren met het tweede team om de wijzigingen door te voeren.

Ben je de ondermaatse WordPress-hostingondersteuning van niveau 1 zonder de antwoorden zat? Probeer ons ondersteuningsteam van wereldklasse! Bekijk onze plannen

Deze aanpak dwingt teams om alle bibliotheken volledig aan te passen wanneer er een wijziging voor een enkele bibliotheek moet plaatsvinden. Alle teams zijn genoodzaakt met elkaar in gesprek te gaan en samen tot een oplossing te komen.

Als gevolg hiervan zal het eerste team niet zo snel kunnen itereren als ze zouden willen, maar de code over verschillende bibliotheken zal op geen enkel moment gaan divergeren.

Samenvattend kan de multi-repo-aanpak helpen bij het creëren van een cultuur van "snel handelen en dingen breken" tussen teams, waar wendbare onafhankelijke teams hun output op hun snelheid kunnen produceren. In plaats daarvan bevordert de monorepo-benadering een cultuur van bewustzijn en zorg, waarin teams niet achter moeten blijven om een ​​probleem helemaal alleen aan te pakken.

Hybride poly-als-mono-benadering

Als we niet kunnen beslissen of we de multi-repo- of monorepo-benadering willen gebruiken, is er ook de tussenaanpak: om meerdere repositories te gebruiken en een hulpmiddel te gebruiken om ze gesynchroniseerd te houden, waardoor het lijkt op een monorepo, maar met meer flexibiliteit.

Meta is zo'n hulpmiddel. Het organiseert meerdere repositories onder subdirectories en biedt een opdrachtregelinterface die dezelfde opdracht op alle tegelijk uitvoert.

Een meta-repository bevat de informatie waaruit repositories een project vormen. Het klonen van deze repository via meta zal dan recursief alle vereiste repository's klonen, waardoor het voor nieuwe teamleden gemakkelijker wordt om onmiddellijk aan hun projecten te gaan werken.

Om een ​​meta-repository en al zijn gedefinieerde meerdere repo's te klonen, moeten we het volgende uitvoeren:

meta git clone [meta repo url]

Meta zal een uitvoeren git clone voor elke repository en plaats deze in een submap:

Een metaproject klonen
Een metaproject klonen. (Bron afbeelding: github.com/mateodelnorte/meta)

Vanaf dat moment, het uitvoeren van de meta exec command voert de opdracht uit op elke submap. Bijvoorbeeld het uitvoeren van git checkout master op elke repository gebeurt als volgt:

meta exec "git checkout master"

Hybride mono-als-poly-benadering

Een andere benadering is het beheren van de code via een monorepo voor ontwikkeling, maar het kopiëren van de code van elke bibliotheek naar zijn onafhankelijke opslagplaats voor implementatie.

Deze strategie is gangbaar binnen het PHP-ecosysteem omdat Packagist (de belangrijkste Composer-repository) een openbare repository-URL vereist om een ​​pakket te publiceren, en het is niet mogelijk om aan te geven dat het pakket zich in een subdirectory van de repository bevindt.

Gezien de Packagist-beperking, kunnen PHP-projecten nog steeds een monorepo gebruiken voor ontwikkeling, maar ze moeten de multi-repo-benadering gebruiken voor implementatie.

Om deze conversie te bereiken, kunnen we een script uitvoeren met: git subtree split Of gebruik een van de beschikbare tools die dezelfde logica uitvoeren:

  • Git Subtree-splitter
  • Git subsplit
  • GitHub-actie voor Monorepo Split

Wie gebruikt Monorepo versus Multi-Repo

Verschillende grote technologiebedrijven geven de voorkeur aan de monorepo-aanpak, terwijl anderen hebben besloten om de multi-repo-methode te gebruiken.

Google, Facebook, Twitter en Uber hebben allemaal publiekelijk ingestaan ​​voor de monorepo-aanpak. Microsoft heeft de grootste Git-monorepo ter wereld om de broncode van het Windows-besturingssysteem te hosten.

Aan de andere kant zijn Netflix, Amazon en Lyft bekende bedrijven die de multi-repo-aanpak gebruiken.

Aan de hybride poly-als-mono-kant werkt Android meerdere repositories bij, die worden beheerd als een monorepo.

Aan de hybride mono-als-poly-kant bewaart Symfony de code voor al zijn componenten in een monorepo. Ze splitsen het op in onafhankelijke opslagplaatsen voor implementatie (zoals: symfony/dependency-injection en symfony/event-dispatcher.)

Voorbeelden van Monorepo en Multi-Repo

Het WordPress-account op GitHub bevat voorbeelden van zowel de monorepo- als de multi-repo-benadering.

Gutenberg, de WordPress-blokeditor, is samengesteld uit enkele tientallen JavaScript-pakketten. Deze pakketten worden allemaal gehost op de WordPress/gutenberg monorepo en beheerd via Lerna om ze te helpen publiceren in de npm-repository.

Openverse, de zoekmachine voor media met een open licentie, host de belangrijkste onderdelen in onafhankelijke opslagplaatsen: front-end, catalogus en API.

Monorepo versus multi-repo: hoe te kiezen?

Zoals bij veel ontwikkelingsproblemen, is er geen vooraf gedefinieerd antwoord op welke aanpak u moet gebruiken. Verschillende bedrijven en projecten zullen profiteren van de ene of de andere strategie op basis van hun unieke voorwaarden, zoals:

  • Hoe groot is de codebase? Bevat het gigabytes aan gegevens?
  • Hoeveel mensen zullen aan de codebase werken? Is het ongeveer 10, 100 of 1,000?
  • Hoeveel pakketten zullen er zijn? Is het ongeveer 10, 100 of 1,000?
  • Aan hoeveel pakketten moet het team op een bepaald moment werken?
  • Hoe nauw zijn de pakketten aan elkaar gekoppeld?
  • Zijn er verschillende programmeertalen bij betrokken? Moeten ze bepaalde software of speciale hardware laten draaien?
  • Hoeveel implementatietools zijn er nodig en hoe complex zijn ze om in te stellen?
  • Wat is de cultuur in het bedrijf? Worden teams aangemoedigd om samen te werken?
  • Welke tools en technologieën weten de teams te gebruiken?

Welke aanpak moet je kiezen voor je codebase? 🤔 Lees hier meer 👇Klik om Tweet

Samengevat

Er zijn twee hoofdstrategieën voor het hosten en beheren van code: monorepo versus multi-repo. De monorepo-aanpak houdt in dat de code voor verschillende bibliotheken of projecten - en zelfs alle code van een bedrijf - in een enkele repository wordt opgeslagen. En het multi-reposysteem verdeelt de code in eenheden, zoals bibliotheken of services, en houdt hun code gehost in onafhankelijke repositories.

Welke aanpak je moet gebruiken, hangt af van een veelheid aan voorwaarden. Beide strategieën hebben verschillende voor- en nadelen, en we hebben ze allemaal in detail besproken in dit artikel.

Heeft u nog vragen over monorepos of multi-repo's? Laat het ons weten in de comments!

Gerelateerde artikelen

0 Comments
Inline feedbacks
Bekijk alle reacties
Terug naar boven knop