Einmalig oder vielfach?

Nur wenige Themen führen zu einem Streit zwischen Ingenieuren schneller als dieses. Manche Leute schwören, alles in ein riesiges Lager zu legen. Andere halten das für Wahnsinn und wollen ein Repository pro Service. Beide Gruppen verweisen auf bekannte Unternehmen, die es auf ihre Weise machen.

Ich denke so darüber aus DevOps-Sicht: Was es für Pipelines, Eigentum und tägliche Arbeit bedeutet.

Was wir vergleichen

Monorepo: alle (oder die meisten) Codes für viele Dienste und Bibliotheken befinden sich in einem Repository.

Polyrepo: Jeder Dienst oder jede Bibliothek hat ein eigenes Repository.

Es gibt auch eine Mittelweg: ein Repository pro Team oder pro Produktbereich. Viele Unternehmen landen dort, auch wenn sie es nicht nennen.

Welche Veränderungen für CI

Hier schadet oder hilft die Entscheidung am meisten.

In einer polyrepo WeltDas ist anfangs einfach. Jedes Repository hat seine eigene Pipeline, es baut nur diesen Service und es ist schnell. Der Schmerz kommt später: geteilte Bibliotheken müssen bei jedem Verbraucher freigegeben, verändert und aktualisiert werden. Eine Änderung, die drei Dienste betrifft, bedeutet drei Pull-Anfragen, drei Überprüfungen, drei Pipelines, manuell koordiniert.

In einem Monorepo, ist eine Querschnittsänderung eine Pull-Anfrage. Das Refactoring einer geteilten Bibliothek und das Aktualisieren aller Benutzer geschieht atomar. Aber naive KI wird langsam: Wenn jeder Commit alles baut und testet, dauern Pipelines ewig, wenn der Repo wächst.

Die Fixwerte für Monorepo-IC sind nur betroffene Bauten: herausfinden, welche Projekte tatsächlich von einem Wandel betroffen sind, und nur diese erstellen und testen. Das braucht Werkzeuge, die das Abhängigkeitsdiagramm verstehen.

Ein Monorepo ohne intelligente Baustoffe ist nur ein sehr großer Polyrepo mit langsameren Leitungen.

Eigentum und Abhängigkeiten

Polyrepos Sie machen das Eigentum offensichtlich. Dieses Repository gehört diesem Team. Die Erlaubnis ist einfach. Aber Abhängigkeitsversionen verschieben sich: Ein Dienst ist auf Version 1 der gemeinsamen Bibliothek, ein anderer auf Version 4, und niemand will ein Upgrade durchführen.

Monorepos Ermutigen Sie alle, die neueste Version des internen Codes zu verwenden, denn es gibt nur eine Version. Die Eigentumsrechte müssen explizit dargelegt werden, in der Regel mit einer CODEOWNERS Eine Datei, die Ordner an Teams abbildet, damit die richtigen Leute die richtigen Änderungen überprüfen.

Werkzeuge, die Monorepos funktionieren lassen

Sie wollen ein Build-Tool, das das Graph versteht und Ergebnisse speichert:

• Nx und Turborepo: in der JavaScript/TypeScript-Welt beliebt, einfach zu übernehmen, mit Remote-Caching.
• Schalen: extrem leistungsfähig und sprachunabhängig, in sehr großem Umfang verwendet. Auch eine bedeutende Investition, um zu lernen und zu erhalten.
• Schuhe und 2 Pfund: andere grafische Build-Systeme, stark für Python und Polyglot-Repos.
• Eingebettete Pfadfilter in GitHub Actions oder GitLab CI: die einfachste Option, die nur dann Aufgaben auslöst, wenn bestimmte Ordner geändert werden. Gut genug für kleine Monorepos.

Cache-Speicherung ist die echte Beschleunigung: wenn der gleiche Code bereits von jemand anderem gebaut und getestet wurde, das Ergebnis wiederverwenden, anstatt es noch einmal zu tun.

Beim Umschalten zwischen den beiden

Migrationen in beide Richtungen passieren.

Polyrepo auf Monorepo: Sie können die Historie speichern, indem Sie Repositories in Unterordner zusammenführen. Das Schwierige ist nicht Git, sondern die gemeinsame Ausstattung, die Installation und die Information.

Monorepo auf Polyrepo: Werkzeuge wie git filter-repo kann einen Ordner in sein eigenes Repository mit Geschichte aufteilen. Der schwierige Teil ist, geteilten Code zu entwirren, der plötzlich eine Versionisierung benötigt.

Egal in welche Richtung, wandern Sie allmählich, eine Abteilung oder ein Team nach dem anderen.

Also, welcher?

Mein großer Leitfaden:

• Kleines Team, eine Handvoll Dienstleistungen, gemeinsame Code: ein Monorepo ist oft einfacher.
• Viele unabhängige Teams, verschiedene Sprachen, wenig gemeinsame Code- Polyrepos sind in Ordnung.
• Große Organisation mit hohem Code-SharingEin Monorepo kann großartig sein, aber nur mit seriösen Baustoffen und einem Team, das es besitzt.

Ehrlich gesagt ist die Struktur nicht so wichtig wie die Disziplin um sie herum: klare Eigentumsrechte, schnelle Pipelines und eine zuverlässige Möglichkeit, geteilten Code zu aktualisieren.

Mein Tipp: Wählen Sie das Layout, das Ihre häufigsten Änderungen leicht macht. Dann investiere in Werkzeuge, damit die ungewöhnlichen nicht schaden.

Desly