Die Strategien Mono-Repo und Multi-Repo sind zwei grundlegende Ansätze für die Speicherung und das Management von Code mittels Git. Wir betrachten beide Methoden sowie ihre jeweiligen Vor- und Nachteile im Detail.
Einführung
In der heutigen Entwicklungswelt werden die meisten Projekte mit Git verwaltet und gehostet. Git hat sich als Standard für verteiltes Quellcode-Management, Versionskontrolle und die Zusammenarbeit von Entwicklern weltweit etabliert. Git zeichnet sich durch seine Schnelligkeit und Effizienz aus. Im Wesentlichen gibt es zwei Hauptansätze zur Organisation und zum Management von Git-Code:
Bevor wir uns die spezifischen Ansätze genauer ansehen, wollen wir kurz das Konzept eines Repositories (Repos) erläutern.
Was sind Repositories (Repos)?
Ein Repository, kurz Repo, ist ein Speicherort, der sämtliche Ordner und Dateien eines Projekts enthält. Es speichert auch Informationen über Benutzer, Beteiligte und deren Rechner.
Die Daten in einem Repo sind versioniert, d.h., jede Änderung wird nachvollziehbar gespeichert. Ein Repo kann einer Einzelperson oder einer Gruppe von Teammitgliedern gehören.
Git selbst ist ein solches Repository. Es kann öffentlich, privat oder nur intern zugänglich sein. GitHub fungiert als Hosting-Service für Git-Repositories und bietet eine benutzerfreundliche Oberfläche.
Git zeichnet sich durch seine Funktionen zur Versionskontrolle und Code-Sharing aus. Ein besonderes Merkmal ist, dass Entwickler bei Änderungen am Code das gesamte Repository auf ihr lokales System kopieren können. Selbst ohne Schreibrechte für ein bestimmtes Projekt können sie den Inhalt lokal kopieren und bearbeiten (dieser Vorgang wird als „Forking“ bezeichnet).
Wenn ein Entwickler seine lokalen Änderungen mit anderen teilen möchte, kann er eine „Pull-Anfrage“ an den Projektverantwortlichen senden.
Ein Projekt kann aus einem einzigen Dienst bestehen. Wenn Ihr Projekt jedoch aus mehreren Workflows besteht, ist es sinnvoll, mehrere unabhängige Dienste für jeden Workflow zu erstellen. Die meisten Entwickler bevorzugen es, größere Projekte in kleinere, eigenständige Dienste aufzuteilen, die spezifische Funktionen erfüllen. Jeder dieser Dienste kann auf bestimmte Geschäftsprobleme zugeschnitten sein. Insbesondere durch serverlose Frameworks können Funktionen als Dienste bereitgestellt werden.
Nachdem diese „Functions-as-Services“ entwickelt und bereitgestellt wurden, ist die nächste Aufgabe, sie zu strukturieren und zu versionieren. Hier stehen Ihnen zwei Möglichkeiten offen: Entweder Sie speichern alle Dienste in einem einzigen Repository (Mono-Repo), oder Sie erstellen für jeden Dienst ein eigenes Repository (Multi-Repo)!
Was ist ein Mono-Repo?
Die Mono-Repo-Strategie beinhaltet, dass alle Dienste in einem einzigen Repository (dem „Mono“-Repository) zentral abgelegt werden. Trotzdem können die einzelnen Dienste weiterhin unabhängig voneinander bereitgestellt und verwaltet werden. Darüber hinaus können Dienste gemeinsame Bibliotheken und Code nutzen.
Große Unternehmen wie Facebook, Google und Dropbox verwenden die Mono-Repo-Strategie.
Vorteile eines Mono-Repos
Der Einsatz eines Mono-Repos bietet mehrere Vorteile:
- Zentraler Speicherort für den gesamten Projektcode, auf den alle Teammitglieder Zugriff haben
- Einfache Wiederverwendung und gemeinsame Nutzung von Code, was die Zusammenarbeit im Team verbessert
- Gute Übersicht über die Auswirkungen von Codeänderungen auf das gesamte Projekt
- Hervorragend geeignet für Code-Refactoring und größere Codeänderungen
- Teammitglieder erhalten eine ganzheitliche Sicht auf das gesamte Projekt
- Einfache Verwaltung von Abhängigkeiten
Nachteile eines Mono-Repos
Natürlich hat auch ein Mono-Repo Nachteile. Der Hauptnachteil ist die Performance. Wenn das Projekt immer größer wird und ständig neue Dateien hinzugefügt werden, können Vorgänge wie Auschecken, Abrufen und Dateisuchen zeitaufwendig werden.
Wenn Sie viele externe Auftragnehmer für Ihr Projekt beschäftigen, ist es möglicherweise nicht ideal, ihnen Zugang zur gesamten Codebasis zu gewähren.
Zudem ist die Implementierung von Continuous Deployment (CD) schwierig, da viele Personen Änderungen einchecken können und das Continuous Integration (CI)-System möglicherweise mehrfach neu bauen muss.
Große Unternehmen, die Mono-Repos verwenden, haben oft maßgeschneiderte Tools, um die Skalierungsprobleme zu bewältigen. Beispielsweise verwendet Facebook ein spezielles Dateisystem und ein eigenes System zur Quellcodeverwaltung.
Was ist ein Multi-Repo?
Die Multi-Repo-Strategie sieht vor, dass ein Projekt in mehreren Repositories aufgeteilt wird, die jeweils einzelne Bibliotheken und Dienste hosten. Bei einer Änderung an einem Dienst müssen Entwickler nur diesen Dienst neu bauen und nicht das gesamte Projekt. Einzelpersonen und Teams können an ihren spezifischen Diensten arbeiten und erhalten nur Zugriff auf die dafür notwendigen Dienste.
Unternehmen wie Netflix und Amazon verwenden Multi-Repos.
Vorteile von Multi-Repos
Es gibt viele Unternehmen, die sich für Multi-Repos anstelle von Mono-Repos entscheiden. Dafür gibt es folgende Gründe:
- Jeder Dienst und jede Bibliothek hat seine eigene Versionierung
- Code-Checkouts und -Pulls sind klein und isoliert, wodurch auch bei wachsender Projektgröße keine Performance-Probleme entstehen
- Teams können unabhängig voneinander arbeiten und müssen nicht auf die gesamte Codebasis zugreifen
- Schnellere Entwicklung und höhere Flexibilität
- Jeder Dienst kann unabhängig veröffentlicht werden und hat seinen eigenen Bereitstellungszyklus, wodurch CI und CD einfacher zu implementieren sind
- Bessere Zugriffskontrolle – nicht alle Teams benötigen Zugriff auf alle Bibliotheken, können aber bei Bedarf Lesezugriff erhalten
Nachteile von Multi-Repos
- Die Abhängigkeiten und Bibliotheken, die von verschiedenen Diensten und Projekten verwendet werden, müssen regelmäßig synchronisiert werden, um die neueste Version zu verwenden
- Kann zu einer isolierten Arbeitsweise führen, die doppelten Code und separate Teams zur Folge hat, die das gleiche Problem lösen
- Jedes Team verwendet möglicherweise andere Best Practices für seinen Code, was die Einhaltung allgemeiner Best Practices erschwert
Unterschiede zwischen Mono- und Multi-Repo
Lassen Sie uns die Unterschiede zwischen Mono-Repo und Multi-Repo kurz zusammenfassen:
| Mono-Repo | Multi-Repo |
| Der gesamte Code aller Projekte einer Organisation befindet sich in einem zentralen Repository | Jeder Dienst und jedes Projekt hat ein separates Repository |
| Teams können zusammenarbeiten und ihre Arbeit gegenseitig einsehen | Teams können autonom arbeiten; Änderungen wirken sich nicht auf andere Teams aus |
| Jeder hat Zugriff auf die gesamte Projektstruktur | Administratoren können den Zugriff auf die notwendigen Projekte/Dienste beschränken |
| Skalierungsprobleme können auftreten, wenn die Projektgröße steigt | Gute Performance aufgrund der begrenzten Code- und Service-Einheiten |
| Schwierige Implementierung von Continuous Deployment (CD) und Continuous Integration (CI) | Entwickler können CD und CI einfacher erreichen, da sie Dienste unabhängig entwickeln können |
| Einfache gemeinsame Nutzung von Bibliotheken, APIs und anderem gemeinsamem Code durch ein zentrales Repository | Änderungen an Bibliotheken und gemeinsamem Code müssen regelmäßig synchronisiert werden, um Probleme zu vermeiden |
Fazit
Sowohl Mono-Repo als auch Multi-Repo sind gängige Ansätze, wobei die beste Wahl von der Größe und den Anforderungen Ihres Projekts sowie dem gewünschten Grad an Versionskontrolle und Zugriffskontrolle abhängt.
Mono-Repo legt Wert auf Konsistenz, während Multi-Repo die Entkopplung betont. Während in einem Mono-Repo das gesamte Team die Änderungen einer einzelnen Person sieht, erstellt Multi-Repo für jedes Team separate Repositories, mit dem Vorteil, dass nur Zugriff auf die benötigten Dienste gewährt wird. Falls Sie für Ihre Projekte eine Kombination aus Mono-Repo und Multi-Repo in Betracht ziehen, könnte Meta interessant sein, ein Tool zur Verwaltung mehrerer Projekte und Bibliotheken.
Zudem könnten Sie an kostenlosen Lernressourcen zu Git interessiert sein.