Wordpress

Monorepo vs Multi-Repo: Kostir og gallar aðferða við kóðageymslu

Það eru tvær meginaðferðir til að hýsa og stjórna kóða í gegnum Git: monorepo vs multi-repo. Báðar aðferðir hafa sína kosti og galla.

Við getum notað hvora aðferð sem er fyrir hvaða kóðagrunn sem er á hvaða tungumáli sem er. Þú getur notað hvaða af þessum aðferðum sem er fyrir verkefni sem innihalda handfylli af bókasöfnum til þúsunda þeirra. Jafnvel þótt það feli í sér nokkra liðsmenn eða hundruð, eða þú vilt hýsa einkakóða eða opinn kóða, geturðu samt farið með monorepo eða multi-repo byggt á ýmsum þáttum.

Hverjir eru kostir og gallar hverrar aðferðar? Hvenær ættum við að nota einn eða annan? Við skulum komast að því!

Hvað eru Repos?

Repo (stytting á repository) er geymsla fyrir allar breytingar og skrár úr verkefni, sem gerir forriturum kleift að „útgáfustýra“ eignum verkefnisins á öllu þróunarstigi þess.

Venjulega er átt við Git geymslur (eins og veitt er af GitHub, GitLab eða Bitbucket), en hugmyndin á einnig við um önnur útgáfustýringarkerfi (eins og Mercurial).

Það eru tvær meginaðferðir til að hýsa og stjórna kóðagrunninum okkar í gegnum Git: monorepo nálgunin og multirepo nálgunin. 🚀 Skoðaðu hvert í þessari handbók ⬇️Smelltu til að kvak

Hvað er Monorepo?

Monorepo nálgunin notar eina geymslu til að hýsa allan kóðann fyrir mörg bókasöfn eða þjónustu sem samanstendur af verkefnum fyrirtækis. Í ysta falli er allur kóðagrunnurinn frá fyrirtæki - sem spannar ýmis verkefni og kóðaður á mismunandi tungumálum - hýst í einni geymslu.

Kostir Monorepo

Að hýsa allan kóðagrunninn á einni geymslu veitir eftirfarandi kosti.

Lækkar aðgangshindranir

Þegar nýir starfsmenn byrja að vinna hjá fyrirtæki þurfa þeir að hlaða niður kóðanum og setja upp nauðsynleg verkfæri til að byrja að vinna að verkefnum sínum. Segjum sem svo að verkefnið sé dreift um margar geymslur, sem hver um sig hefur sínar uppsetningarleiðbeiningar og nauðsynleg verkfæri. Í því tilviki verður upphafsuppsetningin flókin og oftar en ekki verða skjölin ekki fullgerð, sem krefst þess að þessir nýju liðsmenn nái til samstarfsmanna til að fá aðstoð.

Einföldun einfaldar málin. Þar sem það er einn staðsetning sem inniheldur allan kóða og skjöl geturðu hagrætt upphaflegu uppsetningunni.

Miðlæg kóðastjórnun

Að hafa eina geymslu gefur öllum forriturum sýnileika á öllum kóðanum. Það einfaldar kóðastjórnun þar sem við getum notað einn málaleitara til að fylgjast með öllum málum í gegnum líftíma forritsins.

Til dæmis eru þessir eiginleikar dýrmætir þegar mál spannar tvö (eða fleiri) barnasöfn þar sem villan er fyrir hendi á háða bókasafninu. Með mörgum geymslum getur verið erfitt að finna kóðann þar sem vandamálið gerist.

Ofan á þetta þyrftum við að finna út hvaða geymslu á að nota til að búa til málið og bjóða síðan og krossmerkja meðlimi annarra teyma til að hjálpa til við að leysa vandamálið.

Með monorepo, þó, bæði staðsetning kóða vandamál og samvinnu við úrræðaleit verður einfaldara að ná.

Sársaukalausar endurnýjunar-breiðar

Þegar þú býrð til endurnýjun kóðans um allt forrit mun það hafa áhrif á mörg bókasöfn. Ef þú ert að hýsa þær í gegnum margar geymslur getur það reynst erfitt að stjórna öllum mismunandi dráttarbeiðnum til að halda þeim samstilltum hver við aðra.

Monorepo gerir það auðvelt að framkvæma allar breytingar á öllum kóða fyrir öll bókasöfn og senda hann undir einni dráttarbeiðni.

Erfiðara að brjóta aðliggjandi virkni

Með monorepo getum við sett upp öll próf fyrir öll bókasöfn til að keyra í hvert skipti sem einhverju einu bókasafni er breytt. Fyrir vikið hafa líkurnar á breytingum á sumum bókasöfnum lágmarkað skaðleg áhrif á önnur bókasöfn.

Liðin deila þróunarmenningu

Jafnvel þó það sé ekki ómögulegt, með monorepo nálgun, verður það krefjandi að hvetja einstaka undirmenningu meðal mismunandi teyma. Þar sem þeir munu deila sömu geymslu, munu þeir líklega deila sömu forritunar- og stjórnunaraðferðum og nota sömu þróunarverkfæri.

Vandamál með Monorepo nálgun

Að nota eina geymslu fyrir allan kóðann okkar hefur nokkra galla.

Hægari þróunarlotur

Þegar kóðinn fyrir bókasafn inniheldur brotabreytingar, sem gera það að verkum að prófin fyrir háð bókasöfn mistakast, verður einnig að laga kóðann áður en breytingarnar eru sameinaðar.

Ef þessi bókasöfn eru háð öðrum teymum, sem eru upptekin við að vinna að einhverju öðru verki og geta (eða vilja) ekki aðlaga kóðann sinn til að forðast brotbreytingar og láta prófin standast, gæti þróun nýja eiginleikans stöðvast.

Það sem meira er, verkefnið gæti vel byrjað að þróast aðeins á hraða hægasta liðsins í fyrirtækinu. Þessi niðurstaða gæti truflað meðlimi hröðustu liðanna, skapað skilyrði fyrir þá til að vilja yfirgefa fyrirtækið.

Að auki mun bókasafn þurfa að keyra prófin fyrir öll önnur bókasöfn líka. Því fleiri próf sem á að keyra, því lengri tíma tekur að keyra þau, sem hægir á því hversu hratt við getum endurtekið kóðann okkar.

Krefst niðurhals á öllum kóðabasanum

Þegar monorepo inniheldur allan kóðann fyrir fyrirtæki getur það verið risastórt, innihaldið gígabæta af gögnum. Til að leggja sitt af mörkum til hvaða bókasafns sem er hýst innan, myndi hver sem er þurfa niðurhal á allri geymslunni.

Að takast á við stóran kóðagrunn felur í sér lélega notkun á plássi á hörðum diskum okkar og hægari samskipti við hann. Til dæmis hversdagslegar aðgerðir eins og framkvæmd git status eða leit í kóðagrunninum með regex getur tekið margar sekúndur eða jafnvel mínútur lengur en þeir myndu gera með mörgum endurhverfum.

Óbreytt bókasöfn gætu verið nýútgáfa

Þegar við merkjum monorepo, er öllum kóða innan úthlutað nýja merkinu. Ef þessi aðgerð kveikir á nýrri útgáfu, þá verða öll söfn sem hýst eru í geymslunni nýútgefin með útgáfunúmerinu frá merkinu, jafnvel þó að mörg af þessum söfnum hafi ef til vill ekki breyst.

Forking er erfiðara

Opinn uppspretta verkefni verða að auðvelda þátttakendum eins auðvelt og mögulegt er að taka þátt. Með mörgum geymslum geta þátttakendur farið beint í tiltekna geymslu fyrir verkefnið sem þeir vilja leggja sitt af mörkum til. Með monorepo sem hýsir ýmis verkefni, verða þátttakendur þó fyrst að fletta sér inn í rétta verkefnið og þurfa að skilja hvernig framlag þeirra getur haft áhrif á öll önnur verkefni.

Hvað er Multi-Repo?

Multi-repo nálgunin notar nokkrar geymslur til að hýsa mörg bókasöfn eða þjónustu verkefnis þróað af fyrirtæki. Þegar það er í mesta lagi mun það hýsa hvert lágmarkssett af endurnýtanlegum kóða eða sjálfstæðum virkni (eins og örþjónustu) undir geymslunni sinni.

Kostir Multi-Repo

Að hýsa hvert bókasafn óháð öllum öðrum veitir ofgnótt af ávinningi.

Sjálfstæð bókasafnsútgáfa

Þegar geymslu er merkt er öllum kóðagrunni hennar úthlutað „nýja“ merkinu. Þar sem aðeins kóðinn fyrir tiltekið bókasafn er á geymslunni er hægt að merkja og útgefna safnið óháð öllum öðrum söfnum sem hýst eru annars staðar.

Að hafa sjálfstæða útgáfu fyrir hvert bókasafn hjálpar til við að skilgreina ávanatréð fyrir forritið, sem gerir okkur kleift að stilla hvaða útgáfu af hverju bókasafni á að nota.

Óháðar þjónustuútgáfur

Þar sem geymslan inniheldur aðeins kóðann fyrir einhverja þjónustu og ekkert annað, getur hún haft sína eigin dreifingarferil, óháð framvindu sem hefur náðst í forritunum sem fá aðgang að henni.

Þjónustan getur notað hraða útgáfuferil eins og stöðuga afhendingu (þar sem nýr kóði er notaður eftir að hann hefur staðist öll prófin). Sum bókasöfn sem fá aðgang að þjónustunni kunna að nota hægari útgáfuferil, eins og þau sem framleiða aðeins nýja útgáfu einu sinni í viku.

Hjálpar til við að skilgreina aðgangsstýringu í stofnuninni

Aðeins þarf að bæta þeim liðsmönnum sem taka þátt í að þróa bókasafn við samsvarandi geymslu og hlaða niður kóða þess. Fyrir vikið er óbein aðgangsstýringarstefna fyrir hvert lag í forritinu. Þeir sem taka þátt í bókasafninu munu fá ritstjórnarréttindi og allir aðrir geta ekki fengið aðgang að geymslunni. Eða þeir geta fengið lestur en ekki ritstjórnarréttindi.

Leyfir teymum að vinna sjálfstætt

Liðsmenn geta hannað arkitektúr bókasafnsins og innleitt kóða þess sem vinnur í einangrun frá öllum öðrum teymum. Þeir geta tekið ákvarðanir byggðar á því sem bókasafnið gerir í almennu samhengi án þess að verða fyrir áhrifum af sérstökum kröfum frá einhverju utanaðkomandi teymi eða umsókn.

Vandamál með Multi-Repo nálgun

Notkun á mörgum geymslum getur leitt til nokkurra vandamála.

Bókasöfn verða stöðugt að vera endursamstillt

Þegar ný útgáfa af bókasafni sem inniheldur brotabreytingar er gefin út, þarf að aðlaga bókasöfn sem eru háð þessu safni til að byrja að nota nýjustu útgáfuna. Ef útgáfuferill safnsins er hraðari en óháð bókasöfn þess, gætu þau fljótt orðið úr takt við hvert annað.

Liðin þurfa stöðugt að ná sér á strik til að nota nýjustu útgáfurnar frá öðrum liðum. Í ljósi þess að mismunandi lið hafa mismunandi forgangsröðun getur það stundum reynst erfitt að ná þessu.

Þar af leiðandi getur teymi sem ekki getur náð sér á endanum haldið sig við úrelta útgáfuna af hinu háða bókasafni. Þessi niðurstaða mun hafa áhrif á forritið (hvað varðar öryggi, hraða og önnur atriði), og bilið í þróun milli bókasöfna gæti aðeins orðið meira.

May Fragment Teams

Þegar mismunandi teymi þurfa ekki að hafa samskipti geta þau unnið í sínum eigin sílóum. Til lengri tíma litið gæti þetta leitt til þess að teymi framleiði undirmenningu sína innan fyrirtækisins, svo sem að beita mismunandi aðferðafræði við forritun eða stjórnun eða nota mismunandi sett af þróunarverkfærum.

Ef einhver liðsmaður þarf á endanum að vinna í öðru teymi gæti hann orðið fyrir smá menningarsjokki og lært nýja leið til að sinna starfi sínu.

Monorepo vs Multi-Repo: Aðalmunur

Báðar aðferðirnar fjalla að lokum um sama markmið: stjórnun kóðagrunnsins. Þess vegna verða þeir báðir að leysa sömu áskoranir, þar á meðal útgáfustjórnun, efla samvinnu meðal liðsmanna, meðhöndla mál, keyra próf og fleira.

Helsti munur þeirra snýr að tímasetningu þeirra á liðsmönnum til að taka ákvarðanir: annaðhvort fyrirfram fyrir monorepo eða niður í línu fyrir multi-repo.

Við skulum greina þessa hugmynd nánar.

Vegna þess að öll bókasöfn eru útfærð sjálfstætt í fjölsafninu, getur teymi sem gefur út bókasafn með brotlegum breytingum gert það á öruggan hátt með því að úthluta nýju aðalútgáfunúmeri til nýjustu útgáfunnar. Aðrir hópar geta látið ósjálfstæð bókasöfn halda sig við gömlu útgáfuna og skipta yfir í þá nýju þegar kóðinn þeirra hefur verið aðlagaður.

Þessi nálgun tekur ákvörðun um hvenær eigi að laga öll önnur bókasöfn að hverju ábyrga teymi, sem getur gert það hvenær sem er. Ef þeir gera það of seint og nýjar útgáfur bókasafna koma út, verður sífellt erfiðara að minnka bilið milli bókasöfnanna.

Þar af leiðandi, þó að eitt teymi geti endurtekið hratt og oft á kóðanum sínum, gætu önnur teymi reynst ófær um að ná sér og á endanum framleitt bókasöfn sem eru ólík.

Á hinn bóginn, í monorepo umhverfi, getum við ekki gefið út nýja útgáfu af einu bókasafni sem brýtur eitthvað annað bókasafn þar sem próf þeirra munu mistakast. Í þessu tilviki verður fyrsta liðið að hafa samskipti við annað liðið til að fella breytingarnar inn.

Þreyttur á undirstigi 1 WordPress hýsingarstuðningi án svara? Prófaðu stuðningsteymi okkar á heimsmælikvarða! Skoðaðu áætlanir okkar

Þessi nálgun neyðir teymi til að aðlaga öll bókasöfn með öllu þegar breyting verður á einu bókasafni. Öll lið neyðast til að tala saman og komast að lausn saman.

Þar af leiðandi mun fyrsta teymið ekki geta endurtekið eins hratt og það vill, en kóðinn á mismunandi bókasöfnum mun aldrei byrja að víkja.

Í stuttu máli, multi-repo nálgunin getur hjálpað til við að skapa menningu um að „hreyfa sig hratt og brjóta hlutina“ meðal teyma, þar sem lipur sjálfstæð teymi geta framleitt framleiðslu sína á sínum hraða. Þess í stað stuðlar monorepo nálgunin að menningu vitundar og umhyggju, þar sem teymi ættu ekki að vera eftir til að takast á við vandamál ein og sér.

Hybrid Poly-As-Mono nálgun

Ef við getum ekki ákveðið hvort við notum annaðhvort multi-repo eða monorepo nálgunina, þá er líka nálgunin á milli: að nota margar geymslur og nota eitthvert verkfæri til að halda þeim samstilltum, sem gerir það að verkum að það líkist monorepo en með meiri sveigjanleika.

Meta er eitt slíkt tæki. Það skipuleggur margar geymslur undir undirmöppum og býður upp á skipanalínuviðmót sem framkvæmir sömu skipunina á þeim öllum samtímis.

Meta-geymsla inniheldur upplýsingar um hvaða geymslur mynda verkefni. Klónun þessarar geymslu í gegnum meta mun síðan endurkvæmt klóna allar nauðsynlegar geymslur, sem gerir það auðveldara fyrir nýja liðsmenn að byrja strax að vinna að verkefnum sínum.

Til að klóna meta-geymslu og öll skilgreind margfeldi þess verðum við að framkvæma eftirfarandi:

meta git clone [meta repo url]

Meta mun framkvæma a git clone fyrir hverja geymslu og settu hana í undirmöppu:

Klónun metaverkefnis
Klónun metaverkefnis. (Myndheimild: github.com/mateodelnorte/meta)

Upp frá því að framkvæma meta exec skipun mun framkvæma skipunina í hverri undirmöppu. Til dæmis að framkvæma git checkout master á hverri geymslu er gert svona:

meta exec "git checkout master"

Hybrid Mono-As-Poly nálgun

Önnur aðferð er að stjórna kóðanum í gegnum monorepo fyrir þróun, en afrita kóða hvers bókasafns í sjálfstæða geymslu þess til dreifingar.

Þessi stefna er ríkjandi innan PHP vistkerfisins vegna þess að Packagist (aðal Composer geymslan) krefst opinberrar geymsluslóðar til að birta pakka og það er ekki hægt að gefa til kynna að pakkinn sé staðsettur í undirskrá geymslunnar.

Með hliðsjón af Packagist takmörkunum geta PHP verkefni samt notað monorepo fyrir þróun, en þau verða að nota multi-repo nálgunina til dreifingar.

Til að ná þessari umbreytingu getum við framkvæmt handrit með git subtree split Eða notaðu eitt af tiltækum verkfærum sem framkvæma sömu rökfræði:

  • Git Subtree Splitter
  • Git Subsplit
  • GitHub Action fyrir Monorepo Split

Hver er að nota Monorepo vs Multi-Repo

Nokkur stór tæknifyrirtæki eru hlynnt monorepo nálguninni, á meðan önnur hafa ákveðið að nota multi-repo aðferðina.

Google, Facebook, Twitter og Uber hafa öll opinberlega staðfest fyrir monorepo nálgunina. Microsoft rekur stærsta Git monorepo á jörðinni til að hýsa frumkóða Windows stýrikerfisins.

Á hinni hliðinni eru Netflix, Amazon og Lyft fræg fyrirtæki sem nota multi-repo nálgunina.

Á blendinga fjöl-sem-mónó hliðinni uppfærir Android margar geymslur, sem er stjórnað eins og einhleypri.

Á hybrid mono-as-poly hliðinni heldur Symfony kóðanum fyrir alla íhluti þess í monorepo. Þeir skiptu því í sjálfstæðar geymslur til dreifingar (svo sem symfony/dependency-injection og symfony/event-dispatcher.)

Dæmi um Monorepo og Multi-Repo

WordPress reikningurinn á GitHub hýsir dæmi um bæði monorepo og multi-repo nálgun.

Gutenberg, ritstjóri WordPress blokkarinnar, er samsettur úr nokkrum tugum JavaScript pakka. Þessir pakkar eru allir hýstir á WordPress/gutenberg monorepo og tókst í gegnum Lerna að hjálpa til við að birta þær í npm geymslunni.

Openverse, leitarvélin fyrir miðla með opnu leyfi, hýsir helstu hluta sína í sjálfstæðum geymslum: Framhlið, vörulista og API.

Monorepo vs Multi-Repo: Hvernig á að velja?

Eins og með mörg þróunarvandamál er ekkert fyrirfram skilgreint svar um hvaða nálgun þú ættir að nota. Mismunandi fyrirtæki og verkefni munu njóta góðs af einni stefnu eða hinni út frá einstökum aðstæðum þeirra, svo sem:

  • Hversu stór er kóðagrunnurinn? Inniheldur það gígabæta af gögnum?
  • Hversu margir munu vinna á kóðagrunninum? Er það í kringum 10, 100 eða 1,000?
  • Hvað verða margir pakkar? Er það í kringum 10, 100 eða 1,000?
  • Hversu marga pakka þarf teymið að vinna á á hverjum tíma?
  • Hversu þétt saman eru pakkarnir?
  • Koma mismunandi forritunarmál við sögu? Þarfnast þeir að setja upp sérstakan hugbúnað eða sérstakan vélbúnað til að keyra?
  • Hversu mörg dreifingartæki þarf og hversu flókið er að setja þau upp?
  • Hver er menningin í fyrirtækinu? Eru lið hvattir til samstarfs?
  • Hvaða verkfæri og tækni kunna teymin að nota?

Hvaða nálgun ættir þú að taka fyrir kóðagrunninn þinn? 🤔 Lærðu meira hér 👇Smelltu til að kvak

Yfirlit

Það eru tvær meginaðferðir til að hýsa og stjórna kóða: monorepo vs multi-repo. Monorepo nálgunin felur í sér að geyma kóðann fyrir mismunandi bókasöfn eða verkefni - og jafnvel allan kóða frá fyrirtæki - í einni geymslu. Og multi-repo kerfið skiptir kóðanum í einingar, svo sem bókasöfn eða þjónustu, og heldur kóðanum sínum hýst í sjálfstæðum geymslum.

Hvaða aðferð á að nota fer eftir mörgum aðstæðum. Báðar aðferðir hafa nokkra kosti og galla, og við höfum bara farið yfir þá alla í smáatriðum í þessari grein.

Ert þú með einhverjar spurningar eftir um monorepos eða multi-repos? Láttu okkur vita í athugasemdahlutanum!

tengdar greinar

0 Comments
Inline endurgjöf
Skoða allar athugasemdir
Til baka efst á hnappinn