Traduko de la artikolo preparita por kursanoj "DevOps-praktikoj kaj iloj" en la eduka projekto OTUS.

Vi devus elekti monodeponejon ĉar la konduto, kiun ĝi antaŭenigas en viaj teamoj, estas travidebleco kaj komuna respondeco, precipe kiam teamoj kreskas. Kiel ajn, vi devos investi en ilaro, sed ĉiam estas pli bone se la defaŭlta konduto estas la konduto, kiun vi volas en viaj komandoj.

Kial ni parolas pri ĉi tio?

Matt Klein skribis la artikolon "Monorepos: Bonvolu ne!"  (noto de la tradukinto: traduko pri Habré "Monordeponejoj: bonvolu ne fari"). Mi ŝatas Matt, mi pensas ke li estas tre saĝa kaj vi devus legi lian vidpunkton. Li origine publikigis la balotenketon sur Twitter:

Tradukado:
Ĉi tiu novjara tago, mi argumentos pri kiom ridindaj estas monodeponejoj. 2019 komenciĝis trankvile. En la spirito de ĉi tio, mi proponas al vi enketon. Kiuj estas la grandaj fanatikuloj? Subtenantoj:
- Monorepo
- rustiĝi
- Malĝusta balotado / ambaŭ

Mia respondo estis, "Mi estas laŭvorte ambaŭ tiuj homoj." Anstataŭ paroli pri kiel Rust estas drogo, ni rigardu kial mi pensas, ke li eraras pri monodeponejoj. Iom pri vi mem. Mi estas la CTO de Chef Software. Ni havas ĉirkaŭ 100 inĝenierojn, kodan bazon malantaŭen ĉirkaŭ 11-12 jarojn, kaj 4 ĉefajn produktojn. Iuj el ĉi tiu kodo estas en polideponejo (mia komenca pozicio), iuj estas en monodeponejo (mia nuna pozicio).

Antaŭ ol mi komenci: ĉiu argumento, kiun mi prezentas ĉi tie, aplikiĝos al ambaŭ specoj de deponejoj. Miaopinie, ne ekzistas teknika kialo, kial vi elektu unu tipon de deponejo super alia. Vi povas fari ajnan aliron funkcii. Mi volonte parolas pri tio, sed mi ne interesiĝas pri artefaritaj teknikaj kialoj, kial unu superas la alian.

Mi konsentas kun la unua parto de la punkto de Matt:

Ĉar laŭskale, monodeponejo solvos ĉiujn samajn problemojn, kiujn polideponejo solvas, sed samtempe devigas vin firme kunligi vian kodon kaj postulos nekredeblajn klopodojn por pliigi la skaleblon de via versio-kontrolsistemo.

Vi devos solvi la samajn problemojn sendepende de ĉu vi elektas monodeponejon aŭ polideponejon. Kiel vi publikigas eldonojn? Kio estas via aliro al ĝisdatigoj? Malantaŭa kongruo? Transprojektaj dependecoj? Kiuj arkitekturaj stiloj estas akcepteblaj? Kiel vi administras vian konstruan kaj testan infrastrukturon? La listo estas senfina. Kaj vi solvos ilin ĉiujn dum vi kreskos. Ne estas senpaga fromaĝo.

Mi pensas, ke la argumento de Matt similas al vidoj kundividitaj de multaj inĝenieroj (kaj administrantoj) kiujn mi respektas. Ĉi tio okazas de la perspektivo de la inĝeniero laboranta pri la komponento aŭ la teamo laboranta pri la komponento. Vi aŭdas aferojn kiel:

• La kodbazo estas dika - mi ne bezonas ĉiujn ĉi rubaĵojn.
• Estas pli malfacile testi ĉar mi devas testi ĉiujn ĉi rubaĵojn, kiujn mi ne bezonas.
• Estas pli malfacile labori kun eksteraj dependecoj.
• Mi bezonas miajn proprajn virtualajn versiokontrolajn sistemojn.

Kompreneble, ĉiuj ĉi tiuj punktoj estas pravigitaj. Tio okazas en ambaŭ kazoj - en la polideponejo mi havas mian propran rubaĵon, krom tiu necesa por la konstruo... Mi eble bezonas ankaŭ aliajn rubaĵojn. Do mi "simple" kreas ilojn, kiuj kontrolas la tutan projekton. Aŭ mi kreas falsan monodeponejon kun submoduloj. Ni povus ĉirkaŭiri ĉi tion la tutan tagon. Sed mi pensas, ke la argumento de Matt maltrafas la ĉefan kialon, kiun mi renversis sufiĉe forte favore al la monodeponejo:

Ĝi provokas komunikadon kaj montras problemojn

Kiam ni apartigas deponejojn, ni kreas faktan problemon de kunordigo kaj travidebleco. Ĉi tio respondas al la maniero kiel ni pensas pri teamoj (precipe la maniero kiel individuaj membroj pensas pri ili): ni respondecas pri certa komponento. Ni laboras en relativa izoliteco. La limoj estas fiksitaj ĉe mia teamo kaj la komponanto(j) pri kiuj ni laboras.

Ĉar arkitekturo fariĝas pli kompleksa, unu teamo ne plu povas administri ĝin sole. Tre malmultaj inĝenieroj havas la tutan sistemon en sia kapo. Ni diru, ke vi administras komunan komponanton A, kiu estas uzata de Teamoj B, C kaj D. Teamo A refaktorigas, plibonigas la API kaj ankaŭ ŝanĝas la internan efektivigon. Kiel rezulto, la ŝanĝoj ne estas malantaŭen kongruaj. Kiun konsilon vi havas?

• Trovu ĉiujn lokojn, kie la malnova API estas uzata.
• Ĉu estas lokoj kie la nova API ne povas esti uzata?
• Ĉu vi povas ripari kaj testi aliajn komponantojn por certigi, ke ili ne rompas?
• Ĉu ĉi tiuj teamoj povas testi viajn ŝanĝojn nun?

Bonvolu noti, ke ĉi tiuj demandoj estas sendependaj de la deponejo. Vi devos trovi teamojn B, C kaj D. Vi devos paroli kun ili, ekscii la tempon, kompreni iliajn prioritatojn. Almenaŭ ni esperas, ke vi faros.

Neniu vere volas fari ĉi tion. Ĉi tio estas multe malpli amuza ol nur ripari la malbenitan API. Ĉio estas homa kaj senorda. En polideponejo, vi povas simple fari ŝanĝojn, doni ĝin al la homoj laborantaj pri tiu komponanto (verŝajne ne B, C aŭ D) por revizio, kaj pluiri. Teamoj B, C kaj D povas simple resti kun sia nuna versio nuntempe. Ili estos renovigitaj kiam ili rimarkos vian genion!

En monodeponejo, respondeco estas ŝanĝita defaŭlte. Teamo A ŝanĝas ilian komponenton kaj, se ne singarda, tuj rompas B, C kaj D. Tio kondukas al B, C kaj D prezentiĝanta ĉe la pordo de A, scivolante kial Teamo A rompis la kunigon. Ĉi tio instruas al A ke ili ne povas preterlasi mian liston supre. Ili devas paroli pri tio, kion ili faros. Ĉu B, C kaj D povas moviĝi? Kio se B kaj C povas, sed D estis proksime rilatita al kromefiko de la konduto de la malnova algoritmo?

Tiam ni devas paroli pri kiel ni eliros el ĉi tiu situacio:

1. Subteno por pluraj internaj API-oj, kaj markos la malnovan algoritmon kiel malrekomendita ĝis D povas ĉesi uzi ĝin.
2. Subteno por multoblaj eldonversioj, unu kun la malnova interfaco, unu kun la nova.
3. Prokrastu la liberigon de la ŝanĝoj de A ĝis B, C, kaj D povas samtempe akcepti ĝin.

Ni diru, ke ni elektis 1, plurajn APIojn. En ĉi tiu kazo ni havas du pecojn de kodo. Malnova kaj nova. Sufiĉe oportune en iuj situacioj. Ni kontrolas la malnovan kodon reen, markas ĝin kiel malrekomendita, kaj konsentas pri foriga horaro kun la D-teamo. Esence identa por poli- kaj mono-deponejoj.

Por liberigi plurajn versiojn, ni bezonas branĉon. Nun ni havas du komponantojn - A1 kaj A2. Teamoj B kaj C uzas A2 kaj D uzas A1. Ni bezonas, ke ĉiu komponanto estu preta por liberigo ĉar sekurecaj ĝisdatigoj kaj aliaj eraroj povas esti postulataj antaŭ ol D povas antaŭeniri. En polideponejo, ni povas kaŝi ĉi tion en longdaŭra branĉo, kiu sentas sin bone. En monodeponejo, ni devigas la kodon esti kreita en nova modulo. Teamo D ankoraŭ devos fari ŝanĝojn al la "malnova" komponento. Ĉiuj povas vidi la koston, kiun ni pagas ĉi tie - ni nun havas duoble pli da kodo, kaj ajnaj eraroj, kiuj validas por A1 kaj A2, devas validi por ambaŭ. Kun la disbranĉa aliro en polideponejo, ĉi tio estas kaŝita malantaŭ ĉeriz-elekto. Ni konsideras, ke la kosto estas pli malalta ĉar ne ekzistas duobligo. El praktika vidpunkto, la kosto estas la sama: vi konstruos, liberigos kaj konservos du plejparte identajn kodbazojn ĝis vi povos forigi unu el ili. La diferenco estas, ke kun monodeponejo ĉi tiu doloro estas rekta kaj videbla. Ĉi tio estas eĉ pli malbona, kaj tio estas bona.

Fine ni alvenis al la tria punkto. Eldonprokrasto. Eblas, ke ŝanĝoj faritaj de A plibonigos la vivon de Teamo A. Gravaj, sed ne urĝaj. Ĉu ni povas simple prokrasti? En polideponejo, ni puŝas ĉi tion por alpingli la artefakton. Kompreneble ni rakontas ĉi tion al Teamo D. Nur restu en la malnova versio ĝis vi atingos! Ĉi tio starigas vin ludi la malkuraĝulon. Teamo A daŭre laboras pri ilia komponento, ignorante la fakton ke Teamo D uzas ĉiam pli malmodernan version (tio estas la problemo de Team D, ili estas stultaj). Dume, Teamo D parolas nebone pri la senzorga sinteno de Team A al kodstabileco, se ili entute parolas pri ĝi. Monatoj pasas. Finfine, Teamo D decidas rigardi la eblecon de ĝisdatigo, sed A nur havas pli da ŝanĝoj. Teamo A apenaŭ memoras kiam aŭ kiel ili rompis D. La ĝisdatigo estas pli dolora kaj daŭros pli longe. Kiu sendas ĝin pli malsupre en la prioritata stako. Ĝis la tago, kiam ni havas sekurecan problemon en A, kiu devigas nin fari branĉon. Teamo A devas reiri en la tempo, trovi punkton, kiam D estis stabila, ripari la problemon tie kaj pretigi ĝin por liberigo. Ĉi tio estas la fakta elekto kiun homoj faras, kaj ĝi estas senkompare la plej malbona. Ĝi ŝajnas esti bona por kaj Teamo A kaj Teamo D tiel longe kiel ni povas ignori unu la alian.

En monodeponejo, la tria vere ne estas eblo. Vi estas devigita trakti la situacion en unu el du manieroj. Vi devas vidi la kostojn de havi du eldonbranĉojn. Lernu protekti vin kontraŭ ĝisdatigoj, kiuj rompas malantaŭan kongruecon. Sed plej grave: vi ne povas eviti havi malfacilan konversacion.

Laŭ mia sperto, kiam teamoj grandiĝas, ne plu eblas memori la tutan sistemon, kaj tio estas la plej grava parto. Vi devas plibonigi la videblecon de malkonkordo en la sistemo. Vi devas aktive labori por ke teamoj forrigardu de siaj komponantoj kaj rigardu la laboron de aliaj teamoj kaj konsumantoj.

Jes, vi povas krei ilojn, kiuj provas solvi la problemon de polideponejo. Sed mia sperto instruanta kontinuan liveron kaj aŭtomatigon en grandaj entreprenoj diras al mi ĉi tion: la defaŭlta konduto sen la uzo de pliaj iloj estas la konduto, kiun vi atendas vidi. La defaŭlta konduto de polideponejo estas izolado, jen la tuta afero. La defaŭlta konduto de monodeponejo estas komuna respondeco kaj travidebleco, jen la tuta afero. En ambaŭ kazoj, mi kreos ilon, kiu glatigos la malglatajn randojn. Kiel gvidanto, mi elektos monodeponejon ĉiufoje ĉar la iloj bezonas plifortigi la kulturon, kiun mi volas, kaj kulturo venas de etaj decidoj kaj la ĉiutaga laboro de la teamo.

Nur registritaj uzantoj povas partopreni la enketon. Ensaluti, bonvolu.

Kiuj estas la plej grandaj fanatikuloj? Subtenantoj:

• Monorepo

• rustiĝi

• Malĝusta balotado / ambaŭ

33 uzantoj voĉdonis. 13 uzantoj sindetenis.

fonto: www.habr.com