Att kasta ljus över strategier för kodlagring

Mono-repo och Multi-repo är två huvudstrategier för att hosta och hantera kod genom Git. Vi diskuterar både strategierna och deras för- och nackdelar i detalj.

Introduktion

De flesta av de moderna projekten hanteras och hostas på Git. Git har blivit standardplattformen för distribuerad källkodshantering, versionskontroll och samarbete från var som helst i världen. Git är snabbt och effektivt. Det finns två huvudsakliga metoder för att vara värd och hantera din Git-kod:

Innan vi gräver i dessa tillvägagångssätt, låt oss förstå hur repo fungerar.

Vad är Repos?

Ett arkiv (Repo) innehåller alla mappar och filer i ditt projekt. Den innehåller också information om användare, personer och datorer.

Förvarsdata är versionskontrollerad. En repo kan ägas av en individ eller en grupp av teammedlemmar.

Git är ett arkiv. Det kan vara offentligt, privat eller internt. GitHub är en värdtjänst för Git repository och har ett användargränssnitt.

Git tillhandahåller versionskontroll och koddelningsfunktioner, men det som gör Git annorlunda är att om utvecklare vill göra några ändringar i sina filer kan de kopiera hela förvaret till sitt lokala system. Således, även om en utvecklare inte har skrivbehörighet till ett visst projekt, kan de kopiera innehållet lokalt och modifiera det (kallas forking).

Vidare, om utvecklaren vill dela lokalt gjorda ändringar, kan de skicka en ”pull request” till ägaren av projektet.

Ett projekt kan ha en enda tjänst. Om ditt projekt har flera arbetsflöden kan du skapa flera tjänster för varje arbetsflöde. De flesta utvecklare föredrar att dela upp större projekt i mindre oberoende tjänster, med en eller flera funktioner. Varje tjänst kan lösa olika affärsproblem. Med populariteten av serverlösa ramverk kan användare komma åt funktioner som tjänster.

När du väl har skapat dessa funktioner-som-tjänster och distribuerat dem är nästa steg att strukturera och versionskontrollera dem – du kan ha alla dina tjänster i ett arkiv (mono-repo) – eller ha ett separat arkiv för varje tjänst du har ( multi-repo)!

Vad är en Mono-repo?

I en mono-repo-metod kan du behålla alla dina tjänster i ett enda (mono) arkiv. Du kan fortfarande distribuera och hantera varje tjänst oberoende. Tjänsterna kan dela gemensamma bibliotek och kod.

Företag som Facebook, Google och Dropbox använder mono-repo.

Fördelar med Mono-repo

Mono-repo-metoden har många fördelar:

  • En enda plats för att lagra all projektkod och kan nås av alla i teamet
  • Lätt att återanvända och dela kod, samarbeta med teamet
  • Lätt att förstå effekten av din förändring på hela projektet
  • Bästa alternativet för kodrefaktorering och stora ändringar av kod
  • Teammedlemmar kan få en översikt över hela projektet
  • Lätt att hantera beroenden

Nackdelar med Mono-repo

Naturligtvis har mono-repo vissa nackdelar, den främsta är prestandan. Om ditt projekt växer och fler filer läggs till varannan dag, kan utcheckningen, pull och andra operationer bli långsamma och filsökningar kan ta längre tid.

Dessutom, om du anlitar många oberoende entreprenörer för ditt projekt, kanske det inte är så säkert att ge dem tillgång till hela kodbasen.

Vidare är det svårt att implementera Continuous Deployments (CD), eftersom många människor kan checka in sina ändringar, och ditt system för kontinuerlig integration (CI) kan behöva göra flera ombyggnader.

Stora företag som använder mono-repos har skräddarsydda verktyg för att hantera uppskalningsfrågorna. Till exempel använder Facebook ett anpassat filsystem och källkontroll.

Vad är en Multi-repo?

I ett tillvägagångssätt med flera repor finns det flera arkiv som är värd för flera bibliotek och tjänster för ett projekt. Om en tjänst ändras behöver utvecklarna bara bygga om den tjänsten och inte hela projektet. Individer och team kan arbeta med sina specifika tjänster och de får endast tillgång till de tjänster som krävs.

Företag som Netflix och Amazon använder multi-repos.

Fördelar med Multi-repo

Antalet företag som använder multi-repo är betydligt fler än de som går för mono-repo, på grund av följande skäl:

  • Varje tjänst och bibliotek har sin egen version
  • Kodutcheckningar och drag är små och separata, så det finns inga prestandaproblem även om projektstorleken växer
  • Team kan arbeta självständigt och behöver inte ha tillgång till hela kodbasen
  • Snabbare utveckling och flexibilitet
  • Varje tjänst kan släppas separat och ha sin egen distributionscykel, vilket gör CI och CD lättare att implementera
  • Bättre åtkomstkontroll – alla team behöver inte ha full tillgång till alla bibliotek – men kan få läsbehörighet om de behöver

Nackdelar med Multi-repo

  • Beroenden och bibliotek som används över tjänster och projekt måste synkroniseras regelbundet för att få den senaste versionen
  • Uppmuntrar en siled kultur vid något tillfälle, vilket leder till duplicerad kod och individuella team som försöker lösa samma problem
  • Varje team kan följa olika bästa praxis för sin kod, vilket orsakar svårigheter att följa vanliga bästa praxis

Skillnader mellan Mono och Multi Repo

Låt oss rekapitulera skillnaderna mellan mono-repo och multi-repo:

Mono-repo
Multi-repo
All kod för alla projekt i en organisation finns i ett centralt arkiv
Varje tjänst och projekt har ett separat arkiv
Team kan samarbeta och arbeta tillsammans; de kan se varandras förändringar
Team kan arbeta självständigt; individuella ändringar påverkar inte ändringar av andra team eller projekt
Varje person får tillgång till hela projektstrukturen
Administratörer kan begränsa åtkomstkontrollen till projektet eller tjänsten som utvecklaren behöver åtkomst till
Uppskalningsproblem kan uppstå om projektstorleken fortsätter att växa
Bra prestanda på grund av den begränsade koden och mindre serviceenheter
Svårt att implementera Continuous Deployment (CD) och Continuous Integration (CI)
Utvecklare kan enkelt uppnå CD och CI eftersom de kan bygga tjänster oberoende
Utvecklare kan enkelt dela bibliotek, API:er och annan vanlig kod när de uppdateras i det centrala arkivet
Alla ändringar av bibliotek och annan vanlig kod bör synkroniseras med jämna mellanrum för att undvika problem senare

Slutsats

Både mono-repo och multi-repo är lika populära och vilken som är bäst beror på din projektstorlek, projektkrav och nivån på versionshantering och åtkomstkontroll du behöver.

Mono-repo gynnar konsekvens, medan multi-repo fokuserar på frikoppling. Medan i ett mono-repo kan hela teamet se ändringar gjorda av en person, multi-repo skapar en separat repo för varje team, som endast har tillgång till de tjänster som krävs. Om du vill använda en kombination av mono-repo och multi-repo för dina projekt kan du välja metaett verktyg för att hantera flera projekt och bibliotek.

Du kanske också är intresserad av Gratis resurser för att lära dig Git.