Překlad článku byl připraven pro studenty kurzu „DevOps praktiky a nástroje“ v edukativním projektu OTUS.

Musíte zvolit monorepo, protože chování, které podporuje ve vašich týmech, je transparentnost a kolektivní odpovědnost, zejména při růstu týmů. Tak či onak, budete muset investovat do nástrojů, ale je vždy lepší, když je výchozí chování to, které chcete vidět ve svých týmech.

Proč o tom mluvíme?

Matt Klein napsal článek „Monorepos: Prosím, nedělejte to!“ (pozn. překladatele: překlad na Habru „Monorepozitáře: prosím, nedělejte to“). Mám rád Matta, myslím, že je velmi inteligentní a měli byste si přečíst jeho pohled. Původně zveřejnil anketu na Twitteru:

Překlad:
Na tento novoroční den se chci dohadovat o tom, jak absurdní monorepo jsou. Rok 2019 začal nenápadně. V tomto duchu vám navrhuji anketu. Kdo jsou velcí fanoušci? Příznivci:
— Monorepozitář
— Rust
— Špatná anketa / oboje

Moje odpověď byla: „Já 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 mýlí ohledně monorepozitářů. Trochu o sobě. Jsem technický ředitel společnosti Chef Software. Máme asi 100 inženýrů, kódovou základnu, která má asi 11-12 let, a 4 hlavní produkty. Některé z tohoto kódu se nacházejí v polyrepo (moje výchozí pozice), část v monorepo (moje současná pozice).

Než začnu: každý argument, který zde přednesu, bude použitelný pro oba typy repozitářů. Podle mého názoru nejsou žádné technické důvody, proč byste měli zvolit ten nebo onen typ repozitáře. Můžete nechat fungovat jakýkoli přístup. Rád o tom budu diskutovat, ale nezajímá mě umělé technické důvody, proč jedno převyšuje druhé.

Souhlasím s první částí názoru Matta:

Protože na velkém měřítku monorepo vyřeší všechny stejné problémy, které řeší polyrepo, ale zároveň vás provokuje k silné provázanosti vašeho kódu a vyžaduje enormní úsilí při zvyšování škálovatelnosti vašeho systému správy verzí.

Budete čelit stejným problémům, ať už si vyberete monorepozitář nebo polyrepozitor. Jak vydáváte verze? Jaký máte přístup k aktualizacím? Zpětná kompatibilita? Přesně závislosti mezi projekty? Jaké architektonické styly jsou akceptovatelné? Jak spravujete svou infrastrukturu pro sestavování a testování? Seznam je nekonečný. A budete je řešit všechny, jakmile porostete. Zdarma nic není.

Myslím, že Mattův argument je podobný názorům, které sdílí mnozí inženýři (a manažeři), které respektuji. To vychází z pohledu inženýra pracujícího na komponentě, nebo týmu, který na komponentě pracuje. Slyšíte takové věci, jako:

Kódová základna je objemná — nepotřebuji celý tento nepořádek.
Je to těžší testovat, protože musím zkontrolovat celý ten nepořádek, který nepotřebuji.
Je složitější pracovat s externími závislostmi.
Potřebuji své vlastní virtuální systémy správy verzí.

Rozhodně všechny tyto body jsou oprávněné. Platí to v obou případech — v polyrepozitoru mám svůj nepořádek, kromě toho, který potřebuji k sestavení... Možná budu potřebovat další nepořádek. Takže 'jen' vytvářím nástroje, které provádějí checkout celého projektu. Nebo vytvářím falešný monorepozitář s podmoduly. Mohli bychom kolem toho chodit celý den. Ale myslím, že Mattův argument opomíjí hlavní důvod, který jsem dost silně obracel ve prospěch monorepozitáře:

Podněcuje komunikaci a odhaluje problémy.

Když dělíme repozitáře, de facto vytváříme problém koordinace a transparentnosti. To odpovídá tomu, jak přemýšlíme o týmech (zejména jak o nich přemýšlí jednotliví účastníci): neseme odpovědnost za konkrétní komponentu. Pracujeme relativně izolovaně. Hranice jsou stanoveny na mém týmu a komponentě(-ách), na kterých pracujeme.

Při komplikaci architektury již jeden tým nemůže spravovat systém sám. Velmi málo inženýrů má celou systém v paměti. Představte si, že spravujete společnou komponentu A, kterou používají týmy B, C a D. Tým A provádí refactoring, zlepšuje API a mění vnitřní implementaci. V důsledku toho jsou změny zpětně nekompatibilní. Jakou radu byste dali?

Zjistit všechna místa, kde se používá staré API.
Existují místa, kde nelze použít nové API?
Můžete opravit a otestovat jiné komponenty, abyste se ujistili, že se nezlomí?
Mohou tyto týmy zkontrolovat vaše změny hned teď?

Všimněte si, že tyto otázky nezávisí na typu repozitáře. Budete muset najít týmy B, C a D. Budete muset s nimi promluvit, zjistit čas, pochopit jejich priority. Minimálně doufáme, že to uděláte.

Ve skutečnosti to nikdo nechce dělat. Je to mnohem méně vzrušující než pouhá oprava prokletého API. Všechno je to lidské a zamotané. V poli repozitáře můžete jednoduše provést změny, dát je k revizi těm, kteří pracují na této komponentě (pravděpodobně ne B, C nebo D), a jít dál. Týmy B, C a D mohou zatím zůstat na své aktuální verzi. Aktualizují se, když si uvědomí vaši genialitu!

V monorepo je odpovědnost ve defaultu posunuta. Tým A změní svou komponentu a pokud neprojeví obezřetnost, okamžitě rozbije B, C a D. To vede k tomu, že se B, C a D objevují u dveří A, udiveni, proč tým A rozbil sestavení. To učí A, že nemohou přehlédnout můj výše uvedený seznam. Musí mluvit o tom, co mají v plánu udělat. Mohou B, C a D pokračovat? Co když B a C mohou, ale D byl úzce spojen s vedlejším efektem chování starého algoritmu?

Pak bychom měli hovořit o tom, jak se z této situace dostat:

Podpora více interních API, přičemž starý algoritmus bude označen jako zastaralý, dokud D nebude moci přestat jej používat.
Podpora více verzí vydání, jedna se starým rozhraním, jedna s novým.
Zpoždění vydání změn A, dokud současně B, C a D nebudou moci je přijmout.

Představme si, že jsme vybrali 1, několik API. V takovém případě máme dva kousky kódu. Starý a nový. Je to docela pohodlné v některých situacích. Vracíme starý kód zpět, označujeme ho jako zastaralý (deprecated) a dohodneme se na plánu jeho odstranění s týmem D. V zásadě je to identické pro poly a monorepozitář.

Pro vydání několika verzí potřebujeme větev. Nyní máme dva komponenty - A1 a A2. Týmy B a C používají A2, zatímco D používá A1. Potřebujeme, aby byl každý komponent připraven k vydání, protože než D může pokračovat dál, mohou být potřeba bezpečnostní aktualizace a opravy dalších chyb. V polyrepozitáři můžeme toto skrýt v dlouhodobé větvi, která se zdá být v pořádku. V monorepozitáři vytváříme kód násilně v novém modulu. Týmu D stále bude muset provést změny ve "starém" komponentu. Každý může vidět náklady, které zde platíme - nyní máme dvakrát více kódu a všechny opravy chyb, které se aplikují na A1 a A2, musí být aplikovány na oba. S přístupem použití větví v polyrepozitáři je to skryté za cherry-pick. Považujeme náklady za menší, protože tam není duplicita. Z praktického hlediska jsou náklady stejné: budete vytvářet, vydávat a podporovat dvě, většinou identické, báze kódu, dokud nebudete moci jednu z nich odstranit. Rozdíl je v tom, že v monorepozitáři je tento problém přímý a je na očích. To je ještě horší, a to je dobře.

Konečně jsme se dostali k třetímu bodu. Zpoždění uvolnění. Je možné, že změny provedené týmem A zlepší život týmu D. Důležité, ale ne urgentní. Můžeme to prostě zpozdit? V monorepozitáři tlačíme to k upevnění artefaktu. Samozřejmě, že o tom mluvíme s týmem D. Jen zůstaňte na staré verzi, dokud to nedohnáte! To nastavuje atmosféru k útočnosti. Tým A dál pracuje na svém komponentu, ignorujíc fakt, že tým D používá stále starší verzi (to je problém týmu D, jsou hloupí). Mezitím tým D špatně hovoří o nezodpovědném přístupu týmu A ke stabilitě kódu, pokud o tom vůbec mluví. Uplynou měsíce. Nakonec se tým D rozhodne podívat na možnost aktualizace, ale změn v A jen přibývá. Tým A sotva pamatuje, kdy a jak D rozbili. Aktualizace bude bolestivější a zabere více času. Co posunuje tuto záležitost dále dolů v prioritách. Až do dne, kdy nastane bezpečnostní problém v A, který nás donutí provést branch. Tým A se musí vrátit zpět v čase, najít moment, kdy D byl stabilní, opravit tam problém a připravit ho na uvolnění. To je de facto volba, kterou lidé dělají, a určitě je to to nejhorší. Vypadá to, že je to dobré jak pro tým A, tak pro D, dokud se můžeme ignorovat navzájem.

V monorepozitáři třetí možnost opravdu není. Musíte se s touto situací vypořádat jedním ze dvou způsobů. Musíte vidět náklady na existenci dvou uvolňovacích branches. Naučit se chránit sami sebe před aktualizacemi, které rozbíjejí zpětnou kompatibilitu. Ale hlavně: nelze se vyhnout obtížnému rozhovoru.

Z mé zkušenosti, když týmy rostou, už není možné udržet si celou systém v hlavě, a to je ta nejdůležitější část. Musíte zlepšit viditelnost neshod v systému. Musíte aktivně pracovat na tom, aby týmy odtrhly pohled od svých komponent a podívaly se na práci ostatních týmů a uživatelů.

Ano, můžete vytvořit nástroje, které se pokusí vyřešit problém poly-repozitářů. Ale mé zkušenosti s kontinuálním dodáváním a automatizací ve velkých podnicích mi říkají následující: chování ve výchozím nastavení bez použití dodatečných nástrojů je to, co očekáváte vidět. Chování poly-repozitáře ve výchozím nastavení je izolace, to je celý smysl. Chování mono-repozitáře ve výchozím nastavení je společná odpovědnost a transparentnost, to je celý smysl. V obou případech hodlám vytvořit nástroj, který vyhladí ostřejší hrany. Jako vedoucí budu vždy volit mono-repozitář, protože nástroje by měly posilovat kulturu, kterou chci, a kultura vychází z drobných rozhodnutí a každodenní práce týmu.

Pouze registrovaní uživatelé se mohou účastnit ankety. Přihlaste se, prosím.