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:

• Jedno miesto na uloženie všetkých konfigurácií a testov. Pretože všetko sa nachádza v jednom úložisku, môžete svoje CI / CD a bundler nakonfigurovať naraz a potom iba znova použiť konfigurácie na zostavenie všetkých balíkov pred ich publikovaním na diaľku. To isté platí pre testy jednotky, e2e a integrácie - váš modul CI bude schopný spustiť všetky testy bez toho, aby ste museli riešiť ďalšiu konfiguráciu.
• Ľahko refaktorujte globálne funkcie pomocou atómových záväzkov. Namiesto toho, aby ste pre každé repo vykonali požiadavku na stiahnutie, zistili ste, v akom poradí chcete vytvoriť svoje zmeny, stačí urobiť požiadavku na atómový výber, ktorá bude obsahovať všetky potvrdenia súvisiace s funkciou, proti ktorej pracujete.
• Zjednodušené zverejňovanie balíkov. Ak plánujete implementovať novú funkciu do balíka, ktorý je závislý na inom balíku so zdieľaným kódom, môžete to urobiť pomocou jediného príkazu. Je to funkcia, ktorá vyžaduje niektoré ďalšie konfigurácie, o ktorých sa bude neskôr diskutovať v časti venovanej kontrole nástrojov v tomto článku. V súčasnosti existuje bohatý výber nástrojov, napríklad Lerna, Yarn Workspaces a Bazel.
• Jednoduchšia správa závislostí. Len jeden balíček.json . Nie je potrebné znova inštalovať závislosti v každom repo, kedykoľvek chcete aktualizovať svoje závislosti.
• Znovu použite kód so zdieľanými balíkmi, pričom ich stále udržiavajte izolované. Monorepo vám umožňuje opakovane používať vaše balíčky od iných balíkov a zároveň ich udržiavať izolované od seba. Môžete použiť odkaz na vzdialený balík a spotrebovať ich cez jediný vstupný bod. Ak chcete používať lokálnu verziu, môžete používať miestne symbolické odkazy. Túto funkciu je možné implementovať pomocou bash skriptov alebo zavedením niektorých ďalších nástrojov, ako je Lerna alebo Yarn.

Monorepo Nevýhody:

• Nijako sa nedá obmedziť prístup iba k niektorým častiam aplikácie. Bohužiaľ nemôžete zdieľať iba časť svojho monorepo - budete musieť poskytnúť prístup k celej kódovej základni, čo by mohlo viesť k bezpečnostným problémom.

• 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.

• Vyšší čas na zostavenie. Pretože budete mať veľa zdrojového kódu na jednom mieste, váš server CI bude potrebovať viac času na spustenie všetkého, aby mohol schváliť každé PR.

Kontrola nástroja

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ú:

• Bazilej je systém zostavovania orientovaný na spoločnosť Monorepo. Viac informácií o Bazeli: uzasny-bazel
• Priadza je nástroj na správu závislostí JavaScript, ktorý podporuje monorepos prostredníctvom pracovných priestorov.
• Naučte sa je nástroj na správu projektov v JavaScripte s viacerými balíčkami, založený na Yarn.

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:

Naučte sa

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:

1. Bez toho, aby ste ich tlačili na diaľkové ovládanie (NPM)
2. Posielanie vašich balíkov na diaľkové ovládanie

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

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:

1. Single 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.
2. Závislosť symlinking umožňujúci vývoj lokálneho balíka.
3. Jeden zámkový súbor pre všetky závislosti.
4. Cielená aktualizácia závislostí v prípade, že chcete preinštalovať závislosti iba pre jeden balík. To možno vykonať pomocou -focus vlajka.
5. Integrácia s Lernou. Môžete ľahko nastaviť, aby Yarn zvládla všetku inštaláciu / symbolické odkazy a nechala Lernu, aby sa postarala o publikovanie a správu verzií. Toto je zatiaľ najpopulárnejšie nastavenie, pretože vyžaduje menej úsilia a je ľahké s ním pracovať.

Užitočné odkazy:

• Pracovné priestory priadze
• Ako zostaviť mono-repo projekt TypeScript

Bazilej

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é:

1. Bremená the BUILD súbory relevantné pre cieľ.
2. Analýzy vstupy a ich závislosti , použije určené pravidlá zostavenia a vytvorí súbor akcia graf.
3. Vykonáva akcie budovania na vstupoch, kým sa nevyprodukujú konečné výstupy stavania.

Užitočné odkazy:

• JavaScript a Bazel - Dokumenty za vytvorenie projektu Bazel pre JS od nuly.
• Pravidlá JavaScript a TypeScript pre Bazel - Kotol pre JS.

Záver

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 Git

Pochopenie základov

Čo sa myslí pod monolitickou architektúrou?

Monolitická 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.

Čo sú úložiská zdrojových kódov?

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.

Prečo je v programovaní dôležitá modularita?

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.

Čo sú to symbolické odkazy?

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.

Aký je najbežnejší spôsob výroby modulov v JS?

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.