Artikli tõlge on ette valmistatud kursuse üliõpilaste jaoks «DevOps praktikad ja tööriistad» OTUS hariduse projektis.

Te peate valima monorepo, kuna see soodustab teie meeskondades läbipaistvust ja kollektiivset vastutust, eriti meeskondade kasvu korral. 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: Palun ärge tehke seda!» (tõlkija märkuseks: tõlge Habr's) «Monorepos: palun ärge tehke seda»). Mulle meeldib Matt, ma arvan, et ta on väga tark ja te peaksite lugema tema seisukohta. Alguses avaldas ta Twitteris küsitluse:

Tõlge:
Selle uusaasta päeva puhul kavatsen vaielda, kui absurdne on monoreposid kasutada. 2019. aasta algas märkamatult. Sellega seoses pakun teile küsitluse. Kes on suured fännid? Pooldajad:
— Monorepo
— Rustis
— Vale küsitlus / mõlemad

Minu vastus oli: «Ma olen sisuliselt mõlemad need inimesed». Selle asemel, et rääkida, kui uimastav on Rust, vaatame, miks ma arvan, et ta eksib monoreposide osas. Natuke enda kohta. Olen Chef Software'i tehniline direktor. Meil on umbes 100 inseneri, koodibaas, mis on umbes 11–12 aastat vana, ja 4 peamist toodet. Osad sellest koodist asuvad polirepos (minu algne positsioon), osad monorepos (minu praegune positsioon).

Enne kui hakkan: iga argument, mida siin esitlen, kehtib mõlema tüübi hoidlate kohta. Minu arvates ei ole tehnilisi põhjuseid, miks peaksite valima ühte tüüpi hoidla üle teise. Saate mistahes lähenemist tööle panna. Olen valmis sellest rääkima, kuid mind ei huvita kunstlikud tehnilised põhjused, miks üks ületab teist.

Ma nõustun Matti seisukoha esimese osaga:

Sest suurel skaalal lahendab monorepo kõik need samad probleemid, mida lahendab ka polirepo, kuid samal ajal provotseerib teid oma koodi tugevale sidususele ja nõuab uskumatuid jõupingutusi teie versioonihaldus süsteemi skaleeritavuse suurendamiseks.

Teil peate lahendama samu probleeme, olgu te valikuks monoreposiitor või poli-reposiitor. Kuidas te väljalaskeid välja annate? Milline on teie lähenemine uuendustele? Tagasipöördumine? Projekti vahelised sõltuvused? Millised arhitektuurilised stiilid on vastuvõetavad? Kuidas te haldate oma ehitus- ja testimisstruktuuri? Loend on lõpmatu. Ja te peate neid kõiki lahendama, kui kasvate. Tasuta juustu ei ole.

Ma arvan, et Matti argument sarnaneb paljude inseneride (ja juhtide) vaadete kohale, keda ma austan. See tuleb inseneri perspektiivist, kes töötab komponendi kallal, või meeskonna perspektiivist, mis töötab komponendi kallal. Te kuulete selliseid asju nagu:

Koodibaas on mahukas — mulle ei ole kogu see kraam vajalik.
Seda on keerulisem testida, kuna pean kontrollima kogu seda kraami, mis mulle ei ole vajalik.
Keerulisem on töötada väliste sõltuvustega.
Mul on vaja oma versioonihaldussüsteeme.

Ilmselt on kõik need punktid põhjendatud. See toimub mõlemas olukorras — poli-reposiitoris on mul oma kraam, peale selle, mida on vaja ehitamiseks… Võib-olla pean veel rohkemat kraami. Seetõttu loon "lihtsalt" tööriistu, mis teevad kogu projekti lahti. Või loon vale monoreposiitori alamsubmodulitega. Me võiksime sellega terve päeva ringi käia. Kuid ma arvan, et Matti argument jätab tähelepanuta peamise põhjuse, mida ma tõeliselt muutsin monoreposiitori kasuks:

See provotseerib suhtlemist ja näitab probleeme.

Kui me jagame repod, loome de facto koordineerimise ja läbipaistvuse probleemi. See vastab sellele, kuidas me mõtleme meeskondadele (eriti sellele, kuidas eraldi liikmed neid mõistavad): me vastutame teatud komponendi eest. Me töötame suhtelises isolatsioonis. Piirid on fikseeritud minu meeskonna ja komponendi (-de) vahel, millega me töötame.

Kui arhitektuur muutub keerulisemaks, ei saa üks meeskond enam üksi sellega hakkama. Ainult väga vähesed insenerid suudavad kogu süsteemi oma peas hoida. Oletame, et te haldate ühiseid komponente A, mida kasutavad meeskonnad B, C ja D. Meeskond A viib läbi refaktoreerimise, parendab API-d ning muudab sisemise teostuse. Selle tulemusena on muudatused tagasisidekõlbmatud. Millist nõu annate?

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

Pange tähele, et need küsimused ei sõltu hoidla tüübist. Teil on vaja leida meeskonnad B, C ja D. Te peate nendega rääkima, välja selgitama nende ajakava ja prioriteedid. Loodame, et teete seda.

Tegelikult ei taha keegi sellega tegeleda. See on palju vähem põnev kui lihtsalt kuradi API parandamine. Kõik see on inimese ja keeruline. Polühoidlas saate lihtsalt muudatusi teha, lasta need üle vaadata neil, kes selle komponendi kallal töötavad (tõenäoliselt mitte B, C või D), ja edasi liikuda. Meeskonnad B, C ja D saavad hetkel jääda oma praegusele versioonile. Nad uuendavad, kui nad teie geniaalsust tunnustavad!

Monorepois nihkub vastutus vaikimisi. Meeskond A muudab oma komponenti ja kui nad ei ole ettevaatlikud, rikuvad nad kohe B, C ja D. See toob kaasa selle, et B, C ja D ilmuvad A uksele ja imestavad, miks meeskond A rikkus koostamist. See õpetab A-le, et nad ei saa minu ülaltoodud loendit vahele jätta. Nad peavad rääkima, millest nad kavatsevad teha. Kas B, C ja D saavad edasi liikuda? Mis siis, kui B ja C saavad, kuid D on tihedalt seotud vana algoritmi külgefektidega?

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

Toetage mitut sisemist API-d, samal ajal kui vana algoritm on märgistatud aegunuks, kuni D suudab selle kasutamise lõpetada.
Toetage mitut versiooni, üks vanadele liidesele, teine uuele.
Kasutage muudatuste A väljaandmiseks viivitust kuni hetkeni, mil B, C ja D saavad selle koos vastu võtta.

Oletame, et valisime 1, mitu API-d. Sel juhul on meil kaks tükki koodi. Vanem ja uuem. See on mõnes olukorras üsna mugav. Tagastame vanema koodi, märgime selle kasutusest kõrvaldatuks (deprecated) ja kooskõlastame selle eemaldamise ajakava meeskonnaga D. Sisuliselt on see sama nii poli kui ka monoreposiidi puhul.

Mitme versiooni vabastamiseks meil on vajalik haru. Nüüd on meil kaks komponenti — A1 ja A2. Meeskonnad B ja C kasutavad A2, samas kui D kasutab A1. Me vajame, et iga komponent oleks vabastamiseks valmis, kuna enne kui D saab edasi liikuda, võivad olla vajalikud turvauuendused ja teiste tõrgete parandused. Polireposiitides saame selle peita pikaajalisse harusse, mis toimib hästi. Monorepositories sunnime me koodi loomist uues moodulis. Meeskond D peab endiselt tegema muudatusi „vana“ komponendi osas. Kõik saavad näha hinda, mida me siin maksame — meil on nüüd kaks korda rohkem koodi ja kõik parandused, mis rakendatakse A1 ja A2-le, peavad olema rakendatud ka mõlemale. Harudega töötamise lähenemisega polireposiitides on see peidetud cherry-pick'i alla. Peame hinda madalamaks, kuna seal ei ole dubleerimist. Praktikas on hind sama: peate looma, vabastama ja toetama kahte, põhimõtteliselt identset koodibaasi, kuni suudate ühe neist eemaldada. Erinevus on see, et monoreposiis tagab, et see valu on otsene ja nähtav. See on veel hullem ja see on hea.

Lõpuks oleme jõudnud kolmanda punktini. Väljalaske tähtaeg. On võimalik, et A poolt tehtud muudatused parandavad A tiimi tööd. Oluline, aga mitte kiire. Kas me saame lihtsalt oodata? Polürepoositooriumis suuname seda artefakti kindlakstegemise suunas. Loomulikult räägime sellest D tiimile. Lihtsalt jääge vana versiooni juurde, kuni catch-up teete! See valmistab ette mängu kartlikuks. A tiim töötab endiselt oma komponendi kallal, ignoreerides fakti, et D tiim kasutab üha aegumatumat versiooni (see on D tiimi probleem, nad on lollid). Samal ajal räägib D tiim halvasti A tiimi kohatu suhtumise üle koodi stabiilsusesse, kui nad sellest üldse räägivad. Kuu jooksul möödub. Lõpuks otsustavad D tiim vaadata uuendamise võimalust, aga A-s on muudatusi ainult juurde tulnud. A tiim ei mäleta peaaegu, millal ja kuidas nad D-t lõhkusid. Uuendamine on valusam ja võtab rohkem aega. Mis tõukab selle allapoole prioriteetide järjestust. Kuni päeva, mil meil tekib A-s turvaprobleem, mis sunnib meid haru tegema. A tiim peab tagasi minema ajas, leidma hetke, mil D oli stabiilne, parandama seal probleemi ja valmistama selle väljalaskeks. See on de-fakto valik, mille inimesed teevad, ja see on kindlasti halvim. See tundub olevat hea nii A tiimi kui ka D jaoks, kuni me saame üksteist ignoreerida.

Monorepositoorses kolmas ei ole tõeliselt variant. Sa pead toimetulema olukorraga kahest viisist. Sa pead nägema kahe väljalaske haru pidamise kulusid. Õppima end kaitsma tagasipöördumisuuenduste vastu. Aga kõige tähtsam: sa ei pääse keerulisest vestlusest.

Minu kogemuse põhjal, kui tiimid kasvavad, kaob võime hoida kogu süsteemi meeles, ja see on kõige olulisem osa. Pead parandama vastuolude nähtavust süsteemis. Pead aktiivselt töötama, et sundida tiime oma komponente vaatamast eemale ning vaatama teiste tiimide ja tarbijate tööd.

Jah, te saate luua tööriistu, mis püüavad probleemset polirepositooriumi lahendada. Kuid minu kogemus pideva tarnimise ja automatiseerimise alal suurtes ettevõtetes ütleb mulle järgmist: vaikimisi käitumine ilma täiendavate tööriistadeta on see, mida te eeldate nägevat. Polirepositooriumi vaikimisi käitumine on isoleerimine, see on kogu mõte. Monorepositooriumi vaikimisi käitumine on ühine vastutus ja läbipaistvus, see on kogu mõte. Mõlemal juhul kavatse ma luua tööriista, mis aitab teravaid nurki siluda. Juhtkonnana valin ma alati monorepositooriumi, sest tööriistad peaksid tugevdama kultuuri, mida ma soovin, ja kultuur tuleneb pisikestest otsustest ja meeskonna igapäevasest tööst.

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