Ab welcher Repository-Grösse brauchen Teams Monorepo-Build-Werkzeuge über blosses Git hinaus?

Offene Frage

Ein einzelnes Repository für mehrere Dienste und Bibliotheken lässt sich lange allein mit Git-Funktionen und einfachen CI-Regeln betreiben: Cone-Mode-Sparse-Checkout, blobless Partial Clones, Pfadfilter, die entscheiden, welche Pipeline-Jobs laufen, und eine CODEOWNERS-Datei. Irgendwann führen Teams ein eigenes Build-Graph-Werkzeug ein (einen Task Runner mit Abhängigkeitsbewusstsein und Remote-Caching, oder ein hermetisches Buildsystem) und strukturieren das Repository oft danach um.

Wo liegt dieser Punkt? Kandidaten-Schwellenwerte, die in öffentlichen Berichten diskutiert werden, umfassen die Anzahl der Projekte, die Anzahl der Mitwirkenden, die täglich pushen, die Wall-Clock-Zeit der vollständigen CI, die Klongrösse und den Anteil der Builds, die reine Wiederholungen unveränderten Codes sind. Unklar ist, welche davon den Wechsel tatsächlich erzwingt, und ob das Werkzeug wegen gemessenen Schmerzes eingeführt wurde oder wegen dessen, was grössere Organisationen veröffentlichen.

Eine verwandte Unsicherheit ist der Aufwand: wie lange die Migration dauerte, welcher Anteil der Build-Definitionen umgeschrieben werden musste, ob das neue Werkzeug später wieder entfernt wurde, und welche Massnahmen auf Git-Ebene (Sparse Checkout, Partial Clone, Worktrees) danach beibehalten wurden.

Was eine nützliche Antwort enthält

• Repository-Fakten zum Zeitpunkt der Entscheidung: Anzahl der Projekte und Sprachen, Mitwirkende, Commits pro Tag, Klongrösse, CI-Dauer vorher und nachher.
• Der konkrete Auslöser, und ob eine günstigere Massnahme (pfadgefilterte CI, Caching in der bestehenden Pipeline) zuerst versucht wurde und warum sie nicht ausreichte.
• Das gewählte Werkzeug, der Migrationsaufwand in Personenwochen und Probleme in den ersten Monaten.
• Ob das Ergebnis gemessen wurde (Cache-Trefferquote, mediane CI-Zeit, Zeit bis zum ersten Build für einen neuen Mitwirkenden) und welche Zahlen dabei herauskamen.
• Fälle, in denen Teams bei blossem Git blieben, obwohl andere bei vergleichbarer Grösse das für unhandhabbar hielten, und welche Praktiken das ermöglichten.
• Antworten sollten Erfahrungen aus erster Hand von Zusammenfassungen fremder Berichte trennen.