Monorepo versus polyrepo: een aanpak kiezen

Er zijn twee manieren om code over veel projecten te organiseren:

• Monorepo — alle projecten in één repository
• Polyrepo — elk project in zijn eigen repository

Geen van beide is universeel de juiste keuze; dat hangt af van teamgrootte, onderlinge afhankelijkheid en hulpprogramma's.

In een polyrepo heeft elke service of bibliotheek zijn eigen repository, geschiedenis en releasecyclus. Teams beheren hun repositories onafhankelijk.

Een monorepo bevat alles onder één hoofdmap, met mappen per project die één geschiedenis en één set hulpprogramma's delen.

Sterke punten van een monorepo:

• Atomische wijzigingen in meerdere projecten binnen één commit
• Eén bron van waarheid voor gedeelde code
• Eenvoudiger grootschalig herstructureren
• Uniforme configuratie voor hulpprogramma's en CI

Kosten om rekening mee te houden:

• De repository kan zeer groot worden
• CI moet slim genoeg zijn om alleen gewijzigde projecten te bouwen
• Toegangsbeheer is standaard grover
• Vooraf investeren in hulpprogramma's is noodzakelijk

Sterke punten van een polyrepo:

• Duidelijke grenzen van verantwoordelijkheid
• Kleinere, snellere clones en CI per repository
• Onafhankelijke releasefrequentie
• Fijnmazig toegangsbeheer

Kosten van een polyrepo:

• Wijzigingen in meerdere repositories vereisen gecoördineerde PR's
• Gedeelde code raakt verspreid over verschillende versies
• Updates van afhankelijkheden raken gefragmenteerd
• Ontdekken en consistent blijven is moeilijker

In polyrepo's veroorzaken twee services die afhankelijk zijn van verschillende versies van een gedeelde bibliotheek pijnlijke conflicten. Monorepo's vermijden dit met één altijd actuele versie van gedeelde code.

Een vuistregel:

• Sterk onderling afhankelijke projecten die samen veranderen, zijn gebaat bij een monorepo
• Losjes gekoppelde, onafhankelijk uitgebrachte services werken goed met een polyrepo

Veel organisaties combineren beide: een monorepo per domein of team, met aparte repositories voor duidelijk onafhankelijke producten. De grens moet volgen hoe code daadwerkelijk samen verandert.

Polyrepo's samenvoegen tot een monorepo kan terwijl je de geschiedenis behoudt, bijvoorbeeld met git subtree of importhulpprogramma's, maar investeer eerst in de benodigde hulpprogramma's — dat is de doorslaggevende factor.

Je kunt nu nadenken over een strategie voor repositories:

• Monorepo: atomische wijzigingen, gedeelde code en uniforme hulpprogramma's — ten koste van schaalbaarheid en complexiteit in CI
• Polyrepo: duidelijk eigenaarschap en onafhankelijkheid — ten koste van coördinatie tussen repositories en uiteenlopende versies
• Onderlinge afhankelijkheid en teamstructuur bepalen de keuze; hybride vormen komen vaak voor

Dit vormt de basis voor de lessen over monorepo-structuur en hulpprogramma's die volgen.