Was ist ein Monorepo?<\/h2>\n\n\n\n
Ein Monorepo (kurz f\u00fcr \"monolithic repository\") ist ein Repository, das den Quellcode mehrerer oder aller Projekte eines Teams oder eines Unternehmens enth\u00e4lt.<\/p>\n\n\n\n
Einige der gr\u00f6\u00dften Internetunternehmen, wie Google, Facebook, Microsoft und Twitter, arbeiten mit Monorepos.<\/p>\n\n\n\n
Warum kenne ich mich mit Monorepos aus?<\/h3>\n\n\n\n
Bei AndroidPIT<\/a> haben wir im August 2016 ein neues Produkt, das heute aus 25 Microservices und 23 Libraries besteht, als Git-Monorepo aufgesetzt. Zu Beginn waren alle Entwickler z\u00f6gerlich, doch unser Team entschied gemeinsam es auszuprobieren. Wir hielten uns die Option offen das Repository wieder aufzusplitten, falls wir unzufrieden sein sollten. Zwei Jahre sp\u00e4ter \u2013 nachdem wir \u00fcberwiegend positive Erfahrung gemacht hatten \u2013 entschieden wir uns, alle anderen Produkte ebenfalls in Monorepos zusammenzuf\u00fchren.<\/p>\n\n\n\n Zwei lesenswerte, englischsprachige Artikel zu diesem Thema sind:<\/p>\n\n\n\n Im folgenden findest du die Vor- und Nachteile, wie ich sie im Programmiereralltag erfahren habe, bzw. meine Sicht zu den verbreiteten Kritikpunkten.<\/p>\n\n\n\n Reduzierung von Aufwand \/ Kosten:<\/p>\n\n\n\n Verbesserte Wartbarkeit:<\/p>\n\n\n\n Organisation:<\/p>\n\n\n\n Performance \/ Skalierbarkeit:<\/p>\n\n\n\n Architektur:<\/p>\n\n\n\n Organisation:<\/p>\n\n\n\n Ein weit verbreiteter Kritikpunkt an Monorepos ist deren schlechte Performance und Skalierbarkeit. <\/p>\n\n\n\n Aus meiner Erfahrung der letzten drei Jahre kann ich sagen, dass es in den meisten Teams keine Performance-Probleme geben sollte. In den meisten Unternehmen d\u00fcrfte die gesamte Codebasis kleiner sein als der Linux-Kernel (17,9 Mio Codezeilen in 47.000 C\/C++ Files laut cloc<\/a>; und 5,7 Mio Deltas), welcher ebenfalls durch Git verwaltet wird (und f\u00fcr den Git urspr\u00fcnglich entwickelt wurde).<\/p>\n\n\n\n Aktuell arbeite ich an einem Projekt bei IONOS<\/a>. Das Monorepo des Java-Backends ist kleiner als der Linux-Kernel, liegt aber in einer vergleichbaren Gr\u00f6\u00dfenordnung. Das Klonen des gesamten Repositories dauert weniger als eine Minute. Das Umschalten von Branches dauert je nach Alter des Branches zwischen 0,2 und 1,5 Sekunden.<\/p>\n\n\n\n Die meisten von uns arbeiten in Unternehmen dieser Gr\u00f6\u00dfenordnungen; von daher sehe ich in naher Zukunft keine praktischen Probleme bei der Skalierbarkeit eines Monorepos.<\/p>\n\n\n\n Nehmen wir an, wir haben zwei Projekte, \"project-a\" (beispielhaft angelegt unter https:\/\/github.com\/SvenWoltmann\/project-a<\/a>) und \"project-b\" (https:\/\/github.com\/SvenWoltmann\/project-b<\/a>), die wir zu einem Repository \"sparse-checkout-demo\" zusammenfassen wollen. Die zwei Projekte sollen dabei in Unterverzeichnissen mit den jeweiligen Projektnamen angeordnet werden.<\/p>\n\n\n\n Zun\u00e4chst m\u00fcssen wir beide Projekte auschecken (sofern diese nicht bereits vorhanden sind), das Verzeichnis f\u00fcr das Monorepo erstellen und dort ein Git-Repository initialisieren (alternativ eines via GitHub erstellen und klonen):<\/p>\n\n\n Hier die Ausgaben, die du sehen solltest:<\/p>\n\n\n Mit folgenden Kommandos mergen wir Projekt A in das Monorepo:<\/p>\n\n\n Folgende Ausgabe solltest du sehen:<\/p>\n\n\n Das gleiche wiederholen wir f\u00fcr Projekt B:<\/p>\n\n\n Hier die entsprechenden Ausgaben dazu:<\/p>\n\n\n Und das war es schon!<\/p>\n\n\n\n Mit Vor- und Nachteile von Monorepos<\/h2>\n\n\n\n
\n
Was sind die Vorteile eines Monorepos?<\/h3>\n\n\n\n
\n
Entwickler m\u00fcssen nur ein (oder wenige) Repositories auschecken und aktualisieren. Neue Projekte werden in Unterverzeichnissen erstellt und somit automatisch an die anderen Entwickler verteilt, ohne dass diese weitere Repositories auschecken m\u00fcssen.<\/li>\n\n\n\n
Entwickler haben zu jeder Zeit einen konsistenten Stand des Gesamtprojekts \u2013 nicht nur im main<\/em>-Branch, sondern auch auf Branches und alten Commits. Bei vielen Einzelrepositories kommt es hingegen schnell zu Inkompatibilit\u00e4ten.<\/li>\n\n\n\n
Zusammengeh\u00f6rige \u00c4nderungen an mehreren Teilprojekten k\u00f6nnen gemeinsam eingecheckt werden.<\/li>\n\n\n\n
Das Anlegen und Mergen von Branches f\u00fcr \u00c4nderungen, die mehrere Teilprojekte umfassen, ist aufw\u00e4ndig, wenn die Projekte in separaten Repositories liegen. In einem Monorepo muss man nur einmal mergen.<\/li>\n\n\n\n
Das Behandeln von Merge-Konflikten wird vereinfacht, da sich in einem Monorepo w\u00e4hrend der Behandlung des Konflikts die komplette Codebasis in einem konsistenten Zustand befindet. Bei mehreren Repositories muss man diese ggf. erst m\u00fchsam auf einen einheitlichen Zustand bringen.<\/li>\n<\/ul>\n\n\n\n\n
Code kann deutlich einfacher zwischen den Verzeichnissen eines Monorepos verschoben werden als von einem Repository in ein anderes. Somit k\u00f6nnen Entwickler die Modulgrenzen bei \u00c4nderungen von Anforderungen oder Refactorings problemlos anpassen.<\/li>\n\n\n\n
Projekt\u00fcbergreifende Dokumentation kann im Root-Folder des Monorepos abgelegt werden.<\/span><\/li>\n<\/ul>\n\n\n\n\n
Monorepos f\u00fchren dazu, dass alle Entwickler Zugriff auf die gesamte Codebasis haben. In den meisten F\u00e4llen ist dies erw\u00fcnscht, f\u00f6rdert die team\u00fcbergreifende Zusammenarbeit und erlaubt es Entwicklern an Code anderer Teams mitzuarbeiten.<\/li>\n\n\n\n
Monorepos reduzieren den Konfigurationsaufwand der Source Code Management Tools.<\/li>\n<\/ul>\n\n\n\nWas sind die Nachteile eines Monorepos?<\/h3>\n\n\n\n
\n
Kritiker bem\u00e4ngeln, dass Monorepos zu Performance-Probleme f\u00fchren. Ich konnte in Projekten der Gr\u00f6\u00dfe, in der die meisten von uns sich bewegen, bisher keine Performance-Einbu\u00dfen feststellen (s. Folgeabschnitt \"Performance und Skalierbarkeit eines Git-Monorepos<\/a>\").<\/li>\n\n\n\n
Ebenso wird ein erh\u00f6hter Speicherbedarf kritisiert, da jeder Entwickler die gesamte Codebasis auschecken muss. Dies d\u00fcrfte heutzutage in den meisten Projekten unerheblich sein: Der Quellcode des Linux-Kernels bspw. belegt etwa 3,5 GB. Die Repositories der meisten Unternehmen d\u00fcrften kleiner sein.<\/li>\n\n\n\n
Monorepos machen vermeintlich die Build-Pipeline komplexer. Auch das entspricht nicht meiner Erfahrung. Mittels Sparse Checkouts und Polling Filtern kann man problemlos Teilprojekte bauen.<\/li>\n\n\n\n
Angeblich wird die Versionierung komplizierter. Auch dies kann ich nicht nachvollziehen. Es ist sowohl m\u00f6glich die komplette Codebasis zu versionieren (mit Tags wie \"v1.0\") als auch einzelne Teilprojekte (mit Tags wie \"project-a-v1.0\").<\/li>\n<\/ul>\n\n\n\n\n
Einige sind der Meinung, dass ein Monorepo einer sauberen und effektiven Modularisierung entgegen wirkt, da die Entwickler nicht gezwungen sind, den Code auf separate Repositories aufzuteilen. Ich sehe das als Vorteil, da Modulgrenzen durch Monorepos nicht in Stein gemei\u00dfelt werden (s. o. \"Verbesserte Wartbarkeit\").<\/li>\n<\/ul>\n\n\n\n\n
Der unter den Vorteilen aufgef\u00fchrte Aspekt, dass alle Entwickler Zugriff auf die gesamte Codebasis haben, ist nicht in allen Organisationen erw\u00fcnscht. Beispielsweise sollten Projekte f\u00fcr unterschiedliche Kunden eines Auftragsentwicklers nicht in einem Monorepo abgelegt werden.<\/li>\n\n\n\n
Auch wenn Teilprojekte als Open Source-Komponenten freigegenen werden sollen, ist ein Monorepo hinderlich.<\/li>\n<\/ul>\n\n\n\nPerformance und Skalierbarkeit eines Git-Monorepos<\/h2>\n\n\n\n
Zusammenf\u00fchren (Mergen) mehrerer Git-Repositories unter Beibehaltung der History<\/h2>\n\n\n\n
git clone git@github.com:SvenWoltmann\/project-a.git\ngit clone git@github.com:SvenWoltmann\/project-b.git\n\nmkdir sparse-checkout-demo\ngit init sparse-checkout-demo<\/code><\/span>Code-Sprache:<\/span> Klartext<\/span> (<\/span>plaintext<\/span>)<\/span><\/small><\/pre>\n\n\n![\"Git-Repositories](\"https:\/\/www.happycoders.eu\/wp-content\/uploads\/2022\/02\/merge-git-repos-step-1-800x277.png\")
<\/a>cd project-a\ngit filter-branch -f --prune-empty --tag-name-filter cat --tree-filter '\n mkdir -p project-a\n git ls-tree --name-only $GIT_COMMIT | xargs -I{} mv {} project-a\n'\ncd ..\/sparse-checkout-demo\ngit remote add project-a ..\/project-a\ngit fetch project-a\ngit merge --allow-unrelated-histories project-a\/main\ngit remote rm project-a<\/code><\/span>Code-Sprache:<\/span> Klartext<\/span> (<\/span>plaintext<\/span>)<\/span><\/small><\/pre>\n\n\n![\"](\"https:\/\/www.happycoders.eu\/wp-content\/uploads\/2022\/02\/merge-git-repos-step-2-800x289.png\")
<\/a>cd ..\/project-b\ngit filter-branch -f --prune-empty --tag-name-filter cat --tree-filter '\n mkdir -p project-b\n git ls-tree --name-only $GIT_COMMIT | xargs -I{} mv {} project-b\n'\ncd ..\/sparse-checkout-demo\ngit remote add project-b ..\/project-b\ngit fetch project-b\ngit merge --allow-unrelated-histories project-b\/main\ngit remote rm project-b<\/code><\/span>Code-Sprache:<\/span> Klartext<\/span> (<\/span>plaintext<\/span>)<\/span><\/small><\/pre>\n\n\n![\"](\"https:\/\/www.happycoders.eu\/wp-content\/uploads\/2022\/02\/merge-git-repos-step-3-800x433.png\")
<\/a>dir<\/code> und git log<\/code> kannst du sehen, dass beide Teilprojekte und deren Commits im Monorepo enthalten sind:<\/p>\n\n\n
![\"](\"https:\/\/www.happycoders.eu\/wp-content\/uploads\/2022\/02\/merge-git-repos-step-4-800x478.png\")
<\/a>