Mono-repo og Multi-repo er to hovedstrategier for å hoste og administrere kode gjennom Git. Vi diskuterer både strategiene og deres fordeler og ulemper i detalj.
Innholdsfortegnelse
Introduksjon
De fleste av de moderne prosjektene blir administrert og vert på Git. Git har blitt standardplattformen for distribuert kildekodeadministrasjon, versjonskontroll og samarbeid fra hvor som helst i verden. Git er rask og effektiv. Det er to hovedtilnærminger for å være vert for og administrere Git-koden din:
Før vi graver inn i disse tilnærmingene, la oss forstå hvordan repo fungerer.
Hva er Repos?
Et arkiv (Repo) inneholder alle mappene og filene til prosjektet ditt. Den inneholder også informasjon om brukere, personer og datamaskiner.
Lagringsdataene er versjonskontrollerte. En repo kan eies av en person eller en gruppe teammedlemmer.
Git er et depot. Det kan være offentlig, privat eller internt. GitHub er en vertstjeneste for Git repository og har et brukergrensesnitt.
Git tilbyr versjonskontroll og kodedelingsfunksjoner, men det som gjør Git annerledes er at hvis utviklere ønsker å gjøre noen endringer i filene sine, kan de kopiere hele depotet til deres lokale system. Dermed, selv om en utvikler ikke har skrivetilgang til et bestemt prosjekt, kan de kopiere innholdet lokalt og endre det (kalt forking).
Videre, hvis utvikleren ønsker å dele lokalt gjort endringer, kan de sende en «pull request» til eieren av prosjektet.
Et prosjekt kan ha en enkelt tjeneste. Hvis prosjektet ditt har flere arbeidsflyter, kan du opprette flere tjenester for hver arbeidsflyt. De fleste utviklere foretrekker å dele opp større prosjekter i mindre uavhengige tjenester, med en eller flere funksjoner. Hver tjeneste kan løse ulike forretningsproblemer. Med populariteten til serverløse rammeverk kan brukere få tilgang til funksjoner som tjenester.
Når du har opprettet disse funksjonene-som-tjenester og distribuert dem, er neste trinn å strukturere og versjonskontrollere dem – du kan ha alle tjenestene dine i ett depot (mono-repo) – eller ha et separat depot for hver tjeneste du har ( multi-repo)!
Hva er en mono-repo?
I en mono-repo-tilnærming kan du holde alle tjenestene dine i et enkelt (mono) depot. Du kan fortsatt distribuere og administrere hver tjeneste uavhengig. Tjenestene kan dele felles biblioteker og kode.
Selskaper som Facebook, Google og Dropbox bruker mono-repo.
Fordeler med Mono-repo
Mono-repo-tilnærming har mange fordeler:
- Et enkelt sted å lagre all prosjektkoden, og kan nås av alle i teamet
- Enkel å gjenbruke og dele kode, samarbeid med teamet
- Lett å forstå effekten av endringen din på hele prosjektet
- Beste alternativet for koderefaktorering og store endringer i kode
- Teammedlemmer kan få en helhetlig oversikt over hele prosjektet
- Enkel å administrere avhengigheter
Ulemper med Mono-repo
Selvfølgelig har mono-repo noen ulemper, den viktigste er ytelsen. Hvis prosjektet ditt vokser og flere filer legges til annenhver dag, kan utsjekking, pull og andre operasjoner gå tregt og filsøk kan ta lengre tid.
Dessuten, hvis du ansetter mange uavhengige entreprenører for prosjektet ditt, er det kanskje ikke så sikkert å gi dem tilgang til hele kodebasen.
Videre er det vanskelig å implementere Continuous Deployments (CD), fordi mange mennesker kan sjekke inn endringene sine, og Continuous Integration (CI)-systemet må kanskje gjøre flere ombygginger.
Store selskaper som bruker mono-repos har tilpassede verktøy for å håndtere oppskaleringsproblemene. For eksempel bruker Facebook et tilpasset filsystem og kildekontroll.
Hva er en Multi-repo?
I en multi-repo-tilnærming er det flere depoter som er vert for flere biblioteker og tjenester i et prosjekt. Hvis en tjeneste endres, må utviklere bare bygge om den tjenesten og ikke hele prosjektet. Enkeltpersoner og team kan jobbe med sine spesifikke tjenester, og de får tilgang til kun de nødvendige tjenestene.
Selskaper som Netflix og Amazon bruker multi-repos.
Fordeler med Multi-repo
Antall selskaper som tar i bruk multi-repo er mye mer enn de som går for mono-repo, på grunn av følgende årsaker:
- Hver tjeneste og bibliotek har sin egen versjonering
- Kodeutsjekking og trekk er små og separate, og dermed er det ingen ytelsesproblemer selv om prosjektstørrelsen vokser
- Team kan jobbe selvstendig og trenger ikke ha tilgang til hele kodebasen
- Raskere utvikling og fleksibilitet
- Hver tjeneste kan utgis separat og har sin egen distribusjonssyklus, noe som gjør CI og CD enklere å implementere
- Bedre tilgangskontroll – alle team trenger ikke ha full tilgang til alle bibliotekene – men kan få lesetilgang hvis de trenger
Ulemper med Multi-repo
- Avhengighetene og bibliotekene som brukes på tvers av tjenester og prosjekter må synkroniseres regelmessig for å få den nyeste versjonen
- Oppmuntrer til en siled kultur på et tidspunkt, noe som fører til duplikatkode og individuelle team som prøver å løse det samme problemet
- Hvert team kan følge et annet sett med beste fremgangsmåter for koden deres, noe som forårsaker vanskeligheter med å følge vanlige beste fremgangsmåter
Forskjeller mellom Mono og Multi Repo
La oss rekapitulere forskjellene mellom mono-repo og multi-repo:
Mono-repo
Multi-repo
All koden til alle prosjektene til en organisasjon ligger i et sentralt depot
Hver tjeneste og prosjekt har et eget depot
Team kan samarbeide og jobbe sammen; de kan se hverandres endringer
Team kan jobbe selvstendig; individuelle endringer påvirker ikke endringer fra andre team eller prosjekter
Hver person får tilgang til hele prosjektstrukturen
Administratorer kan begrense tilgangskontrollen til prosjektet eller tjenesten som utvikleren trenger tilgang til
Oppskaleringsproblemer kan oppstå hvis prosjektstørrelsen fortsetter å vokse
God ytelse på grunn av begrenset kode og mindre tjenesteenheter
Vanskelig å implementere Continuous Deployment (CD) og Continuous Integration (CI)
Utviklere kan enkelt oppnå CD og CI fordi de kan bygge tjenester uavhengig
Utviklere kan enkelt dele biblioteker, APIer og annen vanlig kode etter hvert som de oppdateres i sentrallageret
Eventuelle endringer i biblioteker og annen vanlig kode bør synkroniseres med jevne mellomrom for å unngå problemer senere
Konklusjon
Både mono-repo og multi-repo er like populære, og hvilken som er best avhenger av prosjektstørrelsen, prosjektkravene og nivået på versjonskontroll og tilgangskontroll du trenger.
Mono-repo favoriserer konsistens, mens multi-repo fokuserer på frakobling. Mens i en mono-repo kan hele teamet se endringer gjort av én person, oppretter multi-repo en separat repo for hvert team, som kun har tilgang til de nødvendige tjenestene. Hvis du vil bruke en kombinasjon av mono-repo og multi-repo for prosjektene dine, kan du gå for metaet verktøy for å administrere flere prosjekter og biblioteker.
Du kan også være interessert i Gratis ressurser for å lære Git.