Oversættelse af artiklen udarbejdet til kursister "DevOps-praksis og værktøjer" i OTUS uddannelsesprojekt.

Du bør vælge et monolager, fordi den adfærd, det fremmer i dine teams, er gennemsigtighed og delt ansvar, især når teams vokser. Uanset hvad, bliver du nødt til at investere i værktøj, men det er altid bedre, hvis standardadfærden er den adfærd, du ønsker i dine kommandoer.

Hvorfor taler vi om dette?

Matt Klein skrev artiklen "Monorepos: Lad være med det!"  (oversætterens note: oversættelse på Habré "Monorepositories: lad være med det"). Jeg kan godt lide Matt, jeg synes, han er meget klog, og du bør læse hans synspunkt. Han postede oprindeligt afstemningen på Twitter:

Oversættelse:
Denne nytårsdag vil jeg skændes om, hvor latterlige monorepositories er. 2019 startede stille og roligt. I dennes ånd tilbyder jeg dig en undersøgelse. Hvem er de store fanatikere? Supportere:
— Monorepo
— Rust
— Forkert afstemning / begge dele

Mit svar var: "Jeg er bogstaveligt talt begge disse mennesker." I stedet for at tale om, hvordan Rust er et stof, så lad os se på, hvorfor jeg tror, ​​han tager fejl med hensyn til monorepositories. Lidt om dig selv. Jeg er CTO for Chef Software. Vi har omkring 100 ingeniører, en kodebase, der går omkring 11-12 år tilbage, og 4 hovedprodukter. Noget af denne kode er i et polyrepository (min startposition), noget er i et monorepository (min nuværende position).

Før jeg begynder: hvert argument, jeg kommer med her, vil gælde for begge slags arkiver. Efter min mening er der ingen teknisk grund til, at du skal vælge en type repository frem for en anden. Du kan få enhver tilgang til at fungere. Jeg taler gerne om det, men jeg er ikke interesseret i kunstige tekniske årsager til, at den ene er en anden overlegen.

Jeg er enig i den første del af Matts pointe:

For i stor skala vil et monolager løse alle de samme problemer, som et polyrepository løser, men samtidig tvinge dig til at koble din kode tæt og kræve en utrolig indsats for at øge skalerbarheden af ​​dit versionskontrolsystem.

Du bliver nødt til at løse de samme problemer, uanset om du vælger et monodepot eller et polydepot. Hvordan udgiver du udgivelser? Hvad er din tilgang til opdateringer? Bagudkompatibilitet? Afhængigheder på tværs af projekter? Hvilke arkitektoniske stilarter er acceptable? Hvordan administrerer du din bygge- og testinfrastruktur? Listen er uendelig. Og du vil løse dem alle, efterhånden som du vokser. Der er ingen gratis ost.

Jeg tror, ​​at Matts argument ligner synspunkter, der deles af mange ingeniører (og ledere), jeg respekterer. Dette sker fra ingeniørens perspektiv, der arbejder på komponenten, eller teamet, der arbejder på komponenten. Du hører ting som:

• Kodebasen er omfangsrig - jeg har ikke brug for alt dette skrammel.
• Det er sværere at teste, fordi jeg skal teste alt det skrammel, som jeg ikke har brug for.
• Det er sværere at arbejde med eksterne afhængigheder.
• Jeg har brug for mine egne virtuelle versionskontrolsystemer.

Selvfølgelig er alle disse punkter berettigede. Dette sker i begge tilfælde - i polyrepository har jeg mit eget skrammel, udover det, der er nødvendigt til opbygningen... Jeg kan også have brug for andet skrammel. Så jeg laver "simpelthen" værktøjer, der tjekker hele projektet. Eller jeg opretter et falsk monorepository med undermoduler. Vi kunne gå rundt her hele dagen. Men jeg tror, ​​Matts argument går glip af hovedårsagen, som jeg vendte ret kraftigt til fordel for monorepository:

Det fremkalder kommunikation og viser problemer

Når vi adskiller depoter, skaber vi et de facto-problem med koordinering og gennemsigtighed. Dette svarer til den måde, vi tænker om teams på (især den måde, individuelle medlemmer tænker om dem): vi er ansvarlige for en bestemt komponent. Vi arbejder relativt isoleret. Grænserne er faste på mit team og den/de komponent(er), vi arbejder på.

Efterhånden som arkitekturen bliver mere kompleks, kan ét team ikke længere styre den alene. Meget få ingeniører har hele systemet i hovedet. Lad os sige, at du administrerer en delt komponent A, der bruges af hold B, C og D. Team A refaktorerer, forbedrer API'en og ændrer også den interne implementering. Som følge heraf er ændringerne ikke bagudkompatible. Hvilket råd har du?

• Find alle steder, hvor den gamle API bruges.
• Er der steder, hvor den nye API ikke kan bruges?
• Kan du reparere og teste andre komponenter for at sikre, at de ikke går i stykker?
• Kan disse teams teste dine ændringer lige nu?

Bemærk venligst, at disse spørgsmål er uafhængige af depottypen. Du bliver nødt til at finde hold B, C og D. Du bliver nødt til at tale med dem, finde ud af tidspunktet, forstå deres prioriteter. Det håber vi i hvert fald, du vil.

Ingen ønsker virkelig at gøre dette. Dette er meget mindre sjovt end bare at reparere den forbandede API. Det hele er menneskeligt og rodet. I et polyrepository kan du blot foretage ændringer, give det til de personer, der arbejder på den komponent (sandsynligvis ikke B, C eller D) til gennemgang, og gå videre. Hold B, C og D kan bare forblive med deres nuværende version indtil videre. De vil blive fornyet, når de indser dit geni!

I et monolager flyttes ansvaret som standard. Hold A ændrer deres komponent og bryder, hvis ikke forsigtigt, straks B, C og D. Dette fører til, at B, C og D dukker op ved A's dør og undrer sig over, hvorfor hold A brød samlingen. Dette lærer A, at de ikke kan springe over min liste ovenfor. De skal tale om, hvad de skal gøre. Kan B, C og D bevæge sig? Hvad hvis B og C kan, men D var tæt forbundet med en bivirkning af den gamle algoritmes adfærd?

Så må vi tale om, hvordan vi kommer ud af denne situation:

1. Understøtter flere interne API'er og vil markere den gamle algoritme som forældet, indtil D kan stoppe med at bruge den.
2. Understøttelse af flere udgivelsesversioner, en med den gamle grænseflade, en med den nye.
3. Udsæt frigivelsen af ​​A's ændringer, indtil B, C og D samtidigt kan acceptere det.

Lad os sige, at vi har valgt 1, flere API'er. I dette tilfælde har vi to stykker kode. Gammelt og nyt. Ganske praktisk i nogle situationer. Vi tjekker den gamle kode ind igen, markerer den forældet og aftaler en tidsplan for fjernelse med D-teamet. Grundlæggende identisk for poly- og mono-lagre.

For at frigive flere versioner har vi brug for en filial. Nu har vi to komponenter - A1 og A2. Hold B og C bruger A2 og D bruger A1. Vi har brug for, at hver komponent er klar til udgivelse, fordi sikkerhedsopdateringer og andre fejlrettelser kan være nødvendige, før D kan komme videre. I et polyrepository kan vi skjule dette i en langlivet gren, der føles godt. I et monolager tvinger vi koden til at blive oprettet i et nyt modul. Hold D skal stadig foretage ændringer i den "gamle" komponent. Alle kan se de omkostninger, vi betaler her - vi har nu dobbelt så meget kode, og eventuelle fejlrettelser, der gælder for A1 og A2, skal gælde for dem begge. Med forgreningstilgangen i et polyrepository er dette skjult bag cherry-pick. Vi anser omkostningerne for at være lavere, fordi der ikke er nogen overlapning. Fra et praktisk synspunkt er omkostningerne de samme: du bygger, frigiver og vedligeholder to stort set identiske kodebaser, indtil du kan slette en af ​​dem. Forskellen er, at med et monodepot er denne smerte direkte og synlig. Det er endnu værre, og det er godt.

Til sidst kom vi til det tredje punkt. Frigivelsesforsinkelse. Det er muligt, at ændringer foretaget af A vil forbedre livet for hold A. Vigtigt, men ikke presserende. Kan vi bare forsinke? I et polyrepository skubber vi dette for at fastgøre artefakten. Selvfølgelig fortæller vi dette til Team D. Bare bliv på den gamle version, indtil du indhenter det! Dette sætter dig op til at spille kujon. Team A fortsætter med at arbejde på deres komponent og ignorerer det faktum, at Team D bruger en stadig mere forældet version (det er Team Ds problem, de er dumme). I mellemtiden taler Team D dårligt om Team A's skødesløse holdning til kodestabilitet, hvis de overhovedet taler om det. Måneder går. Til sidst beslutter Team D sig for at se på muligheden for opdatering, men A har kun flere ændringer. Hold A husker knap, hvornår eller hvordan de brød D. Opgraderingen er mere smertefuld og vil tage længere tid. Hvilket sender det længere ned i prioriteret stakken. Indtil den dag, vi har et sikkerhedsproblem i A, der tvinger os til at lave en filial. Hold A skal gå tilbage i tiden, finde et punkt, hvor D var stabil, løse problemet der og gøre det klar til udgivelse. Dette er det de facto-valg, folk træffer, og det er langt det værste. Det ser ud til at være godt for både hold A og hold D, så længe vi kan ignorere hinanden.

I et monolager er det tredje virkelig ikke en mulighed. Du er tvunget til at håndtere situationen på en af ​​to måder. Du skal se omkostningerne ved at have to udgivelsesgrene. Lær at beskytte dig selv mod opdateringer, der bryder bagudkompatibiliteten. Men vigtigst af alt: du kan ikke undgå at have en svær samtale.

Det er min erfaring, at når hold bliver store, er det ikke længere muligt at have hele systemet i tankerne, og det er den vigtigste del. Du skal forbedre synligheden af ​​uenighed i systemet. Du skal aktivt arbejde for at få teams til at se væk fra deres komponenter og se på andre teams og forbrugeres arbejde.

Ja, du kan oprette værktøjer, der forsøger at løse polyrepository-problemet. Men min erfaring med at undervise i kontinuerlig levering og automatisering i store virksomheder fortæller mig dette: standardadfærden uden brug af yderligere værktøjer er den adfærd, du forventer at se. Standardadfærden for et polyrepository er isolation, det er hele pointen. Standardadfærden for et monolager er delt ansvar og gennemsigtighed, det er hele pointen. I begge tilfælde vil jeg lave et værktøj, der vil udglatte de ru kanter. Som leder vil jeg vælge et monorepository hver gang, fordi værktøjerne skal forstærke den kultur, jeg ønsker, og kulturen kommer fra små beslutninger og teamets daglige arbejde.

Kun registrerede brugere kan deltage i undersøgelsen. Log ind, Vær venlig.

Hvem er de største fanatikere? Supportere:

• Monorepo

• Rust

• Forkert afstemning / begge dele

33 brugere stemte. 13 brugere undlod at stemme.

Kilde: www.habr.com