Monorepo

Programmierer speichern ihren Programmcode nicht einfach auf dem Schreibtisch-Rechner. Sie legen ihn in ein gemeinsames Archiv, das jede Änderung mitschreibt und mehreren Leuten gleichzeitig Zugriff gibt. Ein solches Archiv nennt man Repository, kurz Repo. Große Firmen haben oft hunderte Programme und Dienste – und damit die Wahl: für jedes Programm ein eigenes Repo, oder alles zusammen in ein einziges, riesiges. Die zweite Variante heißt Monorepo, von griechisch « monos » für « einzig ». Es ist also keine besondere Technik, sondern eine Entscheidung darüber, wie man Code organisiert.

Der Streit um doppelte Bausteine

In jeder größeren Firma gibt es Code, den viele Programme brauchen. Etwa eine Funktion, die prüft, ob eine E-Mail-Adresse gültig ist. Oder ein Baustein, der Beträge in Euro korrekt darstellt. Solche gemeinsam genutzten Teile nennt man Bibliotheken.

Liegen alle Programme in getrennten Archiven, muss jedes eine eigene Kopie der Bibliothek einbinden. Findet jemand einen Fehler, muss die Korrektur in zwanzig Projekte einzeln nachgezogen werden. Erfahrungsgemäß bleiben einige davon monatelang auf der alten, fehlerhaften Version. In einem Monorepo existiert die Bibliothek nur einmal. Eine Änderung wirkt sofort überall.

Der zweite Vorteil ist Übersicht. Wer wissen will, welche Programme eine bestimmte Funktion benutzen, sucht einmal quer durch das ganze Archiv. Bei fünfzig verstreuten Repos ist diese Frage praktisch nicht sauber beantwortbar. Google hält deshalb den größten Teil seines Codes in einem einzigen Monorepo – nach eigenen Angaben mehrere Milliarden Zeilen.

Wie ein Archiv mit Millionen Dateien handhabbar bleibt

Technisch ist ein Monorepo zunächst nur ein Ordnerbaum. Oben liegen Verzeichnisse wie « apps » für die einzelnen Programme und « libs » für die gemeinsamen Bausteine. Jedes Team ist für bestimmte Unterordner verantwortlich. Regeln in einer Konfigurationsdatei legen fest, wer Änderungen in welchem Bereich freigeben darf.

Das Hauptproblem ist die Größe. Wenn ein Team eine Zeile ändert, müsste man streng genommen alle Programme neu bauen und testen. Das würde Stunden dauern. Deshalb setzen Firmen sogenannte Build-Werkzeuge ein, etwa Bazel oder Nx. Diese Werkzeuge kennen die Abhängigkeiten zwischen den Ordnern. Sie berechnen, welche Programme von einer Änderung überhaupt betroffen sind, und testen nur diese.

Ein häufiger Irrtum: Ein Monorepo ist nicht dasselbe wie ein Monolith. Ein Monolith ist ein Programm, das als ein einziger großer Block läuft. Ein Monorepo sagt nur, wo der Code liegt – die fertigen Programme können trotzdem hundert getrennte Dienste sein. Umgekehrt kann ein Monolith auch in vielen Repos entwickelt werden. Die beiden Begriffe klingen ähnlich und bedeuten Verschiedenes.

Monorepos in Stellenanzeigen und KI-Projekten

Der Begriff taucht vor allem in Stellenanzeigen und Entwicklerdiskussionen auf. Wenn dort « Erfahrung mit Monorepos » steht, heißt das: Die Firma hat viel Code an einem Ort und braucht Leute, die damit umgehen können. Bekannte Open-Source-Projekte wie React oder Babel sind ebenfalls als Monorepo organisiert. Jeder kann sich diese Archive im Netz ansehen.

Besonders in der KI-Entwicklung ist die Frage aktuell. Ein KI-Produkt besteht meist aus mehreren Teilen: dem Code fürs Training, dem Code fürs Ausliefern der Antworten, einer Weboberfläche und Werkzeugen zur Datenaufbereitung. Diese Teile teilen sich viele Bausteine, etwa die Beschreibung, wie ein Modell aufgebaut ist. Liegen sie getrennt, laufen die Versionen leicht auseinander – und niemand weiß mehr, mit welchem Code ein Modell eigentlich trainiert wurde.

Ein Monorepo ist aber kein Selbstzweck. Für kleine Teams mit zwei oder drei Programmen ist der Aufwand für die Werkzeuge größer als der Nutzen. Auch große Firmen entscheiden sich bewusst anders: Amazon und Netflix arbeiten überwiegend mit vielen einzelnen Repos, weil dort jedes Team möglichst unabhängig bleiben soll. Beide Wege funktionieren – sie verlagern nur, wo die Arbeit anfällt.