Översättningen av artikeln förbereddes för studenter i kursen «DevOps metoder och verktyg» i utbildningsprojektet OTUS.

Du bör välja monorepo eftersom det beteende som det främjar i dina team är transparens och kollektivt ansvar, särskilt när team växer. I vilket fall som helst måste du investera i verktyg, men det är alltid bättre när standardbeteendet är det beteende du vill se i dina team.

Varför pratar vi om detta?

Matt Klein skrev en artikel «Monorepos: Snälla gör inte så!» (övers. anm.: översättning på Habré «Monorepositories: please don’t»). Jag gillar Matt, jag tycker att han är mycket smart, och du bör läsa hans åsikt. Ursprungligen publicerade han en omröstning på Twitter:

Översättning:
På denna nyårsdag skulle jag argumentera för hur absurda monorepositorier är. År 2019 började obemärkt. I den andan föreslår jag en omröstning. Vem är stora entusiaster? Förespråkare:
— Monorepo
— Rust
— Felaktig omröstning / båda

Mitt svar var: «Jag är bokstavligen båda dessa personer». Istället för att prata om hur Rust är en drog, låt oss gå igenom varför jag tycker att han har fel om monorepositorier. Lite om mig själv. Jag är teknisk chef för Chef Software. Vi har cirka 100 ingenjörer, en kodbas som är omkring 11–12 år gammal och 4 huvudprodukter. Del av denna kod ligger i polyrepo (min startposition), del i monorepo (min nuvarande position).

Innan jag börjar: varje argument jag tar upp här kommer att tillämpas på båda typerna av repositorier. Enligt min mening finns det ingen teknisk anledning till varför du bör välja den ena eller den andra typen av repository. Du kan få vilket tillvägagångssätt som helst att fungera. Jag är glad att diskutera detta, men jag är inte intresserad av konstgjorda tekniska anledningar till att det ena övergår det andra.

Jag håller med om den första delen av Matts synpunkt:

För på stor skala kommer ett monorepo att hantera alla de samma problemen som ett polyrepo, men samtidigt utmana dig till en starkare sammankoppling av din kod och kräva otroliga insatser för att öka skalbarheten av ditt versionskontrollsystem.

Oavsett om du väljer en monorepo eller polyrepo kommer du att ställas inför samma problem. Hur släpper ni nya versioner? Vad är er strategi för uppdateringar? Bakåtkompatibilitet? Ömsesidiga beroenden mellan projekt? Vilka arkitekturstilar är acceptabla? Hur hanterar ni er bygg- och testinfrastruktur? Listan kan göras oändlig. Och ni kommer att behöva lösa dem alla i takt med att ni växer. Ingen gratis ost finns.

Jag tror att Matts argument liknar åsikter som delas av många ingenjörer (och chefer) som jag respekterar. Det kommer från perspektivet hos en ingenjör som arbetar med en komponent eller ett team som arbetar med en komponent. Du hör saker som:

Koden är otymplig – jag behöver inte allt det här skräpet.
Det är svårare att testa eftersom jag måste kolla allt det här skräpet som jag inte behöver.
Det är svårare att arbeta med externa beroenden.
Jag behöver mina egna versionshanteringssystem.

Självklart är alla dessa punkter berättigade. Det är fallet i båda scenarierna – i en polyrepo har jag mitt skräp, förutom det som behövs för byggandet… Jag kan behöva ännu mer skräp. Så jag "bara" skapar verktyg som checkoutar hela projektet. Eller så skapar jag ett falskt monorepo med submoduler. Vi skulle kunna diskutera detta hela dagen. Men jag tror att Matts argument missar den grundläggande anledningen till varför jag starkt förespråkar monorepo:

Det främjar kommunikation och visar på problem.

När vi delar upp repository skapar vi de facto en koordinerings- och transparensproblematik. Det matchar hur vi tänker på team (särskilt hur enskilda deltagare tänker på dem): vi är ansvariga för en viss komponent. Vi arbetar relativt isolerat. Gränserna fastställs kring mitt team och de komponenter vi arbetar med.

När arkitekturen blir mer komplex kan ett team inte längre hantera den ensamt. Mycket få ingenjörer har hela systemet i huvudet. Anta att du hanterar en gemensam komponent A som används av team B, C och D. Team A refaktorerar, förbättrar API:et och ändrar den interna implementationen. Som resultat blir förändringarna bakåtkompatibla. Vilket råd skulle du ge?

Identifiera alla platser där det gamla API:et används.
Finns det platser där det nya API:et inte kan användas?
Kan ni fixa och testa andra komponenter för att säkerställa att de inte går sönder?
Kan dessa team kontrollera era förändringar just nu?

Observera att dessa frågor inte beror på typ av lager. Ni behöver hitta team B, C och D. Ni måste prata med dem, ta reda på deras tidsramar och förstå deras prioriteringar. Åtminstone hoppas vi att ni gör det.

Ingen vill faktiskt göra detta. Det är mycket mindre spännande än att bara fixa det förbannade API:et. Allt detta är mänskligt och komplicerat. I ett polerat lager kan ni helt enkelt göra ändringar, ge dem för granskning till dem som arbetar med den här komponenten (förmodligen inte B, C eller D) och gå vidare. Team B, C och D kan förbli på sin nuvarande version för tillfället. De kommer att uppdatera sig själva när de inser er genialitet!

I ett monolager förändras ansvaret per automatik. Team A ändrar sin komponent och om de inte är försiktiga bryter de omedelbart B, C och D. Detta leder till att B, C och D dyker upp vid dörren hos A och undrar varför team A har brutit bygget. Detta lär A att de inte kan hoppa över min lista ovan. De måste prata om vad de planerar att göra. Kan B, C och D gå vidare? Vad händer om B och C kan, men D är djupt kopplad till sideffekterna av det gamla algoritmens beteende?

Vi måste sedan prata om hur vi ska ta oss ur denna situation:

Stödja flera interna API:er, där den gamla algoritmen markeras som föråldrad tills D kan sluta använda den.
Stödja flera versionsutgåvor, en med det gamla gränssnittet, en med det nya.
Fördröja lanseringen av förändringarna i A tills B, C och D samtidigt kan ta emot dem.

Anta att vi har valt 1, flera API:er. I så fall har vi två bitar av kod. Den gamla och den nya. Ganska praktiskt i vissa situationer. Vi återställer den gamla koden, markerar den som föråldrad (deprecated) och samordnar en tidsplan för dess borttagning med team D. I praktiken är det identiskt för både poly- och monorepo.

För att släppa flera versioner behöver vi en gren. Nu har vi två komponenter – A1 och A2. Team B och C använder A2, medan D använder A1. Vi behöver att varje komponent är redo för release, för innan D kan gå vidare kan säkerhetsuppdateringar och andra buggfixar krävas. I poly-repon kan vi dölja detta i en långlivad gren, som känns bra. I monorepo tvingar vi att skapa kod i en ny modul. Team D måste fortfarande göra ändringar i den "gamla" komponenten. Alla kan se kostnaden vi betalar här – vi har nu dubbelt så mycket kod, och alla buggfixar som tillämpas på A1 och A2 måste tillämpas på båda. Med grensystemet i poly-repo är detta dolt bakom cherry-pick. Vi ser kostnaden som mindre, för där sker ingen duplicering. Ur praktisk synvinkel är kostnaden densamma: du kommer att skapa, släppa och underhålla två i huvudsak identiska kodbaser tills du kan ta bort en av dem. Skillnaden är att smärtan i monorepo är direkt och synlig. Det är ännu värre, och det är bra.

Äntligen har vi kommit till den tredje punkten. Förseningen av lanseringen. Det är möjligt att de ändringar som team A gör kommer att förbättra livet för team A. Viktigt, men inte brådskande. Kan vi bara fördröja det? I monorepot pushar vi detta för att befästa artefakten. Självklart pratar vi om det med team D. Håll bara kvar vid den gamla versionen tills ni hinner ikapp! Detta sätter tonen för en fegare inställning. Team A fortsätter att arbeta med sin komponent, och ignorerar det faktum att team D använder en allt mer föråldrad version (det är team D:s problem, de är dumma). Under tiden pratar team D negativt om team A:s nonchalanta inställning till kodens stabilitet, om de ens nämner det. Månader går. Till slut bestämmer sig team D för att se på möjligheten att uppdatera, men ändringarna i A har bara blivit fler. Team A minns knappt när och hur de bröt D. Uppdateringen blir mer smärtsam och tar längre tid. Detta sätter det längre ner på prioriteringslistan. Tills den dagen då vi får ett säkerhetsproblem i A som tvingar oss att göra en branch. Team A måste gå tillbaka i tiden, hitta den punkt då D var stabilt, fixa problemet där och göra det redo för lansering. Detta är ett de facto-val som människor gör, och det är definitivt det sämsta. Det verkar vara bra för både team A och D, så länge vi kan ignorera varandra.

I monorepot är det verkligen inte ett alternativ. Du är tvungen att hantera situationen på två sätt. Du behöver se kostnaderna för att ha två release-grenar. Lära dig att skydda dig mot uppdateringar som bryter bakåtkompatibiliteten. Men det viktigaste är: du kan inte undvika en svår konversation.

Enligt min erfarenhet, när teamen blir stora, finns det inte längre möjlighet att hålla hela systemet i huvudet, och det är den viktigaste delen. Du måste förbättra synligheten för motsättningarna i systemet. Du måste aktivt arbeta för att få teamen att titta bort från sina komponenter och se på arbetet hos andra team och konsumenter.

Ja, du kan skapa verktyg som försöker lösa problemet med polymorf repon. Men min erfarenhet av kontinuerlig leverans och automatisering på stora företag säger mig följande: standardbeteendet utan att använda extra verktyg är det beteende du förväntar dig att se. Standardbeteendet för polymorfa repon är isolering, det är hela poängen. Standardbeteendet för monorepo är gemensamt ansvar och transparens, det är hela poängen. I båda fallen planerar jag att skapa ett verktyg som gör det enklare. Som ledare kommer jag alltid att välja monorepo, eftersom verktyg bör stärka den kultur jag vill ha, och kulturen kommer från små beslut och dagligt arbete från teamet.

Endast registrerade användare kan delta i omröstningen. Logga in, tack.