Kurso studentams parengto straipsnio vertimas „DevOps praktika ir įrankiai“ OTUS edukaciniame projekte.

Turėtumėte pasirinkti vieną saugyklą, nes jos skatinamas elgesys jūsų komandose yra skaidrumas ir bendra atsakomybė, ypač komandoms augant. Bet kuriuo atveju turėsite investuoti į įrankius, bet visada geriau, jei numatytoji elgsena yra tokia, kokios norite savo komandose.

Kodėl mes apie tai kalbame?

Mattas Kleinas parašė straipsnį "Monorepos: prašau ne!"  (vertėjo pastaba: vertimas apie Habré „Vienos saugyklos: prašome nedaryti“). Man patinka Mattas, manau, kad jis labai protingas, todėl turėtumėte perskaityti jo požiūrį. Iš pradžių jis paskelbė apklausą „Twitter“:

Vertimas:
Šią Naujųjų metų dieną ginčysiuosi, kokios juokingos yra monorepozitorijos. 2019-ieji prasidėjo ramiai. Atsižvelgdamas į tai, siūlau jums atlikti apklausą. Kas yra didieji fanatikai? Rėmėjai:
- Monorepo
- Rūdys
- Neteisinga apklausa / abu

Mano atsakymas buvo: „Aš tiesiog esu iš tų žmonių“. Užuot kalbėję apie tai, kaip Rust yra narkotikas, pažiūrėkime, kodėl manau, kad jis klysta dėl monorepozitorių. Šiek tiek apie save. Esu Chef Software CTO. Turime apie 100 inžinierių, kodų bazę, siekiančią maždaug 11–12 metų, ir 4 pagrindinius produktus. Dalis šio kodo yra daugialypėje saugykloje (mano pradinė padėtis), dalis yra monorepozitorijoje (mano dabartinė padėtis).

Prieš pradėdamas: kiekvienas čia pateiktas argumentas bus taikomas abiejų tipų saugykloms. Mano nuomone, nėra jokios techninės priežasties, kodėl turėtumėte pasirinkti vieno tipo saugyklą, o ne kitą. Galite pritaikyti bet kokį požiūrį. Aš mielai apie tai kalbu, bet manęs nedomina dirbtinės techninės priežastys, kodėl vienas pranašesnis už kitą.

Sutinku su pirmąja Mato teiginio dalimi:

Kadangi masteliu monosaugykla išspręs visas tas pačias problemas, kurias išsprendžia daugialypė saugykla, tačiau tuo pačiu privers jus glaudžiai susieti savo kodą ir pareikalaus neįtikėtinų pastangų, kad padidintumėte versijų valdymo sistemos mastelį.

Turėsite išspręsti tas pačias problemas, nepriklausomai nuo to, ar pasirinksite mono saugyklą, ar daugialypės terpės saugyklą. Kaip leidžiate leidimus? Koks jūsų požiūris į atnaujinimus? Atgalinis suderinamumas? Kryžminės projektų priklausomybės? Kokie architektūros stiliai yra priimtini? Kaip valdote savo kūrimo ir testavimo infrastruktūrą? Sąrašas yra begalinis. Ir jūs juos visus išspręsite augdami. Nemokamo sūrio nėra.

Manau, kad Matto argumentai yra panašūs į daugelio inžinierių (ir vadovų), kuriuos gerbiu, nuomonę. Tai atsitinka su komponentu dirbančio inžinieriaus arba su komponentu dirbančios komandos požiūriu. Jūs girdite tokius dalykus:

• Kodų bazė yra didelė – man nereikia viso šito šlamšto.
• Sunkiau išbandyti, nes turiu išbandyti visą šitą šlamštą, kurio man nereikia.
• Sunkiau dirbti su išorinėmis priklausomybėmis.
• Man reikia savo virtualios versijos valdymo sistemos.

Žinoma, visi šie punktai yra pagrįsti. Taip nutinka abiem atvejais - polirepozitorijoje turiu savo šlamštą, be to, kuris reikalingas statybai... Gali prireikti ir kitokio šlamšto. Taigi aš „paprasčiausiai“ kuriu įrankius, kurie tikrina visą projektą. Arba sukuriu netikrą monorepozitoriją su submoduliais. Galėtume vaikščioti aplink tai visą dieną. Tačiau manau, kad Mato argumentas praleidžia pagrindinę priežastį, kurią gana stipriai paverčiau monorepozitorijos naudai:

Tai provokuoja bendravimą ir parodo problemas

Kai atskiriame saugyklas, sukuriame de facto koordinavimo ir skaidrumo problemą. Tai atitinka mūsų mąstymą apie komandas (ypač atskirų narių mąstymą apie jas): mes esame atsakingi už tam tikrą komponentą. Dirbame santykinai izoliuotai. Mano komandos ir komponentų, su kuriais mes dirbame, ribos yra nustatytos.

Kadangi architektūra tampa sudėtingesnė, viena komanda nebegali jos valdyti viena. Labai mažai inžinierių turi visą sistemą savo galvoje. Tarkime, kad valdote bendrinamą komponentą A, kurį naudoja komandos B, C ir D. A komanda pertvarko, tobulina API ir taip pat keičia vidinį diegimą. Dėl to pakeitimai nėra suderinami atgal. Kokių patarimų turite?

• Raskite visas vietas, kur naudojama senoji API.
• Ar yra vietų, kur negalima naudoti naujos API?
• Ar galite pataisyti ir išbandyti kitus komponentus, kad įsitikintumėte, jog jie nesulūžta?
• Ar šios komandos gali išbandyti jūsų pakeitimus dabar?

Atkreipkite dėmesį, kad šie klausimai nepriklauso nuo saugyklos tipo. Reikės susirasti komandas B, C ir D. Reikės su jomis pasikalbėti, išsiaiškinti laiką, suprasti jų prioritetus. Bent jau mes tikimės, kad tai padarysite.

Niekas tikrai nenori to daryti. Tai daug mažiau smagu nei tiesiog taisyti prakeiktą API. Visa tai žmogiška ir netvarkinga. Daugialaikėje saugykloje galite tiesiog atlikti pakeitimus, duoti jį žmonėms, dirbantiems su tuo komponentu (tikriausiai ne B, C ar D), peržiūrėti ir judėti toliau. B, C ir D komandos kol kas gali likti prie dabartinės versijos. Jie bus atnaujinti, kai suvoks jūsų genialumą!

Vienoje saugykloje atsakomybė perkeliama pagal numatytuosius nustatymus. A komanda pakeičia savo komponentą ir, jei neatsargi, iškart sulaužo B, C ir D. Dėl to B, C ir D pasirodo prie A durų ir stebisi, kodėl A komanda sulaužė mazgą. Tai moko A, kad jie negali praleisti mano sąrašo aukščiau. Jie turi kalbėti apie tai, ką ketina daryti. Ar gali B, C ir D judėti? O kas, jei B ir C gali, bet D buvo glaudžiai susiję su šalutiniu senojo algoritmo elgesio poveikiu?

Tada turime kalbėti apie tai, kaip išeisime iš šios situacijos:

1. Kelių vidinių API palaikymas ir pažymės senąjį algoritmą kaip nebenaudojamą, kol D nustos jį naudoti.
2. Kelių leidimo versijų palaikymas, viena su senąja sąsaja, kita su nauja.
3. Atidėkite A pakeitimų paskelbimą, kol B, C ir D galės juos priimti vienu metu.

Tarkime, kad pasirinkome 1, kelias API. Šiuo atveju turime dvi kodo dalis. Senas ir naujas. Gana patogu kai kuriose situacijose. Vėl patikriname seną kodą, pažymime jį kaip nebenaudojamą ir su D komanda susitariame dėl pašalinimo grafiko.

Norėdami išleisti kelias versijas, mums reikia filialo. Dabar turime du komponentus - A1 ir A2. B ir C komandos naudoja A2, o D – A1. Mums reikia, kad kiekvienas komponentas būtų paruoštas išleidimui, nes gali prireikti saugos naujinimų ir kitų klaidų pataisų, kad D galėtų judėti į priekį. Daugialaikėje saugykloje galime tai paslėpti ilgaamžėje šakoje, kuri jaučiasi gerai. Vienoje saugykloje priverčiame kodą sukurti naujame modulyje. Komanda D vis tiek turės atlikti „senojo“ komponento pakeitimus. Čia visi gali matyti, kiek kainuoja mūsų – dabar turime dvigubai daugiau kodo, o bet kokie klaidų pataisymai, taikomi A1 ir A2, turi būti taikomi abiem. Taikant šakojimo metodą daugialypės terpės saugykloje, tai yra paslėpta už vyšnių skynimo. Manome, kad kaina yra mažesnė, nes nėra dubliavimo. Praktiniu požiūriu kaina yra tokia pati: sukursite, išleisite ir prižiūrėsite dvi iš esmės identiškas kodų bazes, kol galėsite ištrinti vieną iš jų. Skirtumas tas, kad naudojant monorepozitoriją šis skausmas yra tiesioginis ir matomas. Tai dar blogiau, ir tai yra gerai.

Galiausiai pasiekėme trečią tašką. Išleidimo delsa. Gali būti, kad A padaryti pakeitimai pagerins A komandos gyvenimą. Svarbu, bet ne skubu. Ar galime tiesiog atidėti? Daugialaikėje saugykloje pastumiame tai, kad prisegtume artefaktą. Žinoma, mes tai sakome komandai D. Tiesiog laikykitės senosios versijos, kol pasieksite! Tai paskatins jus žaisti bailį. A komanda ir toliau dirba su savo komponentu, nekreipdama dėmesio į tai, kad komanda D naudoja vis labiau pasenusią versiją (tai yra komandos D problema, jie kvaili). Tuo tarpu D komanda prastai kalba apie A komandos nerūpestingą požiūrį į kodo stabilumą, jei apskritai apie tai kalba. Praeina mėnesiai. Galiausiai komanda D nusprendžia atnaujinti, bet A turi tik daugiau pakeitimų. A komanda beveik neprisimena, kada ir kaip sulaužė D. Atnaujinimas yra skausmingesnis ir užtruks ilgiau. Dėl to jis nusiunčiamas toliau pirmenybėse. Iki tos dienos, kai A iškyla saugumo problema, dėl kurios turime sukurti filialą. A komanda turi grįžti į praeitį, rasti tašką, kai D buvo stabilus, išspręsti problemą ir paruošti ją paleidimui. Tai de facto žmonių pasirinkimas, ir tai yra pats blogiausias. Atrodo, kad tai naudinga tiek A, tiek D komandai, kol galime vienas kitą ignoruoti.

Vienoje saugykloje trečiasis tikrai nėra pasirinkimas. Esate priversti susidoroti su situacija vienu iš dviejų būdų. Turite pamatyti dviejų išleidimo šakų išlaidas. Išmokite apsisaugoti nuo atnaujinimų, kurie pažeidžia atgalinį suderinamumą. Bet svarbiausia: negalite išvengti sunkaus pokalbio.

Mano patirtis rodo, kad kai komandos tampa didelės, nebeįmanoma turėti omenyje visos sistemos, ir tai yra svarbiausia. Turite pagerinti nesantaikos matomumą sistemoje. Turite aktyviai dirbti, kad komandos atsigręžtų nuo savo komponentų ir pažvelgtų į kitų komandų ir vartotojų darbą.

Taip, galite sukurti įrankius, kurie bando išspręsti daugialypės terpės problemą. Tačiau mano patirtis, mokant nuolatinį pristatymą ir automatizavimą didelėse įmonėse, man sako: numatytasis elgesys nenaudojant papildomų įrankių yra elgesys, kurio tikitės. Numatytasis kelių saugyklos elgesys yra izoliavimas, tai yra visa esmė. Numatytasis monorepozitorijos elgesys yra bendra atsakomybė ir skaidrumas, tai yra visa esmė. Abiem atvejais ketinu sukurti įrankį, kuris išlygins šiurkščius kraštus. Aš, kaip vadovas, kiekvieną kartą rinksiuosi vieną saugyklą, nes įrankiai turi sustiprinti norimą kultūrą, o kultūra kyla iš mažų sprendimų ir kasdieninio komandos darbo.

Apklausoje gali dalyvauti tik registruoti vartotojai. Prisijungti, Prašau.

Kas yra didžiausi fanatikai? Rėmėjai:

• Monorepo

• Rūdys

• Neteisinga apklausa / abu

Balsavo 33 vartotojai. 13 vartotojų susilaikė.

Šaltinis: www.habr.com