Mono-Repo und Multi-Repo sind zwei Hauptstrategien für das Hosten und Verwalten von Code über Git. Wir besprechen sowohl die Strategien als auch ihre Vor- und Nachteile im Detail.
Inhaltsverzeichnis
Einführung
Die meisten modernen Projekte werden auf Git verwaltet und gehostet. Git ist zur Standardplattform für verteiltes Quellcodemanagement, Versionskontrolle und Zusammenarbeit von überall auf der Welt geworden. Git ist schnell und effizient. Es gibt zwei Hauptansätze zum Hosten und Verwalten Ihres Git-Codes:
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 über Benutzer, Personen und Computer.
Die Repository-Daten sind versioniert. Ein Repo 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 verfügt über eine Benutzeroberfläche.
Git bietet Versionskontrolle und Code-Sharing-Funktionen, was Git jedoch anders macht, ist, dass Entwickler, wenn sie 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 daher den Inhalt lokal kopieren und ändern (Forking genannt).
Wenn der Entwickler außerdem lokal vorgenommene Änderungen teilen möchte, kann er eine „Pull-Anforderung“ an den Eigentümer des Projekts senden.
Ein Projekt kann einen einzigen Dienst haben. Wenn Ihr Projekt mehrere Workflows hat, können Sie mehrere Dienste für jeden Workflow 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 serverloser Frameworks können Benutzer auf Funktionen als Dienste zugreifen.
Sobald 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 Ihrer Services 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 jeden Dienst weiterhin unabhängig voneinander 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
- Einfache Wiederverwendung und gemeinsame Nutzung von Code, Zusammenarbeit mit dem Team
- Leicht verständliche Auswirkungen Ihrer Änderung auf das gesamte Projekt
- Beste Option für Code-Refactoring und große Änderungen am Code
- Teammitglieder können sich einen Gesamtüberblick über das gesamte Projekt verschaffen
- Einfach zu verwaltende Abhängigkeiten
Nachteile von Mono-Repo
Natürlich hat Mono-Repo einige Nachteile, der wichtigste ist die Leistung. Wenn Ihr Projekt wächst und jeden zweiten Tag weitere Dateien hinzugefügt werden, können das Auschecken, Abrufen und andere Vorgänge langsam werden und Dateisuchen länger dauern.
Wenn Sie viele unabhängige Auftragnehmer für Ihr Projekt beauftragen, 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 Personen 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. Beispielsweise verwendet Facebook ein benutzerdefiniertes Dateisystem und eine Quellcodeverwaltung.
Was ist ein Multi-Repo?
Bei einem Multi-Repo-Ansatz gibt es mehrere Repositories, 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 größer als die Zahl der Unternehmen, 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, sodass es auch bei wachsender Projektgröße keine Leistungsprobleme gibt
- Teams können unabhängig voneinander arbeiten und müssen keinen Zugriff auf die gesamte Codebasis haben
- Schnellere Entwicklung und Flexibilität
- Jeder Dienst kann separat veröffentlicht werden und hat seinen eigenen Bereitstellungszyklus, wodurch CI und CD einfacher zu implementieren sind
- Bessere Zugriffskontrolle – alle Teams müssen nicht vollen Zugriff auf alle Bibliotheken haben – können aber bei Bedarf Lesezugriff erhalten
Nachteile von Multi-Repo
- Die Abhängigkeiten und Bibliotheken, die über Dienste und Projekte hinweg verwendet werden, müssen regelmäßig synchronisiert werden, um die neueste Version zu erhalten
- Fördert irgendwann eine isolierte Kultur, was zu doppeltem Code und einzelnen Teams führt, die versuchen, das gleiche Problem zu lösen
- Jedes Team befolgt möglicherweise einen anderen Satz von Best Practices für seinen Code, was zu Schwierigkeiten bei der Befolgung allgemeiner Best Practices führt
Unterschiede zwischen Mono- und Multi-Repo
Lassen Sie uns die Unterschiede zwischen Mono-Repo und Multi-Repo 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 zusammenarbeiten; Sie können die Änderungen des anderen sehen
Teams können autonom arbeiten; individuelle Änderungen wirken sich nicht auf Änderungen durch andere Teams oder Projekte aus
Jede Person erhält Zugriff auf die gesamte Projektstruktur
Administratoren können die Zugriffskontrolle auf das Projekt oder den Dienst beschränken, auf das der Entwickler Zugriff benötigt
Skalierungsprobleme 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 problemlos erreichen, da sie Dienste unabhängig voneinander erstellen können
Entwickler können Bibliotheken, APIs und anderen gemeinsamen Code einfach gemeinsam nutzen, wenn 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 Versionsverwaltung und Zugriffskontrolle ab, den Sie benötigen.
Mono-Repo bevorzugt Konsistenz, während sich Multi-Repo auf die Entkopplung konzentriert. Während in einem Mono-Repo das gesamte Team Änderungen sehen kann, die von einer Person vorgenommen wurden, erstellt Multi-Repo ein separates Repo für jedes Team, 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 dafür entscheiden Metaein Tool zum Verwalten mehrerer Projekte und Bibliotheken.
Sie könnten auch an kostenlosen Ressourcen zum Erlernen von Git interessiert sein.