{"id":41027,"date":"2021-10-07T10:53:27","date_gmt":"2021-10-07T08:53:27","guid":{"rendered":"https:\/\/kinsta.com\/?p=100242"},"modified":"2023-09-21T09:52:21","modified_gmt":"2023-09-21T09:52:21","slug":"monorepo-vs-multi-repo","status":"publish","type":"post","link":"https:\/\/kinsta.com\/se\/blog\/monorepo-vs-multi-repo\/","title":{"rendered":"Monorepo vs Multi-Repo: F\u00f6rdelar och nackdelar med olika kodf\u00f6rr\u00e5dsstrategier"},"content":{"rendered":"

Det finns tv\u00e5 huvudstrategier f\u00f6r att lagra<\/a> och hantera kod genom Git: monorepo vs multi-repo. B\u00e5da tillv\u00e4gag\u00e5ngss\u00e4tten har sina f\u00f6rdelar och nackdelar.<\/p>\n

Vi kan anv\u00e4nda b\u00e5da tillv\u00e4gag\u00e5ngss\u00e4tt f\u00f6r vilken kodbas som helst p\u00e5 vilket spr\u00e5k som helst. Du kan anv\u00e4nda b\u00e5de dessa strategier f\u00f6r projekt som inneh\u00e5ller bara n\u00e5gra bibliotek<\/a> till tusentals. \u00c4ven om det handlar om n\u00e5gra teammedlemmar eller hundratals, eller om du vill hosta privat eller \u00f6ppen k\u00e4llkod, kan du fortfarande v\u00e4lja monorepo eller multi-repo baserat p\u00e5 olika faktorer.<\/p>\n

Vilka \u00e4r f\u00f6rdelarna och nackdelarna med respektive tillv\u00e4gag\u00e5ngss\u00e4tt? N\u00e4r borde vi anv\u00e4nda det ena eller det andra? L\u00e5t oss ta reda p\u00e5 det!<\/p>\n

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

Vad \u00e4r repo f\u00f6r n\u00e5got?<\/h2>\n

Ett repo (f\u00f6rkortning f\u00f6r repository, som betyder f\u00f6rvar, f\u00f6rr\u00e5d, eller arkiv) \u00e4r en lagringsplats f\u00f6r alla \u00e4ndringar och filer fr\u00e5n ett projekt, vilket g\u00f6r det m\u00f6jligt f\u00f6r utvecklare att ”versionskontrollera” projektets tillg\u00e5ngar under hela utvecklingsstadiet.<\/p>\n

Vi brukar h\u00e4nvisa till Git<\/a>-f\u00f6rr\u00e5d (som tillhandah\u00e5lls av GitHub<\/a>, GitLab<\/a>, eller Bitbucket<\/a>), men konceptet g\u00e4ller \u00e4ven f\u00f6r andra versionskontrollsystem (t.ex. Mercurial).<\/p>\n\n

Vad \u00e4r monorepo?<\/h2>\n

Monorepo-metoden anv\u00e4nder ett enda f\u00f6rr\u00e5d<\/a> f\u00f6r att hosta all kod f\u00f6r flera bibliotek eller tj\u00e4nster som utg\u00f6r ett f\u00f6retags projekt. I allra h\u00f6gsta grad \u00e4r hela kodbasen fr\u00e5n ett f\u00f6retag \u2013 som r\u00f6r olika projekt och kodas p\u00e5 olika spr\u00e5k \u2013 f\u00f6rvarade i ett enda f\u00f6rr\u00e5d.<\/p>\n

F\u00f6rdelar med monorepo<\/h2>\n

Att f\u00f6rvara hela kodbasen i ett enda f\u00f6rr\u00e5d ger f\u00f6ljande f\u00f6rdelar.<\/p>\n

S\u00e4nker intr\u00e4destr\u00f6skeln<\/h3>\n

N\u00e4r nya anst\u00e4llda b\u00f6rjar arbeta f\u00f6r ett f\u00f6retag m\u00e5ste de ladda ner koden och installera de n\u00f6dv\u00e4ndiga verktygen f\u00f6r att b\u00f6rja arbeta med sina uppgifter. Antag att projektet \u00e4r utspritt \u00f6ver m\u00e5nga f\u00f6rr\u00e5d, var och ett med egna installationsanvisningar och verktyg. I s\u00e5 fall kommer den ursprungliga installationen att vara komplex, och ofta kommer dokumentationen inte vara fullst\u00e4ndig, s\u00e5 att dessa nya teammedlemmar beh\u00f6ver ta hj\u00e4lp av kollegor.<\/p>\n

Ett monorepo f\u00f6renklar saker. Eftersom det finns en enda plats som inneh\u00e5ller all kod och dokumentation<\/a> kan du effektivisera den ursprungliga introduktionen.<\/p>\n

Centralt bel\u00e4gen kodhantering<\/h3>\n

Att ha ett enda f\u00f6rr\u00e5d g\u00f6r all kod synlig f\u00f6r alla utvecklare. Detta f\u00f6renklar kodhantering eftersom vi kan anv\u00e4nda en enda problemtracker f\u00f6r att titta p\u00e5 alla problem under programmets livscykel.<\/p>\n

Dessa egenskaper \u00e4r till exempel v\u00e4rdefulla n\u00e4r ett problem str\u00e4cker sig \u00f6ver tv\u00e5 (eller flera) underbibliotek d\u00e4r felet finns p\u00e5 det beroende biblioteket. Med flera f\u00f6rr\u00e5d kan det vara utmanande att hitta den bit kod<\/a> d\u00e4r problemet intr\u00e4ffar.<\/p>\n

Ut\u00f6ver detta skulle vi beh\u00f6va ta reda p\u00e5 vilket f\u00f6rr\u00e5d som borde anv\u00e4ndas f\u00f6r att skapa problemet och sedan bjuda in och korstagga medlemmar i andra team f\u00f6r att hj\u00e4lpa till att l\u00f6sa problemet.<\/p>\n

Med ett monorepo kan det bli mycket enklare att b\u00e5de lokalisera kodproblem och samarbeta med fels\u00f6kningen.<\/p>\n

Enkel applikationsomfattande refaktorering<\/h3>\n

N\u00e4r du skapar en applikationsomfattande refaktorering av koden kommer flera bibliotek att p\u00e5verkas. Om du f\u00f6rvarar dem p\u00e5 flera f\u00f6rr\u00e5d kan hantering av alla olika pull-f\u00f6rfr\u00e5gningar f\u00f6r att h\u00e5lla dem synkroniserade med varandra snabbt bli en utmaning.<\/p>\n

Ett monorepo g\u00f6r det enkelt att utf\u00f6ra alla \u00e4ndringar av all kod f\u00f6r alla bibliotek och skicka in dem under en enda pull-f\u00f6rfr\u00e5gan.<\/p>\n

Sv\u00e5rare att f\u00f6rst\u00f6ra intilliggande funktionalitet<\/h3>\n

Med monorepo kan vi k\u00f6ra alla tester f\u00f6r alla bibliotek n\u00e4r ett enda bibliotek \u00e4ndras. Som ett resultat har en f\u00f6r\u00e4ndring i vissa bibliotek en mindre negativ effekt p\u00e5 andra bibliotek.<\/p>\n

Teamen delar utvecklingskultur<\/h3>\n

\u00c4ven om det inte \u00e4r om\u00f6jligt blir det med en monorepo-strategi utmanande att inspirera unika subkulturer bland olika team. Eftersom de kommer att dela samma f\u00f6rr\u00e5d kommer de troligen att dela samma programmerings-<\/a> och hanterings-metoder och anv\u00e4nda samma programutvecklingsverktyg<\/a>.<\/p>\n

Problem med monorepo-strategin<\/h2>\n

Att anv\u00e4nda ett enda f\u00f6rr\u00e5d f\u00f6r all v\u00e5r kod har flera nackdelar.<\/p>\n

L\u00e5ngsammare utvecklingscykler<\/h3>\n

N\u00e4r koden f\u00f6r ett bibliotek inneh\u00e5ller brytande \u00e4ndringar som f\u00e5r testerna f\u00f6r beroende bibliotek att misslyckas m\u00e5ste koden ocks\u00e5 fixas innan \u00e4ndringarna sl\u00e5s samman.<\/p>\n

Om dessa bibliotek \u00e4r beroende av andra team, som \u00e4r upptagna med att arbeta med en annan uppgift och inte kan (eller vill) anpassa sin kod f\u00f6r att undvika att bryta f\u00f6r\u00e4ndringar och f\u00e5 testen godk\u00e4nda kan utvecklingen av den nya funktionen avstanna.<\/p>\n

Dessutom kan projektet b\u00f6rja avancera endast enligt f\u00f6retagets l\u00e5ngsammaste teams hastighet. Detta kan frustrera medlemmarna i de snabbaste teamen och f\u00e5 dem att vilja l\u00e4mna f\u00f6retaget.<\/p>\n

Dessutom m\u00e5ste ett bibliotek utf\u00f6ra testerna f\u00f6r alla andra bibliotek ocks\u00e5. Ju fler tester som m\u00e5ste g\u00f6ras<\/a>, desto mer tid tar det, vilket saktar ner hur snabbt vi kan iterera v\u00e5r kod.<\/p>\n

Kr\u00e4ver nedladdning av hela kodbasen<\/h3>\n

N\u00e4r ett monorepo inneh\u00e5ller all kod f\u00f6r ett f\u00f6retag kan det vara enormt, med flera gigabyte av data. F\u00f6r att bidra till ett bibliotek som lagras d\u00e4r skulle man beh\u00f6va ladda ner hela f\u00f6rr\u00e5det.<\/p>\n

Att hantera en stor kodbas inneb\u00e4r d\u00e5lig anv\u00e4ndning av utrymme p\u00e5 v\u00e5ra h\u00e5rddiskar och l\u00e5ngsammare interaktioner. Till exempel vardagliga handlingar som exekvering av git status<\/code> eller s\u00f6ka i kodbasen med en regex kan ta m\u00e5nga sekunder eller till och med minuter l\u00e4ngre \u00e4n de skulle med multi-repo.<\/p>\n

Omodifierade bibliotek kan ha nyligen gjorda versioner.<\/h3>\n

N\u00e4r vi taggar<\/a> monorepot kommer all kod i det f\u00e5 den nya taggen. Om den h\u00e4r \u00e5tg\u00e4rden utl\u00f6ser en ny utg\u00e5va kommer alla bibliotek i f\u00f6rr\u00e5det att sl\u00e4ppas som nya med versionsnumret fr\u00e5n taggen, \u00e4ven om m\u00e5nga av dessa bibliotek kanske inte har haft n\u00e5gra \u00e4ndringar.<\/p>\n

Det \u00e4r sv\u00e5rare att forka<\/h3>\n

Projekt med \u00f6ppen k\u00e4llkod m\u00e5ste g\u00f6ra det s\u00e5 enkelt som m\u00f6jligt f\u00f6r bidragsgivarna att engagera sig. Med flera f\u00f6rr\u00e5d kan bidragsgivare g\u00e5 direkt till det specifika f\u00f6rr\u00e5det f\u00f6r det projekt de vill bidra till. Med ett monorepo som lagrar olika projekt m\u00e5ste dock bidragsgivare f\u00f6rst navigera till r\u00e4tt projekt och kommer beh\u00f6va f\u00f6rst\u00e5 hur deras bidrag kan p\u00e5verka alla andra projekt.<\/p>\n

Vad \u00e4r multi-repo?<\/h2>\n

Multi-repo-metoden anv\u00e4nder flera f\u00f6rr\u00e5d f\u00f6r att lagra flera bibliotek eller tj\u00e4nster av ett projekt som utvecklats av ett f\u00f6retag. Som mest kan det lagra varje liten upps\u00e4ttning \u00e5teranv\u00e4ndbar kod eller frist\u00e5ende funktionalitet (t.ex. en mikrotj\u00e4nst) under ett eget f\u00f6rr\u00e5d.<\/p>\n

F\u00f6rdelar med multi-repo<\/h2>\n

Att f\u00f6rvara varje bibliotek oberoende av alla andra ger en m\u00e4ngd f\u00f6rdelar.<\/p>\n

Oberoende biblioteksversionshantering<\/h3>\n

N\u00e4r du taggar ett f\u00f6rr\u00e5d tilldelas hela kodbasen den ”nya” taggen. Eftersom endast koden f\u00f6r ett specifikt bibliotek finns i f\u00f6rr\u00e5det kan biblioteket m\u00e4rkas och versioneras oberoende av alla andra bibliotek som lagras n\u00e5gon annanstans.<\/p>\n

Att ha en oberoende version f\u00f6r varje bibliotek hj\u00e4lper till att definiera beroendetr\u00e4det f\u00f6r programmet, s\u00e5 att vi kan konfigurera vilken version av varje bibliotek som ska anv\u00e4ndas.<\/p>\n

Oberoende tj\u00e4nstutg\u00e5vor<\/h3>\n

Eftersom f\u00f6rr\u00e5det endast inneh\u00e5ller koden f\u00f6r en specifik tj\u00e4nst och inget annat kan det ha sin egen distributionscykel, oberoende av eventuella framsteg som gjorts p\u00e5 applikationerna som har tillg\u00e5ng till tj\u00e4nsten.<\/p>\n

Tj\u00e4nsten kan anv\u00e4nda en snabb utgivningscykel s\u00e5som kontinuerlig leverans (d\u00e4r ny kod distribueras efter att den f\u00e5tt godk\u00e4nt i alla tester). Vissa bibliotek som anv\u00e4nder tj\u00e4nsten kan anv\u00e4nda en l\u00e5ngsammare cykel, till exempel de som bara producerar en ny utg\u00e5va en g\u00e5ng i veckan.<\/p>\n

Hj\u00e4lper till att definiera \u00e5tkomstkontroll \u00f6ver hela organisationen<\/h3>\n

Endast de teammedlemmar som arbetar med att utveckla ett bibliotek m\u00e5ste l\u00e4ggas till i motsvarande f\u00f6rr\u00e5d och ladda ner koden. Som ett resultat finns det en implicit \u00e5tkomstkontrollstrategi f\u00f6r varje lager i applikationen<\/a>. De som \u00e4r involverade i biblioteket kommer att beviljas redigeringsr\u00e4ttigheter, och ingen annan kan f\u00e5 tillg\u00e5ng till f\u00f6rr\u00e5det. Eller s\u00e5 kan de f\u00e5 l\u00e4s- men inte redigerings-r\u00e4ttigheter.<\/p>\n

Hj\u00e4lper team arbeta autonomt<\/h3>\n

Teammedlemmar kan designa bibliotekets arkitektur och implementera dess kod isolerat fr\u00e5n alla andra team. De kan fatta beslut utifr\u00e5n vad biblioteket g\u00f6r i allm\u00e4nhet utan att p\u00e5verkas av specifika krav fr\u00e5n n\u00e5got externt team eller program.<\/p>\n

Problem med multi-repo-strategin<\/h2>\n

Att anv\u00e4nda flera f\u00f6rr\u00e5d kan ge upphov till flera problem.<\/p>\n

Bibliotek m\u00e5ste st\u00e4ndigt f\u00f6rnyas<\/h3>\n

N\u00e4r en ny version av ett bibliotek som inneh\u00e5ller brytande \u00e4ndringar sl\u00e4pps m\u00e5ste alla bibliotek som \u00e4r beroende av detta bibliotek anpassas f\u00f6r att anv\u00e4nda den senaste versionen. Om bibliotekets utgivningscykel \u00e4r snabbare \u00e4n dess beroende bibliotek kan de snabbt bli osynkroniserade med varandra.<\/p>\n

Team m\u00e5ste st\u00e4ndigt komma i kapp f\u00f6r att anv\u00e4nda de senaste utg\u00e5vorna fr\u00e5n andra team. Med tanke p\u00e5 att olika team har olika prioriteringar kan det ibland vara sv\u00e5rt att uppn\u00e5.<\/p>\n

F\u00f6ljaktligen kan ett team som inte kan komma i kapp h\u00e5lla sig till den f\u00f6r\u00e5ldrade versionen av det beroende biblioteket. Detta kommer f\u00e5 konsekvenser f\u00f6r applikationen (n\u00e4r det g\u00e4ller s\u00e4kerhet, hastighet och andra faktorer), och klyftan i utveckling \u00f6ver de olika biblioteken blir bara bredare.<\/p>\n

Kan fragmentera team<\/h3>\n

N\u00e4r olika team inte beh\u00f6ver interagera med varandra kan de arbeta helt avskilt p\u00e5 flera s\u00e4tt. P\u00e5 l\u00e5ng sikt kan detta leda till att teamen producerar sina egna subkulturer inom f\u00f6retaget, till exempel olika metoder f\u00f6r programmering eller hantering, eller anv\u00e4nda olika upps\u00e4ttningar utvecklingsverktyg.<\/p>\n

Om en teammedlem s\u00e5 sm\u00e5ningom beh\u00f6ver arbeta i ett annat team kan de drabbas av en kulturchock av att beh\u00f6va l\u00e4ra sig ett nytt s\u00e4tt att g\u00f6ra sitt jobb.<\/p>\n

Monorepo vs multi-repo: prim\u00e4ra skillnader<\/h2>\n

B\u00e5da strategierna handlar i slut\u00e4ndan om samma sak: att hantera kodbasen. D\u00e4rmed m\u00e5ste de b\u00e5da l\u00f6sa samma utmaningar, inklusive utgivingshantering, fr\u00e4mja samarbete mellan teammedlemmar<\/a>, l\u00f6sa problem, testa koden, och mycket mer.<\/p>\n

Deras huvudsakliga skillnad g\u00e4ller deras timing f\u00f6r teammedlemmar att fatta beslut: antingen direkt med monorepo eller allteftersom med multi-repo.<\/p>\n

L\u00e5t oss analysera detta lite mer i detalj.<\/p>\n

Eftersom alla bibliotek \u00e4r oberoende versionerade i multi-repo kan ett team som sl\u00e4pper ett bibliotek med brytande \u00e4ndringar g\u00f6ra det s\u00e4kert genom att tilldela ett nytt versionsnummer till den senaste versionen. Andra grupper kan l\u00e5ta sina beroende bibliotek h\u00e5lla sig till den gamla versionen och byta till den nya n\u00e4r deras egen kod anpassats.<\/p>\n

Detta tillv\u00e4gag\u00e5ngss\u00e4tt l\u00e4mnar beslutet om n\u00e4r man ska anpassa alla andra bibliotek upp till varje enskilt team, som kan g\u00f6ra det n\u00e4r som helst. Om de g\u00f6r det f\u00f6r sent och nya biblioteksversioner sl\u00e4pps blir det allt sv\u00e5rare att st\u00e4nga klyftan mellan biblioteken.<\/p>\n

F\u00f6ljaktligen, medan ett team kan iterera snabbt och ofta med sin egen kod kan andra team visa sig of\u00f6rm\u00f6gna att komma i kapp, vilket i slut\u00e4ndan producerar bibliotek som avviker fr\u00e5n varandra.<\/p>\n

\u00c5 andra sidan kan vi i en monorepo-milj\u00f6 inte sl\u00e4ppa en ny version av ett bibliotek som bryter n\u00e5got annat bibliotek eftersom deras tester kommer att misslyckas. I det h\u00e4r fallet m\u00e5ste det f\u00f6rsta teamet kommunicera med det andra teamet f\u00f6r att inf\u00f6rliva \u00e4ndringarna.<\/p>\n

Detta tillv\u00e4gag\u00e5ngss\u00e4tt tvingar team att anpassa alla bibliotek<\/a> tillsammans n\u00e4r en f\u00f6r\u00e4ndring f\u00f6r ett enda bibliotek m\u00e5ste ske. Alla team tvingas prata med varandra och n\u00e5 en l\u00f6sning tillsammans.<\/p>\n

Som ett resultat kommer det f\u00f6rsta teamet inte att kunna iterera s\u00e5 fort de vill, men koden \u00f6ver olika bibliotek kommer inte att b\u00f6rja avvika fr\u00e5n varandra.<\/p>\n

Sammanfattningsvis kan multi-repo-strategin bidra till att skapa en kultur av ”g\u00e5 snabbt fram och bryt saker och ting” bland team, d\u00e4r oberoende team kan producera ny kod med sin egen hastighet. Monorepo-strategin gynnar \u00e5 andra sidan en kultur av medvetenhet och omt\u00e4nksamhet, d\u00e4r team inte kommer hamna efter f\u00f6r att beh\u00f6va hantera ett problem helt sj\u00e4lva.<\/p>\n

Hybrid poly-as-mono-strategi<\/h2>\n

Om vi inte kan besluta om att anv\u00e4nda antingen multi-repo eller monorepo-strategin, finns det ocks\u00e5 mellanliggande strategier: att anv\u00e4nda flera f\u00f6rr\u00e5d och anv\u00e4nda n\u00e5gra verktyg f\u00f6r att h\u00e5lla dem synkroniserade, vilket f\u00e5r dem att lika ett monorepo men med mer flexibilitet.<\/p>\n

Meta<\/a> \u00e4r ett s\u00e5dant verktyg. Det organiserar flera f\u00f6rr\u00e5d i underkataloger och tillhandah\u00e5ller ett kommandoradsgr\u00e4nssnitt<\/a> som exekverar samma kommando p\u00e5 dem alla samtidigt.<\/p>\n

Ett metaf\u00f6rr\u00e5d inneh\u00e5ller information om vilka f\u00f6rr\u00e5d som ett projekt best\u00e5r av. Kloning av detta f\u00f6rr\u00e5d via meta kommer sedan rekursivt klona alla n\u00f6dv\u00e4ndiga f\u00f6rr\u00e5d, vilket g\u00f6r det l\u00e4ttare f\u00f6r nya teammedlemmar att b\u00f6rja arbeta med sina projekt omedelbart.<\/p>\n

F\u00f6r att klona ett metaf\u00f6rr\u00e5d och alla dess definierade f\u00f6rr\u00e5dd, m\u00e5ste vi exekvera f\u00f6ljande:<\/p>\n

meta git clone [meta repo url]\n<\/code><\/pre>\n
Meta kommer att exekvera en git clone<\/code> f\u00f6r varje f\u00f6rr\u00e5d och placera den i en undermapp:<\/p>\n
\"Kloning<\/a>
Kloning av ett metaprojekt. (Bildk\u00e4lla: github.com\/mateodelnorte\/meta<\/a>)<\/figcaption><\/figure>\n
D\u00e4refter kommer kommandot meta exec<\/code> att exekvera kommandot p\u00e5 varje undermapp. Till exempel anv\u00e4nds git checkout master<\/code> p\u00e5 varje f\u00f6rr\u00e5d s\u00e5 h\u00e4r:<\/p>\n
meta exec \"git checkout master\"\n<\/code><\/pre>\n
Hybrid mono-as-poly-strategi<\/h2>\n
Ett annat tillv\u00e4gag\u00e5ngss\u00e4tt \u00e4r att hantera koden via ett monorepo f\u00f6r utveckling, men kopiera varje biblioteks kod till sitt oberoende f\u00f6rr\u00e5d f\u00f6r distribution.<\/p>\n
Denna strategi \u00e4r utbredd inom PHP-ekosystemen eftersom Packagist<\/a> (det huvudsakliga Composer<\/a>-f\u00f6rr\u00e5det) kr\u00e4ver en offentlig f\u00f6rr\u00e5dsadress<\/a> f\u00f6r att publicera ett paket, och det \u00e4r inte m\u00f6jligt att ange att paketet finns i en underkatalog till f\u00f6rr\u00e5det.<\/p>\n
Med tanke p\u00e5 Packagists begr\u00e4nsning kan PHP-projekt fortfarande anv\u00e4nda monorepo f\u00f6r utveckling<\/a>, men m\u00e5ste anv\u00e4nda multi-repo-metoden f\u00f6r distribution.<\/p>\n
F\u00f6r att uppn\u00e5 denna konvertering kan vi k\u00f6ra ett skript med git subtree split<\/code><\/a> eller anv\u00e4nda ett av de tillg\u00e4ngliga verktygen som utf\u00f6r samma logik:<\/p>\n