Wordpress

Monorepo vs Multi-Repo: A kódtárolási stratégiák előnyei és hátrányai

Két fő stratégia létezik a kód tárolására és kezelésére a Giten keresztül: monorepo vs multi-repo. Mindkét megközelítésnek megvannak a maga előnyei és hátrányai.

Bármelyik nyelvű kódbázishoz bármelyik megközelítést használhatjuk. E stratégiák bármelyikét használhatja olyan projektekhez, amelyek több ezer könyvtárat tartalmaznak. Még akkor is, ha néhány vagy több száz csapattagról van szó, vagy privát vagy nyílt forráskódú kódot szeretne tárolni, akkor is választhatja a monorepo vagy a multi-repo használatát különféle tényezők alapján.

Milyen előnyei és hátrányai vannak az egyes megközelítéseknek? Mikor használjuk az egyiket vagy a másikat? Találjuk ki!

Mik azok a repók?

A repo (a repository rövidítése) a projekt összes változásának és fájljának tárolója, amely lehetővé teszi a fejlesztők számára, hogy a projekt eszközeit a fejlesztési szakaszban „verzióvezérléssel” kezeljék.

Általában a Git-tárolókra hivatkozunk (amint azt a GitHub, a GitLab vagy a Bitbucket biztosítja), de a fogalom más verziókezelő rendszerekre is vonatkozik (például a Mercurialra).

Két fő stratégia létezik kódbázisunk tárolására és kezelésére a Giten keresztül: a monorepo megközelítés és a több repó megközelítés. 🚀 Fedezze fel mindegyiket ebben az útmutatóban ⬇️Kattintson Tweet

Mi az a Monorepo?

A monorepo megközelítés egyetlen adattárat használ a vállalat projektjeit alkotó több könyvtár vagy szolgáltatás összes kódjának tárolására. A legszélsőségesebb esetben a vállalat teljes kódbázisa – amely különböző projekteket ölel fel és különböző nyelveken van kódolva – egyetlen adattárban található.

A Monorepo előnyei

A teljes kódbázis egyetlen tárolóban való tárolása a következő előnyöket nyújtja.

Csökkenti a belépési korlátokat

Amikor új munkatársak kezdenek dolgozni egy vállalatnál, le kell tölteniük a kódot, és telepíteniük kell a szükséges eszközöket, hogy elkezdhessenek dolgozni a feladataikon. Tegyük fel, hogy a projekt sok lerakatban van szétszórva, és mindegyik rendelkezik a szükséges telepítési utasításokkal és szerszámokkal. Ebben az esetben a kezdeti beállítás bonyolult lesz, és gyakran a dokumentáció nem lesz teljes, ezért az új csapattagoknak meg kell fordulniuk a kollégákhoz segítségért.

A monorepo leegyszerűsíti a dolgokat. Mivel egyetlen helyen található az összes kód és dokumentáció, egyszerűsítheti a kezdeti beállítást.

Központi helyen található kódkezelés

Egyetlen adattárral minden fejlesztő láthatja az összes kódot. Leegyszerűsíti a kódkezelést, mivel egyetlen problémakövető segítségével figyelhetjük az összes problémát az alkalmazás életciklusa során.

Például ezek a jellemzők akkor értékesek, ha egy probléma két (vagy több) gyermekkönyvtárat érint, és a függő könyvtárban található hiba. Több adattár esetén nehéz lehet megtalálni azt a kódrészletet, ahol a probléma előfordul.

Ezen felül ki kell találnunk, hogy melyik adattárat használjuk a probléma létrehozásához, majd meghívnunk és keresztcímkéznünk kell más csapatok tagjait, hogy segítsenek megoldani a problémát.

A monorepo használatával azonban mind a kódproblémák megtalálása, mind a hibaelhárítási együttműködés egyszerűbbé válik.

Fájdalommentes, az egész alkalmazásra kiterjedő refaktorálás

A kód alkalmazásszintű átalakítása során több könyvtár is érintett lesz. Ha több adattáron keresztül tárolja őket, kihívást jelenthet a különböző lekérési kérések kezelése, hogy azok egymással szinkronban legyenek.

A monorepo megkönnyíti az összes kód módosításának végrehajtását az összes könyvtárban, és egyetlen lekérési kérelemmel elküldi azt.

A szomszédos funkciókat nehezebb megszakítani

A monorepo segítségével beállíthatjuk az összes tesztet az összes könyvtár számára, hogy azok lefussanak, amikor bármelyik könyvtárat módosítják. Ennek eredményeként annak a valószínűsége, hogy bizonyos könyvtárakban változtatásokat hajtanak végre, minimálisra csökkentette a többi könyvtárra gyakorolt ​​káros hatást.

A csapatok megosztják a fejlesztési kultúrát

Bár nem lehetetlen, a monorepo megközelítéssel kihívást jelent egyedi szubkultúrák inspirálása a különböző csapatok között. Mivel ugyanazon az adattáron osztoznak, nagy valószínűséggel ugyanazokat a programozási és felügyeleti módszereket fogják használni, és ugyanazokat a fejlesztőeszközöket fogják használni.

A Monorepo-megközelítés problémái

Ha egyetlen tárhelyet használunk az összes kódunkhoz, számos hátránya van.

Lassabb fejlesztési ciklusok

Ha egy könyvtár kódja megszakító változtatásokat tartalmaz, amelyek miatt a függő könyvtárak tesztje meghiúsul, a kódot is javítani kell a módosítások összevonása előtt.

Ha ezek a könyvtárak más csapatoktól függenek, akik valamilyen más feladaton dolgoznak, és nem tudják (vagy nem akarják) módosítani a kódjukat, hogy elkerüljék a törést okozó változásokat, és sikeresek legyenek a tesztek, akkor az új funkció fejlesztése elakadhat.

Sőt, lehet, hogy a projekt csak a vállalat leglassabb csapatának sebességével indul előre. Ez az eredmény frusztrálhatja a leggyorsabb csapatok tagjait, és olyan feltételeket teremthet számukra, amelyek el akarják hagyni a céget.

Ezenkívül egy könyvtárnak le kell futtatnia a teszteket az összes többi könyvtárra is. Minél több tesztet kell futtatni, annál több időbe telik a futtatásuk, ami lelassítja a kódunk ismétlésének sebességét.

A teljes kódbázis letöltése szükséges

Ha a monorepo tartalmazza a cég összes kódját, akkor az hatalmas lehet, és gigabájtnyi adatot tartalmazhat. A benne tárolt könyvtárhoz való hozzájáruláshoz bárkinek le kell töltenie a teljes tárat.

Ha egy hatalmas kódbázissal foglalkozunk, akkor a merevlemezek helyének rossz kihasználása és lassabb interakciója következik be. Például a mindennapi tevékenységek, mint például a végrehajtás git status vagy a kódbázisban való keresés egy regex segítségével sok másodpercig vagy akár perccel tovább tarthat, mint több repo esetén.

A módosítatlan könyvtárak új verzióval készülhetnek

Amikor felcímkézzük a monorepo-t, az összes kódhoz hozzárendeljük az új címkét. Ha ez a művelet új kiadást vált ki, akkor a lerakatban tárolt összes könyvtár újonnan jelenik meg a címke verziószámával, még akkor is, ha ezek közül a könyvtárak közül sok nem változott.

Az elágazás nehezebb

A nyílt forráskódú projekteknek a lehető legkönnyebbé kell tenniük a közreműködők részvételét. Több adattár esetén a közreműködők közvetlenül a projekt adott tárházához léphetnek, amelyhez hozzájárulni szeretnének. A különböző projekteket befogadó monorepo esetében azonban a közreműködőknek először el kell navigálniuk a megfelelő projektet, és meg kell érteniük, hogy hozzájárulásuk hogyan befolyásolhatja az összes többi projektet.

Mi az a Multi-Repo?

A multi-repo megközelítés több adattárat használ egy vállalat által kifejlesztett projekt több könyvtárának vagy szolgáltatásának tárolására. A legszélsőségesebb esetben minden minimális újrafelhasználható kódkészletet vagy önálló funkciót (például mikroszolgáltatást) tárol a tárában.

A Multi-Repo előnyei

Minden könyvtárnak a többitől függetlenül való tárolása rengeteg előnnyel jár.

Független könyvtári verzió

Egy adattár címkézésekor a teljes kódbázisához hozzárendeljük az „új” címkét. Mivel csak egy adott könyvtár kódja található a tárhelyen, a könyvtár címkézhető és verziózható az összes többi, máshol tárolt könyvtártól függetlenül.

Ha minden könyvtárhoz van egy független verzió, ez segít meghatározni az alkalmazás függőségi fáját, lehetővé téve számunkra, hogy konfiguráljuk az egyes könyvtárak melyik verzióját használjuk.

Független szolgáltatási kiadások

Mivel a lerakat csak néhány szolgáltatás kódját tartalmazza, mást nem, saját üzembe helyezési ciklusa lehet, függetlenül a hozzáférő alkalmazások előrehaladásától.

A szolgáltatás gyors kiadási ciklust használhat, például folyamatos kézbesítést (ahol az új kódot az összes teszten való átadás után telepítik). Egyes, a szolgáltatást elérő könyvtárak lassabb kiadási ciklust alkalmazhatnak, például azok, amelyek csak hetente egyszer adnak ki új kiadást.

Segít meghatározni a hozzáférés-vezérlést az egész szervezeten belül

Csak a könyvtár fejlesztésében részt vevő csapattagokat kell hozzáadni a megfelelő tárolóhoz, és letölteni a kódját. Ennek eredményeként az alkalmazás minden rétegéhez létezik egy implicit hozzáférés-vezérlési stratégia. A könyvtárral érintettek szerkesztési jogot kapnak, és mindenki más nem férhet hozzá a tárhoz. Vagy olvasási, de szerkesztési jogot nem kapnak.

Lehetővé teszi a csapatok önálló munkáját

A csapattagok megtervezhetik a könyvtár architektúráját és implementálhatják a kódját az összes többi csapattól elkülönítve. Döntéseket hozhatnak a könyvtár általános tevékenységei alapján anélkül, hogy valamilyen külső csapat vagy alkalmazás konkrét követelményei befolyásolnák őket.

Problémák a Multi-Repo megközelítéssel

Több adattár használata számos problémát okozhat.

A könyvtárakat folyamatosan újraszinkronizálni kell

Amikor egy könyvtár törést okozó változtatásokat tartalmazó új verzióját adják ki, a könyvtártól függő könyvtárakat hozzá kell igazítani a legújabb verzió használatához. Ha a könyvtár kiadási ciklusa gyorsabb, mint a függő könyvtáraié, akkor ezek gyorsan kieshetnek egymással.

A csapatoknak folyamatosan utol kell érniük, hogy használhassák más csapatok legújabb kiadásait. Tekintettel arra, hogy a különböző csapatoknak más-más prioritásuk van, ennek megvalósítása néha nehézkesnek bizonyulhat.

Következésképpen egy csapat, aki nem tud utolérni, ragaszkodhat a függő könyvtár elavult verziójához. Ez az eredmény hatással lesz az alkalmazásra (biztonsági, sebességi és egyéb szempontok tekintetében), és a könyvtárak közötti fejlesztési szakadék csak tovább nőhet.

May Fragment Teams

Ha a különböző csapatoknak nincs szükségük interakcióra, saját silójukban dolgozhatnak. Hosszú távon ez azt eredményezheti, hogy a csapatok a vállalaton belül alakítják ki szubkultúráikat, például különböző programozási vagy menedzsment-módszereket alkalmaznak, vagy különböző fejlesztőeszközöket alkalmaznak.

Ha egy csapattagnak végül egy másik csapatban kell dolgoznia, egy kis kulturális sokkot szenvedhet el, és új módszert tanulhat a munkája elvégzésére.

Monorepo vs Multi-Repo: Elsődleges különbségek

Mindkét megközelítés végső soron ugyanazt a célt szolgálja: a kódbázis kezelését. Ezért mindkettőjüknek ugyanazokat a kihívásokat kell megoldaniuk, beleértve a kiadáskezelést, a csapattagok közötti együttműködés elősegítését, a problémák kezelését, a tesztek futtatását és egyebeket.

A fő különbség a csapattagok döntéseinek időzítésében rejlik: vagy előzetesen monorepo esetén, vagy lefelé a több repo esetében.

Elemezzük ezt az ötletet részletesebben.

Mivel a többtárolásban minden könyvtárat egymástól függetlenül verzióznak, a törést okozó módosításokkal rendelkező könyvtárat kiadó csapat biztonságosan megteheti, ha új főverziószámot rendel a legújabb kiadáshoz. Más csoportok függő könyvtárai ragaszkodhatnak a régi verzióhoz, és átválthatnak az újra, miután kódjukat adaptálták.

Ez a megközelítés az egyes felelős csapatokra hagyja a döntést, hogy mikor kell az összes többi könyvtárat hozzáigazítani, akik ezt bármikor megtehetik. Ha túl későn teszik ezt, és új könyvtári verziók jelennek meg, a könyvtárak közötti szakadék bezárása egyre nehezebbé válik.

Következésképpen, míg az egyik csapat gyorsan és gyakran a saját kódján iterál, előfordulhat, hogy más csapatok képtelenek felzárkózni, és végül eltérő könyvtárakat hoznak létre.

Másrészről monorepo környezetben nem adhatunk ki egy olyan könyvtár új verzióját, amely megszakít egy másik könyvtárat, mivel a tesztek sikertelenek lesznek. Ebben az esetben az első csapatnak kommunikálnia kell a második csapattal a változtatások beépítése érdekében.

Belefáradt az 1. alacsonyabb szintű WordPress tárhely-támogatásba a válaszok nélkül? Próbálja ki világszínvonalú támogató csapatunkat! Tekintse meg terveinket

Ez a megközelítés arra kényszeríti a csapatokat, hogy az összes könyvtárat teljesen adaptálják, amikor csak egyetlen könyvtárat kell megváltoztatni. Minden csapat kénytelen beszélni egymással, és közösen megoldást találni.

Ennek eredményeként az első csapat nem lesz képes olyan gyorsan iterálni, mint szeretnének, de a különböző könyvtárakban lévő kód soha nem kezd eltérni.

Összefoglalva, a multi-repo megközelítés segíthet létrehozni a „gyorsan mozgatni és megtörni a dolgokat” kultúráját a csapatok között, ahol a fürge, független csapatok a maguk sebességével tudják produkálni eredményeiket. Ehelyett a monorepo megközelítés a tudatosság és törődés kultúráját részesíti előnyben, ahol a csapatoknak nem szabad lemaradniuk, hogy egyedül kezeljék a problémát.

Hibrid Poly-As-Mono Megközelítés

Ha nem tudjuk eldönteni, hogy a multi-repo vagy a monorepo megközelítést használjuk, akkor létezik a közbenső megközelítés is: több adattárat használunk, és valamilyen eszközt alkalmazunk a szinkronizálásra, így a monorepóhoz hasonlít, de nagyobb rugalmasságot biztosít.

A Meta az egyik ilyen eszköz. Több tárolót szervez alkönyvtárak alá, és olyan parancssori felületet biztosít, amely mindegyiken egyszerre hajtja végre ugyanazt a parancsot.

A meta-lerakat tartalmazza azt az információt, hogy mely adattárak alkotják a projektet. Ennek a tárháznak a metán keresztüli klónozása azután rekurzív módon klónozza az összes szükséges tárolót, megkönnyítve az új csapattagok számára, hogy azonnal elkezdjenek dolgozni a projektjeiken.

Egy meta-lerakat és az összes meghatározott többszörös repó klónozásához a következőket kell végrehajtanunk:

meta git clone [meta repo url]

A Meta végrehajtja a git clone minden tárolóhoz, és helyezze el egy almappába:

Meta projekt klónozása
Metaprojekt klónozása. (A kép forrása: github.com/mateodelnorte/meta)

Ettől kezdve végrehajtva a meta exec parancs végrehajtja a parancsot az egyes almappákban. Például a végrehajtás git checkout master minden adattáron a következőképpen történik:

meta exec "git checkout master"

Hibrid Mono-As-Poly megközelítés

Egy másik megközelítés a kód kezelése monorepo-n keresztül fejlesztés céljából, de az egyes könyvtárak kódjait a független lerakatába másolják telepítés céljából.

Ez a stratégia elterjedt a PHP ökoszisztémán belül, mivel a Packagist (a fő Composer tárhely) nyilvános tárhely URL-címet igényel egy csomag közzétételéhez, és nem lehet jelezni, hogy a csomag a tároló alkönyvtárában található.

Tekintettel a Packagist korlátozására, a PHP-projektek továbbra is használhatnak monorepót a fejlesztéshez, de a telepítéshez a multi-repo megközelítést kell használniuk.

Ennek az átalakításnak az eléréséhez futtathatunk egy szkriptet a git subtree split Vagy használja a rendelkezésre álló eszközök egyikét, amelyek ugyanazt a logikát hajtják végre:

  • Git Subtree Splitter
  • Git Subsplit
  • GitHub-akció Monorepo Splithez

Ki használja a Monorepo vs Multi-Repo szolgáltatást?

Több nagy technológiai vállalat a monorepo megközelítést részesíti előnyben, míg mások a multi-repo módszer alkalmazása mellett döntöttek.

A Google, a Facebook, a Twitter és az Uber nyilvánosan kezeskedtek a monorepo megközelítés mellett. A Microsoft a bolygó legnagyobb Git monorepóját futtatja a Windows operációs rendszer forráskódjának tárolására.

A másik oldalon a Netflix, az Amazon és a Lyft híres cégek, amelyek több repo megközelítést alkalmaznak.

A hibrid poly-as-mono oldalon az Android több adattárat frissít, amelyeket monorepoként kezelnek.

A hibrid mono-as-poly oldalon a Symfony minden összetevőjének kódját monorepo-ban tartja. Felosztották független tárolókra a telepítéshez (pl symfony/dependency-injection és a symfony/event-dispatcher.)

Példák Monorepo és Multi-Repo

A GitHubon található WordPress-fiók példákat tartalmaz mind a monorepo, mind a multi-repo megközelítésekre.

A Gutenberg, a WordPress blokkszerkesztője több tucat JavaScript-csomagból áll. Ezek a csomagok mind a WordPress/gutenberg monorepo, és a Lernán keresztül kezelték, hogy segítsenek közzétenni őket az npm adattárban.

Az Openverse, a nyíltan licencelt médiák keresőmotorja, fő részeit független tárolókban tárolja: előtérben, katalógusban és API-ban.

Monorepo vs Multi-Repo: Hogyan válasszunk?

Mint sok fejlesztési probléma esetében, nincs előre meghatározott válasz arra vonatkozóan, hogy melyik megközelítést érdemes alkalmazni. Különböző cégek és projektek profitálnak az egyik vagy másik stratégiából egyedi feltételeik alapján, mint például:

  • Mekkora a kódbázis? Gigabájtnyi adatot tartalmaz?
  • Hány ember fog dolgozni a kódbázison? 10, 100 vagy 1,000 körül van?
  • Hány csomag lesz? 10, 100 vagy 1,000 körül van?
  • Hány csomagon kell egy adott időpontban dolgoznia a csapatnak?
  • Milyen szorosan kapcsolódnak egymáshoz a csomagok?
  • Különböző programozási nyelvek vannak benne? Egy adott szoftver telepítése vagy speciális hardver szükséges a futtatáshoz?
  • Hány telepítési eszközre van szükség, és mennyire bonyolult ezek beállítása?
  • Milyen a kultúra a cégben? Ösztönözik a csapatokat az együttműködésre?
  • Milyen eszközöket és technológiákat tudnak a csapatok használni?

Melyik megközelítést kell alkalmaznia a kódbázishoz? 🤔 Tudjon meg többet itt 👇Kattintson Tweet

Összegzés

Két fő stratégia létezik a kód tárolására és kezelésére: monorepo vs multi-repo. A monorepo megközelítés azt jelenti, hogy a különböző könyvtárak vagy projektek kódját – és akár egy vállalattól származó összes kódot is – egyetlen tárolóban tárolják. A többtárolásos rendszer a kódot egységekre, például könyvtárakra vagy szolgáltatásokra osztja, és a kódjukat független tárolókban tárolja.

Az, hogy melyik megközelítést alkalmazzuk, számos körülménytől függ. Mindkét stratégiának számos előnye és hátránya van, és ebben a cikkben mindegyiket részletesen ismertettük.

Maradt még kérdése a monorepókkal vagy a többrepóval kapcsolatban? Tudassa velünk a megjegyzés rovatban!

Kapcsolódó cikkek

0 Hozzászólások
Inline visszajelzések
Az összes hozzászólás megtekintése
Vissza a lap tetejére gombra