Wergera gotarê ji bo xwendekarên kursê hatiye amadekirin "Pêkanîn û amûrên DevOps" di projeya perwerdehiya OTUS de.

Pêdivî ye ku hûn monorepository hilbijêrin ji ber ku behreya ku ew di tîmên we de pêşve dike şefafî û berpirsiyariya hevpar e, nemaze dema ku tîm mezin dibin. Bi her awayî, hûn ê neçar in ku di amûrkirinê de veberhênan bikin, lê her gav çêtir e ku tevgera xwerû ew behreya ku hûn di emrên xwe de dixwazin be.

Çima em li ser vê yekê dipeyivin?

Matt Klein gotar nivîsand "Monorepos: Ji kerema xwe nekin!"  (têbînîya wergêr: werger li ser Habré "Monorepositories: Ji kerema xwe nekin"). Ez ji Matt hez dikim, ez difikirim ku ew pir jîr e û divê hûn nêrîna wî bixwînin. Wî di destpêkê de anket li ser Twitterê şand:

Werger:
Di vê Roja Sersalê de, ez ê li ser vê yekê nîqaş bikim ka monorepositories çiqas bêhêz in. 2019 bi bêdengî dest pê kir. Di ruhê vê de, ez anketek pêşkêşî we dikim. Fanatîkên mezin kî ne? Piştgir:
- Monorepo
- Zingar
- Anketa çewt / herdu

Bersiva min ev bû, "Ez bi rastî ji wan herdu kesan im." Li şûna ku em bipeyivin ka Rust çawa dermanek e, em lê binihêrin ka çima ez difikirim ku ew di derbarê monorepositories de xelet e. Hinekî li ser xwe. Ez CTO ya Nermalava Chef im. Nêzîkî 100 endezyarên me hene, bingehek kodê ku bi qasî 11-12 salan vedigere, û 4 hilberên sereke hene. Hin ji vê kodê di polîrepository (pozîsyona min a destpêkê) de ye, hin jî di monorepository de ye (pozîsyona min a niha).

Berî ku ez dest pê bikim: her argumana ku ez li vir dikim dê li ser her du celeb depoyan bicîh bibe. Bi dîtina min, sedemek teknîkî tune ku çima hûn celebek depo li ser yekî din hilbijêrin. Hûn dikarin her nêzîkatiyê bixebitin. Ez kêfxweş im ku li ser wê biaxivim, lê ez ji sedemên teknîkî yên çêkirî re eleqedar nabim ku çima yek ji ya din bilindtir e.

Ez bi beşa yekem a xala Matt re dipejirînim:

Ji ber ku di pîvanê de, monorepository dê hemî heman pirsgirêkan çareser bike ku polîdepoyek çareser dike, lê di heman demê de zorê dide we ku hûn koda xwe zexm li hev bikin û ji bo zêdekirina pîvana pergala kontrolkirina guhertoya we hewildanên bêhempa hewce dike.

Hûn neçar in ku heman pirsgirêkan çareser bikin bêyî ku hûn monorepository an polîdepoyek hilbijêrin. Hûn serbestberdanan çawa derdixin? Nêzîkatiya we ji nûvekirinan re çi ye? Lihevhatina paşverû? Pêwendiyên projeya cross? Kîjan şêwazên mîmarî têne pejirandin? Hûn binesaziya çêkirin û ceribandina xwe çawa birêve dibin? Lîsteya bêdawî ye. Û her ku hûn mezin dibin hûn ê wan hemî çareser bikin. Penîrê belaş tune.

Ez difikirim ku argumana Matt dişibihe dîtinên ku ji hêla gelek endezyaran (û rêvebiran) ve ku ez rêz dikim. Ev ji perspektîfa endezyarê ku li ser pêkhatê dixebite an tîmê ku li ser pêkhateyê dixebite pêk tê. Hûn tiştên weha dibihîzin:

• Bingeha kodê mezin e - ne hewceya min bi van hemî nebatan e.
• Ceribandin dijwartir e ji ber ku ez neçar im ku hemî van nebatên ku ez hewce ne biceribînim.
• Zehmettir e ku meriv bi girêdanên derveyî re bixebite.
• Ji min re pergalên kontrola guhertoya xweya virtual hewce dike.

Bê guman, van xalan hemî rastdar in. Ev di her du rewşan de jî diqewime - di polîrepository de ez nefsa xwe ya xwe heye, ji bilî ya ku ji bo çêkirinê hewce ye... Dibe ku ji min re nefsa din jî hewce bike. Ji ber vê yekê ez "bi tenê" amûrên ku tevahiya projeyê kontrol dikin diafirînim. An jî ez bi submodulan monorepository sexte diafirînim. Em dikarin tevahiya rojê li vê derê bimeşin. Lê ez difikirim ku argumana Matt sedema bingehîn ji bîr dike, ya ku min bi giranî di berjewendiya monorepository de hejand:

Têkiliyê provoke dike û pirsgirêkan nîşan dide

Dema ku em depoyan ji hev vediqetînin, em defakto pirsgirêkek hevrêzî û zelalbûnê çêdikin. Ev bi awayê ku em di derbarê tîmê de difikirin re têkildar e (nemaze awayê ku endamên kesane li ser wan difikirin): em ji pêkhateyek diyar berpirsiyar in. Em di bin tecrîdê de dixebitin. Sînor li ser tîmê min û pêkhateya (yên) ku em li ser dixebitin têne rast kirin.

Her ku mîmarî tevlihevtir dibe, yek tîm nema dikare wê bi tenê birêve bibe. Pir hindik endezyar di serê wan de tevahiya pergalê heye. Ka em bibêjin hûn pêkhateyek A ya hevpar a ku ji hêla Tîmên B, C, û D ve tê bikar anîn îdare dikin. Tîma A ji nû ve çêdike, API-yê baştir dike, û di heman demê de pêkanîna hundurîn jî diguhezîne. Wekî encamek, guhertin bi paş ve ne lihevhatî ne. Çi şîretên te hene?

• Hemî cihên ku API-ya kevn tê bikar anîn bibînin.
• Cihên ku API-ya nû nayê bikar anîn hene?
• Ma hûn dikarin hêmanên din rast bikin û biceribînin da ku pê ewle bibin ku ew neşikestin?
• Ma ev tîm dikarin niha guhertinên we biceribînin?

Ji kerema xwe not bikin ku ev pirs ji celebê depoyê serbixwe ne. Hûn ê hewce bikin ku tîmên B, C û D bibînin. Hûn ê hewce bikin ku bi wan re bipeyivin, wextê bibînin, pêşîniyên wan fêm bikin. Bi kêmanî em hêvî dikin ku hûn bikin.

Bi rastî kes naxwaze vê yekê bike. Ev ji rastkirina API-ya lanet pir kêmtir kêfê ye. Ew hemî mirovî û tevlihev e. Di polîrepository de, hûn dikarin bi tenê guheztinan bikin, bidin kesên ku li ser wê hêmanê dixebitin (dibe ku ne B, C an D) ji bo vekolînê, û bimeşin. Tîmên B, C û D tenê dikarin heya niha bi guhertoya xweya heyî re bimînin. Dema ku ew jêhatiya we fam bikin dê werin nûkirin!

Di monorepository de, berpirsiyarî ji hêla xwerû ve tê guheztin. Tîma A pêkhateya xwe diguherîne û, heke ne baldar be, tavilê B, C û D dişikîne. Ev dibe sedem ku B, C û D li ber deriyê A-yê xuya bibin, meraq dikin ka çima Tîma A meclîs şikand. Ev A hîn dike ku ew nikanin navnîşa min a jorîn derbas bikin. Divê ew biaxivin ka ew ê çi bikin. Ma B, C û D dikarin tevbigerin? Ger B û C dikarin, lê D ji nêz ve bi bandorek algorîtmaya kevin ve girêdayî bû?

Wê demê divê em biaxivin ka em ê çawa ji vê rewşê derkevin:

1. Piştgiriya ji bo gelek API-yên hundurîn, û dê algorîtmaya kevin wekî paşverû nîşan bide heya ku D bikaribe dev ji karanîna wê berde.
2. Piştgiriya ji bo gelek guhertoyên serbestberdanê, yek bi navgîniya kevn, yek bi ya nû.
3. Dereng berdana guhertinên A-yê ta ku B, C û D di heman demê de wê qebûl bikin.

Ka em bibêjin me 1, çend API hilbijartiye. Di vê rewşê de em du perçeyên kodê hene. Kevin û nû. Di hin rewşan de pir hêsan e. Em koda kevn ji nû ve kontrol dikin, wê wekî beredayî nîşan didin, û bi tîmê D re li ser nexşeyek rakirinê di bingeh de ji bo depoyên polî û mono yeksan in.

Ji bo berdana gelek guhertoyan, em şaxek hewce ne. Naha du pêkhateyên me hene - A1 û A2. Tîmên B û C A2 û D A1 bikar tînin. Em hewce ne ku her pêkhateyek ji bo serbestberdanê amade be ji ber ku dibe ku nûvekirinên ewlehiyê û rastkirinên din ên xeletiyan hewce bike berî ku D pêşde biçe. Di polîrepository de, em dikarin vê yekê di şaxek demdirêj a ku xweş hîs dike veşêrin. Di monorepository de, em zorê didin kodê ku di modulek nû de were afirandin. Tîma D hîn jî neçar e ku di beşa "kevn" de guhertinan bike. Her kes dikare lêçûna ku em li vir didin bibînin - naha du caran koda me heye, û her rastkirinên xeletiyên ku ji A1 û A2 re derbas dibin divê ji her duyan re derbas bibin. Bi nêzîkbûna şaxkirinê re di polîrepository de, ev li pişt hilbijarka kiraz veşartî ye. Em lêçûn kêmtir dihesibînin ji ber ku dubarebûn tune. Ji helwestek pratîkî ve, lêçûn yek e: hûn ê du bingehên kodê yên bi piranî wekhev ava bikin, berdin û biparêzin heya ku hûn nikaribin yek ji wan jêbirin. Cûdahî ew e ku bi monorepository re ev êş rasterast û xuya ye. Ev hê xerabtir e, û ew baş e.

Di dawiyê de, em gihîştin xala sêyemîn. Dereng berdan. Dibe ku guhertinên ku ji hêla A ve hatine çêkirin dê jiyana Tîma A çêtir bikin. Girîng e, lê ne lezgîn e. Ma em dikarin tenê dereng bikin? Di polîrepository de, em vê yekê dişoxilînin da ku hunerê pîne bikin. Bê guman em vê yekê ji Tîma D re dibêjin. Tenê li ser guhertoya kevn bimînin heya ku hûn bigihîjin! Ev we dihêle ku hûn tirsonek bilîzin. Tîma A berdewam dike ku li ser pêkhateya xwe bixebite, guh nade vê yekê ku Tîma D guhertoyek her ku diçe kevnar bikar tîne (ew pirsgirêka Tîma D ye, ew bêaqil in). Di vê navberê de, Tîma D li ser helwesta bêhiş a Tîma A ya li hember aramiya kodê xirab diaxive, heke ew qet qala wê bikin. Meh derbas dibin. Di dawiyê de, Tîma D biryar dide ku li îhtîmala nûvekirinê binêre, lê A tenê bêtir guhertin heye. Tîma A bi zor tê bîra xwe kengê an çawa wan D şikand. Nûvekirin bi êştir e û dê demek dirêj dirêj bike. Ya ku wê di stûyê pêşîn de bêtir dişîne. Heya roja ku me li A-yê pirsgirêkek ewlehiyê heye ku me neçar dike ku şaxek çêbikin. Tîma A divê di wextê xwe de vegere, xalek bibîne dema ku D aram bû, pirsgirêkê li wir rast bike û wê ji bo berdanê amade bike. Ev hilbijartina defakto ye ku mirov dike, û ew ji dûr ve ya herî xirab e. Wusa dixuye ku hem ji bo Tîma A û hem jî ji bo Tîma D baş e heya ku em dikarin hevûdu paşguh bikin.

Di monorepository de, ya sêyemîn bi rastî ne vebijarkek e. Hûn neçar in ku bi yek ji du awayan bi rewşê re mijûl bibin. Pêdivî ye ku hûn lêçûnên hebûna du şaxên berdanê bibînin. Fêr bibin ku xwe ji nûvekirinên ku lihevhatina paşverû dişkînin biparêzin. Lê ya herî girîng: hûn nikarin xwe ji sohbeteke dijwar dûr bixin.

Di ezmûna min de, dema ku tîm mezin dibin, êdî ne gengaz e ku meriv tevahiya pergalê di hişê xwe de bihêle, û ew beşa herî girîng e. Divê hûn di pergalê de dîtina nakokiyê baştir bikin. Pêdivî ye ku hûn bi rengek çalak bixebitin da ku tîmê ji pêkhateyên xwe dûr bixin û li xebata tîm û xerîdarên din binêrin.

Erê, hûn dikarin amûrên ku hewl didin ku pirsgirêka polyrepository çareser bikin biafirînin. Lê ezmûna min hînkirina radestkirin û otomasyona domdar di pargîdaniyên mezin de ji min re vê yekê vedibêje: behreya xwerû bêyî karanîna amûrên pêvek behreya ku hûn li bendê ne ku bibînin e. Tevgera xwerû ya polîrepository veqetandî ye, ew hemî xal e. Tevgera xwerû ya monorepository berpirsiyarî û şefafî hevpar e, xala tevahî ev e. Di her du rewşan de, ez ê amûrek biafirînim ku dê keviyên zirav xweş bike. Wekî rêber, ez ê her carê monorepository hilbijêrin ji ber ku amûr hewce ne ku çanda ku ez dixwazim xurt bikin, û çand ji biryarên piçûk û xebata rojane ya tîmê tê.

Tenê bikarhênerên qeydkirî dikarin beşdarî anketê bibin. Têketinji kerema xwe.

Fanatîkên herî mezin kî ne? Piştgir:

• Monorepo

• Zingar

• Anketa çewt / herdu

33 bikarhêneran deng dan. 13 bikarhêner jî betal bûn.

Source: www.habr.com