Monorepositorier og multirepositorier er to fremtredende metoder for å organisere og vedlikeholde kode ved bruk av Git. Vi vil utforske begge strategiene grundig, og vurdere deres respektive fordeler og ulemper.
Introduksjon
De fleste moderne prosjekter er nå avhengige av Git for administrasjon og hosting. Git har etablert seg som den ledende plattformen for distribuert kildekodehåndtering, versjonskontroll og samarbeid over geografiske grenser. Gits hastighet og effektivitet er velkjente. Det finnes hovedsakelig to tilnærminger for å hoste og håndtere Git-kode:
Før vi går dypere inn i disse metodene, la oss se på hvordan et repository fungerer.
Hva er Repositorier?
Et repository (repo) er et arkiv som omfatter alle mappene og filene som utgjør et prosjekt. Det inneholder også informasjon om brukere, medarbeidere og maskiner.
Dataene i et repository er underlagt versjonskontroll. Et repository kan tilhøre en enkeltperson eller en gruppe teammedlemmer.
Git er selv et repository. Det kan være offentlig, privat eller internt. GitHub fungerer som en hostingtjeneste for Git-repositorier, og tilbyr et brukervennlig grensesnitt.
Git tilbyr funksjoner for versjonskontroll og deling av kode. Det som skiller Git fra andre systemer, er at utviklere kan kopiere et helt repository til sitt lokale system for å foreta endringer i filene. Dette betyr at selv om en utvikler ikke har skrivetilgang til et spesifikt prosjekt, kan vedkommende kopiere innholdet lokalt og modifisere det (dette kalles forking).
Dersom utvikleren ønsker å dele de lokale endringene, kan de sende en «pull request» til prosjekteieren.
Et prosjekt kan bestå av en enkelt tjeneste. Hvis et prosjekt innebærer flere arbeidsflyter, kan det være fornuftig å opprette separate tjenester for hver av dem. Mange utviklere foretrekker å dele opp større prosjekter i mindre, uavhengige tjenester, som hver representerer en eller flere funksjoner. Hver tjeneste kan være dedikert til å løse spesifikke forretningsproblemer. Med fremveksten av serverløse rammeverk, kan brukere enkelt få tilgang til funksjoner som tjenester.
Etter at du har opprettet og distribuert disse funksjonene-som-tjenester, er det neste steget å strukturere og versjonskontrollere dem. Her kan du velge å ha alle tjenestene i ett enkelt repository (monorepo), eller et separat repository for hver tjeneste (multirepo)!
Hva er et monorepo?
I et monorepo-oppsett vil alle tjenestene dine være samlet i ett enkelt repository (mono). Hver tjeneste kan fortsatt distribueres og administreres separat, og det er mulig å dele felles biblioteker og kode.
Store selskaper som Facebook, Google og Dropbox benytter seg av monorepositorier.
Fordeler med monorepo
Monorepo-strategien har mange fordeler:
- Et sentralt sted for all prosjektkode, tilgjengelig for hele teamet.
- Lett å gjenbruke og dele kode, samt effektivisere samarbeid.
- God oversikt over effekten av endringer på hele prosjektet.
- Ideelt for koderefaktorering og omfattende endringer.
- Gir teamet et helhetlig bilde av prosjektet.
- Enkel håndtering av avhengigheter.
Ulemper med monorepo
Monorepositorier har også noen ulemper, der den mest betydningsfulle er ytelsen. Hvis prosjektet vokser raskt og det legges til mange filer daglig, kan operasjoner som utsjekking og pull bli trege. Filsøk kan også ta lengre tid.
Dersom du engasjerer mange uavhengige entreprenører i prosjektet, kan det også være en sikkerhetsrisiko å gi dem tilgang til hele kodebasen.
Videre kan det være vanskelig å implementere Continuous Deployments (CD), ettersom mange kan sjekke inn endringer samtidig, og Continuous Integration (CI)-systemet kan trenge flere ombygginger.
Store selskaper som bruker monorepos har ofte utviklet spesialverktøy for å håndtere skaleringsutfordringene. Facebook, for eksempel, bruker et tilpasset filsystem og kildekontroll.
Hva er et multirepo?
I en multirepo-tilnærming finnes det flere separate repositorier som inneholder biblioteker og tjenester. Endringer i én tjeneste krever kun ombygging av den spesifikke tjenesten, ikke hele prosjektet. Team og enkeltpersoner kan fokusere på sine definerte tjenester og har kun tilgang til det som er nødvendig.
Selskaper som Netflix og Amazon bruker multirepositorier.
Fordeler med multirepo
Flere selskaper velger multirepo enn monorepo, primært av følgende årsaker:
- Hver tjeneste og hvert bibliotek har sin egen versjonskontroll.
- Kodeutsjekking og pull-operasjoner er mindre og separate, noe som eliminerer ytelsesproblemer selv om prosjektet vokser.
- Team kan arbeide uavhengig og trenger ikke tilgang til hele kodebasen.
- Raskere utvikling og større fleksibilitet.
- Hver tjeneste kan lanseres separat og har sin egen distribusjonssyklus, noe som forenkler implementeringen av CI og CD.
- Bedre tilgangskontroll – ikke alle team trenger full tilgang til alle biblioteker, men kan få lesetilgang etter behov.
Ulemper med multirepo
- Avhengigheter og biblioteker som brukes på tvers av tjenester og prosjekter må synkroniseres regelmessig for å holde seg oppdatert.
- Kan føre til en silo-kultur, med duplisert kode og separate team som forsøker å løse de samme problemene.
- Hvert team kan følge sine egne praksiser, noe som kan gjøre det vanskelig å opprettholde ensartede standarder.
Forskjeller mellom monorepo og multirepo
La oss oppsummere forskjellene mellom monorepo og multirepo:
| Monorepo | Multirepo |
| All kode for alle prosjekter i en organisasjon er lagret i ett sentralt repository. | Hver tjeneste og hvert prosjekt har sitt eget repository. |
| Team kan samarbeide og jobbe sammen, og se hverandres endringer. | Team kan jobbe uavhengig; endringer fra ett team påvirker ikke andre team eller prosjekter. |
| Alle får tilgang til hele prosjektstrukturen. | Administratorer kan begrense tilgangskontrollen til den tjenesten eller det prosjektet som utvikleren trenger tilgang til. |
| Skaleringsproblemer kan oppstå ved fortsatt vekst av prosjektet. | God ytelse takket være 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 felles kode ettersom de oppdateres i det sentrale repositoryet. | Endringer i biblioteker og annen felles kode må synkroniseres jevnlig for å unngå problemer senere. |
Konklusjon
Både monorepo og multirepo er populære, og det beste valget avhenger av prosjektets størrelse, krav og behovet for versjonskontroll og tilgangskontroll.
Monorepo legger vekt på konsistens, mens multirepo fokuserer på isolasjon. I et monorepo kan hele teamet se endringer som er gjort av en enkeltperson, mens et multirepo oppretter et separat repository for hvert team, med tilgang begrenset til de nødvendige tjenestene. Hvis du ønsker å bruke en kombinasjon av monorepo og multirepo for prosjektene dine, kan du utforske meta, et verktøy for å håndtere flere prosjekter og biblioteker.
Du kan også være interessert i å se på gratis ressurser for å lære Git.