Překlad článku připraveného pro studenty kurzu "Postupy a nástroje DevOps" ve vzdělávacím projektu OTUS.

Měli byste si vybrat monorepozitář, protože chování, které ve vašich týmech podporuje, je transparentnost a sdílená odpovědnost, zvláště když týmy rostou. V každém případě budete muset investovat do nástrojů, ale vždy je lepší, když výchozí chování je chování, které chcete ve svých příkazech.

Proč o tom mluvíme?

Matt Klein napsal článek "Monorepos: Prosím, ne!"  (pozn. překladatele: překlad na Habré "Monorepository: prosím ne"). Mám Matta ráda, je podle mě velmi chytrý a měli byste si přečíst jeho názor. Původně zveřejnil anketu na Twitteru:

Překlad:
Letos na Nový rok se budu hádat o tom, jak jsou monorepozitáře směšné. Rok 2019 začal v klidu. V tomto duchu vám nabízím anketu. Kdo jsou velcí fanatici? Podporovatelé:
- Monorepo
- Rez
- Nesprávná anketa / obojí

Moje odpověď byla: "Jsem doslova oba tito lidé." Místo toho, abychom mluvili o tom, jak je Rust droga, pojďme se podívat na to, proč si myslím, že se v monorepozitářích mýlí. Něco málo o sobě. Jsem CTO Chef Software. Máme asi 100 inženýrů, kódovou základnu sahající asi 11–12 let zpět a 4 hlavní produkty. Část tohoto kódu je v polyrepozitáři (moje výchozí pozice), část je v monorepozitáři (moje současná pozice).

Než začnu: každý argument, který zde uvedu, bude platit pro oba druhy úložišť. Podle mého názoru neexistuje žádný technický důvod, proč byste si měli vybrat jeden typ úložiště před jiným. Jakýkoli přístup může fungovat. Rád o tom mluvím, ale umělé technické důvody, proč je jeden nadřazen druhému, mě nezajímají.

Souhlasím s první částí Mattovy myšlenky:

Protože ve velkém měřítku vyřeší monorepozitář všechny stejné problémy, které řeší polyrepozitář, ale zároveň vás nutí pevně propojit váš kód a vyžaduje neuvěřitelné úsilí ke zvýšení škálovatelnosti vašeho systému správy verzí.

Budete muset řešit stejné problémy bez ohledu na to, zda zvolíte monorepozitář nebo polyrepozitář. Jak vydáváte vydání? Jaký je váš přístup k aktualizacím? Zpětná kompatibilita? Meziprojektové závislosti? Jaké architektonické styly jsou přijatelné? Jak spravujete svou infrastrukturu budování a testování? Seznam je nekonečný. A všechny je vyřešíte, jak budete růst. Neexistuje žádný sýr zdarma.

Myslím, že Mattův argument je podobný názorům sdíleným mnoha inženýry (a manažery), které respektuji. K tomu dochází z pohledu inženýra pracujícího na komponentě nebo týmu pracujícího na komponentě. Slyšíte věci jako:

• Kódová základna je objemná - nepotřebuji všechny ty harampádí.
• Je to těžší otestovat, protože musím otestovat všechny ty harampádí, které nepotřebuji.
• S externími závislostmi je obtížnější pracovat.
• Potřebuji své vlastní virtuální systémy pro správu verzí.

Všechny tyto body jsou samozřejmě oprávněné. To se děje v obou případech - v polyrepository mám kromě toho, co je potřeba pro sestavení, vlastní haraburdí... Možná budu potřebovat i jiné haraburdí. Takže „prostě“ vytvářím nástroje, které kontrolují celý projekt. Nebo vytvořím falešný monorepozitář se submoduly. Mohli bychom kolem toho chodit celý den. Ale myslím, že Mattův argument postrádá hlavní důvod, který jsem dost silně přehodil ve prospěch monorepozitáře:

Vyvolává komunikaci a ukazuje problémy

Když oddělujeme úložiště, vytváříme de facto problém koordinace a transparentnosti. Tomu odpovídá i způsob, jakým o týmech přemýšlíme (zejména způsob, jakým o nich uvažují jednotliví členové): jsme zodpovědní za určitou složku. Pracujeme v relativní izolaci. Hranice jsou pevně stanoveny pro můj tým a složku (složky), na kterých pracujeme.

Jak se architektura stává složitější, jeden tým ji již nemůže řídit sám. Jen velmi málo inženýrů má celý systém v hlavě. Řekněme, že spravujete sdílenou komponentu A, kterou používají týmy B, C a D. Tým A refaktoruje, vylepšuje rozhraní API a také mění interní implementaci. V důsledku toho nejsou změny zpětně kompatibilní. jakou radu máte vy?

• Najděte všechna místa, kde se používá staré API.
• Jsou místa, kde nelze nové API použít?
• Můžete opravit a otestovat další součásti, abyste se ujistili, že se nerozbijí?
• Mohou tyto týmy otestovat vaše změny právě teď?

Upozorňujeme, že tyto otázky jsou nezávislé na typu úložiště. Budete muset najít týmy B, C a D. Budete s nimi muset mluvit, zjistit čas, pochopit jejich priority. Alespoň doufáme, že budete.

Tohle opravdu nikdo nechce dělat. To je mnohem méně zábavné než jen oprava toho zatraceného API. Je to všechno lidské a chaotické. V polyrepository můžete jednoduše provést změny, dát je lidem pracujícím na dané komponentě (pravděpodobně ne B, C nebo D) ke kontrole a jít dál. Týmy B, C a D mohou zatím zůstat u své aktuální verze. Budou obnoveni, když si uvědomí vaši genialitu!

V monorepozitáři se odpovědnost standardně přesouvá. Tým A vymění svou součást, a pokud si nedá pozor, okamžitě rozbije B, C a D. To vede k tomu, že se B, C a D objeví u dveří A a diví se, proč tým A rozbil sestavu. To učí A, že nemohou přeskočit můj seznam výše. Musí mluvit o tom, co budou dělat. Mohou se B, C a D pohybovat? Co když B a C mohou, ale D úzce souvisí s vedlejším efektem chování starého algoritmu?

Pak si musíme promluvit o tom, jak se z této situace dostaneme:

1. Podporuje více interních rozhraní API a označí starý algoritmus jako zastaralý, dokud jej D nebude moci přestat používat.
2. Podpora pro více verzí, jednu se starým rozhraním, jednu s novým.
3. Odložte uvolnění změn A, dokud je B, C a D nebudou moci současně přijmout.

Řekněme, že jsme vybrali 1, několik API. V tomto případě máme dva kusy kódu. Staré i nové. V některých situacích docela pohodlné. Zkontrolujeme starý kód, označíme jej jako zastaralý a dohodneme se na plánu odstranění s týmem D. V podstatě totožné pro poly a mono repozitáře.

K vydání více verzí potřebujeme pobočku. Nyní máme dvě složky - A1 a A2. Týmy B a C používají A2 a D používají A1. Potřebujeme, aby byla každá komponenta připravena k vydání, protože může být zapotřebí aktualizací zabezpečení a dalších oprav chyb, než se D bude moci pohnout vpřed. V polyrepozitáři to můžeme schovat do dlouhověké větve, která se cítí dobře. V monorepozitáři vynutíme vytvoření kódu v novém modulu. Tým D bude muset ještě provést změny ve „staré“ komponentě. Každý zde vidí náklady, které platíme – nyní máme dvakrát více kódu a všechny opravy chyb, které se vztahují na A1 a A2, se musí vztahovat na oba. S přístupem větvení v polyrepozitáři je to skryto za třešničkou. Náklady považujeme za nižší, protože nedochází k duplicitě. Z praktického hlediska jsou náklady stejné: vytvoříte, uvolníte a budete udržovat dvě do značné míry identické kódové báze, dokud nebudete moci jednu z nich odstranit. Rozdíl je v tom, že u monorepozitáře je tato bolest přímá a viditelná. Tohle je ještě horší a to je dobře.

Konečně jsme se dostali ke třetímu bodu. Zpoždění uvolnění. Je možné, že změny provedené A zlepší životy týmu A. Důležité, ale ne naléhavé. Můžeme jen zdržet? V polyrepozitáři to stlačíme, abychom připnuli artefakt. Samozřejmě to říkáme týmu D. Jen zůstaňte u staré verze, dokud to nedoženete! To vás nastaví hrát si na zbabělce. Tým A pokračuje v práci na své komponentě a ignoruje fakt, že tým D používá stále zastaralejší verzi (to je problém týmu D, jsou hloupí). Mezitím tým D mluví špatně o nedbalém postoji týmu A ke stabilitě kódu, pokud o tom vůbec mluví. Ubíhají měsíce. Nakonec se tým D rozhodne podívat na možnost aktualizace, ale A má jen více změn. Tým A si sotva pamatuje, kdy nebo jak zlomil D. Upgrade je bolestivější a bude trvat déle. Což jej pošle dále v prioritním zásobníku. Až do dne, kdy máme bezpečnostní problém v A, který nás nutí udělat pobočku. Tým A se musí vrátit v čase, najít bod, kdy byl D stabilní, opravit tam problém a připravit jej na vydání. Toto je de facto volba, kterou lidé dělají, a ta je zdaleka nejhorší. Zdá se, že je to dobré pro tým A i tým D, pokud se můžeme navzájem ignorovat.

V monorepozitáři třetí opravdu nepřichází v úvahu. Jste nuceni řešit situaci jedním ze dvou způsobů. Musíte vidět náklady na dvě pobočky vydání. Naučte se chránit se před aktualizacemi, které narušují zpětnou kompatibilitu. Ale hlavně: nemůžete se vyhnout obtížnému rozhovoru.

Mám zkušenost, že když se týmy rozrostou, už není možné mít na paměti celý systém, a to je nejdůležitější. Musíte zlepšit viditelnost nesouladu v systému. Musíte aktivně pracovat na tom, aby týmy odvrátily pohled od svých součástí a podívaly se na práci jiných týmů a spotřebitelů.

Ano, můžete vytvořit nástroje, které se pokusí vyřešit problém s polyrepository. Ale moje zkušenost s výukou nepřetržitého dodávání a automatizace ve velkých podnicích mi říká toto: výchozí chování bez použití dalších nástrojů je chování, které očekáváte. Výchozí chování polyrepozitáře je izolace, to je celý smysl. Výchozí chování monorepozitáře je sdílená odpovědnost a transparentnost, o to jde. V obou případech vytvořím nástroj, který vyhladí hrubé hrany. Jako vedoucí si pokaždé vyberu monorepozitář, protože nástroje potřebují posílit kulturu, kterou chci, a kultura pochází z drobných rozhodnutí a každodenní práce týmu.

Průzkumu se mohou zúčastnit pouze registrovaní uživatelé. Přihlásit se, prosím.

Kdo jsou největší fanatici? Podporovatelé:

• Monorepo

• Rez

• Nesprávná anketa / obojí

Hlasovalo 33 uživatelů. 13 uživatelů se zdrželo hlasování.

Zdroj: www.habr.com