Artikli tõlge on ette valmistatud OTUS kursuse üliõpilaste jaoks. „DevOps praktikas ja tööriistades“ haridusprojektis OTUS.

Te peate valima monorepo, sest selle soodustatav käitumine teie meeskondades - see on läbipaistvus ja kollektiivne vastutus, eriti meeskondade kasvades. Igal juhul peate investeerima tööriistadesse, kuid alati on parem, kui vaikimisi käitumine on see, mida soovite oma meeskondades näha.

Miks me sellest räägime?

Matt Klein kirjutas artikli «Monorepos: Please don’t!» (tõlkija märkus: tõlge Habrist «Monorepos: palun ärge tehke seda»). Mulle meeldib Matt, arvan, et ta on väga tark, ja te peaksite lugema tema seisukohta. Alguses avaldas ta Twitteris küsitluse:

Tõlge:
Selles uusaasta päeval vaieldan, kui naeruväärsed monorepos on. 2019. aasta algas märkamatult. Selle vaimus pakun teile küsitluse. Kes on suured fännid? Pooldajad:
— Monorepo
— Rust
— Vale küsitlus / mõlemad

Minu vastus oli: "Ma mõtlen tõeliselt nende kahe inimese peale." Enne kui räägime, kui suurepärane on Rust, uurime, miks ma arvan, et ta eksib monorepositooriumide osas. Pisut endast. Olen Chef Software'i tehniline direktor. Meil on umbes 100 inseneri, koodibaas, mis ulatub 11–12 aasta taha, ja 4 peamist toodet. Osa sellest koodist on poli-repositooriumis (minu algne seisukoht), osa monorepositooriumis (minu praegune seisukoht).

Enne alustamist: iga argument, mida ma siin olen välja toonud, kehtib mõlema tüüpi repositooriumide kohta. Minu arvates ei ole tehnilisi põhjuseid, miks peaksite valima ühe või teise repositooriumi. Te saate tööle panna mõlemat lähenemist. Olen valmis sellest rääkima, kuid tehislikud tehnilised põhjused, miks ühte peetakse teise üle, ei huvita mind.

Olen Matti vaate nurga esimeses osas nõus:

Sest suurtes skaalades lahendab monorepo kõik samad probleemid, mis poli-repos, kuid see kutsub teid üles oma koodi tugevamalt siduma ja nõuab teie versioonihaldussüsteemi skaleeritavuse suurendamiseks tohutuid pingutusi.

Peate lahendama samu probleeme sõltumata sellest, kas valite monorepo või poli-repo. Kuidas te vabastate? Milline on teie lähenemine värskendustele? Tagasiühilduvus? Üksteise projektide sõltuvused? Millised arhitektuurilised stiilid on vastuvõetavad? Kuidas te haldate oma ehitamise ja testimise infrastruktuuri? Loend on lõpmatu. Ja te lahendate need kõik kasvanud oluliselt. Tasuta juustu ei ole.

Minu arvates on Matti argument sarnane paljude inseneride (ja juhtide) vaadetele, keda ma austan. See on vaade insenerilt, kes töötab komponendi kallal, või meeskonnalt, kes töötab komponendi kallal. Kuulete selliseid asju nagu:

Koodibaas on kohmakas – mul ei ole vaja kogu seda jama.
Seda on keerulisem testida, kuna pean kontrollima kogu seda prügi, mida mul ei ole vaja.
Väliste sõltuvustega on keerulisem töötada.
Mul on vaja oma versioonihaldussüsteeme.

Muidugi, kõik need punktid on põhjendatud. See juhtub mõlemal juhul — minu poli-reposiitoriumis on oma prügi, lisaks sellele, mis on vajalik koostamiseks… Võib-olla vajab mul ka muud prügi. Seega loon lihtsalt tööriistad, mis teevad projekti checkouti. Või loon vale monoreposti koos alammodulitega. Me võiksime sellest ringi käia terve päeva. Kuid ma arvan, et Matti argument jätab mainimata peamise põhjuse, mille astusin üsna tugevalt monoreposti kasuks:

See stimuleerib suhtlemist ja näitab probleeme.

Kui me jagame repositooriaid, loobime de facto koordineerimise ja läbipaistvuse probleemi. See peegeldab seda, kuidas me mõtleme meeskondadele (eriti sellele, kuidas neid mõistavad üksikud liikmed): vastutame kindla komponendi eest. Töötame suhtelises isolatsioonis. Piirid fikseeritakse minu meeskonna ja töötatava komponendi (-de) ümber.

Arhitektuuri keerukuse suurenedes ei suuda ükski meeskond enam üksi süsteemi hallata. Väga vähesed insenerid suudavad kogu süsteemi peas hoida. Oletame, et haldate ühist komponenti A, mida kasutavad meeskonnad B, C ja D. Meeskond A viib läbi refaktoreerimise, täiustab API-d ja muudab sisemist teostust. Seetõttu on muudatused tagasipöördumatud. Millist nõu annate?

Leidke kõik kohad, kus kasutatakse vana API-d.
Kas on kohti, kus uut API-d ei saa kasutada?
Kas suudate parandada ja testida teisi komponente, et veenduda, et need ei riku midagi?
Kas need meeskonnad saavad teie muudatusi kohe kontrollida?

Pange tähele, et need küsimused ei sõltu repositoriumi tüübist. Peate leidma meeskonnad B, C ja D. Peate nendega rääkima, selgitama välja aja, mõistma nende prioriteete. Loodame, et teete seda.

Tegelikkuses ei taha keegi sellega tegeleda. See on palju vähem põnev kui lihtsalt kuradi API parandamine. See on kõik inimlik ja keeruline. Ühes ühises repodis saate lihtsalt muudatusi teha, anda ülevaatamiseks neile, kes selle komponendiga töötavad (tõenäoliselt mitte B, C või D) ja edasi liikuda. Meeskonnad B, C ja D võivad praegu lihtsalt oma praeguses versioonis püsida. Nad uuendavad end, kui nad teid ära tunnevad!

Monorepositsioonis on vastutus vaikimisi edastatud. Meeskond A muudab oma komponenti ja kui nad ettevaatlikud ei ole, rikuvad nad kohe B, C ja D. See toob kaasa olukorra, kus B, C ja D seisavad A ukse taga, imestades, miks meeskond A koostööd katki tegi. See õpetab A-d, et nad ei saa minu eespool olevat nimekirja vahele jätta. Nad peavad rääkima sellest, mida nad kavatsevad teha. Kas B, C ja D saavad edasi liikuda? Mis siis, kui B ja C saavad, aga D on tihedalt seotud vanema algoritmi kõrvalmõjuga?

Seejärel peame rääkima, kuidas me sellest olukorrast välja saame:

Toetada mitut sise-API-d, kusjuures vanem algoritm tähistatakse vananenuks, kuni D suudab selle kasutamise lõpetada.
Toetada mitut versioonide väljalaset, üks vana liidese, üks uus.
Muudatuse A väljalaskmise edasilükkamine kuni B, C ja D suudavad seda üheaegselt aktsepteerida.

Oletame, et valisime 1 või mitu API-d. Sellisel juhul on meil kaks koodilõiku. Vana ja uus. Teatud olukordades on see üsna mugav. Me tagastame vana koodi tagasi, märgime selle aegunuks (deprecated) ja kooskõlastame selle eemaldamise ajakava meeskonnaga D. Põhimõtteliselt on see identne nii poli- kui monorepositooriumiga.

Mitmekordse versiooni viimistlemiseks vajame haru. Praegu on meil kaks komponenti — A1 ja A2. Meeskonnad B ja C kasutavad A2, samas kui D kasutab A1. Me peame tagama, et iga komponent oleks väljaandmiseks valmis, sest enne kui D saab edasi liikuda, võivad vajada turvaparandusi ja muid tõrgete parandusi. Polireposiitriumis saame seda varjata pika elueaga harus, mis tundub hea. Monoreposiitriumis sunnime uut moodulit looma. Meeskond D peab ikkagi tegema muudatusi 'vana' komponendi osas. Igaüks võib näha, milline on siin tasu — meil on nüüd topelt kood ja kõik A1 ja A2-l kehtivad vigade parandused peavad kehtima mõlema puhul. Harude kasutamise lähenemisega polireposiitriumis on see peidetud cherry-pick'i taha. Peame tasu madalamaks, kuna seal pole dubleerimist. Praktikas on tasu sama: peate looma, väljastama ja toetama kahte, peaaegu identset koodibaasi, kuni saate ühe neist eemaldada. Erinevus on see, et monoreposiitriumis on see valu otse ja silme ees. See on veel hullem, ja see on hea.

Lõpuks jõudsime kolmanda punkti juurde. Väljalaskmise viivitus. On võimalik, et A poolt tehtud muudatused parandavad A meeskonna elu. Oluline, kuid mitte kiire. Kas saame lihtsalt viivitada? Polireposiis teeme selle artefakti lõplikuks. Muidugi räägime sellest D meeskonnale. Lihtsalt jääge vana versiooni juurde, kuni jõuate järele! See seab mängu hirmu. A meeskond jätkab oma komponendi kallal töötamist, ignoreerides, et D meeskond kasutab aina vanemat versiooni (see on D meeskonna probleem, nad on lollid). Samal ajal räägib D meeskond halvasti A meeskonna tähelepanematust koodistabiilsuse osas, kui nad sellest üldse räägivad. Kuud lähevad mööda. Lõpuks otsustab D meeskond kaaluda uuendust, kuid A-s on muutunud ainult rohkem. A meeskond vaevu mäletab, millal ja kuidas nad D-d lõhkusid. Uuendamine on valusam ja võtab rohkem aega. Mis viib selle prioriteetide järjekorras madalamale. Kuni päevani, mil meil ei teki A-s turvaprobleem, mis sunnib meid haru looma. A meeskond peab tagasi minema aega, leidma hetke, mil D oli stabiilne, parandama seal probleemi ja tegema selle väljalaskmiseks valmis. See on de facto valik, mida inimesed teevad, ja kindlasti on see halvim. Tundub, et see sobib nii meeskonnale A kui ka D-le, seni kuni me saame teineteist ignorida.

Monorepositsioonis on kolmas tõeliselt mittevariant. Sa pead olukorraga toime tulema kahel viisil. Sa pead nägema kahe väljaandmisharu hoidmise kulusid. Kuidas end kaitsta tagurpidi ühilduvuse katkemise värskenduste eest. Kuid peamine: sind ei päästa keerulistest vestlustest.

Minu kogemuse põhjal, kui meeskonnad kasvavad, ei ole enam võimalik kogu süsteemi peas hoida, ja see on kõige olulisem. Sa pead parandama süsteemis erinevuste nähtavust. Sa pead aktiivselt töötama selle nimel, et panna meeskonnad oma komponentidest eemale vaatama ning nägema teiste meeskondade ja tarbijate tööd.

Jah, te saate luua tööriistu, mis püüavad lahendada polirepositooriumide probleemi. Kuid minu kogemus pideva kohaletoimetamise (continuous delivery) ja automatiseerimise valdkonnas suurtes ettevõtetes ütleb mulle järgmist: vaikimisi käitumine ilma lisatööriistade kasutamiseta on see, mida te ootate näha. Polirepositooriumi vaikimisi käitumine on isoleeritus, see on kogu mõte. Monorepositooriumi vaikimisi käitumine on ühine vastutus ja läbipaistvus, see on kogu mõte. Mõlemas olukorras kavatsen luua tööriista, mis aitab teravaid nurki tasandada. Juhi seisukohalt valin ma igal korral monorepositooriumi, sest tööriistad peaksid tugevdama kultuuri, mida ma soovin, ja kultuur tuleneb pisikestest otsustest ja igapäevasest meeskonnatööst.

Ainult registreeritud kasutajad saavad küsitluses osaleda. Logige sisse, palun.