Monorepo vs. Polyrepo

Wie Sie Ihren Code auf Repositories aufteilen, klingt nach einer technischen Nebensache – doch diese Entscheidung beeinflusst still und leise, wie Ihr Team zusammenarbeitet, liefert und das System versteht. Ein Monorepo fasst alles in einem einzigen Repository zusammen; beim Polyrepo erhält jeder Service oder jede App ihr eigenes. Keiner der beiden Ansätze ist universell richtig, und die lautesten Meinungen im Internet ignorieren meist Ihre konkrete Situation und Teamgröße. So denken Sie strukturiert darüber nach.

Was ein Monorepo Ihnen bringt

Ein Monorepo vereint Ihre Web-App, Mobile-App, Ihr Backend und gemeinsam genutzte Bibliotheken unter einem Dach. Die Vorteile sind real – insbesondere für kleinere Teams:

• Atomare Änderungen. Aktualisieren Sie einen gemeinsamen Typ, und jeder Konsument wird im selben Pull Request berücksichtigt. Kein aufwändiges Koordinieren über mehrere Repos.
• Eine einzige Quelle der Wahrheit für Tooling. Eine gemeinsame Lint-, Format- und CI-Konfiguration statt Konfigurationsdrift über ein Dutzend Repos.
• Mühelose Code-Wiederverwendung. Gemeinsame TypeScript-Pakete sind schlichte Imports – keine versionierten Pakete, die Sie überall aktualisieren und neu installieren müssen.
• Einfaches Refactoring. Sie finden und beheben jeden Aufrufer einer Funktion, weil alles vor Ihnen liegt.

Tools wie Turborepo und Nx machen das praktikabel, indem sie Builds cachen und nur die Teile verarbeiten, die sich tatsächlich geändert haben.

Was ein Monorepo kostet

Die Nachteile zeigen sich mit wachsender Größe. Build- und CI-Zeiten können ohne intelligentes Caching stark ansteigen. Die Zugriffskontrolle ist weniger granular – einem externen Entwickler Zugang zu einem einzelnen Service zu geben, ohne die gesamte Codebasis offenzulegen, wird schwieriger. Eine naive Konfiguration baut und testet bei jeder Änderung alles neu, was schnell langsam wird. Gutes Tooling mildert all das ab – aber Sie müssen bewusst darin investieren.

Was ein Polyrepo Ihnen bringt

Separate Repositories geben jedem Service harte Grenzen. Ein Team besitzt sein Repo von Anfang bis Ende, deployt nach eigenem Zeitplan und kann nicht versehentlich auf die Interna eines anderen Teams zugreifen. Die Zugriffskontrolle ist von Natur aus granular, das CI jedes Repos ist klein und schnell, und der Schaden durch eine fehlerhafte Änderung bleibt begrenzt.

Der Preis ist Koordinationsaufwand. Eine Änderung, die mehrere Services betrifft, wird zu mehreren Pull Requests in mehreren Repos, die in der richtigen Reihenfolge landen müssen. Gemeinsam genutzter Code muss als versioniertes Paket veröffentlicht werden, und Versionsunterschiede zwischen Repos werden zu einer echten Fehlerquelle. Die Tooling-Konsistenz über viele Repos hinweg aufrechtzuerhalten erfordert aktiven Einsatz.

Wie Sie die Entscheidung tatsächlich treffen

Die ehrliche Antwort lautet: Teamgröße und Kopplung zählen mehr als Ideologie.

1. Frühphasig oder ein einzelnes Produktteam? Nehmen Sie ein Monorepo. Der Koordinationsgewinn ist enorm, wenn alle an allem arbeiten – und es ist der einfachere Ausgangspunkt.
2. Viele unabhängige Teams mit wirklich getrennten Services und Release-Zyklen? Polyrepo-Grenzen reduzieren Reibung und ermöglichen Teams, autonom voranzukommen.
3. Irgendwo dazwischen? Starten Sie mit einem Monorepo und lagern Sie einen Service nur dann in ein eigenes Repo aus, wenn dessen Ownership und Release-Zyklus sich tatsächlich vom Rest unterscheiden.

Die pragmatische Standardwahl

Für die meisten Startups, mit denen wir arbeiten, ist ein Monorepo mit gutem Build-Caching die richtige Entscheidung. Es passt zur Arbeitsweise kleiner Teams – alle im selben Code, gemeinsam liefernd – und verschiebt den Koordinationsaufwand eines Polyrepos auf den Zeitpunkt, an dem Sie tatsächlich die Teamstruktur haben, die davon profitiert. Sie können später immer noch aufteilen; Repos wieder zusammenzuführen ist deutlich schmerzhafter als eines herauszulösen.

Wenn Sie eine Codebasis aufbauen, um die herum Sie ein Team aufstellen möchten, sprechen Sie mit uns.