Wordpress

Monorepo vs Multi-Repo: Klady a zápory strategií úložiště kódu

Existují dvě hlavní strategie pro hostování a správu kódu přes Git: monorepo vs multi-repo. Oba přístupy mají svá pro a proti.

Můžeme použít oba přístupy pro jakoukoli kódovou základnu v jakémkoli jazyce. Kteroukoli z těchto strategií můžete použít pro projekty obsahující několik knihoven až tisíce z nich. I když se to týká několika členů týmu nebo stovek, nebo chcete hostit soukromý nebo open-source kód, stále můžete použít monorepo nebo multi-repo na základě různých faktorů.

Jaké jsou výhody a nevýhody jednotlivých přístupů? Kdy bychom měli použít jedno nebo druhé? Pojďme to zjistit!

Co jsou Repos?

Úložiště (zkratka pro repozitář) je úložiště pro všechny změny a soubory z projektu, které umožňuje vývojářům „kontrolu verzí“ aktiv projektu během jeho vývojové fáze.

Obvykle odkazujeme na repozitáře Git (jak je poskytují GitHub, GitLab nebo Bitbucket), ale tento koncept platí také pro jiné systémy pro správu verzí (jako je Mercurial).

Existují dvě hlavní strategie pro hostování a správu naší kódové základny prostřednictvím Git: přístup monorepo a přístup s více repo. 🚀 Prozkoumejte každý v tomto průvodci ⬇️Kliknutím Tweet

Co je to Monorepo?

Přístup monorepo využívá jediné úložiště pro hostování veškerého kódu pro více knihoven nebo služeb tvořících projekty společnosti. Ve své nejextrémnější podobě je celá kódová základna od společnosti – zahrnující různé projekty a kódovaná v různých jazycích – umístěna v jediném úložišti.

Výhody Monorepo

Hostování celé kódové základny na jediném úložišti poskytuje následující výhody.

Snižuje bariéry vstupu

Když noví zaměstnanci začnou pracovat pro společnost, musí si stáhnout kód a nainstalovat požadované nástroje, aby mohli začít pracovat na svých úkolech. Předpokládejme, že projekt je rozptýlen v mnoha úložištích, z nichž každé má své instalační pokyny a potřebné nástroje. V takovém případě bude počáteční nastavení složité a často nebude dokumentace kompletní, což vyžaduje, aby tito noví členové týmu požádali o pomoc kolegy.

Monorepo zjednodušuje záležitosti. Protože existuje jediné místo obsahující veškerý kód a dokumentaci, můžete zefektivnit počáteční nastavení.

Centrálně umístěná správa kódu

Díky jedinému úložišti bude veškerý kód vidět všem vývojářům. Zjednodušuje správu kódu, protože můžeme použít jediný sledovač problémů ke sledování všech problémů v průběhu životního cyklu aplikace.

Tyto vlastnosti jsou například cenné, když problém zahrnuje dvě (nebo více) podřízených knihoven s chybou existující v závislé knihovně. U více úložišť může být obtížné najít část kódu, kde se problém vyskytuje.

Kromě toho bychom museli zjistit, které úložiště použít k vytvoření problému, a pak pozvat a označit členy jiných týmů, aby pomohli problém vyřešit.

S monorepo je však snazší dosáhnout jak lokalizace problémů s kódem, tak spolupráce při jejich odstraňování.

Bezbolestné refaktoringy pro celou aplikaci

Při vytváření refaktoringu kódu v celé aplikaci bude ovlivněno více knihoven. Pokud je hostujete prostřednictvím více úložišť, může být obtížné spravovat všechny různé požadavky na stahování, aby byly vzájemně synchronizovány.

Monorepo usnadňuje provádění všech úprav veškerého kódu pro všechny knihovny a odesílání v rámci jediného požadavku na stažení.

Obtížnější prolomit sousední funkce

S monorepo můžeme nastavit všechny testy pro všechny knihovny, aby se spustily při každé úpravě jedné knihovny. V důsledku toho pravděpodobnost provedení změny v některých knihovnách minimalizovala nepříznivé účinky na jiné knihovny.

Týmy sdílejí kulturu rozvoje

I když to není nemožné, s monorepo přístupem se stává výzvou inspirovat jedinečné subkultury mezi různými týmy. Vzhledem k tomu, že budou sdílet stejné úložiště, budou s největší pravděpodobností sdílet stejné metodologie programování a správy a používat stejné vývojové nástroje.

Problémy s přístupem Monorepo

Použití jediného úložiště pro celý náš kód má několik nevýhod.

Pomalejší vývojové cykly

Když kód knihovny obsahuje změny, které způsobí selhání testů závislých knihoven, musí být kód také opraven před sloučením změn.

Pokud tyto knihovny závisejí na jiných týmech, které jsou zaneprázdněny prací na nějakém jiném úkolu a nejsou schopny (nebo ochotny) přizpůsobit svůj kód tak, aby se vyhnuly přelomovým změnám a testy prošly, může se vývoj nové funkce zastavit.

A co víc, projekt může klidně začít postupovat jen rychlostí nejpomalejšího týmu ve firmě. Tento výsledek by mohl frustrovat členy nejrychlejších týmů a vytvářet podmínky pro to, aby chtěli společnost opustit.

Kromě toho bude muset knihovna spustit testy i pro všechny ostatní knihovny. Čím více testů je spuštěno, tím více času trvá jejich spuštění, což zpomaluje, jak rychle můžeme iterovat náš kód.

Vyžaduje stažení celé kódové základny

Když monorepo obsahuje veškerý kód pro společnost, může být obrovské a může obsahovat gigabajty dat. Aby mohl kdokoli přispět do jakékoli knihovny hostované v rámci, musel by si stáhnout celé úložiště.

Práce s rozsáhlou kódovou základnou znamená špatné využití místa na našich pevných discích a pomalejší interakce s nimi. Například každodenní činnosti, jako je provádění git status nebo vyhledávání v kódové základně pomocí regulárního výrazu může trvat o mnoho sekund nebo dokonce minut déle, než by tomu bylo u více úložišť.

Neupravené knihovny mohou mít novou verzi

Když označíme monorepo, veškerému kódu v něm je přiřazena nová značka. Pokud tato akce spustí nové vydání, všechny knihovny hostované v úložišti budou nově vydány s číslem verze ze značky, i když mnoho z těchto knihoven nemuselo mít žádnou změnu.

Rozvětvení Je Obtížnější

Open source projekty musí přispěvatelům co nejvíce usnadnit zapojení. S více úložišti mohou přispěvatelé zamířit přímo do konkrétního úložiště projektu, do kterého chtějí přispět. U monorepa hostujícího různé projekty se však přispěvatelé musí nejprve dostat do správného projektu a budou muset pochopit, jak může jejich příspěvek ovlivnit všechny ostatní projekty.

Co je Multi-Repo?

Přístup multi-repo využívá několik úložišť k hostování více knihoven nebo služeb projektu vyvinutého společností. V nejextrémnějším případě bude hostovat každou minimální sadu opakovaně použitelného kódu nebo samostatné funkce (jako je mikroslužba) ve svém úložišti.

Výhody Multi-Repo

Hostování každé knihovny nezávisle na všech ostatních poskytuje nepřeberné množství výhod.

Nezávislé verzování knihoven

Při označování úložiště je celé jeho kódové základně přiřazen štítek „nový“. Vzhledem k tomu, že v úložišti je pouze kód pro konkrétní knihovnu, lze knihovnu označovat a verzovat nezávisle na všech ostatních knihovnách hostovaných jinde.

Nezávislá verze pro každou knihovnu pomáhá definovat strom závislostí pro aplikaci, což nám umožňuje nakonfigurovat, jakou verzi každé knihovny použít.

Nezávislé servisní zprávy

Vzhledem k tomu, že úložiště obsahuje pouze kód pro nějakou službu a nic jiného, ​​může mít svůj vlastní cyklus nasazení, nezávisle na pokroku aplikací, které k němu přistupují.

Služba může využívat rychlý cyklus vydávání, jako je průběžné doručování (kdy je nový kód nasazen poté, co projde všemi testy). Některé knihovny přistupující ke službě mohou používat pomalejší cyklus vydávání, například ty, které vytvářejí nové vydání pouze jednou týdně.

Pomáhá definovat řízení přístupu v celé organizaci

Pouze členové týmu zapojení do vývoje knihovny musí být přidáni do odpovídajícího úložiště a stáhnout jeho kód. Výsledkem je, že pro každou vrstvu v aplikaci existuje implicitní strategie řízení přístupu. Ti, kdo jsou zapojeni do knihovny, získají práva na úpravy a všichni ostatní nemusí mít přístup do úložiště. Nebo jim mohou být udělena práva na čtení, ale ne na úpravy.

Umožňuje týmům pracovat autonomně

Členové týmu mohou navrhnout architekturu knihovny a implementovat její kód pracující izolovaně od všech ostatních týmů. Mohou se rozhodovat na základě toho, co knihovna dělá v obecném kontextu, aniž by byli ovlivněni konkrétními požadavky nějakého externího týmu nebo aplikace.

Problémy s přístupem Multi-Repo

Používání více úložišť může způsobit několik problémů.

Knihovny musí být neustále znovu synchronizovány

Když je vydána nová verze knihovny obsahující přelomové změny, bude nutné upravit knihovny závislé na této knihovně, aby mohly začít používat nejnovější verzi. Pokud je cyklus vydání knihovny rychlejší než cyklus jejích závislých knihoven, mohly by se rychle vzájemně nesynchronizovat.

Týmy budou muset neustále dohánět, aby mohly používat nejnovější verze od jiných týmů. Vzhledem k tomu, že různé týmy mají různé priority, může být někdy obtížné toho dosáhnout.

V důsledku toho tým, který není schopen dohnat, může nakonec zůstat u zastaralé verze závislé knihovny. Tento výsledek bude mít dopad na aplikaci (z hlediska bezpečnosti, rychlosti a dalších aspektů) a propast ve vývoji napříč knihovnami se může jen prohloubit.

May Fragment Teams

Když různé týmy nepotřebují komunikovat, mohou pracovat ve svých vlastních silech. V dlouhodobém horizontu by to mohlo vést k tomu, že týmy produkují své subkultury v rámci společnosti, například používají různé metodiky programování nebo řízení nebo využívají různé sady vývojových nástrojů.

Pokud některý člen týmu nakonec potřebuje pracovat v jiném týmu, může utrpět mírný kulturní šok a naučit se nový způsob, jak dělat svou práci.

Monorepo vs Multi-Repo: Primární rozdíly

Oba přístupy se nakonec zabývají stejným cílem: správou kódové základny. Oba proto musí řešit stejné problémy, včetně správy vydání, podpory spolupráce mezi členy týmu, řešení problémů, spouštění testů a dalších.

Jejich hlavní rozdíl se týká jejich načasování, aby členové týmu činili rozhodnutí: buď předem pro monorepo, nebo po lince pro multi-repo.

Pojďme analyzovat tuto myšlenku podrobněji.

Protože všechny knihovny jsou v multi-repo verzovány nezávisle, tým vydávající knihovnu s přelomovými změnami to může bezpečně provést přiřazením nového hlavního čísla verze nejnovějšímu vydání. Ostatní skupiny mohou mít své závislé knihovny držet staré verze a přejít na novou, jakmile byl jejich kód upraven.

Tento přístup ponechává rozhodnutí, kdy přizpůsobit všechny ostatní knihovny, každému odpovědnému týmu, který to může udělat kdykoli. Pokud to udělají příliš pozdě a budou vydány nové verze knihoven, bude odstranění mezery mezi knihovnami stále obtížnější.

V důsledku toho, zatímco jeden tým může rychle a často opakovat svůj kód, ostatní týmy se mohou ukázat neschopné dohnat, což nakonec vytvoří knihovny, které se liší.

Na druhou stranu v prostředí monorepo nemůžeme vydat novou verzi jedné knihovny, která naruší nějakou jinou knihovnu, protože jejich testy selžou. V tomto případě musí první tým komunikovat s druhým týmem, aby zapracoval změny.

Už vás nebaví podpora hostingu WordPress úrovně 1 bez odpovědí? Vyzkoušejte náš prvotřídní tým podpory! Podívejte se na naše plány

Tento přístup nutí týmy, aby přizpůsobily všechny knihovny úplně, kdykoli musí nastat změna pro jedinou knihovnu. Všechny týmy jsou nuceny spolu mluvit a společně dospět k řešení.

Výsledkem je, že první tým nebude schopen iterovat tak rychle, jak by si přál, ale kód napříč různými knihovnami se v žádném okamžiku nezačne rozcházet.

Stručně řečeno, přístup multi-repo může pomoci vytvořit kulturu „rychlého pohybu a rozbití věcí“ mezi týmy, kde mohou hbité nezávislé týmy produkovat své výstupy svou rychlostí. Namísto toho přístup monorepo upřednostňuje kulturu informovanosti a péče, kde by týmy neměly zůstat pozadu, aby se s problémem vypořádaly samy.

Hybridní přístup Poly-As-Mono

Pokud se nemůžeme rozhodnout, zda použít buď přístup multi-repo nebo monorepo, existuje také přístup mezi tím: použít více repozitářů a použít nějaký nástroj k jejich synchronizaci, takže to připomíná monorepo, ale s větší flexibilitou.

Meta je jedním z takových nástrojů. Organizuje více úložišť pod podadresáře a poskytuje rozhraní příkazového řádku, které provádí stejný příkaz na všech z nich současně.

Metaúložiště obsahuje informace o tom, která úložiště tvoří projekt. Klonování tohoto úložiště přes meta pak rekurzivně naklonuje všechna požadovaná úložiště, což novým členům týmu usnadní okamžitě začít pracovat na svých projektech.

Abychom naklonovali metaúložiště a všechna jeho definovaná vícenásobná úložiště, musíme provést následující:

meta git clone [meta repo url]

Meta provede a git clone pro každé úložiště a umístěte jej do podsložky:

Klonování meta projektu
Klonování metaprojektu. (Zdroj obrázku: github.com/mateodelnorte/meta)

Od té doby provádění meta exec příkaz provede příkaz v každé podsložce. Například provádění git checkout master na každém úložišti se to dělá takto:

meta exec "git checkout master"

Hybridní přístup Mono-As-Poly

Dalším přístupem je správa kódu prostřednictvím monorepo pro vývoj, ale zkopírování kódu každé knihovny do jejího nezávislého úložiště pro nasazení.

Tato strategie je v ekosystému PHP převládající, protože Packagist (hlavní úložiště Composer) vyžaduje k publikování balíčku adresu URL veřejného úložiště a není možné uvést, že se balíček nachází v podadresáři úložiště.

Vzhledem k omezení Packagist mohou projekty PHP stále používat pro vývoj monorepo, ale pro nasazení musí používat přístup multi-repo.

K dosažení tohoto převodu můžeme spustit skript pomocí git subtree split Nebo použijte jeden z dostupných nástrojů, které provádějí stejnou logiku:

  • Git Subtree Splitter
  • Git Subsplit
  • Akce GitHub pro Monorepo Split

Kdo používá Monorepo vs Multi-Repo

Několik velkých technologických společností upřednostňuje přístup monorepo, zatímco jiné se rozhodly použít metodu multi-repo.

Google, Facebook, Twitter a Uber se veřejně zaručily za přístup monorepo. Společnost Microsoft provozuje největší monorepo Git na světě, které hostí zdrojový kód operačního systému Windows.

Na opačné straně jsou Netflix, Amazon a Lyft slavné společnosti využívající multi-repo přístup.

Na straně hybridního poly-as-mono Android aktualizuje více úložišť, která jsou spravována jako monorepo.

Na straně hybridního mono-as-poly Symfony uchovává kód pro všechny své komponenty v monorepo. Rozdělili jej do nezávislých úložišť pro nasazení (jako např symfony/dependency-injection a symfony/event-dispatcher.)

Příklady Monorepo a Multi-Repo

Účet WordPress na GitHubu hostí příklady jak monorepo, tak multi-repo přístupu.

Gutenberg, editor bloků WordPress, se skládá z několika desítek balíčků JavaScriptu. Všechny tyto balíčky jsou hostovány na WordPress/gutenberg monorepo a spravované prostřednictvím společnosti Lerna, aby je pomohla publikovat v úložišti npm.

Openverse, vyhledávač pro média s otevřenou licencí, hostí své hlavní části v nezávislých repozitářích: front-end, katalog a API.

Monorepo vs Multi-Repo: Jak si vybrat?

Stejně jako u mnoha vývojových problémů neexistuje žádná předem definovaná odpověď na to, jaký přístup byste měli použít. Různé společnosti a projekty budou těžit z jedné nebo druhé strategie na základě jejich jedinečných podmínek, jako například:

  • Jak velká je kódová základna? Obsahuje gigabajty dat?
  • Kolik lidí bude pracovat na kódové základně? Je to kolem 10, 100 nebo 1,000?
  • Kolik balíčků bude? Je to kolem 10, 100 nebo 1,000?
  • Na kolika balíčcích musí tým v daný čas pracovat?
  • Jak pevně jsou balíčky propojeny?
  • Jsou zapojeny různé programovací jazyky? Vyžadují ke spuštění konkrétní nainstalovaný software nebo speciální hardware?
  • Kolik nástrojů pro nasazení je potřeba a jak složité je jejich nastavení?
  • Jaká je kultura ve firmě? Jsou týmy podporovány ke spolupráci?
  • Jaké nástroje a technologie týmy umějí používat?

Jaký přístup byste měli zvolit pro svou kódovou základnu? 🤔 Více se dozvíte zde 👇Kliknutím Tweet

Shrnutí

Existují dvě hlavní strategie pro hostování a správu kódu: monorepo vs multi-repo. Přístup monorepo znamená ukládání kódu pro různé knihovny nebo projekty – a dokonce i veškerý kód od společnosti – do jediného úložiště. A multi-repo systém rozděluje kód do jednotek, jako jsou knihovny nebo služby, a jejich kód uchovává v nezávislých úložištích.

Jaký přístup použít, závisí na mnoha podmínkách. Obě strategie mají několik výhod a nevýhod a my jsme je všechny podrobně probrali v tomto článku.

Máte nějaké dotazy ohledně monorepo nebo multirepo? Dejte nám vědět v sekci komentářů!

Související články

0 Komentáře
Vložené zpětné vazby
Zobrazit všechny komentáře
Tlačítko Nahoru