Monorepo - Monorepo

v systémy kontroly revizí, a monorepo („mono“ z řeckého μόνος, mónos, „single, alone“ a „repo“ zkratka pro úložiště ) je strategie vývoje softwaru, kde je kód pro mnoho projektů uložen ve stejném úložiště. Od roku 2017, různé formy této softwarové inženýrské praxe byly staré více než dvě desetiletí, ale obecný koncept byl pojmenován teprve nedávno.[1] Bylo učiněno mnoho pokusů o rozlišení monolitické aplikace a další, novější formy monorepos. [2][3][4]

Google,[5] Facebook,[6] Microsoft,[7] Uber,[8] Airbnb a Cvrlikání[9] všichni používají velmi velká monorepos s různými strategiemi v rozsahu budovat systémy a software pro správu verzí s velkým objemem kódu a denními změnami.

Výhody

Monorepo má oproti jednotlivým úložištím řadu potenciálních výhod:[5][10]

  • Snadné opětovné použití kódu - Podobné funkce nebo komunikační protokoly lze abstrahovat do sdílených knihoven a přímo je zahrnout do projektů bez nutnosti závislosti správce balíčků.
  • Zjednodušená správa závislostí - V prostředí s více úložišti, kde více projektů závisí na závislosti třetí strany, může být tato závislost stažena nebo vytvořena vícekrát. V monorepo lze sestavení snadno optimalizovat, protože všechny odkazované závislosti existují ve stejné kódové základně.
  • Atomové závazky - Když jsou projekty, které spolupracují, obsaženy v samostatných úložištích, je nutné ve verzích synchronizovat, které verze jednoho projektu fungují s ostatními. A v dostatečně velkých projektech se může stát správa kompatibilních verzí mezi závislostmi závislost peklo.[8] V monorepo lze tento problém vyvrátit, protože vývojáři mohou atomově měnit více projektů.[11]
  • Velké refaktorování kódu - Vzhledem k tomu, že vývojáři mají přístup k celému projektu, mohou refaktorové zajistit, aby každá část projektu fungovala i po refaktoru.
  • Spolupráce napříč týmy - V monorepo, které používá zdrojové závislosti (závislosti, které jsou kompilovány ze zdroje),[9] týmy mohou vylepšovat projekty, na kterých pracují jiné týmy. To vede k flexibilnímu vlastnictví kódu.

Omezení a nevýhody

  • Ztráta informací o verzi - I když to není nutné, některá sestavení monorepo používají jedno číslo verze ve všech projektech v úložišti. To vede ke ztrátě na projekt sémantické verze.[12]
  • Nedostatek kontroly přístupu na projekt - S dělenými úložišti lze přístup do úložiště udělit na základě potřeby. Monorepo umožňuje přístup ke čtení veškerého softwaru v projektu, což může představovat nové bezpečnostní problémy.[13]

Všimněte si, že existují systémy verzí, ve kterých toto omezení není problém. Například když Podvracení Je-li použito, je možné stáhnout libovolnou část repo (dokonce i jeden adresář) a autorizaci založenou na cestě lze použít k omezení přístupu k určitým částem úložiště. Podobně téměř všechny verzovací systémy nevyžadují stažení celého úložiště [14][15] [16], takže velikost stahování nebo použitý prostor na disku se v zásadě neliší od více úložišť

Problémy se škálovatelností

Společnosti s velkými projekty narazily na překážky s monorepos, konkrétně týkající se nástrojů pro vytváření a systémů pro správu verzí.[6] Monorepo společnosti Google, o kterém se předpokládá, že je největší na světě, splňuje klasifikaci typu ultra-velký systém[5] a musí každý den zpracovávat desítky tisíc příspěvků v úložišti větším než 80 terabajtů.[17]

Software pro změnu velikosti verze

Viz také: Řízení verzí

Společnosti, které používají nebo přecházejí na stávající software pro správu verzí, zjistily, že software nedokáže efektivně zpracovat množství dat požadovaných pro velké monorepo. Společnosti Facebook a Microsoft se rozhodly přispět k existujícímu softwaru pro správu verzí Mercurial a Git zatímco Google nakonec vytvořil svůj vlastní systém pro správu verzí.

Google spoléhal na více než deset let Nezbytně hostováno na jednom stroji. V roce 2005 se servery pro sestavení Google mohly zamknout až 10 minut najednou. Google to v roce 2010 vylepšil na 30 sekund – 1 minutu.[18] Kvůli problémům se škálováním Google nakonec vyvinul vlastní interní distribuovaný systém pro správu verzí nazvaný Piper.[5]

Facebook narazil na problémy s výkonem systému pro správu verzí Mercurial a udělal předcházející příspěvky klientovi,[19] a v lednu 2014 byl rychlejší než konkurenční řešení v Gitu.[20]

V březnu 2014 společnost Microsoft oznámila, že přešla na používání Gitu pro své monorepo.[21][7] V rámci přechodu společnost Microsoft významným způsobem přispěla ke klientovi Git, aby odstranila zbytečný přístup k souborům a zlepšila manipulaci s velkými soubory Virtuální souborový systém pro Git.[22]

Software pro škálování

Viz také: Vytvářejte automatizaci

Několik nástrojů pro sestavení funguje dobře v monorepo,[9] a teče kam staví a průběžné testování integrace celého úložiště provedeny při přihlášení způsobí problémy s výkonem.[12][13] Směrovaný graf staví systémy jako Dolar, Bazel, Kalhoty a Vyřešte to prosím rozčleněním sestavení a testů do aktivní oblasti vývoje.[1]

Twitter zahájil vývoj Pants v roce 2011, protože v té době byly jak Buck Facebooku, tak Google Bazel uzavřeným zdrojem.[23] Twitter kalhoty s otevřeným zdrojem v roce 2012 na základě licence Apache 2.0.[24]

Prosím, a Jít - založený systém sestavení, byl vyvinut v roce 2016 společností Thought Machine, která byla také inspirována společností Bazel společnosti Google a nespokojena s Facebookem Buck.[25]

Bazel, Buck, Pants a Please všichni používají stejné Starlark (dříve Skylark) budovat jazyk, a jazyk specifický pro doménu na základě Krajta.

Některé specializované nástroje pro sestavování monorepo, jako je Lerna, řeší načítání duplicitních závislostí, ale postrádají jakékoli možnosti směrovaného grafu.[13]

Bit, open-source monorepo management a vytvořený nástroj představený v roce 2018, řeší grafická sestavení a řešení závislostí pro vícekomponentní projekty.

  1. ^ A b Hammant, Paul; Smith, Steve. „Trunk Based Development“. vývoj na základě kmene. Citováno 24. července 2018.
  2. ^ https://medium.com/@brockreece/from-monolith-to-monorepo-19d78ffe9175
  3. ^ https://blog.nrwl.io/misconceptions-about-monorepos-monorepo-monolith-df1250d4b03c
  4. ^ https://medium.com/@maoberlehner/monorepos-in-the-wild-33c6eb246cb9
  5. ^ A b C d Levenberg, Rachel Potvin, Josh (červenec 2016). „Proč Google ukládá miliardy řádků kódu do jednoho úložiště“. Komunikace ACM. Citováno 20. července 2018.
  6. ^ A b DOBRO, DURHAME; Déšť. „Scaling Mercurial at Facebook - Facebook Code“. fb kód. Citováno 24. července 2018.
  7. ^ A b Cooper, Matt. „How we use Git at Microsoft - Azure DevOps“. Dokumenty Microsoftu. Citováno 20. července 2018.
  8. ^ A b Aimee Lucido (7. dubna 2017). Uber Technology Day: Monorepo na Multirepo a zase zpátky. Citováno 24. července 2018.
  9. ^ A b C Dorothy Ordogh (5. dubna 2018). Kalhoty a Monorepos. Citováno 24. července 2018.
  10. ^ Brousse, Nicolasi. „Problematika monorepo a polyrepo ve velkých podnicích“. Digitální knihovna ACM. Citováno 7. září 2019.
  11. ^ Santacroce, Ferdinando; Olsson, Aske; Voss, Rasmus; Narebski, Jakub (2016). Git: Zvládnutí ovládání verzí. Packt Publishing Ltd. str. 756. ISBN  9781787122796.
  12. ^ A b Farina, Matt. „Nebezpečí projektů Monorepo - DZone DevOps“. DZone. Citováno 20. července 2018.
  13. ^ A b C 点 融 黑帮 (16. srpna 2017). „浅谈 monorepo“ [Mluvíme o monorepo]. Sohu (v čínštině). Citováno 20. července 2018.
  14. ^ částečný klon git
  15. ^ Kniha SVN: Řídké adresáře
  16. ^ Preforce: Klon
  17. ^ Metz, Cade (16. září 2015). „Google jsou 2 miliardy řádků kódu - a to vše na jednom místě“. WIRED. Citováno 20. července 2018.
  18. ^ Bloch, Dan. „Stále vše na jednom serveru: Perforce at Scale“ (PDF). Citováno 23. července 2018.
  19. ^ Claburn, Thomas. „Facebook píše na server Rust server Mercurial. Toto není cvičení“. Registrace. Citováno 20. července 2018.
  20. ^ Blewitt, Alex (9. ledna 2014). „Díky Facebooku je Mercurial rychlejší než Git“. InfoQ. Citováno 24. července 2018.
  21. ^ Lardinois, Frederic (24. března 2017). „Microsoft nyní k vývoji Windows používá Git a GVFS“. TechCrunch. Citováno 20. července 2018.
  22. ^ Bright, Petere. „Přechod systému Windows na Git je téměř dokončen: 8 500 závazků a 1 760 sestavení každý den“. Ars Technica. Citováno 20. července 2018.
  23. ^ Mohilo, Dominik (10. června 2016). „8 Build-Tools im Vergleich: Ant - Buildr - Maven - Bazel - Buck - Gradle - Kalhoty - sbt - JAXenter“ [8 srovnávacích nástrojů pro sestavení: Ant - Buildr - Maven - Bazel - Buck - Gradle - Pants - sbt]. JAXenter (v němčině). Citováno 20. července 2018.
  24. ^ Moore, Madison (3. května 2016). „GitLab vydává opravy zabezpečení, Pants 1.0 a integraci Sauce Labs pro JIRA - přehled zpráv SD Times: 3. května 2016 - SD Times“. SD Times. Citováno 20. července 2018.
  25. ^ Ebden, Peter (prosinec 2017). „Please - the Thought Machine Build System“. Blog. Myšlenkový stroj. Citováno 2019-12-28.


Reference