Përkthimi i artikullit të përgatitur për studentët e kursit "Praktikat dhe mjetet e DevOps" në projektin edukativ OTUS.

Ju duhet të zgjidhni një monodepo sepse sjellja që ajo promovon në ekipet tuaja është transparencë dhe përgjegjësi e përbashkët, veçanërisht kur ekipet rriten. Sido që të jetë, do të duhet të investoni në vegla pune, por është gjithmonë më mirë nëse sjellja e paracaktuar është sjellja që dëshironi në komandat tuaja.

Pse po flasim për këtë?

Matt Klein shkroi artikullin "Monorepos: Ju lutem mos!"  (shënim i përkthyesit: përkthim në Habré "Monorepositories: ju lutem mos"). Më pëlqen Matt, mendoj se ai është shumë i zgjuar dhe duhet të lexoni këndvështrimin e tij. Ai fillimisht e postoi sondazhin në Twitter:

përkthim:
Këtë ditë të Vitit të Ri, unë do të debatoj se sa qesharake janë monorepositories. 2019 nisi i qetë. Në frymën e kësaj, unë ju ofroj një sondazh. Kush janë fanatikët e mëdhenj? Mbështetësit:
- Monorepo
- Ndryshk
- Sondazh i pasaktë / të dyja

Përgjigja ime ishte, "Unë jam fjalë për fjalë të dy ata njerëz." Në vend që të flasim për faktin se Rust është një drogë, le të shohim pse mendoj se ai e ka gabim në lidhje me monorepositorët. Pak për veten tuaj. Unë jam CTO i Chef Software. Ne kemi rreth 100 inxhinierë, një bazë kodi që daton rreth 11-12 vjet dhe 4 produkte kryesore. Një pjesë e këtij kodi është në një polidepo (pozicioni im fillestar), disa janë në një depo (pozicioni im aktual).

Përpara se të filloj: çdo argument që bëj këtu do të zbatohet për të dy llojet e depove. Sipas mendimit tim, nuk ka asnjë arsye teknike pse duhet të zgjidhni një lloj depoje mbi një tjetër. Ju mund të bëni çdo qasje të funksionojë. Unë jam i lumtur të flas për këtë, por nuk më interesojnë arsyet teknike artificiale pse njëra është superiore ndaj tjetrës.

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

Sepse në shkallë, një monorepozitor do të zgjidhë të gjitha problemet e njëjta që zgjidh një polidepo, por në të njëjtën kohë do t'ju detyrojë të lidhni fort kodin tuaj dhe që kërkon përpjekje të jashtëzakonshme për të rritur shkallëzueshmërinë e sistemit tuaj të kontrollit të versionit.

Do t'ju duhet të zgjidhni të njëjtat probleme, pavarësisht nëse zgjidhni një monodepo ose një polidepo. Si i lëshoni publikimet? Cila është qasja juaj ndaj përditësimeve? Përputhshmëri e prapambetur? Varësi ndër projekte? Cilat stile arkitekturore janë të pranueshme? Si e menaxhoni infrastrukturën tuaj të ndërtimit dhe testimit? Lista është e pafund. Dhe do t'i zgjidhni të gjitha ndërsa rriteni. Nuk ka djathë falas.

Unë mendoj se argumenti i Matt është i ngjashëm me pikëpamjet e përbashkëta nga shumë inxhinierë (dhe menaxherë) që unë i respektoj. Kjo ndodh nga këndvështrimi i inxhinierit që punon në komponent ose ekipit që punon në komponent. Ju dëgjoni gjëra të tilla si:

• Baza e kodit është e rëndë - nuk më duhen gjithë këto mbeturina.
• Është më e vështirë të provosh sepse më duhet të testoj gjithë këtë mbeturinë që nuk më nevojitet.
• Është më e vështirë të punosh me varësi të jashtme.
• Më duhen sistemet e mia të kontrollit të versionit virtual.

Natyrisht, të gjitha këto pika janë të justifikuara. Kjo ndodh në të dyja rastet - në polirepozitor kam mbeturinat e mia, përveç atij që nevojitet për ndërtimin... Mund të më duhen edhe junk të tjera. Kështu që unë "thjesht" krijoj mjete që kontrollojnë të gjithë projektin. Ose krijoj një monodepo të rreme me nënmodule. Ne mund të ecnim rreth kësaj gjatë gjithë ditës. Por mendoj se argumentit të Matt i mungon arsyeja kryesore, të cilën e ktheva shumë në favor të monorepositorit:

Ajo provokon komunikim dhe shfaq probleme

Kur ne ndajmë depot, ne krijojmë një problem de facto të koordinimit dhe transparencës. Kjo korrespondon me mënyrën se si ne mendojmë për ekipet (veçanërisht mënyrën se si anëtarët individualë mendojnë për to): ne jemi përgjegjës për një komponent të caktuar. Ne punojmë në izolim relativ. Kufijtë janë të fiksuar në ekipin tim dhe komponentin(et) mbi të cilët po punojmë.

Ndërsa arkitektura bëhet më komplekse, një ekip nuk mund ta menaxhojë më vetëm. Shumë pak inxhinierë kanë të gjithë sistemin në kokën e tyre. Le të themi se ju menaxhoni një komponent të përbashkët A që përdoret nga Ekipet B, C dhe D. Ekipi A po rifaktoron, përmirëson API-në dhe gjithashtu ndryshon zbatimin e brendshëm. Si rezultat, ndryshimet nuk janë të pajtueshme. Çfarë këshille keni?

• Gjeni të gjitha vendet ku përdoret API-ja e vjetër.
• A ka vende ku API-ja e re nuk mund të përdoret?
• A mund të rregulloni dhe testoni përbërës të tjerë për t'u siguruar që nuk prishen?
• A mund të testojnë këto ekipe ndryshimet tuaja tani?

Ju lutemi vini re se këto pyetje janë të pavarura nga lloji i depove. Do t'ju duhet të gjeni ekipet B, C dhe D. Do t'ju duhet të flisni me ta, të gjeni kohën, të kuptoni prioritetet e tyre. Të paktën shpresojmë se do ta bëni.

Askush me të vërtetë nuk dëshiron ta bëjë këtë. Kjo është shumë më pak argëtuese sesa thjesht rregullimi i API-së së mallkuar. Është e gjitha njerëzore dhe e çrregullt. Në një polidepo, thjesht mund të bëni ndryshime, t'ua jepni njerëzve që punojnë në atë komponent (ndoshta jo B, C ose D) për shqyrtim dhe të vazhdoni. Ekipet B, C dhe D thjesht mund të qëndrojnë me versionin e tyre aktual për momentin. Ata do të rinovohen kur të kuptojnë gjenialitetin tuaj!

Në një depo, përgjegjësia zhvendoset si parazgjedhje. Ekipi A ndryshon komponentin e tij dhe, nëse nuk është i kujdesshëm, thyen menjëherë B, C dhe D. Kjo çon në shfaqjen e B, C dhe D në derën e A, duke pyetur veten pse Ekipi A e prishi montimin. Kjo i mëson A-së se ata nuk mund ta kalojnë listën time të mësipërme. Ata duhet të flasin për atë që do të bëjnë. A mund të lëvizin B, C dhe D? Po sikur B dhe C të munden, por D ishte i lidhur ngushtë me një efekt anësor të sjelljes së algoritmit të vjetër?

Atëherë duhet të flasim se si do të dalim nga kjo situatë:

1. Mbështetje për API të shumta të brendshme dhe do të shënojë algoritmin e vjetër si të vjetëruar derisa D të ndalojë përdorimin e tij.
2. Mbështetje për versione të shumta lëshimi, një me ndërfaqen e vjetër, një me atë të re.
3. Vonesoni lëshimin e ndryshimeve të A-së derisa B, C dhe D të mund ta pranojnë atë njëkohësisht.

Le të themi se kemi zgjedhur 1, disa API. Në këtë rast kemi dy pjesë kodi. E vjetra dhe e reja. Mjaft i përshtatshëm në disa situata. Ne kontrollojmë përsëri kodin e vjetër, e shënojmë atë si të vjetëruar dhe biem dakord për një plan heqjeje me ekipin D. Në thelb identik për depot poli dhe mono.

Për të lëshuar versione të shumta, na duhet një degë. Tani kemi dy komponentë - A1 dhe A2. Ekipet B dhe C përdorin A2 dhe D përdorin A1. Ne kemi nevojë që çdo komponent të jetë gati për lëshim sepse mund të kërkohen përditësime të sigurisë dhe rregullime të tjera të gabimeve përpara se D të mund të ecë përpara. Në një polidepo, ne mund ta fshehim këtë në një degë jetëgjatë që ndihet mirë. Në një monorepository, ne detyrojmë kodin të krijohet në një modul të ri. Ekipi D do të duhet ende të bëjë ndryshime në komponentin "e vjetër". Të gjithë mund të shohin koston që po paguajmë këtu - tani kemi dyfish më shumë kod dhe çdo rregullim i gabimeve që zbatohet për A1 dhe A2 duhet të zbatohet për të dyja. Me qasjen e degëzimit në një polidepo, kjo fshihet pas zgjedhjes së qershisë. Ne e konsiderojmë koston më të ulët sepse nuk ka dyfishim. Nga pikëpamja praktike, kostoja është e njëjtë: do të ndërtoni, lëshoni dhe mbani dy baza kodesh kryesisht identike derisa të mund të fshini njërën prej tyre. Dallimi është se me një depo kjo dhimbje është e drejtpërdrejtë dhe e dukshme. Kjo është edhe më keq, dhe kjo është mirë.

Më në fund arritëm në pikën e tretë. Vonesa e lëshimit. Është e mundur që ndryshimet e bëra nga A do të përmirësojnë jetën e Ekipit A. E rëndësishme, por jo urgjente. A mund të vonojmë vetëm? Në një polidepo, ne e shtyjmë këtë për të vendosur objektin. Sigurisht që këtë po ia tregojmë ekipit D. Qëndroni në versionin e vjetër derisa të arrini! Kjo ju vendos të luani frikacak. Ekipi A vazhdon të punojë në komponentin e tij, duke injoruar faktin që Ekipi D po përdor një version gjithnjë e më të vjetëruar (ky është problemi i Ekipit D, ata janë budallenj). Ndërkohë, Ekipi D flet keq për qëndrimin e pakujdesshëm të Ekipit A ndaj stabilitetit të kodit, nëse flasin fare për të. Muajt ​​kalojnë. Më në fund, Ekipi D vendos të shikojë mundësinë e përditësimit, por A ka vetëm më shumë ndryshime. Ekipi A mezi kujton se kur dhe si e thyen D. Përmirësimi është më i dhimbshëm dhe do të zgjasë më shumë. E cila e dërgon atë më poshtë në rafte prioritare. Deri ditën që kemi një çështje sigurie në A që na detyron të bëjmë një degë. Skuadra A duhet të kthehet prapa në kohë, të gjejë një pikë kur D ishte e qëndrueshme, të rregullojë problemin atje dhe ta bëjë atë gati për lëshim. Kjo është zgjedhja de fakto që bëjnë njerëzit, dhe është deri tani më e keqja. Duket se është mirë si për ekipin A ashtu edhe për ekipin D për sa kohë që ne mund ta injorojmë njëri-tjetrin.

Në një depo, e treta nuk është me të vërtetë një opsion. Jeni të detyruar të merreni me situatën në një nga dy mënyrat. Ju duhet të shihni kostot për të pasur dy degë lëshimi. Mësoni të mbroheni nga përditësimet që prishin përputhshmërinë e prapambetur. Por më e rëndësishmja: nuk mund të shmangësh një bisedë të vështirë.

Në përvojën time, kur ekipet bëhen të mëdha, nuk është më e mundur të mbash parasysh 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 në mënyrë aktive për t'i bërë ekipet të largojnë shikimin nga komponentët e tyre dhe të shikojnë punën e ekipeve dhe konsumatorëve të tjerë.

Po, mund të krijoni mjete që përpiqen të zgjidhin problemin e polirepositorit. Por përvoja ime në mësimdhënien e shpërndarjes dhe automatizimit të vazhdueshëm në ndërmarrjet e mëdha më thotë këtë: sjellja e paracaktuar pa përdorimin e mjeteve shtesë është sjellja që prisni të shihni. Sjellja e paracaktuar e një polidepoje është izolimi, kjo është e gjithë çështja. Sjellja e paracaktuar e një depoje të vetme është përgjegjësi e përbashkët dhe transparencë, kjo është e gjithë çështja. Në të dyja rastet, unë do të krijoj një mjet që do të lëmojë skajet e përafërt. Si drejtues, do të zgjedh çdo herë një depo të vetme, sepse mjetet duhet të përforcojnë kulturën që dua, dhe kultura vjen nga vendimet e vogla dhe puna e përditshme e ekipit.

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

Kush janë fanatikët më të mëdhenj? Mbështetësit:

• Monorepo

• Ndryshk

• Sondazh i pasaktë / të dyja

33 përdorues kanë votuar. 13 përdorues abstenuan.

Burimi: www.habr.com