{"id":43210,"date":"2021-08-25T10:58:33","date_gmt":"2021-08-25T08:58:33","guid":{"rendered":"https:\/\/kinsta.com\/?p=100242"},"modified":"2023-09-19T07:50:24","modified_gmt":"2023-09-19T06:50:24","slug":"monorepo-vs-multi-repo","status":"publish","type":"post","link":"https:\/\/kinsta.com\/de\/blog\/monorepo-vs-multi-repo\/","title":{"rendered":"Monorepo vs. Multi-Repo: Vor- und Nachteile von Code-Repository-Strategien"},"content":{"rendered":"

Es gibt zwei Hauptstrategien f\u00fcr das Hosten<\/a> und Verwalten von Code \u00fcber Git: Monorepo vs. Multi-Repo. Beide Ans\u00e4tze haben ihre Vor- und Nachteile.<\/p>\n

Wir k\u00f6nnen beide Ans\u00e4tze f\u00fcr jede Codebasis in jeder Sprache verwenden. Du kannst jede dieser Strategien f\u00fcr Projekte verwenden, die eine Handvoll bis tausende von Bibliotheken<\/a> enthalten. Auch wenn es sich um ein paar Teammitglieder oder Hunderte handelt, oder du privaten oder Open Source Code hosten willst, kannst du dich f\u00fcr Monorepo oder Multi-Repo entscheiden, abh\u00e4ngig von verschiedenen Faktoren.<\/p>\n

Was sind die Vor- und Nachteile der beiden Ans\u00e4tze? Wann sollte man das eine oder das andere verwenden? Lass es uns herausfinden!<\/p>\n

<\/div><\/kinsta-auto-toc>\n

Was sind Repos?<\/h2>\n

Ein Repo (kurz f\u00fcr Repository) ist ein Speicher f\u00fcr alle \u00c4nderungen und Dateien eines Projekts, der es Entwicklern erm\u00f6glicht, die Assets des Projekts w\u00e4hrend der gesamten Entwicklungsphase zu „versionskontrollieren“.<\/p>\n

Wir beziehen uns in der Regel auf Git<\/a> Repositories (wie sie von GitHub<\/a>, GitLab<\/a> oder Bitbucket<\/a> bereitgestellt werden), aber das Konzept gilt auch f\u00fcr andere Versionskontrollsysteme (wie Mercurial).<\/p>\n\n

Was ist ein Monorepo?<\/h2>\n

Der Monorepo-Ansatz verwendet ein einziges Repository<\/a>, um den gesamten Code f\u00fcr die verschiedenen Bibliotheken oder Dienste zu hosten, aus denen die Projekte eines Unternehmens bestehen. Im Extremfall wird die gesamte Codebasis eines Unternehmens – die sich \u00fcber verschiedene Projekte erstreckt und in unterschiedlichen Sprachen kodiert ist – in einem einzigen Repository gehostet.<\/p>\n

Vorteile von Monorepo<\/h2>\n

Das Hosten der gesamten Codebase in einem einzigen Repository bietet folgende Vorteile.<\/p>\n

Senkt die Einstiegsh\u00fcrden<\/h3>\n

Wenn neue Mitarbeiter in einem Unternehmen anfangen zu arbeiten, m\u00fcssen sie den Code herunterladen und die ben\u00f6tigten Tools installieren, um mit ihren Aufgaben beginnen zu k\u00f6nnen. Nehmen wir an, das Projekt ist \u00fcber viele Repositories verstreut und jedes hat seine eigenen Installationsanweisungen und ben\u00f6tigten Tools. In diesem Fall wird die anf\u00e4ngliche Einrichtung komplex sein und meistens ist die Dokumentation nicht vollst\u00e4ndig, sodass die neuen Teammitglieder ihre Kollegen um Hilfe bitten m\u00fcssen.<\/p>\n

Ein Monorepo vereinfacht die Sache. Da es einen einzigen Ort gibt, an dem der gesamte Code und die Dokumentation<\/a> zu finden sind, kannst du die Ersteinrichtung rationalisieren.<\/p>\n

Zentral gelegenes Code Management<\/h3>\n

Ein einziges Repository zu haben, gibt allen Entwicklern Einblick in den gesamten Code. Es vereinfacht das Code Management, da wir einen einzigen Issue Tracker nutzen k\u00f6nnen, um alle Issues w\u00e4hrend des gesamten Lebenszyklus der Anwendung zu beobachten.<\/p>\n

Diese Eigenschaften sind zum Beispiel wertvoll, wenn ein Problem zwei (oder mehr) Child-Bibliotheken umspannt und der Fehler in der abh\u00e4ngigen Bibliothek existiert. Mit mehreren Repositories kann es eine Herausforderung sein, die Stelle im Code<\/a> zu finden, an der das Problem auftritt.<\/p>\n

Dar\u00fcber hinaus m\u00fcssten wir herausfinden, welches Repository wir f\u00fcr die Erstellung des Problems verwenden und dann Mitglieder anderer Teams einladen und cross-taggen, um bei der L\u00f6sung des Problems zu helfen.<\/p>\n

Mit einem Monorepo ist es jedoch einfacher, sowohl Codeprobleme zu lokalisieren als auch gemeinsam an der Fehlerbehebung zu arbeiten.<\/p>\n

Schmerzfreie anwendungsweite Refactorings<\/h3>\n

Wenn du ein anwendungsweites Refactoring des Codes durchf\u00fchrst, sind mehrere Bibliotheken betroffen. Wenn du sie \u00fcber mehrere Repositories hostest, kann es eine Herausforderung sein, all die verschiedenen Pull Requests zu verwalten, um sie miteinander synchron zu halten.<\/p>\n

Ein Monorepo macht es einfach, alle \u00c4nderungen am Code f\u00fcr alle Bibliotheken durchzuf\u00fchren und sie unter einem einzigen Pull Request einzureichen.<\/p>\n

Schwieriger, benachbarte Funktionalit\u00e4ten zu brechen<\/h3>\n

Mit dem Monorepo k\u00f6nnen wir alle Tests f\u00fcr alle Bibliotheken so einrichten, dass sie immer dann ausgef\u00fchrt werden, wenn eine einzelne Bibliothek ver\u00e4ndert wird. Dadurch ist die Wahrscheinlichkeit, dass eine \u00c4nderung in einigen Bibliotheken nachteilige Auswirkungen auf andere Bibliotheken hat, minimiert.<\/p>\n

Teams teilen Entwicklungskultur<\/h3>\n

Auch wenn es nicht unm\u00f6glich ist, wird es mit einem Monorepo-Ansatz schwierig, einzigartige Subkulturen zwischen verschiedenen Teams zu inspirieren. Da sie sich das gleiche Repository teilen, werden sie h\u00f6chstwahrscheinlich auch die gleichen Programmier-<\/a> und Verwaltungsmethoden verwenden und die gleichen Tools<\/a> einsetzen.<\/p>\n

Probleme mit dem Monorepo-Ansatz<\/h2>\n

Die Verwendung eines einzigen Repositorys f\u00fcr unseren gesamten Code hat mehrere Nachteile.<\/p>\n

Langsamere Entwicklungszyklen<\/h3>\n

Wenn der Code f\u00fcr eine Bibliothek bahnbrechende \u00c4nderungen enth\u00e4lt, die dazu f\u00fchren, dass die Tests f\u00fcr abh\u00e4ngige Bibliotheken fehlschlagen, muss der Code ebenfalls korrigiert werden, bevor die \u00c4nderungen zusammengef\u00fchrt werden.<\/p>\n

Wenn diese Bibliotheken von anderen Teams abh\u00e4ngen, die mit einer anderen Aufgabe besch\u00e4ftigt sind und nicht in der Lage (oder willens) sind, ihren Code so anzupassen, dass die \u00c4nderungen nicht durchschlagen und die Tests bestehen, kann die Entwicklung des neuen Features ins Stocken geraten.<\/p>\n

Au\u00dferdem kann es sein, dass das Projekt nur mit der Geschwindigkeit des langsamsten Teams im Unternehmen vorankommt. Dieses Ergebnis k\u00f6nnte die Mitglieder der schnellsten Teams frustrieren und die Voraussetzungen daf\u00fcr schaffen, dass sie das Unternehmen verlassen wollen.<\/p>\n

Dar\u00fcber hinaus muss eine Bibliothek auch die Tests f\u00fcr alle anderen Bibliotheken ausf\u00fchren. Je mehr Tests ausgef\u00fchrt<\/a> werden m\u00fcssen, desto mehr Zeit braucht es, um sie auszuf\u00fchren, was die Iterationsgeschwindigkeit unseres Codes verlangsamt.<\/p>\n

Erfordert den Download der gesamten Codebase<\/h3>\n

Wenn die Monorepo den gesamten Code einer Firma enth\u00e4lt, kann sie riesig sein und Gigabytes an Daten enthalten. Um zu einer darin gehosteten Bibliothek beizutragen, w\u00fcrde jeder einen Download des gesamten Repositorys ben\u00f6tigen.<\/p>\n

Der Umgang mit einer riesigen Codebasis impliziert eine schlechte Nutzung des Platzes auf unseren Festplatten und langsamere Interaktionen mit ihr. Zum Beispiel k\u00f6nnen allt\u00e4gliche Aktionen wie das Ausf\u00fchren von git status<\/code> oder die Suche in der Codebase mit einer Regex viele Sekunden oder sogar Minuten l\u00e4nger dauern als bei mehreren Repos.<\/p>\n

Unver\u00e4nderte Bibliotheken k\u00f6nnen neu versioniert sein<\/h3>\n

Wenn wir das Monorepo taggen<\/a>, wird der gesamte Code darin mit dem neuen Tag versehen. Wenn diese Aktion ein neues Release ausl\u00f6st, dann werden alle Bibliotheken, die im Repository gehostet werden, mit der Versionsnummer aus dem Tag neu ver\u00f6ffentlicht, auch wenn viele dieser Bibliotheken vielleicht gar nicht ver\u00e4ndert wurden.<\/p>\n

Forking ist schwieriger<\/h3>\n

Open Source Projekte m\u00fcssen es den Mitwirkenden so einfach wie m\u00f6glich machen, sich zu beteiligen. Mit mehreren Repositories k\u00f6nnen Mitwirkende direkt zu dem spezifischen Repository f\u00fcr das Projekt gehen, zu dem sie beitragen wollen. Bei einem Monorepo, das verschiedene Projekte hostet, m\u00fcssen sich die Mitwirkenden jedoch erst in das richtige Projekt einfinden und verstehen, wie sich ihr Beitrag auf alle anderen Projekte auswirken kann.<\/p>\n

Was ist Multi-Repo?<\/h2>\n

Der Multi-Repo-Ansatz verwendet mehrere Repositories, um die verschiedenen Bibliotheken oder Dienste eines Projekts zu hosten, das von einer Firma entwickelt wird. Im Extremfall hostet es jedes minimale Set an wiederverwendbarem Code oder eigenst\u00e4ndiger Funktionalit\u00e4t (wie z.B. einen Microservice) unter seinem Repository.<\/p>\n

Vorteile von Multi-Repo<\/h2>\n

Das Hosten jeder Bibliothek unabh\u00e4ngig von allen anderen bietet eine F\u00fclle von Vorteilen.<\/p>\n

Unabh\u00e4ngige Bibliotheksversionierung<\/h3>\n

Beim Taggen eines Repositories wird dessen gesamte Codebase mit dem „new“ Tag versehen. Da sich nur der Code einer bestimmten Bibliothek im Repository befindet, kann die Bibliothek unabh\u00e4ngig von allen anderen Bibliotheken, die anderswo gehostet werden, getaggt und versioniert werden.<\/p>\n

Eine unabh\u00e4ngige Version f\u00fcr jede Bibliothek zu haben, hilft dabei, den Abh\u00e4ngigkeitsbaum f\u00fcr die Anwendung zu definieren, was es uns erlaubt, zu konfigurieren, welche Version jeder Bibliothek verwendet werden soll.<\/p>\n

Unabh\u00e4ngige Service Releases<\/h3>\n

Da das Repository nur den Code f\u00fcr einen Dienst enth\u00e4lt und sonst nichts, kann es seinen eigenen Bereitstellungszyklus haben, unabh\u00e4ngig von den Fortschritten der Anwendungen, die auf es zugreifen.<\/p>\n

Der Dienst kann einen schnellen Release-Zyklus verwenden, wie z.B. Continuous Delivery (wo neuer Code eingesetzt wird, nachdem er alle Tests bestanden hat). Einige Bibliotheken, die auf den Service zugreifen, k\u00f6nnen einen langsameren Release-Zyklus verwenden, wie z.B. solche, die nur einmal in der Woche ein neues Release produzieren.<\/p>\n

Hilft bei der Definition der Zugriffskontrolle in der gesamten Organisation<\/h3>\n

Nur die Teammitglieder, die an der Entwicklung einer Bibliothek beteiligt sind, m\u00fcssen zum entsprechenden Repository hinzugef\u00fcgt werden und den Code herunterladen. Als Ergebnis gibt es eine implizite Zugriffskontrollstrategie f\u00fcr jede Schicht in der Anwendung<\/a>. Diejenigen, die mit der Bibliothek zu tun haben, erhalten Bearbeitungsrechte und alle anderen d\u00fcrfen keinen Zugriff auf das Repository erhalten. Oder sie erhalten Leserechte, aber keine Editierrechte.<\/p>\n

Erm\u00f6glicht Teams autonomes Arbeiten<\/h3>\n

Die Teammitglieder k\u00f6nnen die Architektur der Bibliothek entwerfen und den Code implementieren, w\u00e4hrend sie isoliert von allen anderen Teams arbeiten. Sie k\u00f6nnen Entscheidungen treffen, die darauf basieren, was die Bibliothek im allgemeinen Kontext tut, ohne von den spezifischen Anforderungen eines externen Teams oder einer Anwendung beeinflusst zu werden.<\/p>\n

Probleme mit dem Multi-Repo-Ansatz<\/h2>\n

Die Verwendung von mehreren Repositories kann zu verschiedenen Problemen f\u00fchren.<\/p>\n

Bibliotheken m\u00fcssen st\u00e4ndig neu synchronisiert werden<\/h3>\n

Wenn eine neue Version einer Bibliothek ver\u00f6ffentlicht wird, die bahnbrechende \u00c4nderungen enth\u00e4lt, m\u00fcssen Bibliotheken, die von dieser Bibliothek abh\u00e4ngig sind, angepasst werden, um die neueste Version zu verwenden. Wenn der Release-Zyklus der Bibliothek schneller ist als der ihrer abh\u00e4ngigen Bibliotheken, k\u00f6nnen sie schnell aus dem Takt geraten.<\/p>\n

Die Teams m\u00fcssen dann st\u00e4ndig aufholen, um die neuesten Versionen der anderen Teams zu nutzen. Da verschiedene Teams unterschiedliche Priorit\u00e4ten haben, kann sich dies manchmal als m\u00fchsam erweisen.<\/p>\n

Infolgedessen kann ein Team, das nicht in der Lage ist, den R\u00fcckstand aufzuholen, an der veralteten Version der Bibliothek, auf die es angewiesen ist, festhalten. Dieses Ergebnis wird Auswirkungen auf die Anwendung haben (in Bezug auf Sicherheit, Geschwindigkeit und andere \u00dcberlegungen), und die L\u00fccke in der Entwicklung zwischen den Bibliotheken kann nur noch gr\u00f6\u00dfer werden.<\/p>\n

Kann Teams fragmentieren<\/h3>\n

Wenn verschiedene Teams nicht interagieren m\u00fcssen, k\u00f6nnen sie in ihren eigenen Silos arbeiten. Langfristig kann dies dazu f\u00fchren, dass Teams ihre eigenen Subkulturen innerhalb des Unternehmens bilden, wie z.B. unterschiedliche Programmier- oder Managementmethoden oder unterschiedliche Entwicklungstools.<\/p>\n

Wenn ein Teammitglied irgendwann in einem anderen Team arbeiten muss, erleidet es vielleicht einen kleinen Kulturschock und muss eine neue Art und Weise lernen, seine Arbeit zu erledigen.<\/p>\n

Monorepo vs. Multi-Repo: Prim\u00e4re Unterschiede<\/h2>\n

Beide Ans\u00e4tze besch\u00e4ftigen sich letztlich mit dem gleichen Ziel: der Verwaltung der Codebase. Daher m\u00fcssen beide die gleichen Herausforderungen l\u00f6sen, einschlie\u00dflich des Release-Managements, der F\u00f6rderung der Zusammenarbeit zwischen den Teammitgliedern<\/a>, dem Umgang mit Problemen, der Durchf\u00fchrung von Tests und anderen.<\/p>\n

Der Hauptunterschied besteht darin, dass die Teammitglieder Entscheidungen treffen m\u00fcssen: Entweder im Voraus f\u00fcr Monorepo oder im Nachhinein f\u00fcr Multi-Repo.<\/p>\n

Lass uns diese Idee im Detail analysieren.<\/p>\n

Da alle Bibliotheken im Multi-Repo unabh\u00e4ngig voneinander versioniert werden, kann ein Team, das eine Bibliothek mit brechenden \u00c4nderungen ver\u00f6ffentlicht, es sicher tun, indem es der neuesten Version eine neue Hauptversionsnummer zuweist. Andere Gruppen k\u00f6nnen ihre abh\u00e4ngigen Bibliotheken bei der alten Version bleiben lassen und auf die neue wechseln, sobald ihr Code angepasst wurde.<\/p>\n

Dieser Ansatz \u00fcberl\u00e4sst die Entscheidung, wann alle anderen Bibliotheken angepasst werden sollen, jedem verantwortlichen Team, das es zu jeder Zeit tun kann. Wenn sie es zu sp\u00e4t tun und neue Bibliotheksversionen ver\u00f6ffentlicht werden, wird es immer schwieriger, die L\u00fccke zwischen den Bibliotheken zu schlie\u00dfen.<\/p>\n

Infolgedessen kann ein Team schnell und oft an seinem Code iterieren, w\u00e4hrend andere Teams nicht in der Lage sind, aufzuholen, was letztendlich zu divergierenden Bibliotheken f\u00fchrt.<\/p>\n

Auf der anderen Seite k\u00f6nnen wir in einer Monorepo-Umgebung keine neue Version einer Bibliothek ver\u00f6ffentlichen, die eine andere Bibliothek kaputt macht, da deren Tests fehlschlagen werden. In diesem Fall muss das erste Team mit dem zweiten Team kommunizieren, um die \u00c4nderungen einzuarbeiten.<\/p>\n

Dieser Ansatz zwingt die Teams dazu, alle Bibliotheken<\/a> zusammen anzupassen, wenn eine \u00c4nderung f\u00fcr eine einzelne Bibliothek passieren muss. Alle Teams sind gezwungen, miteinander zu reden und gemeinsam eine L\u00f6sung zu finden.<\/p>\n

Das Ergebnis ist, dass das erste Team nicht so schnell iterieren kann, wie es m\u00f6chte, aber der Code \u00fcber verschiedene Bibliotheken hinweg wird zu keinem Zeitpunkt anfangen, auseinanderzulaufen.<\/p>\n

Zusammenfassend l\u00e4sst sich sagen, dass der Multi-Repo-Ansatz dazu beitragen kann, eine Kultur des „move fast and break things“ unter den Teams zu schaffen, in der flinke unabh\u00e4ngige Teams ihren Output in ihrer Geschwindigkeit produzieren k\u00f6nnen. Stattdessen beg\u00fcnstigt der Monorepo-Ansatz eine Kultur der Achtsamkeit und Sorgfalt, in der Teams nicht mit einem Problem allein gelassen werden sollten.<\/p>\n

Hybrider Poly-As-Mono-Ansatz<\/h2>\n

Wenn wir uns nicht entscheiden k\u00f6nnen, ob wir entweder den Multi-Repo oder den Monorepo-Ansatz verwenden sollen, gibt es auch den Zwischending-Ansatz: mehrere Repositories zu verwenden und ein Tool einzusetzen, um sie synchron zu halten, so dass es einem Monorepo \u00e4hnelt, aber mit mehr Flexibilit\u00e4t.<\/p>\n

Meta<\/a> ist ein solches Tool. Es organisiert mehrere Repositories in Unterverzeichnissen und bietet eine Kommandozeilenschnittstelle<\/a>, die den gleichen Befehl auf allen gleichzeitig ausf\u00fchrt.<\/p>\n

Ein Meta-Repository enth\u00e4lt die Informationen dar\u00fcber, welche Repositories ein Projekt ausmachen. Das Klonen dieses Repositories via Meta klont dann rekursiv alle ben\u00f6tigten Repositories, was es f\u00fcr neue Teammitglieder einfacher macht, sofort mit der Arbeit an ihren Projekten zu beginnen.<\/p>\n

Um ein Meta-Repository und alle seine definierten multiplen Repos zu klonen, m\u00fcssen wir folgendes ausf\u00fchren:<\/p>\n

meta git clone [meta repo url]\n<\/code><\/pre>\n
Meta wird f\u00fcr jedes Repository einen git clone <\/code>ausf\u00fchren und es in einem Unterordner ablegen:<\/p>\n
\"Klonen<\/a>
Klonen eines Meta-Projekts. (Bildquelle: github.com\/mateodelnorte\/meta<\/a>)<\/figcaption><\/figure>\n
Von da an wird die Ausf\u00fchrung des meta exec<\/code> Befehls den Befehl in jedem Unterordner ausf\u00fchren. Zum Beispiel wird git checkout master<\/code> auf jedem Repository wie folgt ausgef\u00fchrt:<\/p>\n
meta exec \"git checkout master\"\n<\/code><\/pre>\n
Hybrider Mono-As-Poly-Ansatz<\/h2>\n
Ein anderer Ansatz ist die Verwaltung des Codes \u00fcber ein Monorepo f\u00fcr die Entwicklung, aber das Kopieren des Codes jeder Bibliothek in ein unabh\u00e4ngiges Repository f\u00fcr die Bereitstellung.<\/p>\n
Diese Strategie ist im PHP-\u00d6kosystem weit verbreitet, da Packagist<\/a> (das Haupt-Repository von Composer<\/a>) eine \u00f6ffentliche Repository-URL<\/a> ben\u00f6tigt, um ein Paket zu ver\u00f6ffentlichen, und es nicht m\u00f6glich ist, anzugeben, dass sich das Paket in einem Unterverzeichnis des Repositorys befindet.<\/p>\n
In Anbetracht der Packagist-Beschr\u00e4nkung k\u00f6nnen PHP-Projekte immer noch ein Monorepo f\u00fcr die Entwicklung<\/a> verwenden, aber sie m\u00fcssen den Multi-Repo-Ansatz f\u00fcr die Bereitstellung nutzen.<\/p>\n
Um diese Conversion zu erreichen, k\u00f6nnen wir ein Skript mit git subtree split<\/code><\/a> ausf\u00fchren oder eines der verf\u00fcgbaren Tools verwenden, die die gleiche Logik ausf\u00fchren:<\/p>\n