Prijevod članka pripremljen za studente kursa "DevOps prakse i alati" u obrazovnom projektu OTUS.

Trebali biste odabrati monorepozitorij jer ponašanje koje promovira u vašim timovima je transparentnost i zajednička odgovornost, posebno kako timovi rastu. U svakom slučaju, morat ćete uložiti u alate, ali uvijek je bolje ako je zadano ponašanje ono ponašanje koje želite u svojim naredbama.

Zašto pričamo o ovome?

Matt Klein je napisao članak "Monorepos: Molim te, nemoj!"  (napomena prevodioca: prevod na Habréu “Monorepozitoriji: molim vas nemojte”). Sviđa mi se Matt, mislim da je veoma pametan i trebalo bi da pročitate njegovo gledište. On je prvobitno objavio anketu na Twitteru:

Prevod:
Ove Nove godine ću se raspravljati o tome koliko su monorepozitoriji smiješni. 2019 je počela tiho. U duhu ovoga, nudim vam anketu. Ko su veliki fanatici? Pristalice:
- Monorepo
- rđa
- Netačna anketa / oboje

Moj odgovor je bio: "Ja sam bukvalno oboje od tih ljudi." Umjesto da govorimo o tome kako je Rust lijek, pogledajmo zašto mislim da griješi u vezi sa monorepozitorijumima. Malo o sebi. Ja sam CTO Chef Software. Imamo oko 100 inženjera, bazu kodova koja se kreće unazad oko 11-12 godina i 4 glavna proizvoda. Dio ovog koda je u polirepozitorijumu (moja početna pozicija), neki je u monorepozitorijumu (moja trenutna pozicija).

Prije nego počnem: svaki argument koji ovdje iznesem primjenjivat će se na obje vrste spremišta. Po mom mišljenju, ne postoji tehnički razlog zašto biste odabrali jednu vrstu spremišta u odnosu na drugu. Svaki pristup možete učiniti uspješnim. Rado pričam o tome, ali me ne zanimaju vještački tehnički razlozi zašto je jedno nadmoćnije od drugog.

Slažem se s prvim dijelom Mattove tvrdnje:

Jer na skali, monorepozitorijum će rešiti sve iste probleme koje rešava polirepozitorijum, ali će vas u isto vreme primorati da čvrsto povežete svoj kod i zahtevaće neverovatne napore da povećate skalabilnost vašeg sistema kontrole verzija.

Morat ćete rješavati iste probleme bez obzira da li odaberete monorepozitorij ili polirepozitorij. Kako objavljujete izdanja? Kakav je vaš pristup ažuriranjima? Kompatibilnost unatrag? Međusobne zavisnosti od projekta? Koji su arhitektonski stilovi prihvatljivi? Kako upravljate svojom infrastrukturom za izgradnju i testiranje? Lista je beskrajna. I sve ćeš ih riješiti kako rasteš. Nema besplatnog sira.

Mislim da je Metov argument sličan stavovima koje dijele mnogi inženjeri (i menadžeri) koje poštujem. Ovo se događa iz perspektive inženjera koji radi na komponenti ili tima koji radi na komponenti. Čujete stvari poput:

• Baza kodova je glomazna - ne treba mi svo ovo smeće.
• Teže je testirati jer moram testirati svo ovo smeće koje mi nije potrebno.
• Teže je raditi s vanjskim ovisnostima.
• Trebaju mi ​​vlastiti virtuelni sistemi kontrole verzija.

Naravno, sve ove tačke su opravdane. Ovo se dešava u oba slučaja - u polirepozitorijumu imam svoje smeće, pored onog potrebnog za izgradnju... Možda će mi trebati i drugo smeće. Tako da “jednostavno” kreiram alate koji provjeravaju cijeli projekat. Ili kreiram lažni monorepozitorijum sa podmodulima. Mogli bismo hodati oko ovoga cijeli dan. Ali mislim da Mattov argument propušta glavni razlog, koji sam prilično preokrenuo u korist monorepozitorija:

Provocira komunikaciju i pokazuje probleme

Kada odvojimo repozitorije, stvaramo de facto problem koordinacije i transparentnosti. To odgovara načinu na koji razmišljamo o timovima (naročito načinu na koji pojedini članovi misle o njima): mi smo odgovorni za određenu komponentu. Radimo u relativnoj izolaciji. Granice su fiksirane za moj tim i komponentu(e) na kojoj radimo.

Kako arhitektura postaje složenija, jedan tim više ne može upravljati sam. Vrlo malo inženjera ima cijeli sistem u svojim glavama. Recimo da upravljate zajedničkom komponentom A koju koriste timovi B, C i D. Tim A refaktorira, poboljšava API, a također mijenja internu implementaciju. Kao rezultat toga, promjene nisu kompatibilne unatrag. koji savjet imate?

• Pronađite sva mjesta na kojima se koristi stari API.
• Postoje li mjesta na kojima se novi API ne može koristiti?
• Možete li popraviti i testirati druge komponente kako biste bili sigurni da se ne pokvare?
• Mogu li ovi timovi trenutno testirati vaše promjene?

Imajte na umu da su ova pitanja nezavisna od tipa spremišta. Morat ćete pronaći timove B, C i D. Morat ćete razgovarati s njima, saznati vrijeme, razumjeti njihove prioritete. Barem se nadamo da hoćete.

Niko zaista ne želi ovo da radi. Ovo je mnogo manje zabavno nego samo popravljanje prokletog API-ja. Sve je to ljudski i neuredno. U polirepozitorijumu možete jednostavno napraviti promjene, dati je ljudima koji rade na toj komponenti (vjerovatno ne B, C ili D) na pregled i nastaviti dalje. Timovi B, C i D za sada mogu samo ostati sa svojom trenutnom verzijom. Oni će biti obnovljeni kada shvate vašu genijalnost!

U monorepozitorijumu, odgovornost se prebacuje po defaultu. Tim A mijenja svoju komponentu i, ako ne bude oprezan, odmah razbija B, C i D. To dovodi do toga da se B, C i D pojavljuju na vratima A, pitajući se zašto je Tim A razbio sklop. Ovo uči A da ne mogu preskočiti moju gornju listu. Moraju razgovarati o tome šta će uraditi. Mogu li se B, C i D pomjerati? Šta ako B i C mogu, ali je D usko povezan sa nuspojavom ponašanja starog algoritma?

Zatim moramo razgovarati o tome kako ćemo izaći iz ove situacije:

1. Podrška za više internih API-ja i označit će stari algoritam kao zastarjeli dok D ne prestane da ga koristi.
2. Podrška za više verzija izdanja, jednu sa starim interfejsom, jednu sa novim.
3. Odgodite objavljivanje izmjena A dok ih B, C i D ne mogu istovremeno prihvatiti.

Recimo da smo odabrali 1, nekoliko API-ja. U ovom slučaju imamo dva dijela koda. Staro i novo. Prilično zgodno u nekim situacijama. Vraćamo stari kod, označavamo ga kao zastarelog i dogovaramo se o rasporedu uklanjanja sa D timom. U suštini identično za poli i mono spremišta.

Za izdavanje više verzija potrebna nam je grana. Sada imamo dvije komponente - A1 i A2. Timovi B i C koriste A2, a D koristi A1. Trebamo da svaka komponenta bude spremna za izdavanje jer mogu biti potrebna sigurnosna ažuriranja i druge ispravke grešaka prije nego što D može krenuti naprijed. U polirepozitorijumu, ovo možemo sakriti u dugovečnoj grani koja je dobra. U monorepozitorijumu, prisiljavamo da se kod kreira u novom modulu. Tim D će i dalje morati da izvrši promene na "staroj" komponenti. Svi mogu vidjeti cijenu koju plaćamo ovdje - sada imamo dvostruko više koda, a sve ispravke grešaka koje se primjenjuju na A1 i A2 moraju se primijeniti na oba. Sa pristupom grananja u polirepozitorijumu, ovo je skriveno iza trešnje. Smatramo da je trošak niži jer nema dupliranja. S praktične tačke gledišta, cijena je ista: izgradit ćete, objaviti i održavati dvije uglavnom identične kodne baze dok ne izbrišete jednu od njih. Razlika je u tome što je kod monorepozitorija ovaj bol direktan i vidljiv. Ovo je još gore, i to je dobro.

Konačno smo došli do treće tačke. Odgoda otpuštanja. Moguće je da će promjene koje izvrši A poboljšati živote tima A. Važno, ali nije hitno. Možemo li samo da odložimo? U polirepozitorijumu guramo ovo da zakačimo artefakt. Naravno, ovo govorimo Timu D. Samo ostanite na staroj verziji dok ne nadoknadite! Ovo te postavlja da igraš kukavice. Tim A nastavlja da radi na svojoj komponenti, zanemarujući činjenicu da Tim D koristi sve stariju verziju (to je problem tima D, oni su glupi). U međuvremenu, Tim D loše govori o nemarnom stavu tima A prema stabilnosti koda, ako o tome uopšte govore. Mjeseci prolaze. Konačno, Tim D odlučuje da pogleda mogućnost ažuriranja, ali A ima samo još promjena. Tim A se jedva sjeća kada i kako je razbio D. Nadogradnja je bolnija i trajat će duže. Što ga šalje dalje niz prioritetni stog. Do dana kada imamo sigurnosni problem u A koji nas prisiljava da napravimo granu. Tim A mora se vratiti u prošlost, pronaći tačku kada je D bio stabilan, popraviti problem tamo i pripremiti ga za puštanje. Ovo je de facto izbor koji ljudi donose, i daleko je najgori. Čini se da je dobro i za tim A i za tim D sve dok možemo da ignorišemo jedni druge.

U monorepozitorijumu, treće zaista nije opcija. Primorani ste da se nosite sa situacijom na jedan od dva načina. Morate vidjeti troškove postojanja dvije grane izdanja. Naučite se zaštititi od ažuriranja koja narušavaju kompatibilnost unatrag. Ali najvažnije: ne možete izbjeći težak razgovor.

Po mom iskustvu, kada timovi postanu veliki, više nije moguće imati na umu cijeli sistem, a to je najvažniji dio. Morate poboljšati vidljivost neslaganja u sistemu. Morate aktivno raditi na tome da timovi skrenu pogled sa svojih komponenti i pogledaju rad drugih timova i potrošača.

Da, možete kreirati alate koji pokušavaju riješiti problem polirepozitorija. Ali moje iskustvo podučavanja kontinuirane isporuke i automatizacije u velikim preduzećima govori mi ovo: podrazumevano ponašanje bez upotrebe dodatnih alata je ponašanje koje očekujete da vidite. Podrazumevano ponašanje polirepozitorija je izolacija, u tome je cela poenta. Zadano ponašanje monorepozitorija je zajednička odgovornost i transparentnost, to je cijela poenta. U oba slučaja, napraviću alat koji će izgladiti grube ivice. Kao vođa, svaki put ću izabrati monorepozitorij jer alati trebaju ojačati kulturu koju želim, a kultura dolazi iz sićušnih odluka i svakodnevnog rada tima.

Samo registrovani korisnici mogu učestvovati u anketi. Prijavite semolim.

Ko su najveći fanatici? Pristalice:

• Monorepo

• rđa

• Netačna anketa / oboje

Glasalo je 33 korisnika. Uzdržano je bilo 13 korisnika.

izvor: www.habr.com