Womenintech Part 5: Git Mono-Repos vs. Multi-Repos

Einleitung

Viele Benutzer setzen Git aufgrund seiner Flexibilität als verteiltes Versionskontrollsystem ein. Insbesondere das Branchen und Mergen von Git bietet leistungsstarke Möglichkeiten. Während diese Flexibilität sehr vielseitig einsetzbar ist, gibt es aber auch einige schwierige Fälle. Einer dieser Anwendungsfälle ist die Verwendung von Git mit großen, monolithischen Repositories oder auch Mono-Repos genannt. Mehr zu Git finden Sie in einem meiner früheren Blog Posts hier.

Mono-Repos vs. Multi-Repos

Was sind Mono-Repos?

Mono-Repos sind Repositories, in denen der gesamte Quellcode in einem einzigen Repository aufbewahrt wird und kann mehr als ein logisches Projekt enthalten. Diese Projekte sind lose miteinander verbunden oder können auf andere Weise verbunden sein. Diese Repos machen es zum Beispiel sehr einfach, allen Mitarbeiter Zugriff auf den gesamten Code zu geben. Google und Facebook verwenden ein Mono-Repo.

Vorteile Mono-Repos

Da alle Projekte zentral in einem Repository sind, ist der Zugriff und die Verwendung eines CI/CD Tools sehr einfach. Durch die Verwendung eines einzelnen Repos wird auch der Aufwand beim Verwalten von Dependencies reduziert. Jedes Mal, wenn wir etwas umbenennen möchten, ist das Refactoring so einfach wie das Ausführen eines Grep-Befehls. Die Umstrukturierung ist auch einfacher, da alles sauber an einem Ort und einfacher zu verstehen ist.

Nachteile Mono-Repos

Es gibt viele konzeptionelle Herausforderungen bei der Verwaltung von Projekten in einem Mono-Repo. Git verfolgt den Zustand des gesamten Trees in jedem einzelnen durchgeführten Commit und ist für einzelne oder verwandte Projekte geeignet. Für Repositories mit vielen Projekten die nicht verwandt sind, wird es unhandlich. Neben konzeptionellen Herausforderungen gibt es zahlreiche Performanceprobleme, die sich auf ein Mono-Repo auswirken können.

Was sind Multi-Repos?

Multi-Repos beziehen sich auf Projekte in jeweils eigenen Repositories. Man spricht von Multi-Repos wenn es mehrere Repositories für verschiedenste Dienste gibt. Wenn mehrere Repositories vorhanden sind, ist es einfacher, die Zugriffe auf einzelne Teile davon zu steuern.

Vorteile Multi-Repos

In Multi-Repos ist es einfacher Continuous-Deployment für einzelne Projekte einzurichten, da bei der Verwendung eines Mono-Repos eine zusätzliche Logik für die Verzeichnisse vorhanden sein muss. Es ist einfacher, Integrationstests zu erstellen, wenn alle Services in einem Repository vorhanden sind, da die Erstellung der Testumgebung und -bereitstellung einfacher wird.

Nachteile Multi-Repos

Ein großer Nachteil bei der Verwendung von Multi-Repos und der Verwendung von CI/CD ist jedoch, dass der Zugriff auf andere Repositories und deren Inhalte nicht sehr einfach ist. Da die Projekte in mehrere Teile aufgeteilt werden, kann das auch zu Unklarheiten zwischen Mitarbeitern führen, da diese kein Gesamtbild haben und sich nicht darum kümmern was andere tun, solange ihre Arbeit erledigt ist.

Der Wechsel von Multi-Repos zu einem Mono-Repo

Wie schon in meinen vorigen Blog, Womenintech Part 4: Continous Delivery Of A Static Web Page With Jekyll, GitLab And AWS, beschrieben, wollten wir das Deployment unserer Websiten automatisieren. Da wir mehrere Websiten verwalten, mit Teilweise dem gleichen Content, haben wir uns dazu entschlossen auf ein Mono-Repo umzusteigen. Der Code, den sich alle Websiten teilen, liegt im Root-Verzeichnis des Repos. Natürlich brachte das einige Schwierigkeiten mit sich. Wenn an diesem Code etwas geändert wird, sollte dieser auf allen Websiten deployed werden. Aber wird nur auf einer speziellen Website etwas geändert, sollen die Änderungen natürlich nur dort deployed werden.

Um etwas Logik in das Ganze zu bringen, gibt es in unserem Git-Repository 2 Unterordner die nach unseren Webseiten benannt sind. Davon hat jeder wiederum einen Unterordner source mit jeweils 2 Unterordner en und de. Für unsere Blog Posts gibt es einen zentralen Ordner in unserem Repository, sodass wir uns nicht mehr darum kümmern müssen, auf welchen Seiten wir welchen Post ausspielen müssen. Hier verwenden wir ein Ruby Skript, welches je nach Sprache, den Post an der richtigen Stelle platziert.

Da wir in diesem Fall bestimmten Content auf mehreren Webseiten wiederverwenden, war es für uns die richtige Entscheidung auf eine Mono-Repo umzusteigen. Hätten wir aber verschiedene Projekte die keinen Zusammenhang haben, wären wir sicher bei Mono-Repos geblieben. Man muss natürlich immer die Vor- und Nachteile der jeweiligen Lösung abwägen und herausfinden was für welche Projekte am besten geeignet ist.

Das ursprüngliche Deployment-Skript musste umgeschrieben werden, um diese Anforderungen zu erfüllen. Mit der Hilfe von Edmund und Jürgen, findet das Skript nun heraus, in welchem Ordner wir uns befinden und wohin was deployed werden muss. Ich musste mich mit einigen Problemen auseinandersetzen, aber mit der Hilfe meiner Kollegen konnten wir diese gemeinsam lösen.