ProHoster > Blogs > Administrācija > Monorepozitoriji: lūdzu, obligāti

Monorepozitoriji: lūdzu, obligāti

Monorepozitoriji: lūdzu, obligāti

Kursa studentiem sagatavots raksta tulkojums "DevOps prakse un rīki" OTUS izglītības projektā.

Jums vajadzētu izvēlēties monokrātuvi, jo jÅ«su komandās tā veicina caurspÄ«dÄ«gumu un dalÄ«tu atbildÄ«bu, jo Ä«paÅ”i komandām augot. Jebkurā gadÄ«jumā jums bÅ«s jāiegulda instrumenti, taču vienmēr ir labāk, ja noklusējuma darbÄ«ba ir tāda, kādu vēlaties savās komandās.

Kāpēc mēs par to runājam?

Mets Kleins uzrakstÄ«ja rakstu "Monorepos: LÅ«dzu, nedari!"ā€Š (tulkotāja piezÄ«me: tulkojums par HabrĆ© ā€œMonorepozitoriji: lÅ«dzu, nedarietā€). Man patÄ«k Mets, manuprāt, viņŔ ir ļoti gudrs, un jums vajadzētu izlasÄ«t viņa viedokli. ViņŔ sākotnēji ievietoja aptauju vietnē Twitter:

Monorepozitoriji: lūdzu, obligāti

Tulkojums:
Å ajā Jaungada dienā es strÄ«dÄ“Å”os par to, cik smieklÄ«gi ir monorepozitoriji. 2019. gads sākās mierÄ«gi. Å ajā garā es piedāvāju jums aptauju. Kas ir tie lielie fanātiÄ·i? AtbalstÄ«tāji:
Sākot no Monorepo
Sākot no Rūsa
Sākot no Nepareiza aptauja / abi

Mana atbilde bija: "Es burtiski esmu abi no Å”iem cilvēkiem." Tā vietā, lai runātu par to, kā Rust ir narkotika, paskatÄ«simies, kāpēc, manuprāt, viņŔ kļūdās attiecÄ«bā uz monokrātuvēm. Mazliet par sevi. Es esmu Chef Software CTO. Mums ir aptuveni 100 inženieru, koda bāze, kas aizsākās aptuveni 11ā€“12 gadus, un 4 galvenie produkti. Daļa no Ŕī koda atrodas polirepozitorijā (mana sākuma pozÄ«cija), daļa ir monorepozitorijā (mana paÅ”reizējā pozÄ«cija).

Pirms es sāku: visi Å”eit minētie argumenti attieksies uz abu veidu krātuvēm. Manuprāt, nav tehnisku iemeslu, kāpēc jums vajadzētu izvēlēties viena veida repozitoriju, nevis citu. Jebkurai pieejai var darboties. Es labprāt par to runāju, bet mani neinteresē mākslÄ«gi tehniski apsvērumi, kāpēc viens ir pārāks par otru.

Es piekrītu Metta punkta pirmajai daļai:

Tā kā mērogā monorepozitorijs atrisinās visas tās paÅ”as problēmas, kuras atrisina polirepozitorijs, bet tajā paŔā laikā liekot jums cieÅ”i savienot savu kodu un pieprasot neticamas pÅ«les, lai palielinātu versiju kontroles sistēmas mērogojamÄ«bu.

Jums bÅ«s jāatrisina tās paÅ”as problēmas neatkarÄ«gi no tā, vai izvēlaties monokrātuvi vai polirepozitoriju. Kā jÅ«s izlaižat izlaidumus? Kāda ir jÅ«su pieeja atjauninājumiem? Atgriezeniskā saderÄ«ba? Vairāku projektu atkarÄ«bas? Kādi arhitektÅ«ras stili ir pieņemami? Kā jÅ«s pārvaldāt savu izveides un testÄ“Å”anas infrastruktÅ«ru? Saraksts ir bezgalÄ«gs. Un jÅ«s tos visus atrisināsiet augot. Bezmaksas siera nav.

Es domāju, ka Metta arguments ir līdzīgs uzskatiem, kurus piekrīt daudzi inženieri (un vadītāji), kurus es cienu. Tas notiek no inženiera, kas strādā pie komponenta, vai komandas, kas strādā pie komponenta, skatījumā. Jūs dzirdat tādas lietas kā:

  • Kodu bāze ir apjomÄ«ga ā€” man nevajag visu Å”o atkritumu.
  • To ir grÅ«tāk pārbaudÄ«t, jo man ir jātestē viss Å”is man nevajadzÄ«gais krāms.
  • GrÅ«tāk ir strādāt ar ārējām atkarÄ«bām.
  • Man ir vajadzÄ«gas savas virtuālās versiju kontroles sistēmas.

Protams, visi Å”ie punkti ir pamatoti. Tas notiek abos gadÄ«jumos - polirepozitorijā man ir savs krāms, papildus tam, kas nepiecieÅ”ams bÅ«vÄ“Å”anai... Man var bÅ«t nepiecieÅ”ams arÄ« kāds cits. Tāpēc es "vienkārÅ”i" izveidoju rÄ«kus, kas pārbauda visu projektu. Vai arÄ« es izveidoju viltotu monokrātuvi ar apakÅ”moduļiem. Mēs varētu staigāt pa Å”o visu dienu. Bet es domāju, ka Metta arguments izlaiž garām galveno iemeslu, kuru es diezgan lielā mērā pagriezu par labu monokrātuvei:

Tas provocē saziņu un parāda problēmas

Atdalot repozitorijus, mēs radām de facto koordinācijas un pārredzamÄ«bas problēmu. Tas atbilst tam, kā mēs domājam par komandām (Ä«paÅ”i tam, kā par tām domā atseviŔķi dalÄ«bnieki): mēs esam atbildÄ«gi par noteiktu sastāvdaļu. Mēs strādājam relatÄ«vi izolēti. Robežas ir noteiktas manai komandai un komponentam(-iem), pie kā mēs strādājam.

Tā kā arhitektÅ«ra kļūst sarežģītāka, viena komanda vairs nevar to pārvaldÄ«t viena. Ä»oti nedaudziem inženieriem visa sistēma ir prātā. Pieņemsim, ka jÅ«s pārvaldāt koplietotu komponentu A, ko izmanto komandas B, C un D. Komanda A pārveido, uzlabo API un arÄ« maina iekŔējo ievieÅ”anu. Rezultātā izmaiņas nav savietojamas atpakaļ. Kāds jums ir padoms?

  • Atrodiet visas vietas, kur tiek izmantota vecā API.
  • Vai ir vietas, kur nevar izmantot jauno API?
  • Vai varat salabot un pārbaudÄ«t citus komponentus, lai pārliecinātos, ka tie neplÄ«st?
  • Vai Ŕīs komandas var pārbaudÄ«t jÅ«su izmaiņas tieÅ”i tagad?

LÅ«dzu, ņemiet vērā, ka Å”ie jautājumi nav atkarÄ«gi no repozitorija veida. Jums bÅ«s jāatrod komandas B, C un D. Jums bÅ«s ar viņiem jārunā, jānoskaidro laiks, jāsaprot viņu prioritātes. Mēs vismaz ceram, ka jÅ«s to darÄ«siet.

Neviens Ä«sti nevēlas to darÄ«t. Tas ir daudz mazāk jautri nekā tikai sasodÄ«tā API laboÅ”ana. Tas viss ir cilvēciski un nekārtÄ«gi. Polirepozitorijā varat vienkārÅ”i veikt izmaiņas, nodot to cilvēkiem, kas strādā pie Ŕī komponenta (iespējams, ne B, C vai D), lai viņi to pārskatÄ«tu, un turpināt. Komandas B, C un D pagaidām var palikt pie paÅ”reizējās versijas. Tie tiks atjaunoti, kad viņi apzinās jÅ«su Ä£enialitāti!

Monokrātuvē atbildÄ«ba pēc noklusējuma tiek pārcelta. Komanda A maina savu komponentu un, ja nav piesardzÄ«ga, nekavējoties salauž B, C un D. Tas noved pie tā, ka B, C un D parādās pie A durvÄ«m, prātojot, kāpēc A komanda salauza komplektu. Tas māca A, ka viņi nevar izlaist manu iepriekÅ” minēto sarakstu. Viņiem ir jārunā par to, ko viņi gatavojas darÄ«t. Vai B, C un D var pārvietoties? Ko darÄ«t, ja B un C var, bet D bija cieÅ”i saistÄ«ts ar vecā algoritma uzvedÄ«bas blakusefektu?

Tad mums ir jārunā par to, kā mēs izkļūsim no Ŕīs situācijas:

  1. Atbalsts vairākām iekŔējām API, un vecais algoritms tiks atzÄ«mēts kā novecojis, lÄ«dz D nevarēs to lietot.
  2. Atbalsts vairākām laidiena versijām, vienai ar veco saskarni, otrai ar jauno.
  3. Atlikt A izmaiņu izlaiÅ”anu, lÄ«dz B, C un D var tās vienlaikus pieņemt.

Pieņemsim, ka esam atlasÄ«juÅ”i 1 ā€” vairākas API. Å ajā gadÄ«jumā mums ir divas koda daļas. Vecs un jauns. Diezgan ērti dažās situācijās. Mēs pārbaudām veco kodu, atzÄ«mējam to kā novecojuÅ”u un vienojamies par noņemÅ”anas grafiku ar D komandu. BÅ«tÄ«bā tas ir identisks poli un mono krātuvēm.

Lai izdotu vairākas versijas, mums ir nepiecieÅ”ama filiāle. Tagad mums ir divas sastāvdaļas - A1 un A2. Komandas B un C izmanto A2 un D izmanto A1. Mums ir nepiecieÅ”ams, lai katrs komponents bÅ«tu gatavs izlaiÅ”anai, jo var bÅ«t nepiecieÅ”ami droŔības atjauninājumi un citi kļūdu labojumi, pirms D var virzÄ«ties uz priekÅ”u. Polirepozitorijā mēs to varam paslēpt ilgmūžīgā zarā, kas jÅ«tas labi. Monorepozitorijā mēs piespiežam kodu izveidot jaunā modulÄ«. Komandai D joprojām bÅ«s jāveic izmaiņas "vecajā" komponentā. Ikviens var redzēt izmaksas, ko mēs Å”eit maksājam ā€” tagad mums ir divreiz vairāk koda, un visiem kļūdu labojumiem, kas attiecas uz A1 un A2, ir jāattiecas uz abiem. Izmantojot sazaroÅ”anas pieeju polirepozitorijā, tas tiek paslēpts aiz Ä·irÅ”u izvēles. Mēs uzskatām, ka izmaksas ir zemākas, jo nav dublÄ“Å”anās. No praktiskā viedokļa izmaksas ir tādas paÅ”as: jÅ«s izveidosit, izlaidÄ«sit un uzturēsit divas lielā mērā identiskas kodu bāzes, lÄ«dz varēsit dzēst vienu no tām. AtŔķirÄ«ba ir tāda, ka ar monorepozitoriju Ŕīs sāpes ir tieÅ”as un redzamas. Tas ir vēl sliktāk, un tas ir labi.

Beidzot tikām pie treŔā punkta. IzlaiÅ”anas aizkave. Iespējams, ka A veiktās izmaiņas uzlabos A komandas dzÄ«vi. SvarÄ«gi, bet ne steidzami. Vai mēs varam aizkavēt? Polirepozitorijā mēs to nospiežam, lai piespraustu artefaktu. Protams, mēs to stāstām komandai D. VienkārÅ”i palieciet pie vecās versijas, lÄ«dz panākat! Tas liek jums spēlēt gļēvuli. Komanda A turpina strādāt pie sava komponenta, ignorējot faktu, ka komanda D izmanto arvien novecojuÅ”u versiju (tā ir komandas D problēma, viņi ir stulbi). Tikmēr komanda D slikti runā par komandas A neuzmanÄ«go attieksmi pret koda stabilitāti, ja viņi par to vispār runā. Paiet mēneÅ”i. Visbeidzot, komanda D nolemj izskatÄ«t iespēju atjaunināt, bet A ir tikai vairāk izmaiņu. Komanda A gandrÄ«z neatceras, kad un kā viņi salauza D. JaunināŔana ir sāpÄ«gāka un prasÄ«s ilgāku laiku. Kas to nosÅ«ta tālāk prioritārā kaudze. LÄ«dz dienai, kad A ir droŔības problēma, kas liek mums izveidot filiāli. A komandai ir jāatgriežas pagātnē, jāatrod punkts, kad D bija stabils, jānovērÅ” problēma un jāsagatavo tā atbrÄ«voÅ”anai. Tā ir cilvēku de facto izvēle, un tā ir lÄ«dz Å”im sliktākā. Å Ä·iet, ka tas nāk par labu gan komandai A, gan D komandai, ja vien varam viens otru ignorēt.

Monokrātuvē treÅ”ais tieŔām nav risinājums. JÅ«s esat spiests risināt situāciju vienā no diviem veidiem. Jums ir jāredz divu izlaiÅ”anas filiāļu izmaksas. Uzziniet, kā pasargāt sevi no atjauninājumiem, kas traucē atpakaļejoÅ”u saderÄ«bu. Bet pats galvenais: jÅ«s nevarat izvairÄ«ties no sarežģītas sarunas.

Pēc manas pieredzes, kad komandas kļūst lielas, vairs nav iespējams paturēt prātā visu sistēmu, un tā ir vissvarīgākā daļa. Jums jāuzlabo nesaskaņu redzamība sistēmā. Jums ir aktīvi jāstrādā, lai komandas atskatītos no savām sastāvdaļām un skatītos uz citu komandu un patērētāju darbu.

Jā, jÅ«s varat izveidot rÄ«kus, kas mēģina atrisināt polirepozitorija problēmu. Taču mana pieredze, mācot nepārtrauktu piegādi un automatizāciju lielos uzņēmumos, liecina: noklusējuma darbÄ«ba bez papildu rÄ«ku izmantoÅ”anas ir tāda, kādu jÅ«s sagaidāt. Noklusējuma polirepozitorija darbÄ«ba ir izolācija, un tā ir visa bÅ«tÄ«ba. Monorepozitorija noklusējuma darbÄ«ba ir dalÄ«ta atbildÄ«ba un caurspÄ«dÄ«gums, tas ir visa bÅ«tÄ«ba. Abos gadÄ«jumos es izveidoÅ”u instrumentu, kas izlÄ«dzinās raupjās malas. Kā vadÄ«tājs es katru reizi izvēlÄ“Å”os monokrātuvi, jo rÄ«kiem ir jānostiprina kultÅ«ra, kuru es vēlos, un kultÅ«ra rodas no sÄ«kiem lēmumiem un komandas ikdienas darba.

Aptaujā var piedalīties tikai reģistrēti lietotāji. Ielogoties, lūdzu.

Kuri ir lielākie fanātiķi? Atbalstītāji:

  • Monorepo

  • RÅ«sa

  • Nepareiza aptauja / abi

Nobalsoja 33 lietotāji. 13 lietotāji atturējās.

Avots: www.habr.com

Pievieno komentāru