Prevod članka pripremljen za studente kursa «DevOps prakse in orodja» v izobražvalnem projektu OTUS.

Izbrati morate monorepo, ker vedenje, ki ga spodbuja v vaših ekipah, pomeni preglednost in kolektivno odgovornost, še posebej, ko ekipe rastejo. V vsakem primeru boste morali investirati v orodja, toda vedno je bolje, ko je privzeto vedenje tisto, ki ga želite videti v svojih ekipah.

Zakaj o tem govorimo?

Matt Klein je napisal članek «Monorepos: Please don’t!» (op. prevajalca: prevod na Habr «Monorepos: prosim, ne delajte tega»). Obožujem Matta, mislim, da je zelo pameten, in morate prebrati njegov pogled. Sprva je na Twitterju objavil anketo:

Prevod:
Na ta novolesni dan se bom spoprijel s tem, kako absurdni so monorepoji. Leto 2019 se je začelo neopazno. V duhu tega vam predlagam anketo. Kdo so veliki oboževalci? Podporniki:
— Monorepo
— Rust
— Napačna anketa / oboje

Moj odgovor je bil: «Jaz sem pravzaprav oba ta človeka». Namesto da bi govoril o tem, kako je Rust droga, se pojdimo, zakaj mislim, da se moti glede monorepojev. Malo o meni. Sem tehnični direktor v Chef Software. Imamo okoli 100 inženirjev, koda, ki sega okoli 11–12 let, in 4 glavne produkte. Del te kode je v polirepoju (moji začetni poziciji), del pa v monorepoju (moji trenutni poziciji).

Preden začnem: vsak argument, ki ga tukaj navajam, bo uporabljen za oba tipa repozitorijev. Po mojem mnenju ni nobenih tehničnih razlogov, zakaj bi morali izbrati ta ali oni tip repozitorija. Vsak pristop vam lahko deluje. Vesel sem, da se o tem pogovorim, a ne zanimajo me umetni tehnični razlogi, zakaj je eno boljše od drugega.

Strinjam se s prvim delom Mattovega stališča:

Ker bo na veliki ravni monorepo reševal vse iste probleme, ki jih rešuje tudi polirepo, toda ob tem vas sili v močno povezanost vaše kode in zahteva neverjetne napore za povečanje skalabilnosti vašega sistema nadzora različic.

Ne glede na to, ali se odločite za monorepo ali polirepo, se boste morali spopasti s podobnimi težavami. Kako izdajate različice? Kakšen je vaš pristop k posodobitvam? Obdržite obratno združljivost? Kako upravljate s prečnimi odvisnostmi projektov? Katere arhitekturne sloge sprejemate? Kako obvladujete svojo infrastrukturo za gradnjo in testiranje? Seznam je neskončen. In rešili jih boste vse, ko boste rasli. Brezplačnega sira ni.

Menim, da je Mattov argument podoben mnenjem, ki jih delijo številni inženirji (in menedžerji), ki jih spoštujem. To prihaja z vidika inženirja, ki deluje na komponenti, ali ekipe, ki dela na komponenti. Slišite take stvari, kot so:

Koda je pretirana - ne potrebujem vse te navlake.
Težje je testirati, ker moram preveriti vso to navlako, ki je ne potrebujem.
Težje je delati z zunanjimi odvisnostmi.
Potrebujem svoje virtualne sisteme za upravljanje različic.

Seveda so vse te točke upravičene. To se dogaja v obeh primerih - v polireposu imam svojo navlako, poleg tiste, ki jo potrebujem za gradnjo... Morda bom potreboval še drugo navlako. Zato "enostavno" ustvarim orodja, ki prenesejo celoten projekt. Ali ustvarim lažni monorepo s podmoduli. Lahko bi cel dan razpravljali o tem. Vendar menim, da Mattov argument spregleda osnovni razlog, ki sem ga precej prevzel v prid monorepo:

Spodbuja komunikacijo in razkriva težave.

Ko delimo repozitorije, dejansko ustvarjamo težavo koordinacije in preglednosti. To sovpada s tem, kako razmišljamo o ekipah (še posebej s tem, kako o njih razmišljajo posamezni člani): odgovorni smo za določeno komponento. Delamo v relativni izolaciji. Meje so določene na moji ekipi in komponentah, na katerih delamo.

При усл复杂нения архитектуры одна команда уже не может управлять ею в одиночку. Очень немногие инженеры держат всю систему в голове. Допустим, вы управляете общим компонентом A, который используется командами B, C и D. Команда A проводит рефакторинг, улучшает API и меняет внутреннюю реализацию. В результате изменения являются обратно несовместимыми. Какой совет вы дадите?

Найдите все места, где используется старый API.
Есть ли места, где нельзя использовать новый API?
Можете ли вы исправить и протестировать другие компоненты, чтобы убедиться, что они не сломаются?
Могут ли эти команды проверить ваши изменения прямо сейчас?

Обратите внимание, что эти вопросы не зависят от типа репозитория. Вам нужно будет найти команды B, C и D. Вам нужно будет поговорить с ними, выяснить время и понять их приоритеты. По крайней мере, мы надеемся, что вы это сделаете.

На самом деле никто не хочет заниматься этим. Это гораздо менее увлекательно, чем просто исправление чёртового API. Всё это человеческое и запутанное. В полирепозитории вы можете просто внести изменения, дать на ревью тем, кто работает над этим компонентом (вероятно, не B, C или D), и двигаться дальше. Команды B, C и D могут пока просто оставаться на своей текущей версии. Они обновятся, когда осознают вашу гениальность!

В монорепозитории ответственность сдвигается по умолчанию. Команда A меняет свой компонент и, если не проявит осторожности, немедленно ломает B, C и D. Это приводит к тому, что B, C и D появляются у двери A, удивляясь, почему команда A сломала сборку. Это учит A тому, что они не могут игнорировать мой список выше. Они должны обсуждать, что собираются делать. Могут ли B, C и D двигаться? Что, если B и C могут, но D был тесно связан с побочным эффектом поведения старого алгоритма?

Затем мы должны поговорить о том, как мы выйдем из этой ситуации:

Поддержка нескольких внутренних API, при этом старый алгоритм будет помечен устаревшим, пока D не сможет прекратить его использовать.
Поддержка нескольких версий релизов, одна со старым интерфейсом, одна с новым.
Задержка релиза изменений A до тех пор, пока одновременно B, C и D не смогут принять его.

Recimo, da smo izbrali 1, več API-jev. V tem primeru imamo dva kosa kode. Stara in nova. To je precej priročno v nekaterih situacijah. Staro kodo vrnemo, označimo jo kot zastarjeno (deprecated) in uskladimo načrt za njeno odstranitev s skupino D. V bistvu je identično za poli in za monorepo.

Za izdajo več različic potrebujemo vejo. Zdaj imamo dva komponenta — A1 in A2. Skupini B in C uporabljata A2, medtem ko D uporablja A1. Vsaka komponenta mora biti pripravljena za izdajo, saj lahko pred napredovanjem D potrebujemo posodobitve varnosti in popravke drugih napak. V poli repo lahko to skrijemo v dolgotrajni veji, ki se počuti dobro. V monorepo pa prisilimo ustvarjanje kode v novem modulu. Skupina D bo še vedno morala narediti spremembe v 'stari' komponenti. Vsak lahko vidi stroške, ki jih tukaj plačujemo – zdaj imamo dvakrat več kode, in vse popravke napak, ki se nanašajo na A1 in A2, je treba uporabiti za oboje. Pri pristopu z uporabo vej v poli repo je to skrito za cherry-pick. Stroške ocenjujemo kot manjše, ker ni podvajanja. Z praktičnega vidika so stroški enaki: ustvarjali, izdali in vzdrževali boste dve, večinoma identični, bazi kode, dokler ne boste mogli odstraniti ene od njiju. Razlika je v tem, da je ta bolečina pri monorepo neposredna in na očeh. To je še slabše in to je dobro.

Na koncu smo prispeli do tretje točke. Zakasnitev izdaje. Morda bodo spremembe, ki jih uvede A, izboljšale življenje ekipe A. Pomembno, a ne nujno. Ali lahko enostavno zavlečemo? V monorepozitoriju to potiskamo k utrditvi artefakta. Seveda, o tem govorimo z ekipo D. Preprosto ostanite na stari različici, dokler ne dohiteti! To vodi v igro s tveganjem. Ekipa A še naprej dela na svojem komponentu, ignorira dejstvo, da ekipa D uporablja vse bolj zastarelo različico (to je težava ekipe D, so neumno). Medtem ekipa D slabo govori o neprevidnem odnosu ekipe A do stabilnosti kode, če sploh govorijo o tem. Minili so meseci. Na koncu se ekipa D odloči, da pogleda možnost nadgradnje, a sprememb v A je le še več. Ekipa A se komaj spomni, kdaj in kako so pokvarili D. Nadgradnja je bolj boleča in bo vzela več časa. Kar še dodatno zniža prioritetno lestvico. Do dneva, ko imamo težavo z varnostjo v A, kar nas prisili v izdelavo veje. Ekipa A se mora vrniti nazaj v čas, najti trenutek, ko je bil D stabilen, tam popraviti težavo in ga pripraviti za izdajo. To je de facto izbira, ki jo ljudje sprejemajo, in nedvomno najslabša. Zdi se, da je to dobro tako za ekipo A kot za D, dokler se lahko ignoriramo.

V monorepozitoriju tretja možnost res ni na voljo. Pripravljeni ste se spoprijeti s situacijo na enega od dveh načinov. Morate videti stroške imeti dve izdaji. Naučiti se morate zaščititi pred nadgradnjami, ki prelomijo obratno združljivost. Ampak najbolj pomembno: ne morete ubežati težkemu pogovoru.

Po mojem mnenju, ko ekipe postanejo velike, ni več mogoče obdržati celotnega sistema v mislih in to je najpomembnejši del. Morate izboljšati vidnost nesoglasij v sistemu. Aktivno morate delati na tem, da ekipe odvzamejo pogled s svojih komponent in pogledajo na delo drugih ekip in uporabnikov.

Da, lahko ustvarite orodja, ki se bodo trudila rešiti težave polirepozitorijev. A moje izkušnje z neprekinjeno dobavo (continuous delivery) in avtomatizacijo v velikih podjetjih mi govorijo, da je privzeto vedenje brez dodatnih orodij tisto, kar pričakujete videti. Privzeto vedenje polirepozitorija je izolacija, kar je pomen samega sistema. Privzeto vedenje monorepozitorija pa je skupna odgovornost in preglednost, kar je pomen sama sistema. V obeh primerih nameravam ustvariti orodje, ki bo omogočilo mehčanje ostrih robov. Kot vodja bom vedno izbral monorepozitorij, ker morajo orodja okrepiti kulturo, ki jo želim, in kultura izhaja iz majhnih odločitev ter vsakodnevnega dela ekipe.

Samo registrovani korisnici mogu učestvovati u anketi. Prijavite se, molim vas.