Mono-Repo und Multi-Repo sind zwei Hauptstrategien zum Hosten und Verwalten von Code über Git. Wir besprechen sowohl die Strategien als auch deren Vor- und Nachteile im Detail.
Einleitung
Die meisten modernen Projekte werden auf Git verwaltet und gehostet. Git hat sich zur Standardplattform für verteiltes Quellcodemanagement entwickelt. Versionskontrolleund Zusammenarbeit von überall auf der Welt. Git ist schnell und effizient. Es gibt zwei Hauptansätze zum Hosten und Verwalten Ihres Git-Codes:
- Mono-Repo
- Multi-Repository
Bevor wir uns mit diesen Ansätzen befassen, wollen wir verstehen, wie Repo funktioniert.
Was sind Repos?
Ein Repository (Repo) enthält alle Ordner und Dateien Ihres Projekts. Es enthält auch Informationen zu Benutzern, Personen und Computern.
Die Repository-Daten sind versioniert. Ein Repository kann einer Einzelperson oder einer Gruppe von Teammitgliedern gehören.
Git ist ein Repository. Es kann öffentlich, privat oder intern sein. GitHub ist ein Hosting-Service des Git-Repositorys und hat eine Benutzeroberfläche.
Git bietet Versionskontrolle und Code-Sharing-Funktionen. Was Git jedoch unterscheidet, ist, dass Entwickler, die einige Änderungen an ihren Dateien vornehmen möchten, das gesamte Repository auf ihr lokales System kopieren können. Selbst wenn ein Entwickler keinen Schreibzugriff auf ein bestimmtes Projekt hat, kann er den Inhalt lokal kopieren und ändern (sogenanntes Forking).
Wenn der Entwickler lokal vorgenommene Änderungen teilen möchte, kann er außerdem einen „Pull-Request“ an den Eigentümer des Projekts senden.
Ein Projekt kann einen einzelnen Dienst haben. Wenn Ihr Projekt hat mehrere workflows, können Sie für jeden Workflow mehrere Dienste erstellen. Die meisten Entwickler ziehen es vor, größere Projekte in kleinere unabhängige Dienste aufzuteilen, die eine oder mehrere Funktionen haben. Jeder Dienst kann verschiedene Geschäftsprobleme lösen. Mit der Popularität von serverlose Frameworks, Benutzer können auf Funktionen als Dienste zugreifen.
Nachdem Sie diese Functions-as-Services erstellt und bereitgestellt haben, besteht der nächste Schritt darin, sie zu strukturieren und zu versionieren – Sie können alle Ihre Services in einem Repository (Mono-Repo) haben – oder ein separates Repository für jeden Service, den Sie haben ( Multi-Repo)!
Was ist ein Mono-Repo?
Bei einem Mono-Repo-Ansatz können Sie alle Ihre Dienste in einem einzigen (Mono-)Repository aufbewahren. Sie können weiterhin jeden Dienst unabhängig bereitstellen und verwalten. Die Dienste können gemeinsame Bibliotheken und Code gemeinsam nutzen.
Unternehmen wie Facebook, Google und Dropbox verwenden Mono-Repo.
Vorteile von Mono-Repo
Der Mono-Repo-Ansatz hat viele Vorteile:
- Ein einziger Ort zum Speichern des gesamten Projektcodes, auf den alle im Team zugreifen können
- Einfach wiederzuverwenden und Code zu teilen, mit dem Team zusammenzuarbeiten
- Leicht verständlich, wie sich Ihre Änderung auf das gesamte Projekt auswirkt
- Beste Option für Code-Refactoring und große Codeänderungen
- Teammitglieder können sich einen Gesamtüberblick über das gesamte Projekt verschaffen
- Abhängigkeiten einfach verwalten
Nachteile von Mono-Repo
Mono-Repo hat natürlich einige Nachteile, der Hauptgrund ist die Leistung. Wenn Ihr Projekt wächst und jeden zweiten Tag mehr Dateien hinzugefügt werden, können das Auschecken, Abrufen und andere Vorgänge langsam werden und die Dateisuche kann länger dauern.
Auch, wenn Sie viel einstellen unabhängige Auftragnehmer für Ihr Projekt ist es möglicherweise nicht so sicher, ihnen Zugriff auf die gesamte Codebasis zu gewähren.
Darüber hinaus ist es schwierig, Continuous Deployments (CD) zu implementieren, da viele Benutzer ihre Änderungen einchecken können und Ihr Continuous Integration (CI)-System möglicherweise mehrere Neuerstellungen durchführen muss.
Große Unternehmen, die Mono-Repos verwenden, verfügen über angepasste Tools, um die Skalierungsprobleme zu bewältigen. Facebook verwendet beispielsweise ein benutzerdefiniertes Dateisystem und eine Quellcodeverwaltung.
Was ist ein Multi-Repo?
Bei einem Multi-Repository-Ansatz gibt es mehrere Repositorys, die mehrere Bibliotheken und Dienste eines Projekts hosten. Wenn sich ein Dienst ändert, müssen Entwickler nur diesen Dienst und nicht das gesamte Projekt neu erstellen. Einzelpersonen und Teams können an ihren spezifischen Diensten arbeiten und erhalten nur Zugriff auf die erforderlichen Dienste.
Unternehmen wie Netflix und Amazon verwenden Multi-Repos.
Vorteile von Multi-Repo
Die Zahl der Unternehmen, die Multi-Repo einführen, ist aus folgenden Gründen weitaus höher als diejenigen, die sich für Mono-Repo entscheiden:
- Jeder Dienst und jede Bibliothek haben ihre eigene Versionierung
- Code-Check-outs und -Pulls sind klein und getrennt, daher gibt es keine Leistungsprobleme, selbst wenn die Projektgröße wächst
- Teams können unabhängig arbeiten und müssen nicht auf die gesamte Codebasis zugreifen
- Schnellere Entwicklung und Flexibilität
- Jeder Service kann separat freigegeben werden und hat seinen eigenen Bereitstellungszyklus, wodurch CI und CD einfacher zu implementieren sind
- Bessere Zugriffskontrolle – nicht alle Teams müssen vollen Zugriff auf alle Bibliotheken haben – können aber bei Bedarf Lesezugriff erhalten
Nachteile von Multi-Repo
- Die Abhängigkeiten und Bibliotheken, die dienst- und projektübergreifend verwendet werden, müssen regelmäßig synchronisiert werden, um die neueste Version zu erhalten
- Fördert irgendwann eine isolierte Kultur, die zu doppeltem Code und einzelnen Teams führt, die versuchen, dasselbe Problem zu lösen
- Jedes Team kann für seinen Code unterschiedliche Best Practices befolgen, was zu Schwierigkeiten bei der Befolgung gemeinsamer Best Practices führt
Unterschiede zwischen Mono und Multi Repo
Fassen wir die Unterschiede zwischen Mono-Repo und Multi-Repo zusammen:
| Mono-Repo | Multi-Repository |
| Der gesamte Code aller Projekte einer Organisation befindet sich in einem zentralen Repository | Jeder Dienst und jedes Projekt haben ein separates Repository |
| Teams können zusammenarbeiten und zusammenarbeiten; sie können die Änderungen des anderen sehen | Teams können autonom arbeiten; individuelle Änderungen wirken sich nicht auf Änderungen anderer Teams oder Projekte aus |
| Jede Person erhält Zugriff auf die gesamte Projektstruktur | Administratoren können die Zugriffssteuerung auf das Projekt oder den Dienst beschränken, auf das der Entwickler Zugriff benötigt |
| Scale-up-Probleme können auftreten, wenn die Projektgröße weiter wächst | Gute Leistung aufgrund des begrenzten Codes und der kleineren Diensteinheiten |
| Schwierig zu implementieren Continuous Deployment (CD) und Continuous Integration (CI) | Entwickler können CD und CI leicht erreichen, da sie Dienste unabhängig erstellen können |
| Entwickler können problemlos Bibliotheken, APIs und anderen gemeinsamen Code freigeben, während sie im zentralen Repository aktualisiert werden | Alle Änderungen an Bibliotheken und anderem gemeinsamen Code sollten regelmäßig synchronisiert werden, um spätere Probleme zu vermeiden |
Fazit
Sowohl Mono-Repo als auch Multi-Repo sind gleichermaßen beliebt und welches besser ist, hängt von Ihrer Projektgröße, den Projektanforderungen und dem Grad der Versionierung und Zugriffskontrolle ab, die Sie benötigen.
Mono-Repo begünstigt Konsistenz, während sich Multi-Repo auf Entkopplung konzentriert. Während in einem Mono-Repo das gesamte Team die von einer Person vorgenommenen Änderungen sehen kann, erstellt Multi-Repo für jedes Team ein separates Repo, das nur Zugriff auf die erforderlichen Dienste hat. Wenn Sie für Ihre Projekte eine Kombination aus Mono-Repo und Multi-Repo verwenden möchten, können Sie sich für Ziel, ein Tool zum Verwalten mehrerer Projekte und Bibliotheken.
Dies könnte Sie auch interessieren Kostenlose Ressourcen zum Erlernen von Git.
