![Monorepo Build Systems. DAG vs. depth-first recursive, featuring sparse-checkout [video]](/images/5B8C4ACA-7ED7-4823-9284-B10417C03893)
Monorepos, die Praxis mehrere Projekte oder Komponenten in einem einzigen Repository zu verwalten, gewinnen insbesondere in großen Softwareunternehmen zunehmend an Bedeutung. Diese Struktur bietet enorme Vorteile in Bezug auf Code-Wiederverwendung, Konsistenz und das Management von Abhängigkeiten. Allerdings bringt sie komplexe Herausforderungen im Bereich der Build-Systeme mit sich. Hier treten zwei Bauweisen besonders hervor: der gerichtete azyklische Graph (DAG) und die tiefensuchebasierte rekursive Build-Strategie. Zudem spielt die Technik des Sparse-Checkouts eine wichtige Rolle, um den Umgang mit riesigen Codebasen effizienter zu gestalten.
Ein Monorepo-Build-System muss in der Lage sein, die Abhängigkeiten zwischen verschiedenen Modulen oder Projekten korrekt und performant zu verwalten. Ein sehr verbreiteter Ansatz ist die Verwendung eines gerichteten azyklischen Graphen, kurz DAG. Dabei werden die einzelnen Module oder Komponenten als Knoten betrachtet, während die Abhängigkeiten als gerichtete Kanten zwischen diesen Knoten modelliert werden. Die Eigenschaft, dass der Graph keine Zyklen enthält, ist essenziell, um unendliche Build-Schleifen zu vermeiden. Ein DAG erlaubt es Build-Systemen, Anforderungen transparent zu verfolgen und nur die betroffenen Teile neu zu bauen, wenn sich eine Komponente ändert.
Dies führt nicht nur zu einem schnelleren Build-Prozess, sondern auch zu besserer Skalierbarkeit bei steigender Projektgröße. Im Gegensatz dazu beruht die tiefensuchebasierte rekursive Build-Methode auf einer anderen Logik. Hier wird der Build-Prozess meist top-down gestartet, indem zunächst das Hauptprojekt angegangen wird und dann rekursiv alle seine Abhängigkeiten abgearbeitet werden. Dieses Vorgehen erinnert an einen klassischen Tiefensuchalgorithmus in der Graphentheorie. Während dieses Verfahren relativ einfach zu implementieren ist, stößt es bei großen Monorepos häufig an seine Grenzen.
Tiefensuche kann zu redundanten Berechnungen führen, wenn gemeinsame Abhängigkeiten mehrfach durchlaufen werden. Dadurch erhöht sich der Build-Aufwand und er steigt mit wachsender Projektkomplexität überproportional an. Der Einsatz eines DAG-basierten Systems kann diese Nachteile umgehen, indem es Abhängigkeiten zentral zusammenführt und mehrfach auftretende Module nur einmalige berücksichtigt. Dadurch optimieren sich Speicherverbrauch und Rechenzeit. Insbesondere bei Multi-Team-Projekten, in denen verschiedene Teams getrennte, aber miteinander verknüpfte Module entwickeln, zeigt der DAG seine Stärken, da er Abhängigkeitsinformationen klar strukturiert und Fehlerquellen minimiert.
Eine weitere Herausforderung bei Monorepos ist die schiere Menge an Code, die lokal ausgecheckt werden muss. Hier kommt die Technik des Sparse-Checkouts ins Spiel. Sparse-Checkout erlaubt es Entwicklern, nur eine Teilmenge des vollständigen Repositories auszuwählen und lokal zu laden. Dies reduziert sowohl die benötigte Festplattenkapazität als auch die Zeit für Checkout-Operationen enorm. Besonders in Kombination mit einem DAG-basierten Build-System ergibt sich ein enormes Potenzial für Performance-Steigerungen.
Der grundlegende Workflow beginnt dabei mit einer exakten Definition der relevanten Module anhand der aktuellen Entwicklungsaufgabe oder des zu bauenden Features. Das Build-System identifiziert, welche Module benötigt werden und veranlasst den Sparse-Checkout nur dieser Teilmenge. Auf diese Weise sind unnötige Dateien und Verzeichnisse von der lokalen Umgebung ferngehalten, was nicht nur Speicher spart, sondern auch die Navigation und den Build-Prozess vereinfacht. Moderne Werkzeuge wie Git unterstützen Sparse-Checkout native und machen dessen Handhabung für Entwickler intuitiv. Durch feingranulare Steuerung des ausgecheckten Inhalts wird die Entwicklungszeit schneller, da sowohl die lokale IDE als auch die Build-Tools effizienter arbeiten können.
Insbesondere wenn zusammen mit DAG-basierten Build-Systemen automatisierte Pipelines und CI/CD-Prozesse organisiert werden, steigt die Zuverlässigkeit der Builds nachweislich. Natürlich gibt es auch Szenarien, in denen tiefensuchebasierte Verfahren Sinn ergeben, etwa bei sehr kleinen oder stark modularisierten Komponentenstrukturen mit geringen Abhängigkeiten. Trotz allem wächst die Community und auch industrielle Praxis klar in Richtung DAG-Modelle, besonders wenn Build-Zeiten und Skalierbarkeit priorisiert werden. Die Integration von Sparse-Checkout-Techniken bringt eine neue Dimension bei der Handhabung großer Monorepos. Denn nicht selten umfassen diese Hunderttausende von Dateien und tausende Entwickler arbeiten parallel an verschiedenen Teilen des Codes.
Die Vermeidung globaler Auscheckoperationen schont Ressourcen und verhindert unnötigen Overhead. Somit sorgen moderne Monorepo-Techniken für agilere Entwicklungszyklen und ermöglichen gleichzeitig das Management enorm komplexer Softwarelandschaften. Ein wichtiges theoretisches Element bei Monorepo-Build-Systemen mit DAG ist der sogenannte Topologische Sortieralgorithmus. Er bestimmt die Reihenfolge, in der die Module gebaut werden müssen, um die jeweiligen Abhängigkeiten zu respektieren. Ohne diese Sortierung können Inkonsistenzen und fehlerhafte Ergebnisse entstehen, weil Komponenten vor ihren notwendigen Vorgängern gebaut werden.
Der Topologische Sortierer arbeitet direkt auf der DAG-Struktur und stellt sicher, dass jede Einheit immer erst dann gebaut wird, wenn alle sachlich erforderlichen Vorgänger abgeschlossen sind. Zusätzlich erlauben fortgeschrittene Build-Systeme das Caching von Zwischenergebnissen, die sich aus dem DAG ergeben. Das heißt, wenn ein Modul und seine Abhängigkeiten unverändert bleiben, kann ihr Build-Ergebnis wiederverwendet werden. Dies führt zu erheblichen Zeitgewinnen, die gerade bei umfangreichen Monorepos den Unterschied zwischen stundenlangen und minutenlangen Builds ausmachen können. Weiterhin sind Monorepo-Build-Systeme heute oft auf hochparallele Prozesse ausgelegt.
Die DAG-Struktur ermöglicht eine effiziente Verteilung der Build-Schritte auf mehrere CPUs oder Maschinen. Insbesondere Cloud-basierte CI/CD-Infrastrukturen profitieren von dieser Parallelisierung, da sie schnellere Durchlaufzeiten und bessere Ressourcenauslastung ermöglichen. Im Gegensatz dazu ist die Tiefensuche mit ihrem sequentiellen Charakter eher limitiert in Sachen Parallelisierbarkeit. Sie eignet sich daher weniger für große Projekte mit vielen Abhängigkeiten. Die rekursive Natur der Tiefensuche kann außerdem Probleme beim Debugging verursachen, da Build-Prozesse schwerer transparent und nachvollziehbar sind.
