WordPress

„Monorepo“ ir „Multi-Repo“: kodo saugyklos strategijų privalumai ir trūkumai

Yra dvi pagrindinės kodo prieglobos ir valdymo per „Git“ strategijos: „monorepo“ ir „multi-repo“. Abu būdai turi savo privalumų ir trūkumų.

Mes galime naudoti bet kurį metodą bet kuriai kodų bazei bet kuria kalba. Galite naudoti bet kurią iš šių strategijų projektams, kuriuose yra keletas bibliotekų ir tūkstančiai jų. Net jei tai apima kelis komandos narius ar šimtus arba norite priglobti privatų arba atvirojo kodo kodą, vis tiek galite pasirinkti monorepo arba daugialypį atpirkimą, atsižvelgdami į įvairius veiksnius.

Kokie yra kiekvieno požiūrio pranašumai ir trūkumai? Kada turėtume naudoti vieną ar kitą? Išsiaiškinkime!

Kas yra repo?

Repo (saugyklos santrumpa) yra visų projekto pakeitimų ir failų saugykla, leidžianti kūrėjams „valdyti versiją“ projekto turtą per visą jo kūrimo etapą.

Paprastai kalbame apie „Git“ saugyklas (kaip teikia „GitHub“, „GitLab“ ar „Bitbucket“, tačiau ši sąvoka taikoma ir kitoms versijų valdymo sistemoms (pvz., „Mercurial“).

Yra dvi pagrindinės mūsų kodų bazės prieglobos ir valdymo per Git strategijos: monorepo metodas ir kelių atpirkimo metodas. 🚀 Ištirkite kiekvieną šiame vadove ⬇️Spustelėkite Tweet

Kas yra Monorepo?

Monorepo metodas naudoja vieną saugyklą, kad priglobtų visą kelių bibliotekų ar paslaugų, sudarančių įmonės projektus, kodą. Ekstremaliausiu atveju visa įmonės kodų bazė, apimanti įvairius projektus ir užkoduota skirtingomis kalbomis, yra talpinama vienoje saugykloje.

Monorepo privalumai

Visos kodų bazės talpinimas vienoje saugykloje suteikia šiuos privalumus.

Sumažina patekimo kliūtis

Kai nauji darbuotojai pradeda dirbti įmonėje, jie turi atsisiųsti kodą ir įdiegti reikiamus įrankius, kad galėtų pradėti dirbti su savo užduotimis. Tarkime, kad projektas yra išsklaidytas daugelyje saugyklų, kurių kiekviena turi savo diegimo instrukcijas ir reikalingus įrankius. Tokiu atveju pradinė sąranka bus sudėtinga, o dokumentacija dažniausiai nebus baigta, todėl naujiems komandos nariams reikės kreiptis pagalbos į kolegas.

Monorepo supaprastina reikalus. Kadangi yra viena vieta, kurioje yra visas kodas ir dokumentai, galite supaprastinti pradinę sąranką.

Centrinis kodo valdymas

Turėdami vieną saugyklą, visi kūrėjai gali matyti visą kodą. Tai supaprastina kodo valdymą, nes galime naudoti vieną problemų stebėjimo priemonę, kad galėtume stebėti visas problemas per visą programos gyvavimo ciklą.

Pavyzdžiui, šios charakteristikos yra vertingos, kai problema apima dvi (ar daugiau) antrines bibliotekas, kurių klaida yra priklausomoje bibliotekoje. Kai yra kelios saugyklos, gali būti sudėtinga rasti kodo dalį, kurioje iškyla problema.

Be to, turėtume išsiaiškinti, kurią saugyklą naudoti problemai sukurti, o tada pakviesti ir pažymėti kitų komandų narius, kad padėtų išspręsti problemą.

Tačiau naudojant monorepo kodo problemas rasti ir bendradarbiauti šalinant triktis tampa lengviau.

Visiškai neskausmingas pertvarkymas

Kuriant visos programos kodo pertvarkymą, bus paveiktos kelios bibliotekos. Jei juos priglobiate per kelias saugyklas, gali būti sudėtinga tvarkyti visas skirtingas ištraukimo užklausas, kad jos būtų sinchronizuojamos viena su kita.

„Monorepo“ leidžia lengvai atlikti visus visų bibliotekų kodo pakeitimus ir pateikti jį pagal vieną ištraukimo užklausą.

Sunkiau sulaužyti gretimas funkcijas

Naudodami monorepo, galime nustatyti visus visų bibliotekų testus, kad jie būtų vykdomi, kai tik pakeičiama viena biblioteka. Dėl to tikimybė, kad kai kurios bibliotekos bus pakeistos, sumažino neigiamą poveikį kitoms bibliotekoms.

Komandos dalijasi vystymosi kultūra

Nors tai nėra neįmanoma, taikant monorepo metodą, tampa sudėtinga įkvėpti unikalias subkultūras tarp skirtingų komandų. Kadangi jie turės tą pačią saugyklą, greičiausiai jie naudos tas pačias programavimo ir valdymo metodikas ir naudos tas pačias kūrimo priemones.

Monorepo metodo problemos

Vienos saugyklos naudojimas visam mūsų kodui turi keletą trūkumų.

Lėtesni vystymosi ciklai

Kai bibliotekos kode yra pakeitimų, dėl kurių priklausomų bibliotekų testai nepavyksta, kodas taip pat turi būti pataisytas prieš sujungiant pakeitimus.

Jei šios bibliotekos priklauso nuo kitų komandų, kurios yra užsiėmusios kita užduotimi ir negali (arba nenori) pritaikyti savo kodo, kad išvengtų lūžtančių pakeitimų ir kad testai būtų sėkmingi, naujos funkcijos kūrimas gali sustoti.

Be to, projektas gali pradėti vystytis tik lėčiausios įmonės komandos greičiu. Toks rezultatas gali nuvilti greičiausių komandų narius ir sudaryti sąlygas jiems norėti palikti įmonę.

Be to, biblioteka turės atlikti visų kitų bibliotekų testus. Kuo daugiau testų bus vykdoma, tuo daugiau laiko užtrunka jiems paleisti, todėl sulėtėja, kaip greitai galime kartoti savo kodą.

Reikia atsisiųsti visą kodų bazę

Kai monorepo yra visas įmonės kodas, jis gali būti didžiulis, jame gali būti gigabaitų duomenų. Norint prisidėti prie bet kurios bibliotekos esančios bibliotekos, bet kas turėtų atsisiųsti visą saugyklą.

Darbas su didžiule kodų baze reiškia prastai išnaudojamą vietą standžiajame diske ir lėtesnę sąveiką su ja. Pavyzdžiui, kasdieniai veiksmai, tokie kaip vykdymas git status arba paieška kodų bazėje naudojant reguliariąją išraišką gali užtrukti daug sekundžių ar net minučių ilgiau nei tai būtų atliekama naudojant kelis atpirkimo sandorius.

Nemodifikuotos bibliotekos gali būti naujos versijos

Kai pažymime monorepo, visam jame esančiam kodui priskiriama nauja žyma. Jei šis veiksmas suaktyvina naują leidimą, visos saugykloje priglobtos bibliotekos bus naujai išleistos su versijos numeriu iš žymos, net jei daugelis iš tų bibliotekų neturėjo jokių pakeitimų.

Šakės yra sudėtingesnės

Atvirojo kodo projektai turi padėti bendradarbiams kuo lengviau įsitraukti. Turėdami kelias saugyklas, bendradarbiai gali tiesiogiai patekti į konkrečią projekto, prie kurio nori prisidėti, saugyklą. Vis dėlto, kai monorepo priglobia įvairius projektus, dalyviai pirmiausia turi pereiti prie tinkamo projekto ir suprasti, kaip jų indėlis gali paveikti visus kitus projektus.

Kas yra Multi-Repo?

Taikant kelių saugyklų metodą, naudojamos kelios saugyklos kelioms įmonės sukurto projekto bibliotekoms arba paslaugoms priglobti. Ekstremaliausiu atveju jis talpins kiekvieną minimalų daugkartinio kodo rinkinį arba atskiras funkcijas (pvz., mikropaslaugą) savo saugykloje.

Multi-Repo privalumai

Kiekvienos bibliotekos talpinimas nepriklausomai nuo visų kitų suteikia daug privalumų.

Nepriklausoma bibliotekos versija

Pažymint saugyklą, visai jos kodų bazei priskiriama „nauja“ žyma. Kadangi saugykloje yra tik konkrečios bibliotekos kodas, biblioteka gali būti pažymėta ir versijos nepriklausomai nuo visų kitų bibliotekų, esančių kitur.

Turėdami nepriklausomą kiekvienos bibliotekos versiją, galite nustatyti programos priklausomybės medį, leidžiantį konfigūruoti, kurią kiekvienos bibliotekos versiją naudoti.

Nepriklausomi paslaugų leidimai

Kadangi saugykloje yra tik tam tikros paslaugos kodas ir nieko daugiau, ji gali turėti savo diegimo ciklą, nepriklausomai nuo bet kokios pažangos, padarytos ją pasiekiančiose programose.

Paslauga gali naudoti greito išleidimo ciklą, pvz., nuolatinį pristatymą (kai naujas kodas įdiegiamas po to, kai jis išlaiko visus testus). Kai kurios bibliotekos, kurios pasiekia paslaugą, gali naudoti lėtesnį išleidimo ciklą, pvz., tos, kurios išleidžia naują leidimą tik kartą per savaitę.

Padeda apibrėžti prieigos kontrolę visoje organizacijoje

Tik komandos nariai, dalyvaujantys kuriant biblioteką, turi būti įtraukti į atitinkamą saugyklą ir atsisiųsti jos kodą. Todėl kiekvienam programos sluoksniui yra numanoma prieigos valdymo strategija. Su biblioteka susijusiems asmenims bus suteiktos redagavimo teisės, o visi kiti gali neturėti prieigos prie saugyklos. Arba jiems gali būti suteiktos skaitymo, bet ne redagavimo teisės.

Leidžia komandoms dirbti savarankiškai

Komandos nariai gali kurti bibliotekos architektūrą ir įdiegti jos kodą dirbdami atskirai nuo visų kitų komandų. Jie gali priimti sprendimus remdamiesi tuo, ką biblioteka veikia bendrame kontekste, neturėdami įtakos specifiniams išorinės komandos ar programos reikalavimams.

Su kelių atpirkimo metodu susijusios problemos

Naudojant kelias saugyklas gali kilti keletas problemų.

Bibliotekos turi būti nuolat sinchronizuojamos

Kai išleidžiama nauja bibliotekos versija, kurioje yra laužančių pakeitimų, bibliotekos, priklausančios nuo šios bibliotekos, turės būti pritaikytos, kad būtų galima pradėti naudoti naujausią versiją. Jei bibliotekos išleidimo ciklas yra greitesnis nei priklausomų bibliotekų, jos gali greitai nesinchronizuoti viena su kita.

Komandos turės nuolat pasivyti, kad galėtų naudotis naujausiais kitų komandų leidimais. Atsižvelgiant į tai, kad skirtingos komandos turi skirtingus prioritetus, kartais tai gali būti sunku pasiekti.

Todėl komanda, kuri negali pasivyti, gali prilipti prie pasenusios priklausomos bibliotekos versijos. Šis rezultatas turės įtakos programai (saugumo, greičio ir kitų aspektų atžvilgiu), o bibliotekų plėtros atotrūkis gali tik didėti.

Gegužės fragmento komandos

Kai skirtingoms komandoms nereikia bendrauti, jos gali dirbti savo silose. Ilgainiui tai gali lemti tai, kad komandos sukurs savo subkultūras įmonėje, pavyzdžiui, naudos skirtingas programavimo ar valdymo metodikas arba naudos skirtingus kūrimo įrankių rinkinius.

Jei kuriam nors komandos nariui galiausiai reikės dirbti kitoje komandoje, jis gali patirti kultūrinį šoką ir išmokti naujo būdo atlikti savo darbą.

„Monorepo“ ir „Multi-Repo“: pagrindiniai skirtumai

Abu metodai galiausiai susiję su tuo pačiu tikslu: valdyti kodų bazę. Taigi jie abu turi išspręsti tuos pačius iššūkius, įskaitant leidimų valdymą, komandos narių bendradarbiavimo skatinimą, problemų sprendimą, testų vykdymą ir kitus.

Pagrindinis jų skirtumas yra susijęs su tuo, kaip komandos nariai priima sprendimus: arba iš anksto monorepo atveju, arba po kelių atpirkimo sandorių.

Panagrinėkime šią idėją išsamiau.

Kadangi visų bibliotekų versijos sudaromos atskirai kelių atsargų versijoje, komanda, išleidžianti biblioteką su laužytais pakeitimais, gali tai padaryti saugiai, naujausiam leidimui priskirdama naują pagrindinės versijos numerį. Kitų grupių priklausomos bibliotekos gali laikytis senosios versijos ir pereiti prie naujos, kai jų kodas bus pritaikytas.

Toks požiūris palieka kiekvienai atsakingai komandai, kada pritaikyti visas kitas bibliotekas, nuspręsti, kuri tai gali padaryti bet kada. Jei jie tai padarys per vėlai ir bus išleistos naujos bibliotekos versijos, panaikinti atotrūkį tarp bibliotekų bus vis sunkiau.

Vadinasi, nors viena komanda gali kartoti greitai ir dažnai pagal savo kodą, kitos komandos gali nesugebėti pasivyti ir galiausiai sukurti skirtingas bibliotekas.

Kita vertus, monorepo aplinkoje negalime išleisti naujos vienos bibliotekos versijos, kuri pažeidžia kitą biblioteką, nes jos testai nepavyks. Tokiu atveju pirmoji komanda turi bendrauti su antrąja komanda, kad įtrauktų pakeitimus.

Pavargote nuo žemesnio lygio 1 „WordPress“ prieglobos palaikymo be atsakymų? Išbandykite mūsų pasaulinio lygio palaikymo komandą! Peržiūrėkite mūsų planus

Šis metodas verčia komandas pritaikyti visas bibliotekas, kai tik reikia pakeisti vieną biblioteką. Visos komandos yra priverstos kalbėtis tarpusavyje ir kartu rasti sprendimą.

Dėl to pirmoji komanda negalės kartoti taip greitai, kaip norėtų, tačiau skirtingų bibliotekų kodas niekada nepradės skirtis.

Apibendrinant galima pasakyti, kad kelių atpirkimo sandorių metodas gali padėti sukurti komandų „greitai judėkite ir sulaužykite dalykus“ kultūrą, kai veržlios nepriklausomos komandos gali gaminti savo rezultatus savo greičiu. Vietoj to, monorepo metodas skatina sąmoningumo ir rūpestingumo kultūrą, kai komandos neturėtų būti paliktos pačios spręsti problemą.

Hibridinis „Poly-As-Mono“ metodas

Jei negalime nuspręsti, ar naudoti kelių atpirkimo, ar monorepo metodus, taip pat yra tarpinis metodas: naudoti kelias saugyklas ir naudoti tam tikrą įrankį, kad jos būtų sinchronizuotos, kad būtų panašus į monorepo, bet daugiau lankstumo.

Meta yra viena iš tokių priemonių. Jis suskirsto kelias saugyklas į pakatalogius ir suteikia komandų eilutės sąsają, kuri visuose juose vienu metu vykdo tą pačią komandą.

Meta saugykloje yra informacija apie tai, kurios saugyklos sudaro projektą. Klonuojant šią saugyklą naudojant meta, bus rekursyviai klonuotos visos reikalingos saugyklos, todėl naujiems komandos nariams bus lengviau nedelsiant pradėti dirbti su savo projektais.

Norėdami klonuoti metasaugyklą ir visas jos apibrėžtas kelias saugyklas, turime atlikti šiuos veiksmus:

meta git clone [meta repo url]

Meta vykdys a git clone kiekvienai saugyklai ir įdėkite ją į poaplankį:

Meta projekto klonavimas
Metaprojekto klonavimas. (Vaizdo šaltinis: github.com/mateodelnorte/meta)

Nuo tada vykdant meta exec komanda vykdys komandą kiekviename pakatalogyje. Pavyzdžiui, vykdymas git checkout master kiekvienoje saugykloje atliekama taip:

meta exec "git checkout master"

Hibridinis Mono-As-Poly metodas

Kitas būdas yra kodo valdymas naudojant monorepo plėtrai, bet kiekvienos bibliotekos kodo kopijavimas į nepriklausomą saugyklą, kad būtų galima įdiegti.

Ši strategija yra paplitusi PHP ekosistemoje, nes „Packagist“ (pagrindinė „Composer“ saugykla) reikalauja viešosios saugyklos URL, kad būtų paskelbtas paketas, ir neįmanoma nurodyti, kad paketas yra saugyklos pakatalogyje.

Atsižvelgiant į Packagist apribojimą, PHP projektai vis tiek gali naudoti monorepo plėtrai, tačiau jie turi naudoti kelių atpirkimo metodą diegdami.

Norėdami pasiekti šią konversiją, galime vykdyti scenarijų su git subtree split Arba naudokite vieną iš galimų įrankių, kurie atlieka tą pačią logiką:

  • Git Subtree Splitter
  • Git Subsplit
  • „GitHub“ veiksmas, skirtas „Monorepo Split“.

Kas naudoja „Monorepo vs Multi-Repo“.

Keletas didelių technologijų įmonių pritaria monorepo metodui, o kitos nusprendė naudoti kelių atpirkimo metodą.

„Google“, „Facebook“, „Twitter“ ir „Uber“ viešai laidavo už monorepo metodą. „Microsoft“ valdo didžiausią planetoje „Git monorepo“, kad priglobtų „Windows“ operacinės sistemos šaltinio kodą.

Priešingoje pusėje „Netflix“, „Amazon“ ir „Lyft“ yra žinomos įmonės, taikančios kelių atpirkimo metodą.

Hibridinėje „poly-as-mono“ pusėje „Android“ atnaujina kelias saugyklas, kurios valdomos kaip monorepo.

Hibridinėje mono-as-poly pusėje „Symfony“ saugo visų savo komponentų kodą monorepo. Jie padalijo jį į nepriklausomas saugyklas, kad būtų galima įdiegti (pvz., symfony/dependency-injection ir symfony/event-dispatcher.)

Monorepo ir Multi-Repo pavyzdžiai

„WordPress“ paskyroje „GitHub“ yra tiek monorepo, tiek kelių atpirkimo metodų pavyzdžių.

„Gutenberg“, „WordPress“ blokų rengyklė, sudaryta iš kelių dešimčių „JavaScript“ paketų. Visi šie paketai yra talpinami WordPress/gutenberg monorepo ir valdomi per Lerna, kad padėtų juos paskelbti npm saugykloje.

Openverse, atvirai licencijuotos žiniasklaidos paieškos variklis, pagrindinės dalys yra nepriklausomose saugyklose: Front-end, Katalogas ir API.

Monorepo vs Multi-Repo: kaip pasirinkti?

Kaip ir daugelio kūrimo problemų atveju, nėra iš anksto nustatyto atsakymo, kurį metodą turėtumėte naudoti. Skirtingoms įmonėms ir projektams viena ar kita strategija bus naudinga, atsižvelgiant į jų unikalias sąlygas, pavyzdžiui:

  • Kokio dydžio yra kodų bazė? Ar jame yra gigabaitų duomenų?
  • Kiek žmonių dirbs kodų bazėje? Ar tai maždaug 10, 100 ar 1,000?
  • Kiek bus pakuočių? Ar tai maždaug 10, 100 ar 1,000?
  • Su kiek paketų komanda turi dirbti vienu metu?
  • Kaip tvirtai sujungtos pakuotės?
  • Ar dalyvauja skirtingos programavimo kalbos? Ar jiems paleisti reikalinga speciali programinė įranga ar speciali aparatinė įranga?
  • Kiek diegimo įrankių reikia ir ar sudėtinga juos nustatyti?
  • Kokia kultūra įmonėje? Ar komandos skatinamos bendradarbiauti?
  • Kokias priemones ir technologijas komandos moka naudoti?

Kokio metodo turėtumėte taikyti savo kodų bazei? 🤔 Sužinokite daugiau čia 👇Spustelėkite Tweet

Santrauka

Yra dvi pagrindinės kodo prieglobos ir valdymo strategijos: monorepo vs multi-repo. Taikant monorepo metodą, skirtingų bibliotekų ar projektų kodas – ir net visas įmonės kodas – saugomas vienoje saugykloje. Kelių atsargų sistema padalija kodą į vienetus, pvz., bibliotekas ar paslaugas, ir saugo jų kodą nepriklausomose saugyklose.

Kokį metodą naudoti, priklauso nuo daugelio sąlygų. Abi strategijos turi keletą privalumų ir trūkumų, ir mes ką tik juos visus išsamiai aptarėme šiame straipsnyje.

Ar turite klausimų dėl monorepos ar kelių atpirkimo sandorių? Praneškite mums komentarų skiltyje!

Susiję straipsniai

0 komentarai
Inline atsiliepimai
Peržiūrėti visus komentarus
Atgal į viršų mygtukas