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

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

Zašto pričamo o ovome?

Matt Klein je napisao članak "Monorepos: Molim te, nemoj!"  (napomena prevoditelja: prijevod na Habréu "Monorepozitoriji: molim vas nemojte"). Sviđa mi se Matt, mislim da je vrlo pametan i trebali biste pročitati njegovo gledište. Anketu je izvorno objavio na Twitteru:

Prijevod:
Ovu Novu godinu raspravljat ću o tome koliko su monorepozitoriji smiješni. 2019. je počela tiho. U duhu toga, nudim vam anketu. Tko su veliki fanatici? Podržavatelji:
- Monorepo
- Hrđa
- Netočna anketa / oboje

Moj odgovor je bio: "Ja sam doslovno oboje od tih ljudi." Umjesto da pričamo o tome kako je Rust droga, pogledajmo zašto mislim da griješi u vezi s monoskladištem. Malo o sebi. Ja sam tehnički direktor Chef Softwarea. Imamo oko 100 inženjera, bazu kodova staru 11-12 godina i 4 glavna proizvoda. Dio ovog koda je u polirepozitoriju (moja početna pozicija), dio je u monorepozitoriju (moja trenutna pozicija).

Прежде чем я начну: каждый аргумент, который я здесь привожу, будет применён к репозиториям обоих видов. По моему мнению, нет никаких технических причин, по которым вы должны выбрать тот или иной тип репозитория. Вы сможете заставить работать любой подход. Я рад поговорить об этом, но меня не интересуют искусственные технические причины, по которым одно превосходит другое.

Slažem se s prvim dijelom Mattove tvrdnje:

Budući da će monorepozitorij riješiti sve iste probleme koje rješava višespremište, ali će vas u isto vrijeme prisiliti da čvrsto spojite svoj kod i zahtijevati nevjerojatne napore da povećate skalabilnost vašeg sustava kontrole verzija.

Morat ćete riješiti iste probleme bez obzira da li odaberete monorepozitorij ili polirepozitorij. Kako objavljujete izdanja? Kakav je vaš pristup ažuriranjima? Kompatibilnost unatrag? Međuprojektne ovisnosti? Koji su arhitektonski stilovi prihvatljivi? Kako upravljate svojom infrastrukturom za izradu i testiranje? Popis je beskrajan. I sve ćete ih riješiti kako budete rasli. Nema besplatnog sira.

Mislim da je Mattov argument sličan stavovima mnogih inženjera (i menadžera) koje poštujem. To 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 to smeće koje mi ne treba.
• Teže je raditi s vanjskim ovisnostima.
• Trebam vlastite virtualne sustave za kontrolu verzija.

Naravno, sve ove točke su opravdane. To se događa u oba slučaja - u polirepozitoriju imam svoje smeće, osim onog potrebnog za izgradnju... Možda će mi trebati i drugo smeće. Stoga „jednostavno“ stvaram alate koji provjeravaju cijeli projekt. Ili stvaram lažno monorepozitorij s podmodulima. Mogli bismo hodati oko ovoga cijeli dan. Ali mislim da Mattov argument propušta glavni razlog, koji sam prilično okrenuo u korist monorepozitorija:

Provocira komunikaciju i pokazuje probleme

Kada odvajamo repozitorije, stvaramo de facto problem koordinacije i transparentnosti. To odgovara načinu na koji razmišljamo o timovima (osobito kako o njima razmišljaju pojedini članovi): mi smo odgovorni za određenu komponentu. Radimo u relativnoj izolaciji. Granice su fiksne za moj tim i komponente na kojima radimo.

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

• Pronađite sva mjesta gdje se koristi stari API.
• Postoje li mjesta gdje se novi API ne može koristiti?
• Možete li popraviti i testirati druge komponente kako biste bili sigurni da se neće pokvariti?
• Mogu li ti timovi testirati vaše promjene upravo sada?

Imajte na umu da su ova pitanja neovisna o vrsti repozitorija. 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.

Nitko to zapravo ne želi učiniti. Ovo je puno manje zabavno nego samo popravljati prokleti API. Sve je to ljudski i neuredno. U polirepozitoriju možete jednostavno napraviti promjene, dati ih ljudima koji rade na toj komponenti (vjerojatno ne B, C ili D) na pregled i nastaviti dalje. Timovi B, C i D za sada mogu samo ostati pri svojoj trenutnoj verziji. Obnovit će se kad shvate tvoju genijalnost!

U monorepozitoriju odgovornost se prebacuje prema zadanim postavkama. Tim A mijenja svoju komponentu i, ako nije pažljiv, odmah razbija B, C i D. To dovodi do B, C i D koji se pojavljuju na vratima A, pitajući se zašto je Tim A pokvario sklop. Ovo uči A da ne mogu preskočiti moj gornji popis. Moraju razgovarati o tome što će učiniti. Mogu li se B, C i D kretati? Što ako B i C mogu, ali D je usko povezan s 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 sve dok ga D ne prestane koristiti.
2. Podrška za više verzija izdanja, jedno sa starim sučeljem, jedno s novim.
3. Odgodite objavljivanje A-ovih promjena 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. Ponovno provjeravamo stari kod, označavamo ga kao zastarjeli i dogovaramo raspored uklanjanja s timom D. U osnovi identičan za poli i mono repozitorije.

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 će sigurnosna ažuriranja i drugi ispravci pogrešaka možda biti potrebni prije nego što D može krenuti naprijed. U polirepozitoriju, možemo to sakriti u dugovječnoj grani koja je dobra. U monorepozitoriju prisiljavamo stvaranje koda u novom modulu. Tim D će ipak morati napraviti izmjene na "staroj" komponenti. Svatko može vidjeti trošak koji ovdje plaćamo - sada imamo dvostruko više koda, a svi ispravci grešaka koji se odnose na A1 i A2 moraju se odnositi na oba. S pristupom grananja u polirepozitoriju, ovo je skriveno iza odabira trešnje. Smatramo da je trošak manji jer nema dupliranja. S praktičnog stajališta, cijena je ista: izgradit ćete, objaviti i održavati dvije uglavnom identične baze kodova dok ne budete mogli izbrisati jednu od njih. Razlika je u tome što je kod monorepozitorija ta bol izravna i vidljiva. Ovo je još gore, a to je dobro.

Napokon smo došli do trećeg boda. Odgoda otpuštanja. Moguće je da će promjene koje je napravio A poboljšati život tima A. Važne, ali ne hitne. Možemo li samo odgoditi? U polirepozitoriju, guramo ovo da prikvačimo artefakt. Naravno, ovo govorimo timu D. Samo ostanite na staroj verziji dok ne stignete! Ovo vas postavlja da glumite kukavicu. Tim A nastavlja raditi na svojoj komponenti, zanemarujući činjenicu da tim D koristi sve zastarjeliju 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će govore. Prolaze mjeseci. Konačno, tim D odlučuje razmotriti mogućnost ažuriranja, ali A ima samo još promjena. Tim A se jedva sjeća kada i kako su razbili D. Nadogradnja je bolnija i trajat će dulje. Što ga šalje dalje niz prioritetni skup. Sve do dana kada budemo imali sigurnosni problem u A koji nas prisiljava da napravimo granu. Tim A se mora vratiti u prošlost, pronaći točku kada je D bio stabilan, tamo riješiti problem i pripremiti ga za puštanje. Ovo je de facto izbor koji ljudi čine i daleko je najgori. Čini se da je dobro i za tim A i za tim D sve dok možemo ignorirati jedni druge.

U monorepozitoriju, treći stvarno nije opcija. Prisiljeni ste se nositi sa situacijom na jedan od dva načina. Morate vidjeti troškove dva izdanja ogranka. Naučite se zaštititi od ažuriranja koja prekidaju kompatibilnost sa starijim verzijama. Ali najvažnije: ne možete izbjeći težak razgovor.

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

Da, možete izraditi alate koji pokušavaju riješiti problem polirepozitorija. Ali moje iskustvo podučavanja kontinuirane isporuke i automatizacije u velikim poduzećima govori mi sljedeće: zadano ponašanje bez upotrebe dodatnih alata je ponašanje koje očekujete da ćete vidjeti. Zadano ponašanje polirepozitorija je izolacija, to je cijela poanta. Zadano ponašanje monorepozitorija je podijeljena odgovornost i transparentnost, to je cijela poanta. U oba slučaja, napravit ću alat koji će izravnati grube rubove. Kao voditelj, odabrat ću monorepozitorij svaki put jer alati trebaju ojačati kulturu koju želim, a kultura proizlazi iz sitnih odluka i svakodnevnog rada tima.

U anketi mogu sudjelovati samo registrirani korisnici. Prijaviti se, molim.

Tko su najveći fanatici? Podržavatelji:

• Monorepo

• Hrđa

• Netočna anketa / oboje

Glasovalo je 33 korisnika. Suzdržano je bilo 13 korisnika.

Izvor: www.habr.com