Preklad článku pripraveného pre študentov kurzu "Postupy a nástroje DevOps" vo vzdelávacom projekte OTUS.

Mali by ste si vybrať monorepozitár, pretože správanie, ktoré podporuje vo vašich tímoch, je transparentnosť a zdieľaná zodpovednosť, najmä keď tímy rastú. V každom prípade budete musieť investovať do nástrojov, ale vždy je lepšie, ak je predvolené správanie také, aké chcete vo svojich príkazoch.

Prečo o tom hovoríme?

Matt Klein napísal článok "Monorepos: Prosím, nie!"  (pozn. prekladateľa: preklad na Habré „Monorepository: prosím, nie“). Mám rád Matta, myslím si, že je veľmi šikovný a mali by ste si prečítať jeho názor. Pôvodne zverejnil prieskum na Twitteri:

Preklad:
Tento Nový rok budem polemizovať o tom, aké smiešne sú monorepozitáre. Rok 2019 začal pokojne. V duchu tohto vám ponúkam prieskum. Kto sú veľkí fanatici? Podporovatelia:
- Monorepo
- Hrdza
- Nesprávny prieskum / oboje

Moja odpoveď bola: "Som doslova obaja z týchto ľudí." Namiesto rozprávania o tom, ako je Rust droga, sa pozrime na to, prečo si myslím, že sa mýli s monorepozitármi. Trochu o sebe. Som CTO Chef Software. Máme asi 100 inžinierov, kódovú základňu spred 11-12 rokov a 4 hlavné produkty. Časť tohto kódu je v polyrepozitári (moja východisková pozícia), časť je v monorepozitári (moja aktuálna pozícia).

Skôr ako začnem: každý argument, ktorý tu uvediem, sa bude vzťahovať na oba druhy úložísk. Podľa môjho názoru neexistuje žiadny technický dôvod, prečo by ste si mali zvoliť jeden typ úložiska pred iným. Každý prístup môže fungovať. Rád sa o tom porozprávam, ale umelé technické dôvody, prečo je jeden nadradený druhému, ma nezaujímajú.

Súhlasím s prvou časťou Mattovho názoru:

Pretože vo väčšom rozsahu monorepozitár vyrieši všetky tie isté problémy, ktoré rieši polyrepozitár, no zároveň vás núti pevne prepojiť váš kód a vyžaduje neuveriteľné úsilie na zvýšenie škálovateľnosti vášho systému na správu verzií.

Budete musieť riešiť rovnaké problémy bez ohľadu na to, či si vyberiete monorepozitár alebo polyrepozitár. Ako vydávate vydania? Aký je váš prístup k aktualizáciám? Spätná kompatibilita? Závislosti medzi projektmi? Aké architektonické štýly sú prijateľné? Ako spravujete svoju budovaciu a testovaciu infraštruktúru? Zoznam je nekonečný. A všetky ich vyriešite, ako budete rásť. Neexistuje žiadny syr zadarmo.

Myslím si, že Mattov argument je podobný názorom zdieľaným mnohými inžiniermi (a manažérmi), ktorých rešpektujem. K tomu dochádza z pohľadu inžiniera pracujúceho na komponente alebo tímu pracujúceho na komponente. Počuješ veci ako:

• Kódová základňa je objemná - nepotrebujem všetky tieto odpadky.
• Je to ťažšie testovať, pretože musím testovať všetky tie odpadky, ktoré nepotrebujem.
• S vonkajšími závislosťami sa pracuje ťažšie.
• Potrebujem svoje vlastné virtuálne systémy na správu verzií.

Samozrejme, všetky tieto body sú opodstatnené. Stáva sa to v oboch prípadoch – v polyrepozitári mám okrem toho, ktorý je potrebný na zostavenie, svoj vlastný odpad... Môžem potrebovať aj iný odpad. Takže „jednoducho“ vytváram nástroje, ktoré kontrolujú celý projekt. Alebo vytvorím falošný monorepozitár so submodulmi. Mohli by sme okolo toho chodiť celý deň. Myslím si však, že Mattov argument obchádza hlavný dôvod, ktorý som dosť výrazne prehodil v prospech monorepozitára:

Vyvoláva komunikáciu a ukazuje problémy

Keď oddelíme úložiská, vytvárame de facto problém koordinácie a transparentnosti. Tomu zodpovedá aj spôsob uvažovania o tímoch (najmä spôsob, akým o nich uvažujú jednotliví členovia): sme zodpovední za určitú zložku. Pracujeme v relatívnej izolácii. Hranice sú pevne stanovené pre môj tím a zložky, na ktorých pracujeme.

Ako sa architektúra stáva zložitejšou, jeden tím ju už nemôže riadiť sám. Len veľmi málo inžinierov má celý systém v hlave. Povedzme, že spravujete zdieľaný komponent A, ktorý používajú tímy B, C a D. Tím A refaktoruje, zlepšuje API a tiež mení internú implementáciu. V dôsledku toho zmeny nie sú spätne kompatibilné. Akú radu máte vy?

• Nájdite všetky miesta, kde sa používa staré API.
• Existujú miesta, kde sa nové API nedá použiť?
• Môžete opraviť a otestovať ďalšie komponenty, aby ste sa uistili, že sa nerozbijú?
• Môžu tieto tímy otestovať vaše zmeny práve teraz?

Upozorňujeme, že tieto otázky sú nezávislé od typu úložiska. Budete musieť nájsť tímy B, C a D. Budete sa s nimi musieť porozprávať, zistiť čas, pochopiť ich priority. Aspoň dúfame, že budete.

Toto naozaj nikto nechce robiť. Je to oveľa menej zábavné ako len oprava toho prekliateho API. Všetko je to ľudské a chaotické. V polyrepozitári môžete jednoducho vykonať zmeny, dať to ľuďom pracujúcim na danom komponente (pravdepodobne nie B, C alebo D) na kontrolu a pokračovať ďalej. Tímy B, C a D môžu zatiaľ zostať pri svojej aktuálnej verzii. Obnovia sa, keď si uvedomia vašu genialitu!

V monorepozitári je zodpovednosť štandardne presunutá. Tím A vymení svoj komponent a ak si nedá pozor, okamžite rozbije B, C a D. To vedie k tomu, že B, C a D sa objavia pri dverách A a čudujú sa, prečo tím A rozbil zostavu. To učí A, že nemôžu preskočiť môj zoznam vyššie. Musia hovoriť o tom, čo budú robiť. Môžu sa B, C a D pohybovať? Čo ak B a C môžu, ale D úzko súviselo s vedľajším účinkom správania starého algoritmu?

Potom sa musíme porozprávať o tom, ako sa z tejto situácie dostaneme:

1. Podpora viacerých interných rozhraní API a označí starý algoritmus ako zastaraný, kým ho D nebude môcť prestať používať.
2. Podpora viacerých verzií vydania, jedna so starým rozhraním, jedna s novým.
3. Odložte uvoľnenie zmien A, kým ich B, C a D nebudú môcť súčasne prijať.

Povedzme, že sme vybrali 1, niekoľko rozhraní API. V tomto prípade máme dva kusy kódu. Staré aj nové. V niektorých situáciách celkom pohodlné. Skontrolujeme starý kód, označíme ho ako zastaraný a dohodneme sa na pláne odstránenia s tímom D. V podstate identické pre poly a mono repozitáre.

Na vydanie viacerých verzií potrebujeme pobočku. Teraz máme dve zložky - A1 a A2. Tímy B a C používajú A2 a D používa A1. Potrebujeme, aby bol každý komponent pripravený na vydanie, pretože môžu byť potrebné aktualizácie zabezpečenia a iné opravy chýb, kým sa D bude môcť pohnúť vpred. V polyrepozitári to môžeme skryť do dlhovekej vetvy, ktorá sa cíti dobre. V monorepozitári nútime vytvorenie kódu v novom module. Tím D bude musieť ešte vykonať zmeny v „starom“ komponente. Každý tu vidí náklady, ktoré platíme – teraz máme dvakrát toľko kódu a všetky opravy chýb, ktoré sa vzťahujú na A1 a A2, sa musia vzťahovať na obe. S prístupom vetvenia v polyrepozitári je to skryté za čerešňovým výberom. Náklady považujeme za nižšie, pretože nedochádza k duplicite. Z praktického hľadiska sú náklady rovnaké: vytvoríte, uvoľníte a budete udržiavať dve prevažne identické kódové základne, kým nebudete môcť jednu z nich odstrániť. Rozdiel je v tom, že pri monorepozitári je táto bolesť priama a viditeľná. Toto je ešte horšie a to je dobré.

Konečne sme sa dostali k tretiemu bodu. Oneskorenie uvoľnenia. Je možné, že zmeny vykonané A zlepšia život tímu A. Dôležité, ale nie naliehavé. Môžeme len meškať? V polyrepozitári to stlačíme, aby sme pripli artefakt. Samozrejme, že to hovoríme tímu D. Zostaňte pri starej verzii, kým ju nedobehnete! Toto vás prinúti hrať sa na zbabelca. Tím A pokračuje v práci na svojom komponente, ignorujúc fakt, že tím D používa čoraz zastaranejšiu verziu (to je problém tímu D, sú hlúpi). Medzitým tím D zle hovorí o neopatrnom postoji tímu A k stabilite kódu, ak o tom vôbec hovorí. Prechádzajú mesiace. Nakoniec sa tím D rozhodne pozrieť na možnosť aktualizácie, ale A má len viac zmien. Tím A si sotva pamätá, kedy alebo ako zlomil D. Aktualizácia je bolestivejšia a bude trvať dlhšie. Čo ho pošle ďalej v poradí priorít. Až do dňa, keď máme bezpečnostný problém v A, ktorý nás núti urobiť si pobočku. Tím A sa musí vrátiť v čase, nájsť bod, kedy bol D stabilný, opraviť tam problém a pripraviť ho na uvoľnenie. Toto je de facto voľba ľudí a je zďaleka najhoršia. Zdá sa, že je to dobré pre tím A aj tím D, pokiaľ sa môžeme navzájom ignorovať.

V monorepozitári tretia možnosť naozaj nie je. Ste nútení riešiť situáciu jedným z dvoch spôsobov. Musíte vidieť náklady na dve pobočky vydania. Naučte sa chrániť sa pred aktualizáciami, ktoré narušujú spätnú kompatibilitu. Ale hlavne: nemôžete sa vyhnúť zložitému rozhovoru.

Podľa mojich skúseností, keď sa tímy rozrastú, už nie je možné mať na pamäti celý systém, a to je najdôležitejšia časť. Musíte zlepšiť viditeľnosť nezhôd v systéme. Musíte aktívne pracovať na tom, aby tímy odvrátili pohľad od svojich komponentov a pozreli sa na prácu iných tímov a spotrebiteľov.

Áno, môžete vytvoriť nástroje, ktoré sa pokúsia vyriešiť problém polyrepository. Ale moje skúsenosti s výučbou nepretržitého doručovania a automatizácie vo veľkých podnikoch mi hovoria toto: predvolené správanie bez použitia ďalších nástrojov je správanie, ktoré očakávate. Predvolené správanie polyrepozitára je izolácia, to je podstata. Predvolené správanie monorepozitára je zdieľaná zodpovednosť a transparentnosť, o to ide. V oboch prípadoch vytvorím nástroj, ktorý vyhladí hrubé hrany. Ako líder si vždy vyberiem monorepozitár, pretože nástroje potrebujú posilniť kultúru, ktorú chcem, a kultúra pochádza z drobných rozhodnutí a každodennej práce tímu.

Do prieskumu sa môžu zapojiť iba registrovaní užívatelia. Prihlásiť saProsím.

Kto sú najväčší fanatici? Podporovatelia:

• Monorepo

• Hrdza

• Nesprávny prieskum / oboje

Hlasovalo 33 užívateľov. 13 užívateľov sa zdržalo hlasovania.

Zdroj: hab.com