Monorepo

Was ist ein Monorepo?

Ein Monorepo ist ein einzelnes versioniertes Repository, das viele Projekte enthält: mehrere Apps, gemeinsame Bibliotheken, Infrastruktur-Code, alles an einem Ort mit einer Historie. Es ist das Gegenteil eines Polyrepo-Setups, bei dem jedes Projekt in seinem eigenen Repository mit eigener Versionierung und eigenem Release-Zyklus lebt.

Der Reiz liegt im geteilten Code ohne die Reibung. Wenn ein Frontend, ein Backend und drei gemeinsame Pakete zusammenliegen, landet eine Änderung, die alle betrifft, in einem einzigen atomaren Commit, mit einem Satz Tests, gegen eine konsistente Version jeder Abhängigkeit. Kein internes Paket veröffentlichen und darauf warten, dass abhängige Repos nachziehen. Der Preis ist das Tooling: ein naives Monorepo baut und testet bei jeder Änderung alles neu, daher stützt es sich auf Build-Systeme wie Turborepo, Nx oder Bazel, die den Abhängigkeitsgraphen verstehen und nur anfassen, was sich wirklich geändert hat. Ein Unternehmen mit einer Web-App, einer mobilen App und einer API, die dieselben Typen und dieselbe Validierungslogik teilen, hält sie im Monorepo im Gleichschritt, sodass eine Änderung an einem gemeinsamen Typ den Build sofort bricht statt Wochen später in der Produktion.

Google, Meta und viele moderne Produktteams arbeiten mit Monorepos. Das Muster skaliert, aber nur mit dem richtigen Build- und CI-Tooling darunter.

Monorepos bei Dallonses

Wir setzen Monorepos in Projekten ein, in denen mehrere Apps echten Code teilen, denn die Alternative ist ein langsames Tröpfeln von Versionskonflikt-Bugs, die niemand gern jagt. Gemeinsame Typen, die beim Build auffallen, eine Pull Request, die Frontend und Backend zugleich berührt, eine einzige Quelle der Wahrheit für Abhängigkeiten. Die Struktur zahlt sich beim ersten Mal aus, wenn ein brechender Change in der CI auftaucht und nicht in den Händen eines Kunden.

Die Disziplin steckt im Tooling, nicht im Ordneraufbau. Ein Monorepo ohne intelligentes Caching und selektive Builds macht aus jedem Commit einen zwanzigminütigen CI-Lauf, den Teams still zu überspringen beginnen. Wir richten den Abhängigkeitsgraphen so ein, dass Pipelines nur bauen und testen, was sich geändert hat, und genau hier trifft diese Arbeit auf unsere CI/CD-Pipelines und die Plattformstandardisierung. Das Repo bleibt schnell, und schnell ist es, was dafür sorgt, dass Menschen die Prüfungen weiter ausführen.

Jonglieren Sie mit mehreren Repos, die ständig auseinanderdriften? Ein Monorepo könnte die Lösung sein. Sprechen wir.

Sprechen Sie mit uns über Ihren Code