Monorepos sú horúcou témou diskusie. V poslednej dobe vyšlo veľa článkov o tom, prečo by ste tento typ architektúry mali a nemali používať pre svoj projekt, ale väčšina z nich je tak či onak zaujatá. Táto séria je pokusom zhromaždiť a vysvetliť čo najviac informácií, aby ste pochopili, ako a kedy používať monorepos.
TO Monorepository je architektonický koncept, ktorý v zásade obsahuje všetok význam vo svojom názve. Namiesto spravovania viacerých úložísk ponecháte všetky svoje izolované časti kódu v jednom úložisku. Majte na pamäti slovo izolovaný —To znamená, že monorepo nemá nič spoločné s monolitickými aplikáciami. V jednom repo môžete mať veľa druhov logických aplikácií; napríklad webová stránka a jej aplikácia pre iOS.
Tento koncept je pomerne starý a objavil sa asi pred desiatimi rokmi. Google bol jednou z prvých spoločností, ktoré prijali tento prístup pri správe svojich kódových databáz. Môžete sa opýtať, ak existuje už desaťročie, tak prečo je to taká horúca téma až teraz? Väčšinou za posledných 5 - 6 rokov prešlo veľa vecí dramatickými zmenami. ES6, preprocesory SCSS, správcovia úloh, NPM atď. - ak chcete dnes udržiavať malú aplikáciu založenú na reakciách, musíte sa dnes zaoberať balíčkami projektov, testovacími balíkmi, skriptmi CI / CD, konfiguráciami Dockeru a ktovie čo ešte. A teraz si predstavte, že namiesto malej aplikácie musíte udržiavať obrovskú platformu pozostávajúcu z mnohých funkčných oblastí. Ak uvažujete o architektúre, budete chcieť urobiť dve hlavné veci: Oddeľte sa od problémov a vyhnite sa duplikovaniu kódu.
Aby ste to dosiahli, pravdepodobne budete chcieť izolovať veľké funkcie do niektorých balíkov a potom ich použiť prostredníctvom jedného vstupného bodu v hlavnej aplikácii. Ako však spravujete tieto balíčky? Každý balík bude musieť mať svoju vlastnú konfiguráciu prostredia pracovného toku, čo znamená, že zakaždým, keď budete chcieť vytvoriť nový balík, budete musieť nakonfigurovať nové prostredie, skopírovať všetky konfiguračné súbory atď. Alebo napríklad ak budete musieť niečo zmeniť vo svojom systéme zostavovania, budete musieť prejsť každé repo, vykonať potvrdenie, vytvoriť požiadavku na načítanie a počkať na každé zostavenie, čo vás veľmi spomalí. V tomto kroku sa stretávame s monorepos.
Namiesto toho, aby sme mali veľa úložísk s vlastnými konfiguráciami, budeme mať iba jeden zdroj pravdy - monorepo: jeden bežec testovacej sady, jeden konfiguračný súbor Docker a jedna konfigurácia pre Webpack. A stále máte škálovateľnosť, príležitosť na oddelenie problémov, zdieľanie kódu s bežnými balíkmi a mnoho ďalších výhod. Znie to pekne, však? No je. Existujú však aj niektoré nevýhody. Pozrime sa podrobne na presné výhody a nevýhody používania monorepo vo voľnej prírode.
Výhody Monorepo:
Monorepo Nevýhody:
Zlý výkon Gitu pri práci na rozsiahlych projektoch. Tento problém sa začína objavovať až dňa obrovský aplikácie s viac ako miliónom záväzkov a stovkami vývojárov vykonávajúcich svoju prácu každý deň súčasne v rovnakom repo. To sa stáva obzvlášť nepríjemným, pretože Git používa riadený acyklický graf (DAG) na znázornenie histórie projektu. Pri veľkom počte záväzkov môže byť akýkoľvek príkaz, ktorý prejde grafom, s prehlbovaním histórie pomalý. Výkon sa spomaľuje aj z dôvodu počtu odporúčaní (t. J. Vetiev alebo značiek, ktoré je možné vyriešiť odstránením odporúčaní, ktoré už nepotrebujete) a množstva sledovaných súborov (ako aj ich váhy, aj keď je možné problém s ťažkými súbormi vyriešiť pomocou Choďte na LFS ).
Poznámka: V súčasnosti sa Facebook snaží vyriešiť problémy so škálovateľnosťou VCS opravou Mercurialu a pravdepodobne čoskoro to nebude taký veľký problém.
Sada nástrojov na správu monorepos sa neustále rozrastá a v súčasnosti je skutočne ľahké sa stratiť vo všetkých rôznych stavebných systémoch pre monorepos. O populárnych riešeniach pomocou môžete kedykoľvek vedieť toto repo . Ale teraz sa poďme rýchlo pozrieť na nástroje, ktoré sa v súčasnosti v JavaScripte často používajú:
Väčšina nástrojov používa skutočne podobný prístup, existujú však určité nuansy.
Ponoríme sa hlbšie do pracovného toku Lerna, ako aj do ďalších nástrojov v časti 2 tohto článku, pretože ide o dosť rozsiahlu tému. Teraz si len poďme urobiť prehľad toho, čo je vo vnútri:
Tento nástroj skutočne pomáha pri práci so sémantickými verziami, nastavovaní pracovného toku budovania, posúvaní vašich balíkov atď. Hlavná myšlienka spoločnosti Lerna je, že váš projekt má priečinok balíkov, ktorý obsahuje všetky vaše izolované časti kódu. Okrem balíkov máte aj hlavnú aplikáciu, ktorá môže napríklad žiť v priečinku src. Takmer všetky operácie v Lerne fungujú podľa jednoduchého pravidla - iterujete všetky svoje balíčky a robíte s nimi nejaké akcie, napríklad zvyšujete verziu balíkov, aktualizujete závislosť všetkých balíkov, zostavujete všetky balíčky atď.
S Lernou máte dve možnosti, ako používať svoje balíčky:
Pri použití prvého prístupu môžete pre svoje balíčky použiť miestne referencie a v podstate sa nestaráte o to, aby ste ich vyriešili pomocou symbolických odkazov.
Ale ak používate druhý prístup, ste nútení importovať svoje balíčky zo vzdialeného. (napr. import { something } from @yourcompanyname/packagename;
), čo znamená, že vždy získate vzdialenú verziu svojho balíka. Pre miestny vývoj budete musieť v koreňovom adresári svojho priečinka vytvoriť symbolické odkazy, aby zväzovač vyriešil miestne balíčky namiesto toho, aby používal tie, ktoré sú vo vašom node_modules/
. Preto pred spustením Webpacku alebo vášho obľúbeného balíka programov budete musieť spustiť lerna bootstrap
, ktorý automaticky prepojí všetky balíčky.
Priadza je spočiatku manažérom závislostí pre balíčky NPM, ktorý nebol pôvodne vytvorený na podporu monorepos. Ale vo verzii 1.0, Vývojári priadze vydal funkciu s názvom Pracovné priestory . V čase vydania to nebolo také stabilné, ale po chvíli sa to stalo použiteľným pre produkčné projekty.
Pracovný priestor je v podstate balík, ktorý má svoje vlastné balíček.json a môže mať niekoľko konkrétnych pravidiel zostavenia (napríklad samostatné tsconfig.json ak vo svojich projektoch používate TypeScript.). Vlastne to môžete nejako zvládnuť bez Yarn Workspaces pomocou bash a mať presne rovnaké nastavenie, ale tento nástroj pomáha uľahčiť proces inštalácie a aktualizácie závislostí na balíček.
Stručne povedané, program Yarn so svojimi pracovnými priestormi poskytuje nasledujúce užitočné funkcie:
node_modules
priečinok v koreňovom adresári pre všetky balíky. Napríklad, ak máte packages/package_a
a packages/package_b
—s vlastnými package.json
—všetky závislosti sa nainštalujú iba v koreňovom adresári. To je jeden z rozdielov medzi tým, ako fungujú Yarn a Lerna.-focus
vlajka.Užitočné odkazy:
Bazel je nástroj na vytváranie rozsiahlych aplikácií, ktorý dokáže spracovať viacjazyčné závislosti a podporuje množstvo moderných jazykov (Java, JS, Go, C ++ atď.). Vo väčšine prípadov je použitie Bazelu pre malé a stredné aplikácie JS prehnané, ale vo veľkom meradle môže vďaka svojmu výkonu poskytnúť veľa výhod.
Bazel svojou povahou vyzerá podobne ako Make, Gradle, Maven a ďalšie nástroje, ktoré umožňujú zostavenie projektu na základe súboru, ktorý obsahuje popis pravidiel zostavenia a závislostí projektu. Rovnaký súbor v Bazeli sa volá BUILD a je umiestnená vo vnútri pracovného priestoru projektu Bazel. The BUILD súbor používa svoje Starlark , ľudsky čitateľný a zostaviteľný jazyk na vysokej úrovni, ktorý sa veľmi podobá Pythonu.
Spravidla s tým veľa nebudete mať do činenia BUILD pretože na webe existuje veľa štandardných platforiem, ktoré sa dajú ľahko nájsť a ktoré sú už nakonfigurované a pripravené na vývoj. Kedykoľvek chcete vytvoriť svoj projekt, Bazel v zásade urobí nasledovné:
Užitočné odkazy:
Monorepos sú iba nástrojom. Existuje veľa argumentov o tom, či má alebo nemá budúcnosť, ale pravdou je, že v niektorých prípadoch tento nástroj robí svoju prácu a pracuje s ňou efektívne. V priebehu posledných niekoľkých rokov sa tento nástroj vyvinul, získal oveľa väčšiu flexibilitu, prekonal množstvo problémov a odstránil vrstvu zložitosti z hľadiska konfigurácie.
Je treba ešte vyriešiť veľa problémov, napríklad zlý výkon systému Git, ale dúfajme, že sa to v blízkej budúcnosti vyrieši.
Ak by ste sa chceli naučiť vytvoriť pre svoju aplikáciu robustný kanál CI / CD, odporúčam Ako zostaviť kanál efektívneho počiatočného nasadenia s GitLab CI .
Súvisiace: Vysvetlenie vylepšeného toku GitMonolitická architektúra vo vývoji softvéru znamená prístup, pri ktorom implementujete svoju aplikáciu ako sadu úzko prepojených komponentov / funkcií zložených do jedného dielu. Nemôžete použiť žiadne komponenty mimo rozsahu aplikácie.
Repozitár je miesto na ukladanie a načítanie zdrojového kódu na jeho inštaláciu / vývoj. Repos ukladajú všetky verzie údajov so súvisiacimi metadátami, čo umožňuje revízie histórie alebo prácu na samostatných paralelných verziách toho istého projektu.
Voľne spojený kód sa ukázal ako spoľahlivejší, pretože nám umožňuje zavádzať zmeny bez toho, aby sme sa báli rozbiť veci na iných miestach. Toto umožňuje bezpečnejší vývoj a zjednodušuje refaktoring.
Symlinks (symbolické odkazy) sú súbory odkazujúce na pôvodný priečinok / súbor vo forme relatívnej alebo absolútnej cesty namiesto skutočného obsahu. V takom prípade sa používajú na ovplyvnenie rozlíšenia názvu cesty na správne miesto.
Najpopulárnejším spôsobom, ako v súčasnosti izolovať kód do samostatných modulov, je použitie balíkov npm (je to možné pomocou programu Yarn alebo npm). Sú zabalené do priečinka s vlastnými konfiguračnými súbormi a potom presunuté na vzdialený server.