Iwwersetzung vum Artikel virbereet fir Course Studenten "DevOps Praktiken an Tools" am OTUS pädagogesche Projet.

Dir sollt e Monorepository wielen well d'Verhalen dat et an Ären Teams fördert ass Transparenz a gemeinsame Verantwortung, besonnesch wann d'Teams wuessen. Egal wéi, Dir musst an Tooling investéieren, awer et ass ëmmer besser wann de Standardverhalen dat Verhalen ass wat Dir an Äre Kommandoen wëllt.

Firwat schwätzen mir iwwer dëst?

De Matt Klein huet den Artikel geschriwwen "Monorepos: W.e.g. net!"  (Note vum Iwwersetzer: Iwwersetzung op Habré "Monorepositories: w.e.g. net"). Ech hunn de Matt gär, ech mengen hien ass ganz schlau an Dir sollt säi Standpunkt liesen. Hien huet ursprénglech d'Ëmfro op Twitter gepost:

Iwwersetzung:
Dësen Neijoerschdag wäert ech streiden iwwer wéi lächerlech Monorepositories sinn. 2019 huet roueg ugefaangen. Am Sënn vun dësem bidden ech Iech eng Ëmfro un. Wien sinn déi grouss Fanatiker? Supporter:
- Monorepo
- Rust
- Falsch Ëmfro / souwuel

Meng Äntwert war: "Ech si wuertwiertlech béid vun deene Leit." Amplaz ze schwätzen iwwer wéi Rust en Medikament ass, loosst eis kucken firwat ech mengen datt hien iwwer Monorepositories falsch ass. E bëssen iwwer Iech selwer. Ech sinn den CTO vu Chef Software. Mir hunn ongeféier 100 Ingenieuren, eng Codebasis déi ongeféier 11-12 Joer zréck geet, a 4 Haaptprodukter. E puer vun dësem Code ass an engem Polyrepository (meng Startpositioun), e puer ass an engem Monorepository (meng aktuell Positioun).

Ier ech ufänken: all Argument, dat ech hei maachen, gëlt fir béid Aarte vu Repositories. Menger Meenung no gëtt et keen technesche Grond firwat Dir eng Zort Repository iwwer en aneren sollt wielen. Dir kënnt all Approche maachen. Ech sinn frou doriwwer ze schwätzen, mee ech interesséieren mech net u kënschtlechen technesche Grënn firwat een dem aneren iwwerleeën ass.

Ech averstanen mam éischten Deel vum Matt sengem Punkt:

Well op Skala wäert e Monorepository all déiselwecht Probleemer léisen, déi e Polyrepository léist, awer gläichzäiteg forcéiert Iech Äre Code enk ze koppelen an onheemlech Efforte erfuerderen fir d'Skalierbarkeet vun Ärem Versiounskontrollsystem ze erhéijen.

Dir musst déiselwecht Probleemer léisen, egal ob Dir e Monorepository oder e Polyrepository wielt. Wéi verëffentlecht Dir Verëffentlechungen? Wat ass Är Approche fir Updates? Réckkompatibilitéit? Kräiz Projet Ofhängegkeeten? Wéi eng architektonesch Stiler sinn akzeptabel? Wéi verwalt Dir Är Bau- an Testinfrastruktur? D'Lëscht ass endlos. An Dir wäert se all léisen wéi Dir wuessen. Et gëtt kee gratis Kéis.

Ech mengen dem Matt säin Argument ass ähnlech wéi Meenungen, déi vu villen Ingenieuren (a Manager) gedeelt ginn, déi ech respektéieren. Dëst geschitt aus der Perspektiv vum Ingenieur deen un der Komponent schafft oder dem Team dat un der Komponent schafft. Dir héiert Saachen wéi:

• D'Codebase ass voluminös - ech brauch net all dës Dreck.
• Et ass méi schwéier ze testen well ech all dës Dreck muss testen déi ech net brauch.
• Et ass méi schwéier mat externen Ofhängegkeeten ze schaffen.
• Ech brauch meng eege virtuell Versioun Kontroll Systemer.

Natierlech sinn all dës Punkte gerechtfäerdegt. Dëst geschitt a béide Fäll - am Polyrepository hunn ech meng eegen Dreck, zousätzlech zu deem wat fir de Bau gebraucht gëtt ... Ech brauch vläicht och aner Dreck. Also ech erstellen "einfach" Tools déi de ganze Projet iwwerpréiwen. Oder ech erstellen e gefälschte Monorepository mat Submodulen. Mir kéinten de ganzen Dag ronderëm goen. Awer ech mengen dem Matt säin Argument vermësst den Haaptgrond, deen ech zimlech schwéier fir de Monorepository ëmgedréint hunn:

Et provozéiert Kommunikatioun a weist Problemer

Wa mir Repositories trennen, kreéiere mir e de facto Problem vu Koordinatioun an Transparenz. Dëst entsprécht der Aart a Weis wéi mir iwwer Teams denken (besonnesch wéi déi eenzel Memberen iwwer si denken): mir si fir e bestëmmte Volet verantwortlech. Mir schaffen a relativ Isolatioun. D'Grenze si fest op meng Equipe an de Komponent(en) un deem mir schaffen.

Wéi d'Architektur méi komplex gëtt, kann een Team et net méi eleng managen. Ganz wéineg Ingenieuren hunn de ganze System am Kapp. Loosst eis soen datt Dir e gemeinsame Komponent A verwalt deen vun den Teams B, C, an D benotzt gëtt. Team A refactoréiert, verbessert d'API, an ännert och déi intern Implementatioun. Als Resultat sinn d'Ännerungen net zréckkompatibel. Wéi eng Rotschléi hutt Dir?

• Fannt all Plazen wou déi al API benotzt gëtt.
• Ginn et Plazen wou déi nei API net benotzt ka ginn?
• Kënnt Dir aner Komponenten fixéieren an testen fir sécher ze sinn datt se net briechen?
• Kënnen dës Équipë Är Ännerungen elo testen?

Notéiert w.e.g. datt dës Froen onofhängeg vum Repositorytyp sinn. Dir musst d'Equipe B, C an D fannen. Dir musst mat hinnen schwätzen, d'Zäit erausfannen, hir Prioritéite verstoen. Op d'mannst hoffen mir datt Dir wäert.

Keen wëll dat wierklech maachen. Dëst ass vill manner Spaass wéi just déi verdammt API ze fixéieren. Et ass alles mënschlech a knaschteg. An engem Polyrepository kënnt Dir einfach Ännerungen maachen, et un de Leit ginn, déi un deem Komponent schaffen (wahrscheinlech net B, C oder D) fir ze iwwerpréiwen, a weidergoen. D'Equipe B, C an D kënne fir de Moment just bei hirer aktueller Versioun bleiwen. Si ginn erneiert wann se Äert Genie realiséieren!

An engem Monorepository gëtt d'Verantwortung als Standard verréckelt. D'Equipe A ännert hir Komponent an, wann net virsiichteg, brécht direkt B, C an D. Dëst féiert dozou, datt B, C an D bei der Dier vun A opdauchen, a sech froen, firwat d'Equipe A d'Versammlung gebrach huet. Dëst léiert A datt se meng Lëscht hei uewen net iwwersprangen kënnen. Si musse schwätzen iwwer wat se maachen. Kann B, C an D bewegen? Wat wann B an C kann, mee D war enk Zesummenhang mat enger Säit Effekt vun der aler Algorithmus Verhalen?

Da musse mir schwätzen iwwer wéi mir aus dëser Situatioun kommen:

1. Ënnerstëtzung fir verschidde intern APIen, a markéiert den alen Algorithmus als ofgeschaaft bis D et ophale kann ze benotzen.
2. Ënnerstëtzung fir verschidde Verëffentlechungsversioune, eng mat der aler Interface, eng mat der neier.
3. Verspéid d'Verëffentlechung vun den Ännerungen vun A bis B, C an D et gläichzäiteg akzeptéiere kënnen.

Loosst eis soen datt mir 1 ausgewielt hunn, verschidde APIen. An dësem Fall hu mir zwee Stéck Code. Al an nei. Ganz bequem an e puer Situatiounen. Mir kontrolléieren den ale Code zréck, markéieren et als ofgeschaaft, a stëmmen iwwer e Entfernungsplang mat der D-Team Wesentlech identesch fir Poly- a Mono-Repositories.

Fir verschidde Versiounen ze verëffentlechen, brauche mir eng Branche. Elo hu mir zwee Komponenten - A1 an A2. D'Equipe B an C benotzen A2 an D benotzt A1. Mir brauchen all Komponent prett fir d'Verëffentlechung ze sinn, well Sécherheetsupdates an aner Bugfixes erfuerderlech kënne sinn ier D no vir ka goen. An engem Polyrepository kënne mir dëst an enger laanglieweger Branche verstoppen déi gutt fillt. An engem Monorepository forcéiere mir de Code fir an engem neie Modul erstallt ze ginn. D'Equipe D muss nach ëmmer Ännerungen un der "aler" Komponent maachen. Jidderee kann d'Käschte gesinn, déi mir hei bezuelen - mir hunn elo duebel sou vill Code, an all Bugfixes, déi op A1 an A2 gëllen, mussen op déi zwee gëllen. Mat der Verzweigungs Approche an engem Polyrepository ass dëst hannert Kiischte verstoppt. Mir betruechten d'Käschte méi niddereg well et keng Duplikatioun ass. Vun engem praktesche Standpunkt sinn d'Käschte d'selwecht: Dir wäert zwee gréisstendeels identesch Codebasen bauen, befreien an ënnerhalen bis Dir ee vun hinnen läsche kënnt. Den Ënnerscheed ass datt mat engem Monorepository dëse Schmerz direkt a sichtbar ass. Dëst ass nach méi schlëmm, an dat ass gutt.

Schlussendlech si mer zum drëtte Punkt ukomm. Fräisetzung Verspéidung. Et ass méiglech datt d'Ännerunge vun A d'Liewe vum Team A verbesseren. Wichteg, awer net dréngend. Kënne mir just verzögeren? An engem Polyrepository drécke mir dëst fir den Artefakt ze pin. Natierlech erziele mir dat dem Team D. Bleift einfach op der aler Versioun bis Dir matkritt! Dëst setzt Iech op fir de Feigling ze spillen. Team A schafft weider un hirer Komponent, ignoréiert d'Tatsaach datt d'Team D eng ëmmer méi al Versioun benotzt (dat ass de Problem vum Team D, si sinn domm). Mëttlerweil schwätzt d'Team D schlecht iwwer dem Team A seng suergfälteg Haltung zu Codestabilitéit, wa se iwwerhaapt doriwwer schwätzen. Méint passéieren. Endlech decidéiert Team D d'Méiglechkeet vun engem Update ze kucken, awer A huet nëmmen méi Ännerungen. D'Team A erënnert sech kaum wéini oder wéi se gebrach hunn D. D'Upgrade ass méi schmerzhaf a wäert méi laang daueren. Wat schéckt et weider op de Prioritéit Stack. Bis den Dag wou mir e Sécherheetsprobleem an A hunn, déi eis forcéiere fir eng Branche ze maachen. D'Team A muss zréck an d'Zäit goen, e Punkt fannen wann D stabil war, de Problem do fixéieren an et fäerdeg maachen fir d'Verëffentlechung. Dëst ass déi de facto Wiel déi d'Leit maachen, an et ass bei wäitem dat Schlëmmst. Et schéngt gutt fir d'Equipe A an d'Team D ze sinn, soulaang mir all aner ignoréiere kënnen.

An engem Monorepository ass déi drëtt wierklech keng Optioun. Dir sidd gezwongen mat der Situatioun op eng vun zwou Weeër ze këmmeren. Dir musst d'Käschte gesinn fir zwee Verëffentlechungszweige ze hunn. Léiert Iech selwer virun Updates ze schützen déi Réckkompatibilitéit briechen. Awer am wichtegsten: Dir kënnt e schwieregen Gespréich net vermeiden.

Menger Erfahrung, wann Équipë grouss ginn, ass et net méi méiglech de ganze System am Kapp ze halen, an dat ass dee wichtegsten Deel. Dir musst d'Visibilitéit vum Diskord am System verbesseren. Dir musst aktiv schaffen fir Teams ze kréien fir vun hire Komponenten ewech ze kucken an d'Aarbecht vun aneren Teams a Konsumenten ze kucken.

Jo, Dir kënnt Tools erstellen déi probéieren de Polyrepository Problem ze léisen. Awer meng Erfahrung, déi kontinuéierlech Liwwerung an Automatisatioun a grousse Entreprisen léiert, seet mir dëst: d'Standardverhalen ouni d'Benotzung vun zousätzlech Tools ass d'Verhalen, déi Dir erwaart ze gesinn. De Standardverhalen vun engem Polyrepository ass Isolatioun, dat ass de ganze Punkt. De Standardverhalen vun engem Monorepository ass gemeinsam Verantwortung an Transparenz, dat ass de ganze Punkt. A béide Fäll wäert ech e Tool erstellen deen déi rau Kanten glatt. Als Leader wäert ech all Kéier e Monorepository wielen well d'Tools brauchen fir d'Kultur ze verstäerken déi ech wëll, an d'Kultur kënnt aus klengen Entscheedungen an der alldeeglecher Aarbecht vum Team.

Nëmme registréiert Benotzer kënnen un der Ëmfro deelhuelen. Umellen, wann ech glift.

Wien sinn déi gréisste Fanatiker? Supporter:

• Monorepo

• Rust

• Falsch Ëmfro / souwuel

33 Benotzer hunn gestëmmt. 13 Benotzer hu sech enthalen.

Source: will.com