Përkthimi i artikullit është përgatitur për studentët e kursit «Praktikat dhe mjetet DevOps» në projektin arsimor OTUS.

Duhet të zgjidhni një monorepozit të vetëm, sepse sjellja që ai inkurajon në ekipet tuaja është transparenca dhe përgjegjësia kolektive, sidomos me rritjen e ekipeve. Megjithatë, do t'ju duhet të investoni në mjete, por gjithmonë është më mirë kur sjellja e paracaktuar është ajo që doni të shihni në ekipet tuaja.

Pse po flasim për këtë?

Matt Klein shkroi një artikull «Monorepos: Ju lutem, mos e bëni!» (shënim i përkthyesit: përkthimi në Habré «Monorepozitat: ju lutem mos e bëni»). Më pëlqen Matti, mendoj se është shumë i mençur dhe duhet ta lexoni pikëpamjen e tij. Fillimisht ai publikoi një anketë në Twitter:

Përkthimi:
Në këtë ditë të Vitit të Ri, unë do të debatoj se sa absurde janë monorepozitat. Vitit 2019 filloi pa zhurmë. Në këtë frymë, ju propozoj një anketë. Kush është një fanatik i madh? Mbështetësit:
— Monorepozita
— Rust
— Anketa e gabuar / të dyja

Përgjigja ime ishte: «Unë në fakt jam këto dy persona». Në vend që të flasim se sa është një drogë Rust, le të kuptojmë pse mendoj se ai është gabim për monorepozitat. Pak për veten time. Jam drejtor teknik në Chef Software. Kemi rreth 100 inxhinierë, një bazë kodi që është rreth 11-12 vjeçare dhe 4 produkte kryesore. Disa nga ky kod ndodhet në polirepozita (pozita ime fillestare), disa në monorepozita (pozita ime aktuale).

Para se të filloj: çdo argument që do të paraqes këtu do të aplikohet në të dy llojet e repozitave. Në mendimin tim, nuk ka arsye teknike për të cilat duhet të zgjidhni një lloj ose tjetrin. Ju mund ta bëni të funksionojë çdo qasje. Jam i lumtur të flas për këtë, por nuk më interesojnë arsyet teknike artificiale përse njëra është më e mirë se tjetra.

Jam dakord me pjesën e parë të pikëpamjes së Mattit:

Sepse në një shkallë të madhe, monorepozita do të zgjidhë të njëjtat probleme që zgjidh edhe polirepozita, por duke ju nxitur në lidhshmëri më të fortë të kodit tuaj dhe kërkuar përpjekje të pabesueshme për të rritur shkallëzueshmërinë e sistemit tuaj të kontrollit të versioneve.

Do të keni për të zgjidhur të njëjtat probleme, pavarësisht nëse zgjidhni një monorepo ose një polirepo. Si i lëshoni versionet? Çfarë qasje keni ndaj përditësimeve? Kompatibiliteti mbrapsht? Varësitë ndërmjet projekteve? Cilat stile arkitekturore janë të pranueshme? Si menaxhoni infrastrukturën tuaj të ndërtimit dhe testimit? Lista është e pafund. Dhe do i zgjidhni të gjitha këto gjatë rritjes tuaj. Qengji falas nuk ekziston.

Mendoj se argumenti i Matt është i ngjashëm me pikëpamjet që ndajnë shumë inxhinierë (dhe menaxherë) që respektoj. Kjo ndodh nga perspektiva e një inxhinieri që punon mbi një komponent, ose të një ekipi që punon mbi një komponent. Ju dëgjoni gjëra të tilla si:

Baza e kodit është e ngarkuar — nuk më nevojitet tërë kjo mbetje.
Është më e komplikuar të testohet, sepse duhet të kontrolloj gjithë këtë mbetje që nuk më nevojitet.
Është më e vështirë të punosh me varësitë e jashtme.
Më duhen sistemet e mia të menaxhimit të versioneve virtuale.

Pa dyshim, të gjitha këto pika janë të arsyeshme. Kjo ndodh në të dy rastet — në një polirepo unë kam mbetjet e mia, përveç atyre që nevojiten për ndërtim… Mund të kem nevojë edhe për mbetje të tjera. Prandaj «thjesht» krijoj mjete që bëjnë checkout të gjithë projektit. Ose krijoj një monorepo të rreme me submodule. Mund ta diskutojmë gjithë ditën rreth kësaj. Por mendoj se argumenti i Matt kalon përtej shkakut kryesor që unë e kam rrehur fort në favor të një monorepo:

Ai provokon komunikimin dhe tregon problemet.

Kur ndajmë repot, në fakt krijojmë një problem koordinimi dhe transparence. Kjo përputhet me mënyrën se si mendojmë për ekipet (sidomos se si mendojnë pjesëtarët e veçantë): ne jemi përgjegjës për një komponent të caktuar. Ne punojmë në një izolim relativ. Kufijtë janë të fiksohen në ekipin tim dhe komponentin(-et) mbi të cilat punojmë.

Kur arkitektura bëhet më e komplikuar, një ekip nuk mund ta menaxhojë më atë vetëm. Shumë pak inxhinierë e mbajnë tërë sistemin në mend. Le të themi se ju menaxhoni komponentin ortak A, i cili përdoret nga ekipet B, C dhe D. Ekipi A bën refaktorizimin, përmirëson API dhe ndryshon implementimin e brendshëm. Si rezultat, ndryshimet janë përsëri të pabashkëpunueshme. Çfarë këshilloni që t'i jepni?

Gjeni të gjitha vendet ku përdoret API i vjetër.
A ka vende ku nuk mund të përdoret API i ri?
A mund t'i korrigjoni dhe t'i testoni komponentët e tjerë për t'u siguruar që ata nuk do të prishen?
A mund të kontrollojnë këto ekipe ndryshimet tuaja tani?

Kujdes, këto pyetje nuk varen nga tipi i repositorit. Ju duhet të gjeni ekipet B, C dhe D. Ju duhet të flisni me ta, të kuptoni kohën dhe të kuptoni prioritetet e tyre. Të paktën shpresojmë që ju do ta bëni këtë.

Në të vërtetë, askush nuk do të donte ta bënte këtë. Kjo është shumë më pak e tërheqëse se thjesht të korrigjoni një API të tire. E gjithë kjo është njerëzore dhe e ndërlikuar. Në një poli-repositor, ju thjesht mund të bëni ndryshime, t'i jepni për kontroll atyre që punojnë mbi këtë komponent (ndoshta jo B, C ose D), dhe të shkoni përpara. Ekipet B, C dhe D mund të qëndrojnë në versionin e tyre aktual. Ata do të azhurnohen kur të kuptojnë gjenialitetin tuaj!

Në një mono-repositor, përgjegjësia lëviz automatikisht. Ekipi A ndërron komponentin e tij dhe, nëse nuk është i kujdesshëm, menjëherë prish B, C dhe D. Kjo bën që B, C dhe D të shfaqen në derën e A, duke e pyetur se pse ekipi A prishi ndërtimin. Kjo e mëson A se nuk mund të anashkalojnë listën time më sipër. Ata duhet të flasin për atë që do të bëjnë. A mund të përparojnë B, C dhe D? Çfarë nëse B dhe C mund, por D është ngushtësisht i lidhur me efektin anësor të sjelljes së algoritmit të vjetër?

Pastaj ne duhet të flasim për atë se si do të dalim nga kjo situatë:

Mbështetje për disa API të brendshëm, kurse algoritmi i vjetër do të shënohet si i vjetruar, derisa D të mund ta ndalojë përdorimin e tij.
Mbështetje për disa versione lëshimesh, një me ndërfaqen e vjetër, një me të re.
Shkakto vonesën e lëshimit të ndryshimeve A derisa B, C dhe D të mund ta pranojnë atë ndoshta njëkohësisht.

Le të themi se zgjodhëm 1, disa API. Në këtë rast, ne kemi dy copa kodi. Të vjetra dhe të reja. Mjaft të përshtatshme në disa situata. Ne e kthejmë kodin e vjetër prapa, e shënojmë si të tejkaluar (deprecated) dhe bie dakord me ekipin D për një orar për heqjen e tij. Në thelb është identike për poli dhe për monorepozitorin.

Për botimin e disa versioneve na nevojitet një dege. Tani kemi dy komponentë — A1 dhe A2. Ekipet B dhe C përdorin A2, ndërsa D përdor A1. Na nevojitet që çdo komponent të jetë i gatshëm për botim, sepse para se D të mund të avancojë, mund të kërkohen përditësime sigurie dhe rregullime të tjera gabimesh. Në poli-repozitor, ne mund ta fshehim këtë në një degë me jetëgjatësi, e cila ndjehet mirë. Në monorepozitor ne e krijojmë me forcë kodin në një modul të ri. Ekipit D atij do t'i duhet akoma të bëjë ndryshime në komponentin "e vjetër". Çdo njeri mund të shohë koston që po paguajmë këtu — tani kemi dyfish më shumë kod, dhe çdo rregullim të gabimeve që aplikohet për A1 dhe A2 duhet të aplikohet për të dy. Me qasjen e përdorimit të degëve në poli-repozitor, kjo fshihet pas cherry-pick. Ne e konsiderojmë kostën si më të vogël, sepse atje nuk ka përsëritje. Nga pikëpamja praktike, kostoja është e njëjtë: do të krijoni, botoni dhe mbani dy baza kodi, kryesisht identike, deri sa të mund të hiqni një nga to. Diferenca është se në monorepozitor, kjo dhimbje është e drejtpërdrejtë dhe është në sy. Kjo është edhe më keq, dhe kjo është mirë.

Më në fund, arritëm në pikën e tretë. Vonesa në lëshim. Është e mundur që ndryshimet e B-së do ta përmirësojnë jetën e ekipit A. E rëndësishme, por jo urgjente. A mund të vonojmë thjesht? Në monorepozitorin, ne e nxisim këtë për të konsoliduar artefaktin. Sigurisht, ne e diskutojmë këtë me ekipin D. Thjesht mbetni me versionin e vjetër derisa të përparoni! Kjo i hap rrugë një loje frikacaku. Ekipi A vazhdon të punojë mbi komponentin e tij, duke injoruar faktin që ekipi D po përdor një version gjithnjë e më të vjetruar (është problemi i ekipit D, ata janë të paqëndrueshëm). Në të njëjtën kohë, ekipi D flet keq për kujdesin e pandjeshëm të ekipit A ndaj stabilitetit të kodit, nëse flasin ndonjëherë për të. Kalojnë muaj. Në fund, ekipi D vendos të shqyrtojë mundësinë e përditësimit, por ndryshimet në A janë rritur vetëm. Ekipi A ia del me vështirësi të kujtojë se kur dhe si e prishën D. Përditësimi bëhet më i dhimbshëm dhe do të marrë më shumë kohë. Çka e vendos atë më poshtë në prioritetet. Deri në atë ditë, kur na lind një problem sigurie në A, që na detyron të bëjmë një degëzim. Ekipi A duhet të kthehet pas në kohë, të gjejë momentin kur D ishte i qëndrueshëm, të rregullojë problemin atje dhe ta bëjë atë gati për lëshim. Kjo është një zgjedhje de facto që e bëjnë njerëzit, dhe padyshim është më e keqja. Duket se është mirë si për ekipin A ashtu edhe për D, derisa mund të injorojmë njëri-tjetrin.

Në monorepozitor, opsioni i tretë – në të vërtetë nuk është një mundësi. Ju e keni të detyrueshme të merret me situatën në një nga dy mënyrat. Duhet të shihni kostot e të pasurit dy dega lëshimi. Të mësoni të mbroni veten nga përditësimet që shkatërrojnë kompatibilitetin mbrapa. Por gjëja kryesore: nuk mund të shmangni një bisedë të vështirë.

Nga përvoja ime, kur ekipet bëhen të mëdha, nuk ka më mundësi për të mbajtur mend të gjithë sistemin, dhe kjo është pjesa më e rëndësishme. Ju duhet të përmirësoni dukshmërinë e mosmarrëveshjeve në sistem. Ju duhet të punoni aktivisht për t'i detyruar ekipet të heqin syrin nga komponentët e tyre dhe të shohin punën e ekipet të tjera dhe të konsumatorëve.

Po, ju mund të krijoni mjete që përpiqen të zgjidhin problemin e poli-repozitorëve. Por përvoja ime me trajnimin e dorëzimit të vazhdueshëm dhe automatizimin në ndërmarrje të mëdha më thotë se: sjellja e paracaktuar pa përdorimin e mjeteve shtesë është ajo sjellje që prisni të shihni. Sjellja e poli-repozitorëve në parazgjedhje është izolimi, kjo është e gjithë kuptimi. Sjellja e monorepozitorëve në parazgjedhje është përgjegjësia e përbashkët dhe transparenca, kjo është e gjithë kuptimi. Në të dy rastet, unë do të krijoj një mjet që do të lehtësojë këndvështrimet e ashpra. Si lider, do të zgjedh gjithmonë monorepozitorin, sepse mjetet duhet të forcojnë kulturën që unë dua, dhe kultura rrjedh nga vendimet e vogla dhe puna e përditshme e ekipit.

Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. Hyni, ju lutem.