Monorepo oder mehrere Repositories?

Ein Remote, ein Repository?

Die Vorstellung wirkt zunächst konsequent:

ein Team
→ ein Microfrontend
→ ein Repository
→ eine Pipeline
→ ein Release

Wenn Microfrontends unabhängige Frontend-Bereiche schaffen sollen, scheint ein gemeinsames Repository dieser Unabhängigkeit zu widersprechen. Der Quellcode liegt schließlich am selben Ort. Abhängigkeiten sind sichtbar. Teams können theoretisch auf dieselben Dateien zugreifen. Änderungen an zentralen Konfigurationen betreffen möglicherweise den gesamten Workspace.

Daraus entsteht schnell die Schlussfolgerung, jedes Remote benötige ein eigenes Repository.

In realen Produkten existiert jedoch ein ebenso plausibler Gegenentwurf:

ein Monorepo
├── Host
├── Remote A
├── Remote B
├── Remote C
├── gemeinsame Plattformbibliotheken
└── getrennte Builds und Deployments

Auch in dieser Struktur können die Remotes getrennt gebaut, getestet, veröffentlicht und von unterschiedlichen Teams verantwortet werden. Der gemeinsame Quellort sagt zunächst nur aus, dass die Projekte im selben Repository verwaltet werden. Er sagt noch nichts darüber aus, ob sie dasselbe Artefakt erzeugen oder gemeinsam veröffentlicht werden müssen.

Umgekehrt erzeugen mehrere Repositories nicht automatisch echte Unabhängigkeit:

Repository A
Repository B
Repository C

aber:
├── gemeinsame Freigabe
├── zentrale Testumgebung
├── synchronisierte Releases
├── manuelle Vertragsmigration
└── gemeinsamer Betriebskalender

Der Quellcode wurde getrennt. Die Veränderungs- und Releaseprozesse bleiben dennoch gekoppelt.

Damit verschiebt sich die entscheidende Frage. Nicht die Anzahl der Repositories ist zuerst zu klären, sondern die Bedeutung ihrer Grenzen:

Welche Grenze bildet ein Repository tatsächlich ab?

Microfrontends ermöglichen getrennte Repositories. Sie verlangen sie nicht.

Repository-Grenzen sind weder automatisch Deployment-Grenzen noch fachliche oder organisatorische Grenzen. Ein Monorepo kann unabhängige Releases sehr gut unterstützen, solange Deployables, Ownership und Pipelines getrennt bleiben. Mehrere Repositories können Autonomie stärken, erhöhen aber die Kosten gemeinsamer Toolchains, lokaler Entwicklung und übergreifender Änderungen.

Die zweite Hälfte dieser Entscheidung ist organisatorisch: Ein Monorepo skaliert besonders gut innerhalb gemeinsamer Governance. Mehrere Repositories werden häufig dort sinnvoll, wo Zugriffsrechte, Budgetverantwortung, Releasehoheit und organisatorische Kontrolle tatsächlich getrennt sind.

Vier Grenzen, die häufig verwechselt werden

In Diskussionen über Monorepos werden mehrere Arten von Grenzen häufig so behandelt, als müssten sie am selben Ort verlaufen:

Repository-Grenze
≠
Deployment-Grenze
≠
Team- und Ownership-Grenze
≠
fachliche Grenze

Diese Grenzen können zusammenfallen. Sie müssen es aber nicht.

Repository-Grenze

Die Repository-Grenze entscheidet unter anderem:

• welcher Quellcode gemeinsam versioniert wird,
• welche Änderungen atomar in einem Commit möglich sind,
• welche Toolchains und Regeln zentral verfügbar sind,
• welche Personen Zugriff auf denselben Quellraum besitzen.

Sie beschreibt damit vor allem einen gemeinsamen Entwicklungs- und Kontrollraum.

Deployment-Grenze

Die Deployment-Grenze entscheidet:

• welches Artefakt unabhängig gebaut wird,
• welche Einheit separat veröffentlicht werden kann,
• welche Pipeline und Laufzeit ein Deployable besitzt,
• welcher Release ein anderes Deployable nicht zwingend mitziehen muss.

Sie verläuft dort, wo aus Quellcode eine unabhängig veröffentlichbare und betreibbare Einheit entsteht.

Team- und Ownership-Grenze

Die Team- und Ownership-Grenze entscheidet:

• wer Änderungen verantwortet,
• wer Releases freigibt,
• wer bei Störungen reagiert,
• wer Architektur- und Produktentscheidungen trifft.

Ownership ist damit mehr als die Erlaubnis, Dateien zu verändern. Sie umfasst Verantwortung für Verhalten, Qualität, Betrieb und Weiterentwicklung.

Fachliche Grenze

Die fachliche Grenze entscheidet:

• welche Capability ein Produktbereich besitzt,
• welche Modelle und Regeln dort gelten,
• welche Daten und Use Cases zu seiner Verantwortung gehören.

Sie folgt dem Produkt und seiner Fachlichkeit, nicht zwangsläufig einer Verzeichnisstruktur.

Ein Repository kann mehrere fachliche und technische Grenzen enthalten. Mehrere Repositories können trotzdem eine einzige eng gekoppelte Veränderungseinheit bilden.

Die Repository-Struktur sollte eine gewünschte Arbeits- und Governance-Struktur unterstützen. Sie erzeugt diese Struktur nicht automatisch.

Microfrontends verlangen keine getrennten Repositories

Die technische Stärke von Microfrontends liegt darin, getrennte Frontend-Bereiche unabhängig integrieren und veröffentlichen zu können. Diese Fähigkeit eröffnet unterschiedliche organisatorische Modelle:

• ein gemeinsames Monorepo,
• ein Repository pro Remote,
• ein Repository pro Business Unit,
• mehrere Monorepos innerhalb eines Gesamtprodukts,
• externe Partner-Repositories,
• Mischformen aus diesen Varianten.

Die Fähigkeit zur Verteilung ist keine Pflicht zur maximalen Verteilung.

Technische Autonomie bedeutet, dass eine Trennung möglich ist. Sie bedeutet nicht, dass jede mögliche Trennung sofort vollzogen werden muss.

Ein Remote sollte nicht deshalb im selben Repository liegen müssen, weil seine Integration technisch keine andere Struktur erlaubt. Umgekehrt muss es aber auch nicht künstlich ausgelagert werden, nur um seine Bezeichnung als Microfrontend zu rechtfertigen.

Ein Repository pro Remote ist keine natürliche Konsequenz der Microfrontend-Architektur, sondern eine organisatorische Entscheidung.

Gerade bei einem gemeinsamen Produkt können mehrere Remotes fachlich getrennt und unabhängig veröffentlicht sein, während ihre Teams dieselben Plattformstandards, Entwicklungswerkzeuge und Qualitätsregeln verwenden. In diesem Fall kann ein Monorepo die Zusammenarbeit vereinfachen, ohne die Deployment-Grenzen aufzulösen.

Warum ein Monorepo unabhängige Releases nicht verhindert

Ein Monorepo kann mehrere eigenständige Deployables enthalten:

workspace
├── host
├── todos-remote
├── tasks-remote
├── members-remote
├── platform-contracts
└── shared-tooling

Innerhalb dieses Workspaces können die Remotes weiterhin eigene Releaseeinheiten bilden:

todos-remote
├── eigenes Artefakt
├── eigene Pipeline
└── eigener Deploymentzeitpunkt

tasks-remote
├── eigenes Artefakt
├── eigene Pipeline
└── eigener Deploymentzeitpunkt

Repository und Release liegen auf unterschiedlichen Ebenen.

Ein Commit kann mehrere Projekte ändern, ohne alle zu veröffentlichen. Builds und Deployments können gezielt nur die betroffenen Deployables behandeln.

Zum Release-Monolithen wird ein Monorepo dann, wenn Prozesse und Pipelines alle Projekte künstlich gemeinsam behandeln.

Das geschieht beispielsweise, wenn jede Änderung grundsätzlich einen vollständigen Produktbuild auslöst, alle Tests unabhängig von der tatsächlichen Betroffenheit ausgeführt werden müssen oder eine zentrale Freigabe stets sämtliche Deployables gemeinsam veröffentlicht. Diese Kopplung entsteht nicht durch den gemeinsamen Repository-Root. Sie entsteht durch die gewählte Build-, Test- und Freigabelogik.

Ein Monorepo verhindert unabhängige Releases nicht. Eine globale Build-, Test- und Freigabelogik kann es jedoch tun.

Gemeinsamer Quellort darf nicht gemeinsames Release bedeuten.

Unabhängige Releases bedeuten nicht, dass jede Veränderung nur ein Projekt berührt. Sie bedeuten, dass nicht betroffene Deployables nicht aus rein strukturellen Gründen mit veröffentlicht werden müssen.

Die realen Stärken eines Monorepos

Die Vorteile eines Monorepos werden gelegentlich als persönliche Bequemlichkeit abgetan. Tatsächlich beschreiben sie reale Entwicklungsökonomie.

Sichtbarer Abhängigkeitsgraph

Abhängigkeiten zwischen Host, Remotes, Plattformverträgen und Bibliotheken können zentral analysiert werden. Ein solcher Graph ersetzt keine Architektur, macht ihre technischen Folgen aber überprüfbar.

Atomare Änderungen

Eine mehrere Projekte betreffende Änderung kann in einem Commit umgesetzt werden:

ein Commit
├── Plattformvertrag
├── Host-Adapter
├── Remote A
└── Tests

Die Änderung bleibt als zusammengehöriger Vorgang sichtbar. Der Vertrag wird nicht an einer Stelle verändert, während die notwendige Consumer-Anpassung in einem anderen Repository vergessen wird.

Atomar bedeutet dabei nicht automatisch gleichzeitig deployt. Wenn die Artefakte zeitlich unabhängig veröffentlicht werden, muss der Vertrag trotzdem mit dem möglichen Versionsversatz umgehen können.

Gemeinsame Toolchain

Linting, Tests, TypeScript-Konfiguration, Build-Werkzeuge und Qualitätsregeln können gemeinsam gepflegt werden. In der Praxis wirkt diese gemeinsame Toolchain häufig weniger spektakulär, als sie wirtschaftlich ist.

Einfachere lokale Entwicklung

Mehrere Deployables lassen sich aus einem Workspace starten und in ihrer tatsächlichen Integration prüfen. Das ist besonders wertvoll für Abläufe, die Host, Remotes und gemeinsame Plattformdienste berühren.

Übergreifende Refactorings

Umbenennungen, API-Anpassungen und strukturelle Änderungen können repositoryweit gesucht, bewertet und ausgeführt werden. Betroffene Stellen sind nicht über mehrere Suchräume verteilt.

Das bedeutet nicht, dass jedes Team fremden Code beliebig verändern sollte. Es bedeutet zunächst nur, dass Auswirkungen sichtbar und Änderungen technisch zusammenhängend bearbeitbar sind.

Auffindbarkeit

Code, Verträge, Tests und technische Dokumentation liegen in einem gemeinsamen Navigationsraum. Neue Teammitglieder können Produktzusammenhänge leichter nachvollziehen. Verantwortliche sehen schneller, wie eine Plattformregel tatsächlich verwendet wird.

Diese Vorteile sind nicht nur Komfort. Sie reduzieren reale Kosten koordinierter Veränderungen.

Die Risiken der gemeinsamen Nähe

Die Vorteile eines Monorepos entstehen durch Nähe. Genau diese Nähe erzeugt seine Risiken.

Unerlaubte direkte Imports

Wenn alles technisch erreichbar ist, können Remotes interne Implementierungen anderer Produktbereiche importieren. Ein benötigter Typ oder eine Hilfsfunktion ist nur wenige Verzeichnisse entfernt. Aus einer kurzfristigen Abkürzung entsteht eine dauerhafte Abhängigkeit.

Die Nähe im Repository darf nicht mit erlaubter architektonischer Kopplung verwechselt werden.

Zu viele Shared Libraries

Ähnlicher Code wird vorschnell zentralisiert. Aus zwei lokalen Implementierungen entsteht eine gemeinsame Bibliothek, die bald von vielen Remotes verwendet wird. Eine kleine Anpassung betrifft anschließend das gesamte Produkt.

Shared Libraries sind nicht grundsätzlich falsch. Sie benötigen jedoch einen stabilen gemeinsamen Zweck und klare Ownership. Ähnlichkeit allein ist noch kein solcher Zweck.

Globale Toolchain

Eine zentrale Toolchain vereinfacht Pflege, vergrößert aber den Wirkungsbereich ihrer Änderungen. Ein Upgrade an der Root-Konfiguration kann große Teile des Workspaces betreffen, auch wenn die Deployables getrennt veröffentlicht werden.

Die zentrale Toolchain ist damit eine reale Plattformverantwortung.

Scheinbar kostenlose Cross-Team-Änderungen

Ein Team kann fremden Code direkt anpassen, weil alles im selben Pull Request erreichbar ist. Technisch ist das effizient. Organisatorisch kann es Ownership unterlaufen.

Die Möglichkeit zur atomaren Änderung darf nicht bedeuten, dass die verantwortlichen Teams nur noch nachträglich informiert werden.

Zentrale Pipeline als Engpass

Eine beschädigte Root-Konfiguration oder globale CI-Regel kann viele Deployables gleichzeitig blockieren. Auch ein unabhängiges Remote kann dann nicht veröffentlicht werden, obwohl sein eigener Code unverändert und funktionsfähig ist.

Große Affected-Radien

Änderungen in zentralen Bibliotheken können Builds und Tests zahlreicher Remotes auslösen. Das erhöht nicht nur Laufzeiten, sondern zeigt auch, wie viel Verantwortung in einem gemeinsamen Baustein konzentriert wurde.

Ein Monorepo benötigt Governance gerade deshalb, weil technische Grenzüberschreitungen so einfach sind.

Was Nx Affected tatsächlich zeigt

Eine Affected-Strategie nutzt einen Projekt- und Abhängigkeitsgraphen, um aus einer Änderung die betroffenen Projekte abzuleiten:

Änderung
    │
    ▼
Projekt- und Abhängigkeitsgraph
    │
    ▼
betroffene Projekte
    ├── Builds
    ├── Tests
    ├── E2E-Szenarien
    └── Deployments

Nx Affected ist ein bekanntes Beispiel für dieses Prinzip. Entscheidend ist hier nicht das konkrete Werkzeug, sondern die graphbasierte Auswahl.

Unveränderte, nicht abhängige Projekte müssen nicht zwangsläufig erneut gebaut oder vollständig geprüft werden.

Die Aussagekraft hängt jedoch vom korrekt modellierten Graphen ab. Direkte Projektabhängigkeiten können erfasst werden. Versteckte Laufzeitkopplungen, gemeinsam genutzte externe Konfigurationen oder implizite Verträge liegen möglicherweise außerhalb des sichtbaren Graphen.

Affected macht Kopplung sichtbar. Es beseitigt sie nicht.

Ein einfaches Beispiel verdeutlicht den Unterschied:

Änderung an Remote A
└── nur Remote A betroffen

Eine lokale Änderung kann einen kleinen Affected-Radius besitzen. Das Remote lässt sich gezielt bauen, testen und veröffentlichen.

Anders sieht es bei einer zentralen Bibliothek aus:

Änderung an zentraler Plattformbibliothek
├── Host
├── Remote A
├── Remote B
└── Remote C betroffen

Dieses Ergebnis kann eine legitime zentrale Verantwortung zeigen. Ein Authentifizierungskontext oder ein stabiler Lifecycle-Vertrag betrifft möglicherweise bewusst alle Integrationspartner.

Es kann aber auch auf eine zu breite Shared Library hinweisen, in der fachlich unabhängige Funktionen zusammengefasst wurden.

Ein großer Affected-Radius ist keine Schwäche des Monorepos. Er ist ein Architekturhinweis.

Warum mehrere Repositories Autonomie sichtbarer machen

Das idealtypische Gegenmodell trennt die Remotes physisch:

Remote A Repository
├── eigener Quellcode
├── eigene Pipeline
├── eigene Toolchain
└── eigener Release

Remote B Repository
├── eigener Quellcode
├── eigene Pipeline
├── eigene Toolchain
└── eigener Release

Diese Struktur macht bestimmte Grenzen unmittelbar sichtbar.

Technische Zugriffsgrenzen sind eindeutiger. Teams können Toolchains unabhängig verändern. Pipelines und Releases sind organisatorisch getrennt. Ein beschädigtes Repository blockiert nicht automatisch alle anderen. Externe Organisationen benötigen keinen Zugriff auf den vollständigen Produktquellcode.

Ownership lässt sich weniger beiläufig übergehen, weil eine Änderung am fremden Remote einen bewussten Wechsel in einen anderen Verantwortungsraum erfordert.

Mehrere Repositories können Autonomie schützen, weil fremde Änderungen nicht beiläufig möglich sind.

Diese physische Trennung wird häufig als Polyrepo bezeichnet. Sie kann sinnvoll sein, wenn die technische Struktur eine tatsächlich getrennte Verantwortung abbildet.

Sie garantiert jedoch keine unabhängige Architektur.

Mehrere Repositories können weiterhin durch synchronisierte Releases, zentrale Freigaben, eine gemeinsame Testumgebung, manuelle Integrationsschritte oder Abhängigkeiten von noch nicht veröffentlichten Artefakten gekoppelt sein.

Der Quellcode ist dann getrennt, die Veränderungsmechanik aber nicht.

Die versteckten Kosten mehrerer Repositories

Mehrere Repositories erzeugen häufig organisatorische Ruhe. Technisch und operativ sind sie jedoch nicht kostenlos.

Toolchain-Drift

Repositories können unterschiedliche Versionen von Frameworks, Build-Werkzeugen, Linting und Tests verwenden. Diese Freiheit kann erwünscht sein, etwa bei stark unterschiedlichen Lebenszyklen.

Sie kann aber auch Pflegekosten erzeugen: Sicherheitskorrekturen, Qualitätsregeln und Wissen über Build- und Testsysteme verteilen sich auf mehrere Varianten.

Duplizierte Infrastruktur

Jedes Repository benötigt gegebenenfalls eine eigene Ausprägung von:

• CI-Konfiguration,
• Dependency-Updates,
• Qualitätsregeln,
• Release-Automatisierung,
• lokalen Startanweisungen,
• Security- und Compliance-Konfiguration.

Zentrale Vorlagen können diese Wiederholung reduzieren. Sie führen allerdings erneut eine gemeinsame Plattformabhängigkeit ein, die versioniert und gepflegt werden muss.

Erschwerte lokale Entwicklung

Für produktweite Abläufe müssen mehrere Repositories ausgecheckt, gestartet und in kompatiblen Versionen kombiniert werden. Nicht jedes Team benötigt jederzeit das vollständige Produkt. Sobald jedoch ein integrativer Fehler untersucht werden muss, wird die verteilte Struktur spürbar.

Geringere Auffindbarkeit

Verträge, Implementierungen, Tests und zuständige Teams liegen über mehrere Orte verteilt. Eine globale Suche wird durch Kataloge, Dokumentation und Paketregistrierungen ersetzt.

Das kann gut funktionieren. Es benötigt jedoch bewusst gepflegte Navigations- und Informationsstrukturen.

Cross-Repository-Änderungen

Eine gemeinsame Änderung benötigt mehrere Pull Requests, Versionen und koordinierte Rollouts. Die technische Trennung macht sichtbar, dass mehrere Verantwortungsbereiche betroffen sind. Gleichzeitig steigt der operative Aufwand.

Vertragsmigrationen

Consumer und Provider können nicht in einem atomaren Commit vollständig umgestellt werden. Übergangskompatibilität wird erforderlich. Neue und alte Vertragsvarianten müssen vorübergehend parallel existieren.

Die organisatorische Trennung beseitigt Koordination nicht. Sie verlagert sie aus dem Repository in Verträge, Versionen und Releaseabläufe.

Mehrere Repositories machen Kopplung sichtbarer. Sie machen sie nicht automatisch kleiner.

Atomare Änderung oder kompatible Migration

Ein zentraler Trade-off zwischen Monorepo und mehreren Repositories liegt in der Mechanik gemeinsamer Veränderungen.

Atomare Änderung im Monorepo

ein Commit
├── Vertrag ändern
├── Provider anpassen
├── Consumer anpassen
└── Tests aktualisieren

Eine solche Änderung ist schnell koordinierbar. Der Gesamtzusammenhang bleibt sichtbar. Fehler in der gemeinsamen Anpassung werden früh erkannt.

Die Atomizität besitzt jedoch ein Risiko: Sie kann verschleiern, dass mehrere unabhängig verantwortete Deployables betroffen sind.

Wenn die Änderung nur funktioniert, nachdem alle Beteiligten gleichzeitig veröffentlicht wurden, existiert trotz gemeinsamen Commits eine Releasekopplung. Das Monorepo macht die Implementierung bequem, löst aber nicht das Problem unterschiedlicher Deploymentzeitpunkte.

Auch unabhängig veröffentlichte Deployables innerhalb eines Monorepos benötigen kompatible Übergänge, wenn ihre Releases zeitlich auseinanderliegen können.

Kompatible Migration über mehrere Repositories

Bei getrennten Repositories wird der Übergang typischerweise expliziter:

1. Provider erweitert Vertrag kompatibel.
2. Neue Vertragsversion wird veröffentlicht.
3. Consumer migrieren unabhängig.
4. Alte und neue Variante existieren vorübergehend parallel.
5. Alte Variante wird später entfernt.

Dieses Vorgehen unterstützt unabhängige Zeitpläne. Consumer müssen nicht gleichzeitig veröffentlichen. Organisatorische Autonomie wird technisch ernst genommen.

Der Preis besteht aus zusätzlicher Übergangslogik, Versionierung, längeren Migrationsphasen und höherem Koordinationsbedarf.

Ein Monorepo macht koordinierte Änderungen billig. Mehrere Repositories erzwingen häufiger kompatible Veränderungen.

Getrennte Repositories machen unabhängige Veränderung teurer, aber häufig auch ehrlicher.

Das ist kein Argument gegen atomare Änderungen. Sie sind wertvoll, solange sie nicht mit einem zwingenden gemeinsamen Deployment verwechselt werden.

Die eigentliche Grenze ist Governance

Die Repository-Entscheidung wird häufig als technische Skalierungsfrage behandelt. In vielen Produkten ist Governance jedoch das wichtigere Kriterium.

Ein Monorepo passt häufig gut zu einer Struktur wie dieser:

gemeinsames Produkt
├── gemeinsame Governance
├── gemeinsame technische Leitung
├── gemeinsame Zugriffsregeln
├── gemeinsame Qualitätsstandards
├── ähnliche Toolchains
└── abgestimmte Plattformverantwortung

Unter diesen Bedingungen existiert ein gemeinsames Interesse daran, technische Regeln zentral zu pflegen, Abhängigkeiten sichtbar zu halten und koordinierte Änderungen effizient umzusetzen.

Das bedeutet nicht, dass jedes Team denselben Releasezeitpunkt oder dieselben fachlichen Prioritäten besitzen muss. Es bedeutet, dass ein gemeinsamer Kontroll- und Entwicklungsraum grundsätzlich erwünscht ist.

Ein Monorepo optimiert Zusammenarbeit innerhalb gemeinsamer Governance.

Die gemeinsame Governance muss konkret sein. Sie umfasst beispielsweise die Zuständigkeit für Root-Konfigurationen, Plattformbibliotheken, Architekturregeln, zentrale Pipelines und übergreifende Qualitätsstandards.

Ein Monorepo bezahlt mit Governance.

Ohne diese Governance wird der gemeinsame Workspace schnell zu einem Raum, in dem jeder alles ändern kann, aber niemand die Folgen zentraler Entscheidungen verantwortet.

Weltweit verteilt ist nicht automatisch organisatorisch getrennt

Geografische Distanz ist keine Repository-Grenze.

Ein Produkt kann über Berlin, München, New York und Singapur verteilt sein und trotzdem eine gemeinsame Governance besitzen. Die Teams können dieselben Zugriffsregeln, Architekturstandards, Produktziele und Plattformverantwortlichen haben.

In einem solchen Umfeld kann ein Monorepo räumliche Distanz durch einen gemeinsamen technischen Kontext ausgleichen. Abhängigkeiten, Verträge und Qualitätsregeln bleiben sichtbar.

Umgekehrt können zwei Teams im selben Gebäude organisatorisch vollständig getrennt sein. Wenn sie unterschiedliche Budgets, Freigaben, Zugriffsrechte und Verantwortungsmodelle besitzen, ist ihre physische Nähe für die Repository-Entscheidung weitgehend bedeutungslos.

Die relevante Entfernung ist nicht geografisch. Sie ist organisatorisch.

Mehrere Firmen und Business Units verändern die Entscheidung

Anders wird die Situation bei einem Gesamtprodukt, an dem mehrere organisatorisch eigenständige Einheiten beteiligt sind:

gemeinsames Produkt
├── Business Unit A
├── Business Unit B
├── Tochtergesellschaft
├── externer Dienstleister
└── Partnerunternehmen

Zwischen diesen Einheiten können sich Zugriffsrechte, Vertraulichkeit, Budgetverantwortung, Personalverantwortung, Releasefreigaben, Compliance, Betriebsmodelle, Prioritäten, Lebenszyklen, Haftung und Support unterscheiden.

Technisch wäre auch hier ein Monorepo möglich. Organisatorisch würde es jedoch zu einem gemeinsamen Kontrollraum. Dann müssten dauerhaft Fragen beantwortet werden wie:

• Wer darf welchen Bereich lesen?
• Wer darf globale Regeln verändern?
• Wer besitzt die zentrale CI?
• Wer entscheidet über Toolchain-Upgrades?
• Wer behebt eine beschädigte Hauptpipeline?
• Wer darf einen fremden Produktbereich freigeben?

Diese Fragen sind lösbar. Ihre dauerhafte Lösung kann jedoch teurer sein als der gemeinsame Quellraum nützt.

Ein Monorepo kann innerhalb gemeinsamer Governance hervorragend skalieren. Über Governance-Grenzen hinweg kann dieselbe Zentralität zum Konflikt werden.

Je weiter Ownership, Zugriffsrechte und Releaseverantwortung auseinanderliegen, desto weniger sollte ein gemeinsamer Repository-Root zur Voraussetzung werden.

Getrennte Repositories können dann organisatorische Autonomie schützen:

Organisation A
├── besitzt Repository A
├── besitzt Pipeline A
├── besitzt Remote A
└── veröffentlicht Remote A

Organisation B
├── besitzt Repository B
├── besitzt Pipeline B
├── besitzt Remote B
└── veröffentlicht Remote B

Eine Organisation benötigt keinen vollständigen Zugriff auf fremden Quellcode. Toolchain-Entscheidungen können lokal getroffen werden. Ein Pipelinefehler blockiert nicht automatisch alle Beteiligten. Releasefreigaben bleiben innerhalb der verantwortlichen Organisation. Vertragliche und regulatorische Grenzen lassen sich technisch abbilden.

Mehrere Repositories sind hier nicht zwingend technisch einfacher. Sie können organisatorisch ruhiger sein.

Ein Monorepo optimiert Zusammenarbeit innerhalb gemeinsamer Governance. Mehrere Repositories können Autonomie über Governance-Grenzen hinweg schützen.

Hybridmodelle statt Repository-Dogma

Die Repository-Frage muss nicht einmal für das gesamte Produkt einheitlich beantwortet werden.

Ein mögliches Modell sieht so aus:

Gesamtprodukt
├── BU A Monorepo
│   ├── Remote A1
│   ├── Remote A2
│   └── API A
│
├── BU B Monorepo
│   ├── Remote B1
│   └── Remote B2
│
├── Partner Repository
│   └── Remote C
│
└── versionierte Plattformverträge

Innerhalb einer Business Unit können mehrere zusammengehörige Remotes, APIs und Libraries in einem Monorepo liegen. Dort profitieren sie von gemeinsamer Toolchain, Auffindbarkeit und atomaren Änderungen.

Andere Business Units, Firmen oder Lieferanten besitzen eigene Repositories oder Monorepos. Sie veröffentlichen ihre Deployables innerhalb ihrer Governance und integrieren sich über versionierte Plattformverträge.

Diese Verträge sollten auf das tatsächlich Notwendige begrenzt bleiben, beispielsweise:

• Mounting- und Lifecycle-Vertrag,
• Authentifizierungskontext,
• Navigation,
• Designsystem oder Tokens,
• Observability,
• veröffentlichte API- und Eventverträge.

Die Repository-Struktur muss nicht die technische Remote-Struktur eins zu eins nachzeichnen.

Ein Repository pro Governance-Raum kann sinnvoller sein als ein Repository pro Remote.

Das Hybridmodell ist keine universelle Best Practice. Es zeigt, dass ein Remote eine Deployment- und Integrationsentscheidung ist, während ein Repository zusätzlich Zusammenarbeit, Zugriff und Kontrolle strukturiert.

Ownership ohne physische Trennung

Ein Monorepo verhindert klare Ownership nicht. Es verlangt jedoch, dass Ownership sichtbar und überprüfbar wird.

Mögliche Mechanismen sind:

• Code Ownership,
• Projekt-Tags und Modulgrenzen,
• eingeschränkte Imports,
• getrennte Pipelines,
• getrennte Releaseberechtigungen,
• definierte Verantwortliche,
• Architecture Tests,
• unterschiedliche Deploymentziele.

Diese Mechanismen ersetzen keine Zusammenarbeit. Sie verhindern aber, dass der gemeinsame Quellraum als Einladung zu beliebigen Grenzüberschreitungen verstanden wird.

Ownership, die nur in einem Organigramm steht, ist schwach. Ownership, die ausschließlich durch getrennte Repositories erzwungen wird, kann unnötig teuer sein.

Die passende Stärke liegt häufig dazwischen:

gemeinsamer Workspace
+
sichtbare und überprüfbare Grenzen
+
getrennte Deployments
+
klare Verantwortliche

Ein Monorepo ist besonders plausibel, wenn gemeinsame Governance besteht, koordinierte Änderungen häufig vorkommen, Toolchains ähnlich sind und regelmäßig an Plattformverträgen gearbeitet wird. Auch gemeinsame lokale Entwicklung, zentrale Auffindbarkeit und kontrollierbare Zugriffsrechte sprechen dafür.

Voraussetzung bleibt, dass Deployments trotz gemeinsamen Quellorts getrennt sind und Modul- sowie Ownership-Grenzen tatsächlich wirken.

Mehrere Repositories sind besonders plausibel, wenn unterschiedliche Firmen oder Vertragspartner beteiligt sind, Business Units echte Autonomie besitzen, Zugriffsrechte stark voneinander abweichen oder eigene Compliance- und Freigabeprozesse gelten.

Auch deutlich unterschiedliche Lebenszyklen, eigenständige Finanzierung, stark abweichende Toolchains, kaum gemeinsame atomare Änderungen oder notwendige Vertraulichkeit können eine Repository-Grenze begründen.

Die Repository-Grenze wird besonders sinnvoll, wenn sie eine reale Governance-, Vertrauens- oder Zugriffsgrenze abbildet.

Governance oder Koordination

Die Entscheidung zwischen Monorepo und mehreren Repositories ist keine Glaubensfrage. Beide Modelle besitzen unterschiedliche Kostenprofile.

Monorepo

Stärken
├── atomare Änderungen
├── gemeinsame Toolchain
├── sichtbarer Graph
├── einfache Auffindbarkeit
└── effiziente lokale Entwicklung

Kosten
├── Governance
├── Modulgrenzen
├── zentrale Toolchain-Entscheidungen
├── potenziell große Affected-Radien
└── Schutz vor beiläufiger Kopplung

Mehrere Repositories

Stärken
├── klare Zugriffsgrenzen
├── autonome Toolchains
├── getrennte Pipelines
├── organisatorische Isolation
└── sichtbare Ownership

Kosten
├── Cross-Repository-Koordination
├── Versionsmanagement
├── duplizierte Automatisierung
├── schwierigere lokale Integration
└── kompatible Migrationen

Ein Monorepo bezahlt mit Governance. Mehrere Repositories bezahlen mit Koordination.

Ein Monorepo kann ein Produkt mit mehreren unabhängig veröffentlichten Remotes erheblich vereinfachen. Diese Nähe benötigt jedoch klare Ownership, wirksame Modulgrenzen und getrennte Releaseprozesse.

Mehrere Repositories werden besonders dort sinnvoll, wo Governance, Zugriffsrechte, Firmen oder Releaseverantwortungen tatsächlich getrennt sind. Dort kann organisatorische Autonomie wichtiger sein als die Effizienz gemeinsamer Änderungen.

Repository-Grenzen sind keine Deployment-Grenzen. Affected macht Kopplung sichtbar, beseitigt sie aber nicht. Die Repository-Struktur sollte die Grenze abbilden, innerhalb der gemeinsames Ändern und gemeinsame Kontrolle tatsächlich erwünscht sind.

Das Repository entscheidet nicht, ob ein Release unabhängig ist. Es entscheidet, wie teuer gemeinsame Veränderung und organisatorische Autonomie werden.