Was ist ein Monorepo? Vor- und Nachteile von mehreren Projekten in einem Repository

Was ist ein Monorepo?

Ein Monorepo ist ein einziges Repository zur Versionskontrolle, das mehrere zusammengehörige Anwendungen und Bibliotheken enthält. Konkret liegt jedes Projekt in einem eigenen Ordner, doch alle teilen sich dieselbe Historie, denselben Änderungsfluss und meist dieselben Werkzeugeinstellungen. Kurz gesagt: ein Repository für viele Projekte.

Entscheidend ist, dass ein Monorepo eine Entscheidung über die Ablage des Codes ist und keine Architektur. Daher können die Projekte darin weiterhin unabhängig erscheinen. Ein gemeinsames Repository macht also noch kein gemeinsames Paket.

In diesem Leitfaden beantworten wir die Frage auf konzeptioneller Ebene. Auf Befehle und Konfigurationsdetails verzichten wir bewusst, denn Sie sollen die Entscheidung sicher treffen können.

Beispielszenario: Ein Team baut eine Website, eine mobile App und eine Zahlungsbibliothek, die beide nutzen. Zum Beispiel braucht bei drei Repositories jede Änderung an der Bibliothek Abstimmung an drei Stellen. Stattdessen genügt in einem Repository ein einziger Schritt.

Was ist ein Monorepo einfach erklärt, mit einem Vergleich aus dem Alltag?

Stellen Sie sich zunächst ein Mehrfamilienhaus vor. Jede Wohnung hat eine eigene Tür und einen eigenen Grundriss, allerdings gehören Eingang, Aufzug und Parkplatz allen. Wenn jemand den Aufzug erneuert, nutzen deshalb alle Wohnungen gleichzeitig den neuen.

Ein Polyrepo gleicht dagegen einer Straße mit Einfamilienhäusern. Außerdem hat jedes Haus seinen eigenen Garten, eigene Reparaturen und eigene Regeln. Sie haben viel Freiheit, müssen dann aber bei jeder gemeinsamen Änderung an jeder Tür klopfen.

Der Vergleich hat natürlich Grenzen. Im Haus folgen allerdings alle derselben Hausverwaltung. In der Software legen Sie Zuständigkeiten und Zugriffsregeln selbst fest, daher muss ein Monorepo nicht alles für alle öffnen.

Ist ein Monorepo dasselbe wie ein Monolith?

Nein, doch viele verwechseln beide Begriffe, deshalb lohnt die Klärung. Zunächst beschreibt ein Monolith eine Anwendung, die als ein Stück läuft. Ein Monorepo beschreibt dagegen, wo der Code liegt.

Zum Beispiel kann ein Monorepo drei Dienste, eine Weboberfläche und eine gemeinsame Bibliothek enthalten. In der Praxis liefern und skalieren Sie jeden dieser Teile getrennt aus. Umgekehrt können Sie einen Monolithen trotzdem auf mehrere Repositories verteilen.

• Monorepo: wie Sie Code ablegen (Entscheidung auf Repositoryebene).
• Monolith: wie die Anwendung läuft (Entscheidung auf Architekturebene).
• Microservices: die Aufteilung der Anwendung in kleine, unabhängige Dienste (Entscheidung auf Architekturebene).

Der Gedanke "wir gehen auf Microservices, also brauchen wir viele Repositories" ist daher falsch. Stattdessen halten viele Teams den Großteil ihrer Microservices in einem Repository. Sie treffen beide Entscheidungen unabhängig voneinander.

Wie funktioniert ein Monorepo?

Ein typisches Monorepo hat in der Praxis auf oberster Ebene wenige Ordner. In einem Ordner liegen die Anwendungen, in einem zweiten die gemeinsamen Pakete und in einem dritten die geteilte Konfiguration. Jedes Projekt behält seine eigene Abhängigkeitsdefinition, während das Stammverzeichnis alles verbindet.

Vor allem ist wichtig, dass Ihre Werkzeuge die Verbindungen zwischen den Projekten verstehen. Nutzt eine App eine gemeinsame Bibliothek, liest das Werkzeug diese Beziehung und baut daraus einen Abhängigkeitsgraphen. Daher ist dieser Graph die Grundlage der intelligenten Builds, die wir weiter unten beschreiben.

Aus Sicht von Git ändert sich nichts. Das heißt: Sie haben weiterhin eine Historie, einen Hauptzweig und einen Änderungsfluss. Grundkenntnisse in Git reichen deshalb als Einstieg, und unsere Git und GitHub Anleitung frischt sie bei Bedarf auf.

Wie gehen Sie in einem Monorepo mit Abhängigkeiten um?

Die Verwaltung von Abhängigkeiten ist der stille Held jedes Monorepos. Es gibt zwei Arten: interne Abhängigkeiten zwischen Ihren Projekten und externe Abhängigkeiten zu Bibliotheken von Dritten. Wenn Sie eine davon vernachlässigen, gerät das Repository daher schnell durcheinander.

Bei internen Abhängigkeiten ist die Regel zunächst einfach. Ein Projekt soll nur von gemeinsamen Paketen abhängen, die unter ihm liegen. Apps nutzen Pakete, aber Pakete hängen nie von Apps ab. Somit verhindert diese Richtungsregel zirkuläre Abhängigkeiten und erleichtert es, betroffene Projekte zu finden.

Bei externen Bibliotheken sehen wir zudem zwei Wege. Erstens gibt es die Einheitsversion, bei der alle Projekte dieselbe Version nutzen. Zweitens gibt es die flexible Variante, bei der jedes Projekt seine eigene Version wählt. Die Einheitsversion schafft Konsistenz, zwingt Sie allerdings zu Upgrades an allen Stellen gleichzeitig.

• Halten Sie die Abhängigkeitsrichtung in einem Satz fest: Apps hängen von Paketen ab, nie umgekehrt.
• Entscheiden Sie sich für eine Einheitsversion oder eine flexible Variante und dokumentieren Sie die Wahl.
• Entfernen Sie ungenutzte Abhängigkeiten in regelmäßigen Abständen.

Beim Zuschnitt der Pakete hilft unser Artikel zu den SOLID Prinzipien als Kompass. Hat jedes Paket genau eine Verantwortung, dann bleibt auch der Abhängigkeitsgraph übersichtlich.

Was ist ein Monorepo im Vergleich zu einem Polyrepo?

Ein Polyrepo hält jedes Projekt oder Paket in einem eigenen Repository. Wenn Sie beide Ansätze nebeneinander legen, fällt die Entscheidung daher leichter. Die folgende Tabelle fasst allgemeine Tendenzen zusammen, Ihr tatsächliches Ergebnis hängt jedoch von Team und Werkzeugen ab.

Wofür taugt ein Monorepo also? Für gemeinsamen Code und Konsistenz. Ein Polyrepo taugt andererseits für klare Grenzen und Unabhängigkeit. Beides kann richtig sein, denn die eigentliche Frage lautet, welches Modell den Schmerz Ihres Teams tatsächlich lindert.

Welche Vorteile hat ein Monorepo?

Alle Vorteile stammen aus derselben Wurzel: Weil alles an einem Ort liegt, steigt die Sichtbarkeit. Hier sind die Vorteile, die Teams in der Praxis am stärksten spüren.

• Gemeinsamer Code: Sie nutzen Oberflächenkomponenten, Validierungsregeln und Typdefinitionen, ohne sie zu kopieren.
• Atomare Änderungen: Sie aktualisieren eine Bibliothek und alle Apps, die sie nutzen, in einer einzigen Änderung.
• Einheitliche Werkzeuge: Formatierung, Prüfregeln und Testeinstellungen liegen an einem Ort.
• Leichte Auffindbarkeit: Sie durchsuchen das ganze Repository, um zu sehen, wo eine Funktion vorkommt.
• Einfachere Abhängigkeiten: Die Frage, welche Version einer gemeinsamen Bibliothek jede App nutzt, verschwindet meist.
• Leichterer Einstieg: Neue Entwickler klonen ein Repository und sehen das gesamte System.

Diese Vorteile zeigen sich vor allem, wenn Projekte eng verbunden sind. Bei wirklich unabhängigen Projekten bleibt der Gewinn allerdings klein.

Außerdem gibt es eine menschliche Seite. Zum Beispiel kann, wer in einem einzigen Repository arbeitet, den Code anderer Teams lesen und daraus lernen. Somit werden die Mauern zwischen Teams niedriger, und Fragen fallen leichter. Diese Offenheit braucht jedoch gemeinsame Regeln, sonst fasst jeder alles an.

Warum sind atomare Änderungen im Monorepo so wertvoll?

Eine atomare Änderung bedeutet, dass zusammengehörige Teile in einem Vorgang gemeinsam geändert werden. Stellen Sie sich zum Beispiel vor, Sie benennen in einer gemeinsamen Bibliothek eine Funktion um, und drei Apps nutzen diese Funktion.

Im Polyrepo ändern Sie zunächst die Bibliothek und veröffentlichen eine neue Version. Danach heben Sie in drei Repositories die Version an. In dieser Zeit kann das System also uneinheitlich bleiben. Zudem müssen Sie verfolgen, welche App bei welcher Version hängt.

Im Monorepo aktualisieren Sie die Bibliothek und die drei Apps stattdessen in derselben Änderung. Zudem sieht die prüfende Person die gesamte Wirkung auf einem Bildschirm. Außerdem laufen die Tests für alle zusammen, sodass Sie eine kaputte Verbindung schon vor dem Zusammenführen entdecken.

Kurz gesagt: Das ist das stärkste Argument der Monorepo Befürworter. Der Vorteil hat allerdings einen Preis: Je größer die Änderung, desto größer die Last beim Review. Die Gewohnheit kleiner, fokussierter Änderungen wird daher entscheidend.

Welche Nachteile und Risiken hat ein Monorepo?

Wer alles an einen Ort legt, sammelt auch die Probleme an einem Ort. Diese Herausforderungen begegnen Teams am häufigsten.

• Build und Testdauer: Ein Aufbau, der bei jeder Änderung alle Projekte baut, wird mit wachsendem Repository sehr langsam.
• Rechte und Zugriff: Wenn jeder in jeden Ordner schreiben darf, verschwimmt die Verantwortung.
• Größe des Repositorys: Mit wachsender Historie und Dateizahl werden Klonen und manche Git Vorgänge schwerfälliger.
• Abhängigkeit von Werkzeugen: Große Repositories brauchen meist spezielle Build Werkzeuge, und diese haben eine Lernkurve.
• Risiko brechender Änderungen: Ein Fehler in einem gemeinsamen Paket kann viele Apps gleichzeitig treffen.
• Release Durcheinander: Ohne klare Regeln weiß niemand, welches Projekt wann erscheint.

Für jeden Punkt dieser Liste gibt es einen Ausweg, deshalb behandeln wir sie weiter unten. Ohne solche Auswege zu starten, ist trotzdem der häufigste Fehler bei Monorepo Projekten.

Zum Beispiel wechselt ein Team auf ein Repository und merkt nach einigen Monaten, dass jede Änderung die gesamte Testsuite startet. Dann wächst die Wartezeit, und die Geduld der Entwickler sinkt. Das Problem liegt also nicht im Monorepo selbst, sondern in fehlenden Werkzeugen.

Was bedeutet ein Build nur für betroffene Projekte?

Ein Build nur für betroffene Projekte (englisch affected build) baut und testet nur die Projekte, die eine Änderung berührt, plus jene, die davon abhängen. Zunächst ordnet das Werkzeug die geänderten Dateien dem Abhängigkeitsgraphen zu. Dadurch überspringen Sie alle unbeteiligten Projekte.

Beispielszenario: Das Repository enthält ein Admin Panel, eine mobile Oberfläche und eine Zahlungsbibliothek. Konkret ändern Sie nur einen Text im Admin Panel. Mobile Oberfläche und Zahlungsbibliothek hängen nicht von dieser Änderung ab, also müssen Sie beide nicht neu bauen.

Ändern Sie dagegen die Zahlungsbibliothek, kehrt sich das Bild um. Somit gilt jedes Projekt, das von ihr abhängt, als betroffen, und Sie testen alle. Daher hält genau diese Unterscheidung ein großes Monorepo schnell.

Die Nx Dokumentation erklärt, dass das Werkzeug aus Ihrer Codebasis einen Projektgraphen aufbaut und damit betroffene Projekte bestimmt. Andere Werkzeuge haben zwar eigene Methoden, doch die Logik bleibt gleich, daher lässt sich das Konzept übertragen.

Wie funktioniert ein Build Cache im Monorepo?

Ein Build Cache speichert das Ergebnis einer Aufgabe und nutzt es wieder, sobald dieselbe Eingabe erneut auftaucht. Zunächst berechnet das Werkzeug aus Quelldateien und Konfiguration einen Fingerabdruck. Sieht es denselben Fingerabdruck erneut, liefert es das gespeicherte Ergebnis, statt die Arbeit zu wiederholen.

In der Praxis bedeutet das: Sie bauen ein Paket nicht neu, das eine Kollegin gestern gebaut hat. Teilen sich alle den Cache (ein Remote Cache), können Sie außerdem das Ergebnis Ihres Teams nutzen.

Die Einführung von Bazel beschreibt, dass das Werkzeug bereits erledigte Arbeit speichert und nur neu baut, was nötig ist. Damit der Cache verlässlich bleibt, müssen Sie allerdings jede Eingabe vollständig angeben. Fehlt eine Angabe, liefert er folglich ein falsches Ergebnis.

Wie funktioniert Continuous Integration in einem Monorepo?

Continuous Integration bedeutet, bei jeder Änderung automatisch zu bauen und zu testen. In einem Repository muss dieser Ablauf daher die Auswirkung jeder Änderung berechnen. Sonst startet schon eine winzige Korrektur die komplette Testsuite.

In einem guten Aufbau läuft der Ablauf in der Praxis in drei Schritten. Zunächst ermitteln Sie die geänderten Dateien. Danach bestimmen Sie über den Abhängigkeitsgraphen die betroffenen Projekte. Schließlich führen Sie Build und Test nur für diese aus.

Somit ist das die zweite Säule, die ein Monorepo schnell hält. Zusammen mit dem Cache läuft dann bei den meisten Änderungen nur eine kleine Teilmenge. Dennoch löst eine Änderung an einem großen gemeinsamen Paket immer eine breite Testrunde aus, und das ist normal.

Ein weiteres Detail ist lesbare Ausgabe. In einem Repository mit Hunderten Projekten müssen Sie zudem klar sehen, welches Projekt warum gescheitert ist. Nehmen Sie sich deshalb beim Aufbau Zeit für das Layout der Ausgabe.

Wie steuern Sie Releases in einem Monorepo?

Dasselbe Repository bedeutet allerdings nicht, dass alles gleichzeitig erscheint. Es gibt zwei Grundmodelle. Erstens tragen beim Modell mit fester Version alle Pakete dieselbe Versionsnummer. Zweitens läuft beim Modell mit unabhängigen Versionen jedes Paket in seinem eigenen Tempo.

Was ist ein Monorepo bei Releases in der Praxis? Die meisten kleinen Teams wählen das feste Modell, weil es einfach ist. Das unabhängige Modell ist flexibler, verlangt aber einen Aufbau, der erfasst, welche Änderung welches Paket anhebt. Dabei helfen außerdem Release Werkzeuge mit Änderungsprotokoll.

1. Teilen Sie Ihre Pakete zunächst in zwei Gruppen: Apps, die Nutzer erreichen, und Bibliotheken, die nur intern dienen.
2. Definieren Sie den Release Ablauf für jede App getrennt, damit jede in ihre eigene Umgebung ausliefern kann.
3. Schreiben Sie die Versionsregel für veröffentlichte Pakete auf und teilen Sie sie mit dem Team.
4. Proben Sie den Rückfallplan für jeden Release Ablauf vorab.

Liefern Sie Ihre Apps als Container aus, hilft Ihnen unser Leitfaden zu Docker und Containern beim Aufbau dieses Ablaufs. In der Praxis hindert ein Monorepo keine App daran, ihr eigenes Image zu bauen.

Zusammengefasst nimmt Ihnen ein Monorepo die Unabhängigkeit bei Releases nicht weg. Es verlangt nur, dass Sie diese Unabhängigkeit selbst festlegen.

Welche Werkzeugkategorien gibt es für Monorepos?

Wir stellen hier kein einzelnes Produkt in den Vordergrund. Die Auswahl ändert sich schnell, deshalb ist das Denken in Kategorien langlebiger. Prüfen Sie aktuelle Funktionen bitte in der offiziellen Dokumentation des jeweiligen Werkzeugs.

Im JavaScript Umfeld sind npm Workspaces das einfachste Beispiel der ersten Kategorie. Sie gehören zum Paketmanager, daher brauchen Sie kein zusätzliches Werkzeug. Bei Task Runnern fallen zudem oft Nx und Turborepo, bei Build Systemen Bazel und Pants. Die richtige Wahl hängt daher von Ihrer Sprache und der Repository Größe ab.

Wie bleibt Git in einem sehr großen Monorepo schnell?

Wächst ein Repository, brauchen Sie allerdings nicht immer jede Datei im Arbeitsverzeichnis. Git bietet dafür konkret Funktionen für einen Teil des Arbeitsbaums. Die Dokumentation zu Git Sparse Checkout erklärt, dass Sie Ihren Arbeitsbaum auf eine Teilmenge der verfolgten Dateien verkleinern können.

In der Praxis behalten Sie nur die Ordner auf der Platte, an denen Sie arbeiten. Somit bleibt Ihr Alltag selbst bei einem riesigen Repository klein. Laut Dokumentation reicht im Cone Modus zudem die Angabe von Verzeichnissen, was den Aufbau einfach hält.

Außerdem bietet Git Klon Optionen, die einen Teil der Historie auslassen. Genaue Befehle und Schalter entnehmen Sie bitte der Git Dokumentation, denn Details ändern sich zwischen Versionen. Bei kleinen und mittleren Repositories brauchen Sie diese Einstellungen allerdings nicht.

Wie regeln Sie Rechte und Code Verantwortung im Monorepo?

Ein Repository bedeutet allerdings nicht, dass jeder überall schreibt. Stattdessen legen Sie Verantwortung auf Ordnerebene fest. Plattformen wie GitHub bieten dafür eine Datei für Code Owner.

Laut GitHub Dokumentation fordert die Plattform automatisch ein Review von den Code Ownern an, sobald ein Pull Request deren Code ändert. Jede Änderung am Zahlungsordner geht somit durch das Zahlungsteam.

1. Benennen Sie für jeden Ordner der obersten Ebene ein verantwortliches Team.
2. Legen Sie die Zuständigkeitsdatei im Repository an und ordnen Sie ihr Teamnamen zu.
3. Aktivieren Sie die Pflicht zum Review für den Hauptzweig.
4. Geben Sie gemeinsamen Paketen mehr als einen Verantwortlichen, damit niemand zum Einzelrisiko wird.
5. Aktualisieren Sie die Liste bei jeder Änderung der Teams.

Somit bietet ein Monorepo mit diesem Aufbau gemeinsame Sichtbarkeit und klare Verantwortung zugleich.

Wann sollten Sie ein Monorepo wählen?

Ein Monorepo schafft vor allem dann Nutzen, wenn Ihre Projekte einander oft berühren. Wenn Ihnen mehrere der folgenden Anzeichen bekannt vorkommen, prüfen Sie den Ansatz ernsthaft.

• Dasselbe Team baut mehrere Apps und eine gemeinsame Bibliothek zusammen.
• Das Team kopiert eine gemeinsame Oberflächenkomponente oder Typdefinition in viele Projekte.
• Sie diskutieren über Versionskonflikte und das Argument "bei mir läuft es".
• Die Abstimmung einer Änderung über mehrere Repositories dauert länger als die Änderung selbst.
• Unterschiede bei Formatierung, Prüfregeln und Testeinstellungen zwischen Repositories verursachen Ärger.

Beispielszenario: Ein E-Commerce Team baut einen Shop, ein Admin Panel und eine gemeinsame Bibliothek für Produktdaten. Alle drei stützen sich außerdem auf dieselbe Datenstruktur. Für dieses Team entfällt somit mit einem Repository die Synchronisationsarbeit.

Wann ist ein Monorepo keine gute Idee?

Es ist nicht für jedes Team die richtige Wahl, und das sagen wir offen. Deshalb sind in manchen Fällen getrennte Repositories gesünder.

• Die Projekte sind wirklich unabhängig und teilen keinen Code.
• Verschiedene Teams haben stark unterschiedliche Release Rhythmen und Freigabeprozesse.
• Aus Sicherheitsgründen darf manch ein Code nur einem engen Kreis offenstehen.
• Im Team kann niemand die Build Werkzeuge aufsetzen und pflegen.
• Sie müssen ein Open Source Paket von einem geschlossenen Produkt trennen.

Vor allem für die Trennung des Zugriffs bietet die Repository Grenze den klarsten Schutz. Regeln auf Ordnerebene funktionieren. Trotzdem ist eine Trennung auf Repositoryebene immer die einfachere und stabilere Garantie.

Ein weiteres Zeichen ist die Teamkultur. Zum Beispiel stören sich kleine, unabhängige Teams, die in ihrem eigenen Tempo arbeiten, eventuell an gemeinsamen Regeln. Dann funktioniert das Monorepo technisch, erzeugt aber menschliche Reibung.

Was empfehlen wir einem kleinen Team beim Thema Monorepo?

Für kleine Teams ist ein Monorepo oft einfacher, als Sie denken. Das Repository ist klein, daher sind Build Dauer, Größe und Rechteprobleme noch nicht entstanden. Zudem spüren Sie die Vorteile von gemeinsamem Code und Konsistenz vom ersten Tag an.

Unsere Erfahrung aus der Praxis lautet: Haben Sie zwei oder drei verbundene Projekte, ist der Start mit einem Repository und eine spätere Trennung meist günstiger. Allerdings ist Zusammenführen später in der Regel mühsamer als Trennen. Das ist also eine Startempfehlung und keine Garantie.

Viele kleine Teams, die fragen, was ist ein Monorepo, wollen eigentlich nur eines wissen: Lohnt sich die zusätzliche Komplexität? Unsere Antwort lautet: Ja, wenn Sie Code teilen, und noch nicht, wenn Sie das nicht tun.

• Starten Sie einfach: Nutzen Sie zuerst die Workspace Funktion Ihres Paketmanagers.
• Entscheiden Sie über zusätzliche Werkzeuge erst, wenn echte Verlangsamungen beginnen.
• Legen Sie die Ordnerstruktur früh und klar fest: Apps an einem Ort, gemeinsame Pakete an einem anderen.
• Weisen Sie gemeinsamen Paketen eine Verantwortung zu, auch in einem kleinen Team.

Wenn Sie Hilfe bei der Struktur Ihres Softwareprojekts möchten, besprechen wir Repository und Architektur gern mit Ihnen im Rahmen unserer individuellen Softwareentwicklung.

Wie planen Sie den Wechsel vom Polyrepo zum Monorepo?

Alles auf einmal zu verschieben ist riskant. Gehen Sie daher in kleinen, umkehrbaren Schritten vor, damit Ihr Verlust begrenzt bleibt, falls etwas schiefgeht.

1. Ziel aufschreiben: Halten Sie fest, was Sie lösen wollen, zum Beispiel kopierten gemeinsamen Code.
2. Pilot wählen: Starten Sie mit den zwei Projekten, die am meisten Code teilen.
3. Historie bewahren: Führen Sie nach Möglichkeit die Historien der alten Repositories zusammen, damit die Spur der Verantwortung erhalten bleibt.
4. Struktur aufbauen: Legen Sie die Ordner für Apps und gemeinsame Pakete an.
5. Ablauf umziehen: Passen Sie Ihren Ablauf für Continuous Integration an die neue Struktur an.
6. Verantwortung festlegen: Aktivieren Sie Code Verantwortung und Review Regeln gleich mit dem Umzug.
7. Messen: Vergleichen Sie Build Dauer und Zufriedenheit des Teams vor und nach dem Umzug.

Läuft der Pilot gut, nehmen Sie danach die übrigen Projekte Schritt für Schritt auf. Scheitert er, sollte der Weg zurück dennoch leicht sein.

Machen Sie den Umzug nicht zu einem Mammutprojekt neben dem Alltag. Zerlegen Sie ihn stattdessen in kleine Arbeitspakete und planen Sie diese in Sprints ein. Dabei helfen die Ansätze aus unserem Artikel zum agilen Projektmanagement.

Auch die Kommunikation zählt beim Umzug. Informieren Sie das Team zunächst vorab, erklären Sie die neue Ordnerstruktur auf einer Seite und antworten Sie in den ersten Wochen schnell auf Fragen. Selbst ein technisch perfekter Umzug braucht allerdings Zeit, bis sich Gewohnheiten ändern.

Was gehört auf eine praktische Checkliste für ein Monorepo?

Nach der Entscheidung zeigt die folgende Liste die Punkte, die Sie leicht übersehen. Haken Sie die Punkte danach gemeinsam mit Ihrem Team einzeln ab.

• Ist die Ordnerstruktur aufgeschrieben, und liest jeder sie gleich?
• Haben Sie ein Werkzeug gewählt, das den Abhängigkeitsgraphen versteht?
• Haben Sie den Ablauf für Build und Test betroffener Projekte an Continuous Integration angebunden?
• Arbeitet der Build Cache verlässlich?
• Sind die Zuständigkeitsdatei und das verpflichtende Review aktiv?
• Haben Sie für ein großes Repository die Option eines Teil Arbeitsbaums geprüft?
• Haben Sie für jedes Projekt eine Regel für unabhängige Releases festgelegt?
• Prüfen Sie das Repository auf Geheimnisse wie Schlüssel und Passwörter?
• Liegt für neue Entwickler eine einseitige Einstiegshilfe bereit?

Antworten Sie bei mehr als der Hälfte der Liste mit Nein, ist es somit klüger, den Umzug zu verschieben und zuerst die Grundlagen zu schaffen.

Wie hängt ein Monorepo mit KI gestütztem Programmieren und Infrastruktur als Code zusammen?

Wir streifen kurz zwei Nachbarthemen, denn zu beiden haben wir eigene Artikel. KI gestützte Programmierwerkzeuge arbeiten vor allem dann konsistenter, wenn ihr Kontext breit ist. Ein Repository kann diesen Kontext erleichtern, weil es die Beziehung zwischen App und gemeinsamer Bibliothek an einer Stelle zeigt. Details finden Sie im Artikel Was ist Vibe Coding.

Beschreiben Sie Ihre Infrastruktur als Code, ist die Frage, ob diese Definitionen im selben Repository wie der Anwendungscode liegen, eine eigene Entscheidung. Ein getrenntes Repository bedeutet zunächst getrennte Rechte. Dasselbe Repository bedeutet dagegen, dass eine Änderung App und Infrastruktur somit zusammen aktualisiert. Das haben wir im Artikel Was ist Infrastructure as Code behandelt.

Bauen Sie mehrere Frontend Apps, lesen Sie außerdem unseren Beitrag zum Unterschied zwischen Next.js und React. Teams entscheiden sich bei solchen Projekten mit mehreren Apps daher oft für ein Monorepo.

Welche Irrtümer rund um das Monorepo sind verbreitet?

Zudem machen einige falsche Vorstellungen die Entscheidung schwerer, als sie sein müsste. Räumen wir die häufigsten aus.

• "Ein Monorepo heißt, alles erscheint zusammen." Nein, Projekte können unabhängig erscheinen.
• "Nur große Firmen brauchen eines." Nein, kleine Teams starten oft am leichtesten.
• "Monorepos sind immer langsam." Nein, mit passenden Werkzeugen führen Sie nur die nötige Arbeit aus.
• "Jeder darf im Monorepo jeden Code ändern." Nein, Zuständigkeitsregeln begrenzen das.
• "Wenn wir uns einmal entscheiden, gibt es kein Zurück." Nein, ein Wechsel ist in beide Richtungen möglich, kostet aber Aufwand.

Der gemeinsame Nenner ist also die Verwechslung von Werkzeug und Ziel. Das Ziel ist ein Team, das konsistente Software mit weniger Reibung liefert.

Fazit: Ist ein Monorepo die richtige Wahl für Sie?

Die kurze Antwort auf die Frage, was ist ein Monorepo, lautet: viele Projekte in einem Repository. Die lange Antwort ist ein Abwägen. Sie gewinnen gemeinsamen Code, atomare Änderungen und Konsistenz, müssen aber Build Dauer, Rechte und Repository Größe im Griff behalten.

Sie können die Entscheidung daher auf drei Fragen reduzieren. Ändern sich Ihre Projekte oft gemeinsam? Kopieren Sie gemeinsamen Code zwischen Repositories? Kümmert sich jemand in Ihrem Team um das Werkzeug? Antworten Sie dreimal mit Ja, ist ein Monorepo somit ein starker Kandidat.

Sind Sie unsicher, starten Sie dann mit einem kleinen Pilot und messen das Ergebnis. Als Talha Aslan und Team empfehlen wir diesen Weg bei Entscheidungen zur Softwarearchitektur, denn ein leicht umkehrbarer Versuch ist mehr wert als eine lange Debatte.