Paghubad sa artikulo nga giandam alang sa mga estudyante sa kurso "Mga gawi ug himan sa DevOps" sa OTUS nga proyekto sa edukasyon.

Kinahanglan ka nga mopili og monorepository tungod kay ang pamatasan nga gipasiugda niini sa imong mga koponan mao ang transparency ug gipaambit nga responsibilidad, labi na kung ang mga koponan motubo. Sa bisan unsang paagi, kinahanglan ka nga mamuhunan sa tooling, apan kanunay nga mas maayo kung ang default nga pamatasan mao ang pamatasan nga gusto nimo sa imong mga mando.

Nganong naghisgot man ta niini?

Gisulat ni Matt Klein ang artikulo "Monorepos: Palihug ayaw!"  (mubo sa tighubad: hubad sa Habré "Monorepositories: palihug ayaw"). Ganahan ko ni Matt, abi nakog buotan kaayo siya ug basahon nimo iyang punto de bista. Siya orihinal nga nag-post sa poll sa Twitter:

Paghubad:
Karong Bag-ong Tuig, makiglalis ko kung unsa ka kataw-anan ang mga monorepositories. Ang 2019 nagsugod sa hilom. Sa diwa niini, nagtanyag ko nimo og survey. Kinsa ang mga dagkong panatiko? Mga tigpaluyo:
- Monorepo
- taya
- Sayop nga poll / pareho

Ang akong tubag mao, "Ako sa literal pareho sa mga tawo." Imbis nga hisgutan kung giunsa ang Rust usa ka tambal, tan-awon naton kung ngano nga sa akong hunahuna siya sayup bahin sa mga monorepositories. Usa ka gamay bahin sa imong kaugalingon. Ako ang CTO sa Chef Software. Adunay kami mga 100 ka mga inhenyero, usa ka base sa code nga mobalik mga 11-12 ka tuig, ug 4 nga nag-unang mga produkto. Ang uban niini nga code naa sa polyrepository (akong sugod nga posisyon), ang uban naa sa monorepository (akong posisyon karon).

Sa wala pa ako magsugod: ang matag argumento nga akong gihimo dinhi magamit sa parehas nga mga lahi sa mga repositoryo. Sa akong opinyon, walay teknikal nga rason ngano nga kamo kinahanglan nga mopili sa usa ka matang sa repository sa ibabaw sa lain. Mahimo nimong buhaton ang bisan unsang pamaagi nga molihok. Nalipay ako sa paghisgot bahin niini, apan dili ako interesado sa artipisyal nga teknikal nga mga hinungdan ngano nga ang usa labaw sa lain.

Miuyon ko sa unang bahin sa punto ni Matt:

Tungod kay sa sukdanan, ang usa ka monorepository makasulbad sa tanan nga parehas nga mga problema nga gisulbad sa usa ka polyrepository, apan sa parehas nga oras gipugos ka nga hugot nga ipares ang imong code ug nanginahanglan daghang mga paningkamot aron madugangan ang scalability sa imong sistema sa pagkontrol sa bersyon.

Kinahanglan nimong sulbaron ang parehas nga mga problema bisan kung mopili ka usa ka monorepository o usa ka polyrepository. Giunsa nimo pag-release ang mga pagpagawas? Unsa ang imong pamaagi sa pag-update? Balik nga pagkaangay? Cross dependencies sa proyekto? Unsang mga istilo sa arkitektura ang madawat? Giunsa nimo pagdumala ang imong pagtukod ug pagsulay nga imprastraktura? Ang listahan walay katapusan. Ug masulbad nimo silang tanan samtang ikaw motubo. Walay libre nga keso.

Sa akong hunahuna ang argumento ni Matt parehas sa mga panan-aw nga gipaambit sa daghang mga inhenyero (ug managers) nga akong gitahud. Kini mahitabo gikan sa panglantaw sa engineer nga nagtrabaho sa component o sa team nga nagtrabaho sa component. Nakadungog ka og mga butang sama sa:

• Ang codebase dako kaayo - dili nako kinahanglan kining tanan nga basura.
• Mas lisud ang pagsulay tungod kay kinahanglan nako nga susihon ang tanan nga basura nga wala nako kinahanglana.
• Mas lisud ang pagtrabaho sa mga eksternal nga dependency.
• Kinahanglan nako ang akong kaugalingon nga virtual nga bersyon sa pagkontrol sa mga sistema.

Siyempre, kining tanan nga mga punto makatarunganon. Kini mahitabo sa duha ka mga kaso - sa polyrepository ako adunay akong kaugalingon nga junk, dugang pa sa usa nga gikinahanglan alang sa pagtukod ... mahimo usab ako nagkinahanglan sa uban nga mga basura. Busa ako "yano" naghimo og mga himan nga nagsusi sa tibuok nga proyekto. O naghimo ako usa ka peke nga monorepository nga adunay mga submodules. Makasuroysuroy mi niini tibuok adlaw. Apan sa akong hunahuna ang argumento ni Matt nawala sa panguna nga hinungdan, nga akong gibalibaran pag-ayo pabor sa monorepository:

Kini naghagit sa komunikasyon ug nagpakita sa mga problema

Kung magbulag kami sa mga repository, maghimo kami usa ka de facto nga problema sa koordinasyon ug transparency. Kini katumbas sa paagi sa atong paghunahuna mahitungod sa mga team (ilabi na sa paagi sa tagsa-tagsa nga mga miyembro sa paghunahuna mahitungod kanila): kita ang responsable alang sa usa ka partikular nga component. Nagtrabaho kami nga medyo bulag. Ang mga utlanan gitakda sa akong team ug ang (mga) component nga among gitrabaho.

Samtang ang arkitektura nahimong mas komplikado, ang usa ka team dili na makadumala niini nga mag-inusara. Gamay ra nga mga inhenyero ang adunay tibuuk nga sistema sa ilang ulo. Ingnon ta nga nagdumala ka sa usa ka gipaambit nga sangkap A nga gigamit sa mga Team B, C, ug D. Ang Team A nag-refactoring, nagpauswag sa API, ug nagbag-o usab sa internal nga pagpatuman. Ingon usa ka sangputanan, ang mga pagbag-o dili katugma sa likod. Unsay advice nimo?

• Pangitaa ang tanang dapit diin gigamit ang karaang API.
• Aduna bay mga lugar diin ang bag-ong API dili magamit?
• Mahimo ba nimo ayohon ug sulayan ang ubang mga sangkap aron masiguro nga dili kini mabuak?
• Makasulay ba kini nga mga team sa imong mga pagbag-o karon?

Palihug timan-i nga kini nga mga pangutana independente sa tipo sa repository. Kinahanglan nimo pangitaon ang mga team B, C ug D. Kinahanglan nimo nga makig-istorya kanila, mahibal-an ang oras, masabtan ang ilang mga prayoridad. Sa labing gamay nanghinaut kami nga buhaton nimo.

Walay usa nga gustong mobuhat niini. Kini dili kaayo makalingaw kay sa pag-ayo lamang sa makadaot nga API. Kini tanan tawo ug gubot. Sa usa ka polyrepository, mahimo ka lang maghimo mga pagbag-o, ihatag kini sa mga tawo nga nagtrabaho sa kana nga sangkap (tingali dili B, C o D) alang sa pagrepaso, ug magpadayon. Ang mga Team B, C ug D mahimong magpabilin sa ilang kasamtangan nga bersyon sa pagkakaron. Mabag-o sila kung makaamgo sila sa imong kaalam!

Sa usa ka monorepository, ang responsibilidad gibalhin pinaagi sa default. Gibag-o sa Team A ang ilang component ug, kung dili mag-amping, gibuak dayon ang B, C ug D. Kini modala ngadto sa B, C ug D nga nagpakita sa pultahan ni A, nahibulong nganong giguba sa Team A ang asembliya. Kini nagtudlo sa A nga dili nila malaktawan ang akong listahan sa ibabaw. Kinahanglang maghisgot sila kon unsay ilang buhaton. Mahimo bang molihok ang B, C ug D? Unsa kaha kung mahimo ang B ug C, apan ang D suod nga may kalabotan sa usa ka epekto sa pamatasan sa daan nga algorithm?

Dayon kinahanglan natong hisgutan kung unsaon nato paggawas niini nga sitwasyon:

1. Suporta alang sa daghang internal nga mga API, ug markahan ang daan nga algorithm nga wala na magamit hangtod ang D makahunong sa paggamit niini.
2. Suporta alang sa daghang mga bersyon sa pagpagawas, usa nga adunay daan nga interface, usa nga adunay bag-o.
3. Ilangan ang pagpagawas sa mga kausaban ni A hangtod ang B, C, ug D makadawat niini nga dungan.

Ingnon ta nga gipili namo ang 1, daghang mga API. Sa kini nga kaso kita adunay duha ka piraso sa code. Daan ug bag-o. Kombenyente sa pipila ka mga sitwasyon. Among susihon pagbalik ang daan nga code, markahan kini nga wala na magamit, ug mouyon sa usa ka eskedyul sa pagtangtang uban sa D team. Sa tinuud parehas alang sa poly ug mono repository.

Aron buhian ang daghang mga bersyon, kinahanglan namon ang usa ka sanga. Karon kami adunay duha ka sangkap - A1 ug A2. Ang mga Team B ug C naggamit sa A2 ug ang D naggamit sa A1. Kinahanglan namon ang matag sangkap nga andam alang sa pagpagawas tungod kay ang mga update sa seguridad ug uban pang mga pag-ayo sa bug mahimo’g gikinahanglan sa dili pa makapadayon ang D. Sa usa ka polyrepository, mahimo natong itago kini sa usa ka dugay na nga sanga nga gibati nga maayo. Sa usa ka monorepository, gipugos namon ang code nga himuon sa usa ka bag-ong module. Kinahanglan pa nga magbag-o ang Team D sa "daan" nga sangkap. Makita sa tanan ang gasto nga among gibayad dinhi - kami karon adunay doble nga gidaghanon sa code, ug bisan unsang mga pag-ayo sa bug nga magamit sa A1 ug A2 kinahanglan nga magamit sa duha niini. Uban sa branching approach sa usa ka polyrepository, kini gitago sa likod sa cherry-pick. Gikonsiderar namon nga mas ubos ang gasto tungod kay wala’y pagdoble. Gikan sa praktikal nga baroganan, pareho ra ang gasto: magtukod ka, magpagawas, ug magmentinar sa duha nga parehas nga mga codebase hangtod matangtang nimo ang usa niini. Ang kalainan mao nga sa usa ka monorepository kini nga kasakit direkta ug makita. Mas grabe pa kini, ug maayo kana.

Sa kataposan, nakaabot kami sa ikatulong punto. Paglangan sa pagpagawas. Posible nga ang mga pagbag-o nga gihimo ni A makapauswag sa kinabuhi sa Team A. Importante, apan dili dinalian. Mahimo bang maglangan lang? Sa usa ka polyrepository, among giduso kini aron i-pin ang artifact. Siyempre gisulti namo kini sa Team D. Pabilin lang sa daan nga bersyon hangtod nga makaapas ka! Kini nagbutang kanimo sa pagdula sa talawan. Ang Team A nagpadayon sa pagtrabaho sa ilang component, nga wala magtagad sa kamatuoran nga ang Team D naggamit sa usa ka mas karaan nga bersyon (kana ang problema sa Team D, sila mga tanga). Samtang, ang Team D dili maayo nga naghisgot bahin sa Team A nga walay pagtagad nga kinaiya ngadto sa code stability, kung sila maghisgot bahin niini. Milabay ang mga bulan. Sa katapusan, ang Team D nakahukom nga tan-awon ang posibilidad sa pag-update, apan ang A adunay daghang mga pagbag-o. Ang Team A halos wala makahinumdom kung kanus-a o giunsa nila gibuak ang D. Ang pag-upgrade mas sakit ug mas dugay. Nga nagpadala niini nga mas ubos sa priority stack. Until niabot ang adlaw nga naa miy security issue sa A nga napugos mi nga magbuhat ug branch. Ang Team A kinahanglan nga mobalik sa panahon, mangita usa ka punto kung kanus-a ang D lig-on, ayohon ang problema didto, ug andama kini alang sa pagpagawas. Kini ang de facto nga pagpili nga gihimo sa mga tawo, ug kini ang labing daotan. Maayo daw para sa Team A ug Team D basta mabalewala lang namo ang usag usa.

Sa usa ka monorepository, ang ikatulo dili gyud kapilian. Napugos ka sa pag-atubang sa sitwasyon sa usa sa duha ka paagi. Kinahanglan nimong tan-awon ang gasto sa pagbaton ug duha ka sanga sa pagpagawas. Pagkat-on sa pagpanalipod sa imong kaugalingon gikan sa mga update nga makaguba sa backward compatibility. Apan ang labing importante: dili nimo malikayan nga adunay lisud nga panag-istoryahanay.

Sa akong kasinatian, kung ang mga koponan modako, dili na posible nga ibutang sa hunahuna ang tibuuk nga sistema, ug kana ang labing hinungdanon nga bahin. Kinahanglan nimong pauswagon ang visibility sa panagsumpaki sa sistema. Kinahanglan ka nga aktibo nga magtrabaho aron makuha ang mga koponan nga magpalayo sa ilang mga sangkap ug tan-awon ang trabaho sa ubang mga koponan ug mga konsumedor.

Oo, makahimo ka og mga himan nga mosulay sa pagsulbad sa problema sa polyrepository. Apan ang akong kasinatian sa pagtudlo sa padayon nga paghatod ug automation sa dagkong mga negosyo nagsulti kanako niini: ang default nga kinaiya nga walay paggamit sa dugang nga mga himan mao ang kinaiya nga imong gilauman nga makita. Ang default nga pamatasan sa usa ka polyrepository mao ang pag-inusara, kana ang tibuuk nga punto. Ang default nga pamatasan sa usa ka monorepository gipaambit nga responsibilidad ug transparency, kana ang tibuuk nga punto. Sa duha ka mga kaso, maghimo ako og usa ka himan nga makapahapsay sa mga bagis nga mga ngilit. Isip usa ka lider, magpili ko og monorepository matag higayon tungod kay ang mga himan kinahanglan nga mapalig-on ang kultura nga gusto nako, ug ang kultura naggikan sa gagmay nga mga desisyon ug sa adlaw-adlaw nga trabaho sa team.

Ang mga rehistradong tiggamit lamang ang makaapil sa survey. Sign in, walay sapayan.

Kinsa ang pinakadako nga mga panatiko? Mga tigpaluyo:

• Monorepo

• taya

• Sayop nga poll / pareho

33 ka tiggamit ang miboto. 13 ka tiggamit ang nag-abstain.

Source: www.habr.com