Wordpress

Monorepo vs Multi-Repo: Vor- und Nachteile von Code-Repository-Strategien

Es gibt zwei Hauptstrategien für das Hosten und Verwalten von Code über Git: Monorepo vs. Multi-Repo. Beide Ansätze haben ihre Vor- und Nachteile.

Wir können beide Ansätze für jede Codebasis in jeder Sprache verwenden. Sie können jede dieser Strategien für Projekte verwenden, die eine Handvoll Bibliotheken oder Tausende von ihnen enthalten. Selbst wenn es sich um einige oder Hunderte Teammitglieder handelt oder Sie privaten oder Open-Source-Code hosten möchten, können Sie basierend auf verschiedenen Faktoren Monorepo oder Multi-Repo verwenden.

Was sind die Vor- und Nachteile der einzelnen Ansätze? Wann sollten wir das eine oder das andere verwenden? Lass es uns herausfinden!

Was sind Repos?

Ein Repo (kurz für Repository) ist ein Speicher für alle Änderungen und Dateien eines Projekts, der es Entwicklern ermöglicht, die Assets des Projekts während seiner gesamten Entwicklungsphase „Versionskontrolle“ zu machen.

Wir beziehen uns normalerweise auf Git-Repositorys (wie von GitHub, GitLab oder Bitbucket bereitgestellt), aber das Konzept gilt auch für andere Versionskontrollsysteme (wie Mercurial).

Es gibt zwei Hauptstrategien für das Hosten und Verwalten unserer Codebasis über Git: den Monorepo-Ansatz und den Multi-Repo-Ansatz. 🚀 Erkunden Sie jeden in diesem Leitfaden ⬇️Klicken Sie, um Tweet

Was ist ein Monorepo?

Der Monorepo-Ansatz verwendet ein einziges Repository, um den gesamten Code für die mehreren Bibliotheken oder Dienste zu hosten, aus denen die Projekte eines Unternehmens bestehen. Im Extremfall wird die gesamte Codebasis eines Unternehmens – die sich über verschiedene Projekte erstreckt und in verschiedenen Sprachen codiert ist – in einem einzigen Repository gehostet.

Vorteile von Monorepo

Das Hosten der gesamten Codebasis in einem einzigen Repository bietet die folgenden Vorteile.

Senkt Eintrittsbarrieren

Wenn neue Mitarbeiter für ein Unternehmen arbeiten, müssen sie den Code herunterladen und die erforderlichen Tools installieren, um mit der Arbeit an ihren Aufgaben zu beginnen. Angenommen, das Projekt ist über viele Repositorys verstreut, von denen jedes seine Installationsanweisungen und Tools benötigt. In diesem Fall ist die anfängliche Einrichtung komplex und die Dokumentation ist in den meisten Fällen nicht vollständig, sodass diese neuen Teammitglieder sich an Kollegen wenden müssen, um Hilfe zu erhalten.

Ein Monorepo vereinfacht die Sache. Da es einen einzigen Speicherort gibt, der den gesamten Code und die Dokumentation enthält, können Sie die Ersteinrichtung optimieren.

Zentral gelegene Codeverwaltung

Ein einziges Repository ermöglicht allen Entwicklern die Sichtbarkeit des gesamten Codes. Es vereinfacht die Codeverwaltung, da wir einen einzigen Issue-Tracker verwenden können, um alle Probleme während des gesamten Lebenszyklus der Anwendung zu überwachen.

Diese Eigenschaften sind beispielsweise wertvoll, wenn ein Problem zwei (oder mehr) untergeordnete Bibliotheken umfasst, wobei der Fehler in der abhängigen Bibliothek vorhanden ist. Bei mehreren Repositorys kann es schwierig sein, den Codeabschnitt zu finden, in dem das Problem auftritt.

Darüber hinaus müssten wir herausfinden, welches Repository zum Erstellen des Problems verwendet werden soll, und dann Mitglieder anderer Teams einladen und markieren, um bei der Lösung des Problems zu helfen.

Mit einem Monorepo sind jedoch sowohl das Auffinden von Codeproblemen als auch die Zusammenarbeit bei der Fehlerbehebung einfacher zu erreichen.

Problemlose anwendungsweite Refactorings

Beim Erstellen einer anwendungsweiten Umgestaltung des Codes sind mehrere Bibliotheken betroffen. Wenn Sie sie über mehrere Repositorys hosten, kann sich die Verwaltung all der verschiedenen Pull-Requests als eine Herausforderung erweisen, um sie miteinander zu synchronisieren.

Ein Monorepo macht es einfach, alle Änderungen an allen Codes für alle Bibliotheken durchzuführen und sie unter einem einzigen Pull-Request zu senden.

Angrenzende Funktionalität ist schwieriger zu unterbrechen

Mit dem Monorepo können wir alle Tests für alle Bibliotheken so einrichten, dass sie immer dann ausgeführt werden, wenn eine einzelne Bibliothek geändert wird. Infolgedessen hat die Wahrscheinlichkeit einer Änderung in einigen Bibliotheken die negativen Auswirkungen auf andere Bibliotheken minimiert.

Teams teilen Entwicklungskultur

Auch wenn es nicht unmöglich ist, wird es mit einem Monorepo-Ansatz schwierig, einzigartige Subkulturen zwischen verschiedenen Teams zu inspirieren. Da sie sich dasselbe Repository teilen, werden sie höchstwahrscheinlich dieselben Programmier- und Verwaltungsmethoden verwenden und dieselben Entwicklungstools verwenden.

Probleme mit dem Monorepo-Ansatz

Die Verwendung eines einzigen Repositorys für unseren gesamten Code hat mehrere Nachteile.

Langsamere Entwicklungszyklen

Wenn der Code für eine Bibliothek grundlegende Änderungen enthält, die dazu führen, dass die Tests für abhängige Bibliotheken fehlschlagen, muss der Code vor dem Zusammenführen der Änderungen ebenfalls korrigiert werden.

Wenn diese Bibliotheken von anderen Teams abhängig sind, die mit einer anderen Aufgabe beschäftigt sind und nicht in der Lage (oder willens) sind, ihren Code anzupassen, um die Breaking Changes zu vermeiden und die Tests bestehen zu lassen, kann die Entwicklung der neuen Funktion ins Stocken geraten.

Darüber hinaus kann das Projekt möglicherweise nur mit der Geschwindigkeit des langsamsten Teams im Unternehmen vorankommen. Dieses Ergebnis könnte die Mitglieder der schnellsten Teams frustrieren und Bedingungen dafür schaffen, dass sie das Unternehmen verlassen möchten.

Darüber hinaus muss eine Bibliothek auch die Tests für alle anderen Bibliotheken ausführen. Je mehr Tests ausgeführt werden müssen, desto länger dauert ihre Ausführung, was die Geschwindigkeit der Iteration unseres Codes verlangsamt.

Erfordert den Download der gesamten Codebasis

Wenn das Monorepo den gesamten Code für ein Unternehmen enthält, kann es riesig sein und Gigabyte an Daten enthalten. Um zu einer darin gehosteten Bibliothek beizutragen, müsste jeder das gesamte Repository herunterladen.

Der Umgang mit einer riesigen Codebasis impliziert eine schlechte Nutzung des Speicherplatzes auf unseren Festplatten und eine langsamere Interaktion damit. Zum Beispiel alltägliche Handlungen wie das Ausführen von git status oder die Suche in der Codebasis mit einer Regex kann viele Sekunden oder sogar Minuten länger dauern als bei mehreren Repos.

Unmodifizierte Bibliotheken können neu versioniert werden

Wenn wir das Monorepo markieren, wird dem gesamten Code darin das neue Tag zugewiesen. Wenn diese Aktion eine neue Version auslöst, werden alle im Repository gehosteten Bibliotheken mit der Versionsnummer aus dem Tag neu veröffentlicht, auch wenn bei vielen dieser Bibliotheken möglicherweise keine Änderungen vorgenommen wurden.

Gabelung ist schwieriger

Open-Source-Projekte müssen es den Mitwirkenden so einfach wie möglich machen, sich einzubringen. Mit mehreren Repositorys können Mitwirkende direkt zu dem spezifischen Repository für das Projekt gehen, zu dem sie beitragen möchten. Bei einem Monorepo, das verschiedene Projekte hostet, müssen sich die Mitwirkenden jedoch zuerst in das richtige Projekt einfinden und verstehen, wie sich ihr Beitrag auf alle anderen Projekte auswirken kann.

Was ist Multi-Repo?

Der Multi-Repo-Ansatz verwendet mehrere Repositories, um die mehreren Bibliotheken oder Dienste eines von einem Unternehmen entwickelten Projekts zu hosten. Im Extremfall hostet es jeden minimalen Satz an wiederverwendbarem Code oder eigenständiger Funktionalität (z. B. einen Microservice) in seinem Repository.

Vorteile von Multi-Repo

Das Hosten jeder Bibliothek unabhängig von allen anderen bietet eine Vielzahl von Vorteilen.

Unabhängige Bibliotheksversionierung

Beim Taggen eines Repositorys wird dessen gesamte Codebasis mit dem „neuen“ Tag versehen. Da sich nur der Code für eine bestimmte Bibliothek im Repository befindet, kann die Bibliothek unabhängig von allen anderen an anderer Stelle gehosteten Bibliotheken mit Tags versehen und versioniert werden.

Eine unabhängige Version für jede Bibliothek zu haben, hilft bei der Definition des Abhängigkeitsbaums für die Anwendung, sodass wir konfigurieren können, welche Version jeder Bibliothek verwendet werden soll.

Unabhängige Service-Releases

Da das Repository nur den Code für einige Dienste enthält und sonst nichts, kann es unabhängig vom Fortschritt der darauf zugreifenden Anwendungen einen eigenen Bereitstellungszyklus haben.

Der Service kann einen schnellen Release-Zyklus wie Continuous Delivery verwenden (bei dem neuer Code bereitgestellt wird, nachdem er alle Tests bestanden hat). Einige Bibliotheken, die auf den Dienst zugreifen, verwenden möglicherweise einen langsameren Release-Zyklus, beispielsweise solche, die nur einmal pro Woche eine neue Version erstellen.

Hilft bei der Definition der Zugriffskontrolle im gesamten Unternehmen

Nur die Teammitglieder, die an der Entwicklung einer Bibliothek beteiligt sind, müssen dem entsprechenden Repository hinzugefügt werden und ihren Code herunterladen. Als Ergebnis gibt es eine implizite Zugriffskontrollstrategie für jede Schicht in der Anwendung. Diejenigen, die an der Bibliothek beteiligt sind, erhalten Bearbeitungsrechte, und alle anderen erhalten möglicherweise keinen Zugriff auf das Repository. Oder sie erhalten Lese-, aber keine Bearbeitungsrechte.

Ermöglicht Teams autonomes Arbeiten

Teammitglieder können die Architektur der Bibliothek entwerfen und ihren Code unabhängig von allen anderen Teams implementieren. Sie können Entscheidungen basierend auf dem, was die Bibliothek im allgemeinen Kontext tut, treffen, ohne von den spezifischen Anforderungen eines externen Teams oder einer Anwendung beeinflusst zu werden.

Probleme mit dem Multi-Repo-Ansatz

Die Verwendung mehrerer Repositorys kann zu mehreren Problemen führen.

Bibliotheken müssen ständig neu synchronisiert werden

Wenn eine neue Version einer Bibliothek mit Breaking Changes veröffentlicht wird, müssen Bibliotheken, die von dieser Bibliothek abhängig sind, angepasst werden, damit sie die neueste Version verwenden können. Wenn der Release-Zyklus der Bibliothek schneller ist als der ihrer abhängigen Bibliotheken, können sie schnell nicht mehr synchron sein.

Die Teams müssen ständig aufholen, um die neuesten Versionen anderer Teams zu verwenden. Da verschiedene Teams unterschiedliche Prioritäten haben, kann dies manchmal mühsam sein.

Folglich kann ein Team, das nicht in der Lage ist, aufzuholen, am Ende an der veralteten Version der abhängigen Bibliothek festhalten. Dieses Ergebnis wird Auswirkungen auf die Anwendung haben (in Bezug auf Sicherheit, Geschwindigkeit und andere Aspekte), und die Entwicklungslücke zwischen den Bibliotheken wird möglicherweise nur noch größer.

Mai-Teams fragmentieren

Wenn verschiedene Teams nicht interagieren müssen, arbeiten sie möglicherweise in ihren eigenen Silos. Langfristig könnte dies dazu führen, dass Teams ihre Subkulturen innerhalb des Unternehmens produzieren, indem sie beispielsweise unterschiedliche Programmier- oder Managementmethoden anwenden oder unterschiedliche Sets von Entwicklungswerkzeugen verwenden.

Wenn ein Teammitglied irgendwann in einem anderen Team arbeiten muss, erleidet es möglicherweise einen kleinen Kulturschock und lernt eine neue Art, seine Arbeit zu erledigen.

Monorepo vs. Multi-Repo: Hauptunterschiede

Beide Ansätze verfolgen letztlich dasselbe Ziel: die Verwaltung der Codebasis. Daher müssen beide die gleichen Herausforderungen lösen, einschließlich des Release-Managements, der Förderung der Zusammenarbeit zwischen Teammitgliedern, der Behandlung von Problemen, der Durchführung von Tests und mehr.

Ihr Hauptunterschied betrifft das Timing der Teammitglieder, um Entscheidungen zu treffen: entweder im Voraus für Monorepo oder auf der ganzen Linie für Multi-Repo.

Lassen Sie uns diese Idee genauer analysieren.

Da alle Bibliotheken im Multi-Repository unabhängig versioniert werden, kann ein Team, das eine Bibliothek mit Breaking Changes veröffentlicht, dies sicher tun, indem es der neuesten Version eine neue Hauptversionsnummer zuweist. Andere Gruppen können ihre abhängigen Bibliotheken bei der alten Version belassen und auf die neue umstellen, sobald ihr Code angepasst wurde.

Dieser Ansatz überlässt die Entscheidung, wann alle anderen Bibliotheken angepasst werden, jedem verantwortlichen Team, das dies jederzeit tun kann. Wenn sie es zu spät tun und neue Bibliotheksversionen veröffentlicht werden, wird es immer schwieriger, die Lücke zwischen den Bibliotheken zu schließen.

Während ein Team seinen Code schnell und oft iterieren kann, können sich andere Teams als nicht in der Lage erweisen, aufzuholen und letztendlich Bibliotheken zu erstellen, die voneinander abweichen.

Auf der anderen Seite können wir in einer Monorepo-Umgebung keine neue Version einer Bibliothek veröffentlichen, die eine andere Bibliothek beschädigt, da deren Tests fehlschlagen. In diesem Fall muss das erste Team mit dem zweiten Team kommunizieren, um die Änderungen zu übernehmen.

Müde von unterdurchschnittlichem WordPress-Hosting-Support der Stufe 1 ohne die Antworten? Testen Sie unser erstklassiges Support-Team! Schauen Sie sich unsere Pläne an

Dieser Ansatz zwingt Teams dazu, alle Bibliotheken insgesamt anzupassen, wenn eine Änderung für eine einzelne Bibliothek erforderlich ist. Alle Teams sind gezwungen, miteinander zu sprechen und gemeinsam eine Lösung zu finden.

Infolgedessen kann das erste Team nicht so schnell iterieren, wie es möchte, aber der Code in verschiedenen Bibliotheken wird zu keinem Zeitpunkt auseinanderlaufen.

Zusammenfassend lässt sich sagen, dass der Multi-Repo-Ansatz dazu beitragen kann, unter Teams eine Kultur des „Move Fast and Break Things“ zu schaffen, in der flinke, unabhängige Teams ihre Ergebnisse in ihrer Geschwindigkeit produzieren können. Stattdessen bevorzugt der Monorepo-Ansatz eine Kultur des Bewusstseins und der Sorgfalt, in der Teams nicht zurückgelassen werden sollten, um ein Problem alleine zu lösen.

Hybrider Poly-As-Mono-Ansatz

Wenn wir uns nicht entscheiden können, ob wir entweder den Multi-Repo- oder den Monorepo-Ansatz verwenden sollen, gibt es auch den Zwischenansatz: mehrere Repositorys zu verwenden und ein Werkzeug zu verwenden, um sie synchronisiert zu halten, wodurch es einem Monorepo ähnelt, aber mit mehr Flexibilität.

Meta ist ein solches Werkzeug. Es organisiert mehrere Repositorys in Unterverzeichnissen und bietet eine Befehlszeilenschnittstelle, die auf allen denselben Befehl gleichzeitig ausführt.

Ein Meta-Repository enthält die Informationen darüber, aus welchen Repositorys ein Projekt besteht. Durch das Klonen dieses Repositorys über Meta werden dann alle erforderlichen Repositorys rekursiv geklont, was es neuen Teammitgliedern erleichtert, sofort mit der Arbeit an ihren Projekten zu beginnen.

Um ein Meta-Repository und alle seine definierten multiplen Repositorys zu klonen, müssen wir Folgendes ausführen:

meta git clone [meta repo url]

Meta wird a ausführen git clone für jedes Repository und legen Sie es in einen Unterordner:

Klonen eines Metaprojekts
Klonen eines Metaprojekts. (Bildquelle: github.com/mateodelnorte/meta)

Von da an die Ausführung der meta exec Befehl führt den Befehl in jedem Unterordner aus. Zum Beispiel die Ausführung git checkout master auf jedem Repository wird so gemacht:

meta exec "git checkout master"

Hybrider Mono-As-Poly-Ansatz

Ein anderer Ansatz besteht darin, den Code für die Entwicklung über ein Monorepo zu verwalten, aber den Code jeder Bibliothek zur Bereitstellung in ihr unabhängiges Repository zu kopieren.

Diese Strategie ist im PHP-Ökosystem weit verbreitet, da Packagist (das Haupt-Repository von Composer) eine öffentliche Repository-URL benötigt, um ein Paket zu veröffentlichen, und es nicht möglich ist, anzugeben, dass sich das Paket in einem Unterverzeichnis des Repositorys befindet.

Angesichts der Packagist-Einschränkung können PHP-Projekte weiterhin ein Monorepo für die Entwicklung verwenden, sie müssen jedoch den Multi-Repo-Ansatz für die Bereitstellung verwenden.

Um diese Konvertierung zu erreichen, können wir ein Skript mit ausführen git subtree split Oder verwenden Sie eines der verfügbaren Tools, die dieselbe Logik ausführen:

  • Git-Teilbaum-Splitter
  • Git-Subsplit
  • GitHub-Aktion für Monorepo-Split

Wer verwendet Monorepo vs. Multi-Repo

Mehrere große Technologieunternehmen bevorzugen den Monorepo-Ansatz, während sich andere für die Multi-Repo-Methode entschieden haben.

Google, Facebook, Twitter und Uber haben sich alle öffentlich für den Monorepo-Ansatz verbürgt. Microsoft betreibt das größte Git-Monorepo der Welt, um den Quellcode des Windows-Betriebssystems zu hosten.

Auf der anderen Seite sind Netflix, Amazon und Lyft berühmte Unternehmen, die den Multi-Repo-Ansatz verwenden.

Auf der hybriden Poly-as-Mono-Seite aktualisiert Android mehrere Repositorys, die wie ein Monorepo verwaltet werden.

Auf der Hybrid-Mono-as-Poly-Seite hält Symfony den Code für alle seine Komponenten in einem Monorepo. Sie teilen es in unabhängige Repositorys für die Bereitstellung auf (wie z symfony/dependency-injection und symfony/event-dispatcher.)

Beispiele für Monorepo und Multi-Repo

Das WordPress-Konto auf GitHub hostet Beispiele sowohl für den Monorepo- als auch für den Multi-Repo-Ansatz.

Gutenberg, der WordPress-Blockeditor, besteht aus mehreren Dutzend JavaScript-Paketen. Diese Pakete werden alle auf der WordPress/gutenberg monorepo und verwaltet über Lerna, um sie bei der Veröffentlichung im npm-Repository zu unterstützen.

Openverse, die Suchmaschine für offen lizenzierte Medien, hostet ihre Hauptteile in unabhängigen Repositories: Frontend, Katalog und API.

Monorepo vs. Multi-Repo: Wie wählt man?

Wie bei vielen Entwicklungsproblemen gibt es keine vordefinierte Antwort darauf, welchen Ansatz Sie verwenden sollten. Verschiedene Unternehmen und Projekte profitieren aufgrund ihrer einzigartigen Bedingungen von der einen oder anderen Strategie, wie zum Beispiel:

  • Wie groß ist die Codebasis? Enthält es Gigabyte an Daten?
  • Wie viele Leute werden an der Codebasis arbeiten? Sind es etwa 10, 100 oder 1,000?
  • Wie viele Pakete wird es geben? Sind es etwa 10, 100 oder 1,000?
  • An wie vielen Paketen muss das Team gleichzeitig arbeiten?
  • Wie eng sind die Pakete gekoppelt?
  • Sind verschiedene Programmiersprachen beteiligt? Benötigen sie eine bestimmte installierte Software oder spezielle Hardware, um ausgeführt zu werden?
  • Wie viele Bereitstellungstools sind erforderlich und wie komplex ist die Einrichtung?
  • Wie ist die Kultur im Unternehmen? Werden Teams zur Zusammenarbeit ermutigt?
  • Welche Tools und Technologien kennen die Teams?

Welchen Ansatz sollten Sie für Ihre Codebasis wählen? 🤔 Erfahre hier mehr 👇Klicken Sie, um Tweet

Zusammenfassung

Es gibt zwei Hauptstrategien für das Hosten und Verwalten von Code: Monorepo vs. Multi-Repo. Beim Monorepo-Ansatz wird der Code für verschiedene Bibliotheken oder Projekte – und sogar der gesamte Code eines Unternehmens – in einem einzigen Repository gespeichert. Und das Multi-Repo-System teilt den Code in Einheiten wie Bibliotheken oder Dienste auf und hält ihren Code in unabhängigen Repositorys gehostet.

Welche Vorgehensweise zu verwenden ist, hängt von einer Vielzahl von Bedingungen ab. Beide Strategien haben mehrere Vor- und Nachteile, die wir in diesem Artikel gerade ausführlich behandelt haben.

Sie haben noch Fragen zu Monorepos oder Multi-Repos? Lass es uns im Kommentarbereich wissen!

Verwandte Artikel

0 Kommentare
Inline-Feedbacks
Alle Kommentare anzeigen
Nach oben-Taste