Prevod članka pripravljen za študente "Prakse in orodja DevOps" v izobraževalnem projektu OTUS.

Izbrati bi morali monorepozitorij, ker je vedenje, ki ga spodbuja v vaših ekipah, preglednost in deljena odgovornost, zlasti ko ekipe rastejo. V vsakem primeru boste morali vložiti v orodja, vendar je vedno bolje, če je privzeto vedenje tisto, ki ga želite v svojih ukazih.

Zakaj govorimo o tem?

Matt Klein je napisal članek "Monorepos: Prosim, ne!"  (opomba prevajalca: prevod na Habréju "Monorepozitoriji: prosim, ne"). Všeč mi je Matt, mislim, da je zelo pameten in bi morali prebrati njegovo stališče. Anketo je prvotno objavil na Twitterju:

Prevod:
Ta novoletni dan se bom prepiral o tem, kako smešna so monorepozitoriji. Leto 2019 se je začelo mirno. V duhu tega vam ponujam anketo. Kdo so veliki fanatiki? Podporniki:
- Monorepo
- Rust
- Napačna anketa / oboje

Moj odgovor je bil: "Jaz sem dobesedno oba." Namesto da bi govorili o tem, da je Rust droga, poglejmo, zakaj mislim, da se moti glede monorepozitorijev. Nekaj ​​malega o sebi. Sem tehnični direktor Chef Software. Imamo približno 100 inženirjev, bazo kode, staro približno 11-12 let, in 4 glavne izdelke. Nekaj ​​te kode je v polirepozitoriju (moj začetni položaj), nekaj v monorepozitoriju (moj trenutni položaj).

Preden začnem: vsak argument, ki ga tukaj navedem, bo veljal za obe vrsti skladišč. Po mojem mnenju ni tehničnega razloga, zakaj bi morali izbrati eno vrsto repozitorija namesto druge. Vsak pristop lahko učinkuje. Z veseljem govorim o tem, vendar me ne zanimajo umetni tehnični razlogi, zakaj je eden boljši od drugega.

Strinjam se s prvim delom Mattove trditve:

Ker bo monorepozitorij v velikem obsegu rešil vse iste težave, kot jih rešuje polirepozitorij, hkrati pa vas bo prisilil, da tesno povežete svojo kodo in bo zahteval neverjetna prizadevanja za povečanje razširljivosti vašega sistema za nadzor različic.

Enake težave boste morali rešiti ne glede na to, ali izberete monorepozitorij ali polirepozitorij. Kako izdajate izdaje? Kakšen je vaš pristop do posodobitev? Združljivost za nazaj? Navzkrižne odvisnosti projektov? Kateri arhitekturni slogi so sprejemljivi? Kako upravljate svojo gradnjo in testiranje infrastrukture? Seznam je neskončen. In vse jih boste rešili, ko boste rasli. Brezplačnega sira ni.

Mislim, da je Mattov argument podoben stališčem mnogih inženirjev (in menedžerjev), ki jih spoštujem. To se zgodi z vidika inženirja, ki dela na komponenti, ali ekipe, ki dela na komponenti. Slišite stvari, kot so:

• Kodna baza je obsežna - ne potrebujem vse te smeti.
• Težje je testirati, ker moram testirati vso to kramo, ki je ne potrebujem.
• Težje je delati z zunanjimi odvisnostmi.
• Potrebujem svoje virtualne sisteme za nadzor različic.

Seveda so vse te točke upravičene. To se zgodi v obeh primerih - v polirepozitoriju imam svojo smeti, poleg tiste, ki je potrebna za gradnjo ... Morda bom potreboval tudi drugo smeto. Zato »preprosto« ustvarim orodja, ki preverjajo celoten projekt. Ali pa ustvarim lažno monorepozitorij s podmoduli. Po tem bi lahko hodili ves dan. Toda mislim, da Mattov argument zgreši glavni razlog, ki sem ga precej obrnil v prid monorepozitoriju:

Provocira komunikacijo in kaže težave

Ko ločimo repozitorije, ustvarimo dejanski problem koordinacije in preglednosti. To ustreza našemu razmišljanju o ekipah (predvsem o tem, kako o njih razmišljajo posamezni člani): odgovorni smo za določeno komponento. Delamo relativno izolirano. Meje za mojo ekipo in komponente, na katerih delamo, so določene.

Ko postaja arhitektura kompleksnejša, je ena ekipa ne more več upravljati sama. Zelo malo inženirjev ima celoten sistem v glavi. Recimo, da upravljate komponento A v skupni rabi, ki jo uporabljajo ekipe B, C in D. Ekipa A preoblikuje, izboljšuje API in spreminja tudi interno izvedbo. Posledično spremembe niso združljive za nazaj. Kaj svetujete?

• Poiščite vsa mesta, kjer se uporablja stari API.
• Ali obstajajo kraji, kjer novega API-ja ni mogoče uporabiti?
• Ali lahko popravite in preizkusite druge komponente, da se prepričate, da se ne pokvarijo?
• Ali lahko te ekipe prav zdaj preizkusijo vaše spremembe?

Upoštevajte, da so ta vprašanja neodvisna od vrste repozitorija. Poiskati boste morali ekipe B, C in D. Z njimi se boste morali pogovoriti, ugotoviti čas, razumeti njihove prioritete. Vsaj upamo, da boste.

Tega res nihče noče storiti. To je veliko manj zabavno kot samo popravljanje prekletega API-ja. Vse je človeško in grdo. V polirepozitoriju lahko preprosto naredite spremembe, jih daste v pregled ljudem, ki delajo na tej komponenti (verjetno ne B, C ali D), in nadaljujete. Ekipe B, C in D lahko zaenkrat ostanejo pri trenutni različici. Prenovljeni bodo, ko bodo spoznali vašo genialnost!

V monorepozitoriju je odgovornost privzeto prestavljena. Ekipa A spremeni svojo komponento in, če ni previdna, takoj zlomi B, C in D. To vodi do B, C in D, ki se prikažejo na vratih A in se sprašujejo, zakaj je ekipa A zlomila sestavo. To nauči A, da ne morejo preskočiti mojega zgornjega seznama. Govoriti morajo o tem, kaj bodo naredili. Ali se B, C in D lahko premikajo? Kaj pa, če B in C lahko, vendar je bil D tesno povezan s stranskim učinkom obnašanja starega algoritma?

Potem se moramo pogovoriti o tem, kako se bomo rešili iz te situacije:

1. Podpora za več notranjih API-jev in bo stari algoritem označil kot zastarel, dokler ga D ne bo prenehal uporabljati.
2. Podpora za več različic izdaje, eno s starim vmesnikom, eno z novim.
3. Odložite objavo A-jevih sprememb, dokler jih B, C in D ne sprejmejo hkrati.

Recimo, da smo izbrali 1, več API-jev. V tem primeru imamo dva dela kode. Staro in novo. V nekaterih situacijah zelo priročno. Ponovno preverimo staro kodo, jo označimo kot zastarelo in se dogovorimo o urniku odstranitve z ekipo D. V bistvu enako za poli in mono repozitorije.

Za izdajo več različic potrebujemo vejo. Zdaj imamo dve komponenti - A1 in A2. Ekipi B in C uporabljata A2, D pa A1. Vsaka komponenta mora biti pripravljena za izdajo, ker bodo morda potrebne varnostne posodobitve in drugi popravki napak, preden lahko D napreduje. V polirepozitoriju lahko to skrijemo v dolgoživo vejo, ki se počuti dobro. V monorepozitoriju prisilimo, da se koda ustvari v novem modulu. Ekipa D bo morala še vedno spremeniti "staro" komponento. Vsi lahko vidijo stroške, ki jih plačujemo tukaj - zdaj imamo dvakrat več kode in vsi popravki napak, ki veljajo za A1 in A2, morajo veljati za oba. Z razvejanim pristopom v polirepozitoriju je to skrito za češnjevo izbiro. Menimo, da so stroški nižji, ker ni podvajanja. S praktičnega vidika je cena enaka: zgradili boste, izdali in vzdrževali dve v veliki meri enaki kodni bazi, dokler ne boste mogli izbrisati ene od njiju. Razlika je v tem, da je pri monorepozitorju ta bolečina neposredna in vidna. To je še slabše in to je dobro.

Končno smo prišli do tretje točke. Zakasnitev sprostitve. Možno je, da bodo spremembe, ki jih je naredil A, izboljšale življenje ekipe A. Pomembne, vendar ne nujne. Lahko samo odlašamo? V polirepozitoriju to potisnemo, da pripnemo artefakt. Seveda to povemo ekipi D. Samo ostanite na stari različici, dokler ne dohitite! To vas postavi v vlogo strahopetca. Ekipa A nadaljuje z delom na svoji komponenti, pri čemer ignorira dejstvo, da ekipa D uporablja vse bolj zastarelo različico (to je problem ekipe D, oni so neumni). Medtem ekipa D slabo govori o malomarnem odnosu ekipe A do stabilnosti kode, če o tem sploh govori. Meseci minevajo. Končno se ekipa D odloči preučiti možnost posodobitve, vendar ima A samo še več sprememb. Ekipa A se komaj spomni, kdaj in kako je zlomila D. Nadgradnja je bolj boleča in bo trajala dlje. Kar ga pošlje nižje po prednostnem kupu. Do dneva, ko imamo varnostno težavo v A, ki nas prisili, da naredimo vejo. Ekipa A se mora vrniti v preteklost, najti točko, ko je bil D stabilen, tam odpraviti težavo in jo pripraviti za izdajo. To je de facto izbira, ki jo ljudje naredijo, in je daleč najslabša. Zdi se, da je dobro za ekipo A in ekipo D, če se lahko ignoriramo.

V monorepozitoriju tretje resnično ni možnost. Prisiljeni ste se spopasti s situacijo na enega od dveh načinov. Videti morate stroške dveh izdanih podružnic. Naučite se zaščititi pred posodobitvami, ki porušijo združljivost s prejšnjimi različicami. Toda najpomembneje: težkemu pogovoru se ne morete izogniti.

Po mojih izkušnjah, ko se ekipe povečajo, ni več mogoče imeti v mislih celotnega sistema in to je najpomembnejši del. Izboljšati morate vidnost neskladja v sistemu. Aktivno si morate prizadevati, da ekipe pripravite do tega, da pogledajo stran od svojih komponent in pogledajo delo drugih ekip in potrošnikov.

Da, ustvarite lahko orodja, ki poskušajo rešiti problem polirepozitorija. Toda moje izkušnje s poučevanjem neprekinjenega izvajanja in avtomatizacije v velikih podjetjih mi pravijo naslednje: privzeto vedenje brez uporabe dodatnih orodij je vedenje, ki ga pričakujete. Privzeto vedenje polirepozitorija je izolacija, to je bistvo. Privzeto vedenje monorepozitorija je deljena odgovornost in preglednost, to je bistvo. V obeh primerih bom ustvaril orodje, ki bo zgladilo grobe robove. Kot vodja bom vsakič izbral monorepozitorij, ker morajo orodja okrepiti kulturo, ki jo želim, kultura pa izhaja iz majhnih odločitev in vsakodnevnega dela ekipe.

V anketi lahko sodelujejo samo registrirani uporabniki. Prijaviti se, prosim.

Kdo so največji fanatiki? Podporniki:

• Monorepo

• Rust

• Napačna anketa / oboje

Glasovalo je 33 uporabnikov. 13 uporabnikov se je vzdržalo.

Vir: www.habr.com