Kursuse üliõpilastele koostatud artikli tõlge "DevOpsi tavad ja tööriistad" OTUS haridusprojektis.

Peaksite valima monohoidla, kuna see käitumine teie meeskondades on läbipaistvus ja jagatud vastutus, eriti kui meeskonnad kasvavad. Mõlemal juhul peate investeerima tööriistadesse, kuid alati on parem, kui vaikekäitumine on selline, nagu soovite oma käskudes.

Miks me sellest räägime?

Matt Klein kirjutas artikli "Monorepos: palun ära!"  (tõlkija märkus: tõlge Habré kohta "Monohoidlad: palun ärge tehke"). Mulle meeldib Matt, ma arvan, et ta on väga tark ja sa peaksid tema seisukohta lugema. Ta postitas küsitluse algselt Twitterisse:

Tõlge:
Sel uusaastapäeval vaidlen selle üle, kui naeruväärsed on monorepositooriumid. 2019 algas vaikselt. Selle vaimus pakun teile küsitlust. Kes on suured fanaatikud? Toetajad:
- Monorepo
- Rust
- Vale küsitlus / mõlemad

Minu vastus oli: "Ma olen sõna otseses mõttes mõlemad need inimesed." Selle asemel, et rääkida sellest, kuidas Rust on ravim, vaatame, miks ma arvan, et ta eksib monohoidlate osas. Natuke endast. Olen Chef Software CTO. Meil on umbes 100 inseneri, umbes 11–12 aasta tagune koodibaas ja 4 põhitoodet. Osa sellest koodist on polürepositooriumis (minu lähtepositsioon), osa monohoidlas (minu praegune asukoht).

Enne alustamist: iga argument, mille ma siin esitan, kehtib mõlemat tüüpi hoidlate kohta. Minu arvates pole tehnilist põhjust, miks peaksite valima ühte tüüpi hoidla teise asemel. Saate mis tahes lähenemisviisi tööle panna. Räägin sellest hea meelega, aga mind ei huvita kunstlikud tehnilised põhjused, miks üks on teisest parem.

Nõustun Matti mõtte esimese osaga:

Sest mastaapselt lahendab monohoidla kõik samad probleemid, mida lahendab polürepository, kuid samal ajal sunnib teid koodi tihedalt siduma ja nõuab uskumatuid jõupingutusi teie versioonihaldussüsteemi skaleeritavuse suurendamiseks.

Peate lahendama samad probleemid olenemata sellest, kas valite mono- või polürepositooriumi. Kuidas väljalaseid välja annate? Milline on teie lähenemine uuendustele? Tagasiühilduvus? Projektidevahelised sõltuvused? Millised arhitektuuristiilid on vastuvõetavad? Kuidas te oma ehitus- ja testimisinfrastruktuuri haldate? Nimekiri on lõputu. Ja te lahendate need kõik kasvades. Tasuta juustu pole olemas.

Ma arvan, et Matti argument sarnaneb vaadetega, mida jagavad paljud insenerid (ja juhid), keda ma austan. See ilmneb komponendi kallal töötava inseneri või komponendi kallal töötava meeskonna vaatenurgast. Kuulete selliseid asju nagu:

• Koodibaas on mahukas – ma ei vaja kogu seda rämpsu.
• Seda on raskem testida, sest ma pean testima kogu seda rämpsu, mida ma ei vaja.
• Väliste sõltuvustega on keerulisem töötada.
• Mul on vaja oma virtuaalset versioonikontrollisüsteemi.

Loomulikult on kõik need punktid õigustatud. See juhtub mõlemal juhul - polürepositooriumis on mul oma rämps, lisaks ehitamiseks vajaminevale... võib vaja minna ka muud rämpsu. Nii et ma "lihtsalt" loon tööriistad, mis kontrollivad kogu projekti. Või loon alammoodulitega võlts-monohoidla. Võiksime selle ümber käia terve päeva. Kuid ma arvan, et Matti argument jätab tähelepanuta peamise põhjuse, mille ma üsna tugevalt monorepositooriumi kasuks pöörasin:

See provotseerib suhtlemist ja näitab probleeme

Hoidlate eraldamisel tekitame de facto koordineerimise ja läbipaistvuse probleemi. See vastab sellele, kuidas me meeskondadest mõtleme (eriti sellele, kuidas üksikud liikmed neist mõtlevad): me vastutame teatud komponendi eest. Töötame suhtelises isolatsioonis. Minu meeskonna ja komponentide, mille kallal töötame, piirid on fikseeritud.

Kuna arhitektuur muutub keerukamaks, ei saa üks meeskond seda enam üksi hallata. Väga vähestel inseneridel on kogu süsteem peas. Oletame, et haldate jagatud komponenti A, mida kasutavad meeskonnad B, C ja D. Meeskond A tegeleb ümbertöötamisega, täiustab API-d ja muudab ka sisemist juurutamist. Seetõttu ei ole muudatused tagasiühilduvad. Mis nõu teil on?

• Otsige üles kõik kohad, kus vana API-t kasutatakse.
• Kas on kohti, kus uut API-t kasutada ei saa?
• Kas saate teisi komponente parandada ja testida, et veenduda, et need ei puruneks?
• Kas need meeskonnad saavad teie muudatusi praegu testida?

Pange tähele, et need küsimused ei sõltu hoidla tüübist. Peate leidma meeskonnad B, C ja D. Peate nendega rääkima, leidma aja, mõistma nende prioriteete. Vähemalt loodame, et teete seda.

Keegi ei taha seda tegelikult teha. See on palju vähem lõbus kui lihtsalt neetud API parandamine. Kõik on inimlik ja segane. Polürepositooriumis saate lihtsalt muudatusi teha, anda selle komponendiga töötavatele inimestele (tõenäoliselt mitte B, C või D) ülevaatamiseks ja edasi liikuda. Meeskonnad B, C ja D võivad praegu jääda oma praeguse versiooni juurde. Neid uuendatakse, kui nad mõistavad teie geniaalsust!

Monohoidlas on vastutus vaikimisi nihutatud. Meeskond A vahetab oma komponente ja, kui ei ole ettevaatlik, purustab kohe B, C ja D. See viib selleni, et B, C ja D ilmuvad A ukse taha ja imestavad, miks meeskond A koostu lõhkus. See õpetab A-le, et nad ei saa minu ülaltoodud loendit vahele jätta. Nad peavad rääkima sellest, mida nad tegema hakkavad. Kas B, C ja D saavad liikuda? Mis siis, kui B ja C saavad, kuid D oli tihedalt seotud vana algoritmi käitumise kõrvalmõjuga?

Siis peame rääkima, kuidas me sellest olukorrast välja tuleme:

1. Tugi mitmele sisemisele API-le ja märgib vana algoritmi aegunuks, kuni D saab selle kasutamise lõpetada.
2. Toetus mitmele versioonile, millest üks on vana liidesega, teine ​​uuega.
3. Viivitage A muudatuste avaldamist, kuni B, C ja D saavad selle samaaegselt vastu võtta.

Oletame, et oleme valinud 1, mitu API-d. Sel juhul on meil kaks koodiosa. Vana ja uus. Mõnes olukorras üsna mugav. Kontrollime vana koodi uuesti sisse, märgime selle aegunuks ja lepime D-tiimiga kokku eemaldamise ajakava. Põhimõtteliselt identne polü- ja monohoidlate puhul.

Mitme versiooni avaldamiseks vajame haru. Nüüd on meil kaks komponenti - A1 ja A2. Võistkonnad B ja C kasutavad A2 ja D kasutavad A1. Peame kõik komponendid olema vabastamiseks valmis, sest enne D edasiliikumist võib vaja minna turvavärskendusi ja muid veaparandusi. Polürepositooriumis saame peita selle pikaealise oksa sisse, mis tunneb end hästi. Monohoidlas sunnime koodi looma uues moodulis. Meeskond D peab siiski tegema muudatusi "vanas" komponendis. Kõik näevad siin makstavat kulu – meil on nüüd kaks korda rohkem koodi ja kõik veaparandused, mis kehtivad A1 ja A2 puhul, peavad kehtima mõlema puhul. Polürepositooriumis hargneva lähenemisviisiga on see peidetud cherry-picki taha. Hindame hindame väiksemaks, kuna puudub dubleerimine. Praktilisest seisukohast on hind sama: loote, vabastate ja hooldate kahte suures osas identset koodibaasi, kuni saate ühe neist kustutada. Erinevus seisneb selles, et monorepositooriumi puhul on see valu otsene ja nähtav. See on veelgi hullem ja see on hea.

Lõpuks jõudsime kolmanda punktini. Vabastamise viivitus. Võimalik, et A tehtud muudatused parandavad meeskonna A elu. Tähtis, kuid mitte kiireloomuline. Kas me saame viivitada? Polürepositooriumis surume seda artefakti kinnitamiseks. Loomulikult räägime sellest meeskonnale D. Jätkake lihtsalt vana versiooniga, kuni jõuate järele! See paneb sind mängima argpüksi. Meeskond A jätkab tööd oma komponendi kallal, ignoreerides tõsiasja, et meeskond D kasutab üha vananenud versiooni (see on meeskonna D probleem, nad on rumalad). Vahepeal räägib meeskond D halvasti meeskonna A hoolimatust suhtumisest koodi stabiilsusesse, kui nad sellest üldse räägivad. Kuud mööduvad. Lõpuks otsustab meeskond D uurida värskendamise võimalust, kuid A-l on ainult rohkem muudatusi. Meeskond A ei mäleta vaevu, millal või kuidas nad D purustasid. Uuendamine on valusam ja võtab kauem aega. Mis saadab selle prioriteetsete virna allapoole. Kuni päevani, mil A-s on turvaprobleem, mis sunnib meid haru looma. Meeskond A peab minema ajas tagasi, leidma punkti, mil D oli stabiilne, lahendama seal probleemi ja valmistama selle vabastamiseks valmis. See on inimeste de facto valik ja see on kaugelt halvim. Tundub, et see on hea nii meeskonnale A kui ka D-le, kuni suudame üksteist ignoreerida.

Monohoidlas pole kolmas tõesti valik. Olete sunnitud olukorraga tegelema kahel viisil. Peate nägema kahe väljalaskeharu omamise kulusid. Õppige end kaitsma uuenduste eest, mis rikuvad tagasiühilduvust. Aga mis kõige tähtsam: te ei saa vältida rasket vestlust.

Minu kogemuse järgi, kui meeskonnad saavad suureks, ei ole enam võimalik kogu süsteemi silmas pidada ja see on kõige olulisem osa. Peate parandama ebakõlade nähtavust süsteemis. Peate aktiivselt töötama selle nimel, et meeskonnad vaataksid oma komponentidelt kõrvale ning vaataksid teiste meeskondade ja tarbijate tööd.

Jah, saate luua tööriistu, mis proovivad lahendada polürepositooriumi probleemi. Kuid minu kogemus pideva tarnimise ja automatiseerimise õpetamisel suurettevõtetes ütleb mulle seda: vaikekäitumine ilma täiendavate tööriistade kasutamiseta on käitumine, mida ootate. Polühoidla vaikekäitumine on isolatsioon, see on kogu mõte. Monohoidla vaikekäitumine on jagatud vastutus ja läbipaistvus, see on kogu mõte. Mõlemal juhul kavatsen luua tööriista, mis silub karedad servad. Juhina valin ma iga kord monohoidla, sest tööriistad peavad tugevdama seda kultuuri, mida ma tahan, ja kultuur tuleb väikestest otsustest ja meeskonna igapäevatööst.

Küsitluses saavad osaleda ainult registreerunud kasutajad. Logi sissepalun.

Kes on suurimad fanaatikud? Toetajad:

• Monorepo

• Rust

• Vale küsitlus / mõlemad

33 kasutajat hääletas. 13 kasutajat jäi erapooletuks.

Allikas: www.habr.com