Das Monorepo-Muster verwendet ein einziges Versionskontroll-Repository für alle Ihre Projekte und Assets. Sie werden Ihre serverseitigen, Front-End- und Infrastruktur-Konfigurationsdateien in einem Repository zusammenfassen, zu dem alle beitragen. Sollten Sie es verwenden?
Das Muster ist bei großen Technologieunternehmen beliebt. Google, Microsoft und Facebook gehören zu den Organisationen, die Monorepos verwenden. Was macht ein Monorepo so attraktiv?
Die Alternative
Monorepo steht gegen Multi-Repo. Beim Muster mit mehreren Repositorys erstellen Sie für jedes Ihrer Projekte ein neues Repository. Es ist normalerweise ziemlich klar, wann ein Projekt ein eigenes Repository verdient.
Wenn Sie eine App erstellen, haben Sie möglicherweise drei Repositorys:
- Serverseitiger Code:Ihre API (möglicherweise mit zusätzlichen Repositorys für Datenbankschemas und Dokumentation).
- Android-Projekt: Der Android-Build Ihrer App, der Java oder Kotlin verwendet.
< li>iOS-Projekt: Objective-C oder Swift für Ihre iOS-App.
Hier ist alles, was Ihr Unternehmen ausmacht, in verschiedene Funktionseinheiten unterteilt. Mit einem Monorepo verlassen Sie diese Gruppierung und nehmen immer die aggregierte Ansicht. Alle Ihre Assets gehören zusammen und werden entsprechend versioniert.
Zusammenarbeit
Einer der am häufigsten genannten Monorepo-Vorteile betrifft die Zusammenarbeit. In einem Monorepo sieht jeder alles. Dies fördert die Übersichtlichkeit, erleichtert die Offenheit und erleichtert den Zugriff von Mitarbeitern in verschiedenen Teams auf die anderen&8217; arbeiten.
Menschen können leichter an einer Aufgabe zusammenarbeiten, auch wenn sie außerhalb ihrer üblichen Verantwortlichkeiten liegt. In einem Szenario mit mehreren Repositorys müssen Sie möglicherweise zuerst um Zugriff auf das relevante Repository bitten. Dies führt zu Reibungen, die der Monorepo-Ansatz vollständig vermeidet.
Monorepos ermutigen jeden dazu, die Verantwortung für das Endziel zu übernehmen und nicht für die einzelnen Teile, aus denen es besteht. Dies kann dazu führen, dass sich die Menschen stärker eingebunden fühlen und besser darüber informiert sind, was vor sich geht. Ein App-Entwickler berührt vielleicht nie die Serverkomponenten, aber er kann “fühlen” sie entwickeln sich parallel zu ihrer eigenen Arbeit.
Einfache Abstraktion
Monorepos vereinfachen auch die Codeabstraktion. Es ist üblich, dass Ihre Back-End- und Front-End-Komponenten ähnliche Funktionen aufweisen. Es ist sinnvoll, dies in eine gemeinsam genutzte Bibliothek zu abstrahieren.
Im Multi-Repo-Paradigma müssten Sie ein neues Repository erstellen und dann in den anderen darauf verweisen. Dies kann durch das Erstellen eines Pakets oder die Verwendung von Git-Submodulen erfolgen. In jedem Fall ist viel Arbeit erforderlich, bevor Ihr abstrahierter Code wieder in die Projekte eingespeist werden kann, aus denen er stammt.
Der Prozess ist einfacher, wenn Sie ein Monorepo haben. Sie können den Code in ein sinnvolles Verzeichnis verschieben und ihn dann dort importieren, wo er benötigt wird. Eine “Abstraktion” dauert Sekunden. Es ist ähnlich praktisch, wenn es an der Zeit ist, den Code zu dokumentieren: Sie können die Dokumente zu Ihrem gemeinsamen Dokumentationssystem hinzufügen.
Multi-Repos weisen auch praktische Hindernisse bei der Abstraktion von Code auf. Ein Mitglied des Entwicklungsteams verfügt oft nicht über die erforderlichen GitLab-, GitHub- oder Bitbucket-Berechtigungen, um ein neues Repository zu erstellen. Dies führt zu noch größeren Gemeinkosten, wenn ein Teamleiter die neue Bibliothek genehmigen und ein Repository einrichten muss. Monorepos helfen einzelnen Entwicklern, wiederverwendbaren Code zu erstellen, indem spezielle Abstraktionsprozesse eliminiert werden.
Über die Erstellung der Abstraktion hinaus vereinfachen Monorepos die Wartung gemeinsam genutzter Module. Sie müssen nicht jedes Mal, wenn Sie es aktualisieren, jeden Consumer eines Pakets aktualisieren. Alle Abhängigkeiten existieren in derselben Codebasis, sodass Sie ohne Paketmanager oder dedizierte Versionierung darauf verweisen können.
Entwicklungsgeschwindigkeit
Die Verwendung eines Monorepos kann die Entwicklungsgeschwindigkeit beschleunigen. Wir haben dies in den vorherigen Abschnitten angesprochen, aber es lohnt sich, mehr darauf zu achten.
Monorepos reduzieren doppelte Aktionen. Wenn Sie umgestalten müssen, ist es ein einziges Suchen und Ersetzen, um die Änderung auf die gesamte Codebasis anzuwenden. Es gibt weniger Wechsel zwischen Projekten und weniger Pull-Requests zur Überprüfung.
Mitwirkenden werden mehr Möglichkeiten zur Selbstbedienung gegeben. Da Informationen nicht in Team-Repositorys gespeichert werden, sind die Mitarbeiter besser gerüstet, um nach den benötigten Details zu suchen. Dies kann das Hin und Her bei der Codeplanung und -überprüfung reduzieren.
Diese Eigenschaften helfen auch beim Refactoring eines vorhandenen Systems. Der Versuch, eine Legacy-Anwendung in ihr “Frontend” und “Back-End” könnte der falsche Ansatz sein. Änderungen auf einer Seite wirken sich unweigerlich auf die andere aus, sodass Sie die beiden Repositorys ständig abgleichen. Die Verwendung eines Monorepos hilft Ihnen, große Teile der Codebasis schnell umzugestalten, da Sie wissen, dass Sie das gesamte System und nicht nur einzelne Komponenten beeinflussen.
Who Are Monorepos für?
Monorepos eignen sich gut für große Teams mit mehreren Projekten. Die Vorteile sind bei einer Handvoll kleiner Projekte nicht unbedingt offensichtlich. Monorepos funktionieren am besten in einer Größenordnung, bei der es bei einem Multi-Repo-Ansatz zu spürbarer Ineffizienz kommen würde.
Monorepos sind nicht dasselbe wie Monolithen. Ein Monolith beschreibt normalerweise eine Anwendung, bei der die Daten- und Präsentationsschichten vermischt sind. Das gesamte System wird bei jeder Änderung bereitgestellt.
Monorepos kapseln im Allgemeinen mehrere Systeme. Sie haben mehrere Ausgabeartefakte, z. B. eine API, eine Website und eine mobile App. Nicht alle Artefakte müssen für jede Änderung erzeugt werden. Monorepos sollen Code-Sharing und Refactoring erleichtern. Sie sollen nicht zu einem eng gekoppelten System führen, das künstlich miteinander verbunden ist.
Das Muster ist nicht für jedes Team geeignet. In vielen Fällen ist es einfacher, mit mehreren Repositorys zu arbeiten. Sie fühlen sich oft logischer an und sind leichter in den Griff zu bekommen. Sie müssen keine Zusammenführungskonflikte in unterschiedlichen Teilen des Systems lösen und es ist einfacher, Releases zu handhaben. CI-Pipelines werden schneller, da Sie nicht jedes Projekt in jeder Pipeline testen müssen.
Dedizierte Repositorys bieten auch einen saubereren Commit-Verlauf. Monorepo-Historien werden durch Commits für jedes Projekt innerhalb des Repos verunreinigt. Dies macht es schwieriger zu verfolgen, wie sich einzelne Komponenten entwickelt haben.
Mehrere Repositorys lassen sich einfacher in Versionskontrollsoftware wie GitHub und GitLab integrieren. Diese Tools gehen von einer Eins-zu-Eins-Zuordnung zwischen Repositorys und Projekten aus. Es kann mühsam sein, Issues und Pull-Requests in einem Monorepo zu verfolgen. Sie müssen Tags sorgfältig verwenden, um jedes Problem dem entsprechenden Projekt zuzuordnen.
Beachten Sie abschließend, dass die meisten Organisationen mit Monorepos eine spezielle Infrastruktur verwenden, um sie zu unterstützen. Git ist nicht für Monorepos ausgelegt und kann Probleme haben, wenn Sie eine ausreichende Skalierung erreichen. Millionen von Objekten in Ihrem Commit-Verlauf zu haben kann zu Verlangsamungen führen, wenn Git den Graphen durchlaufen muss.
Zusammenfassung
Das Monorepo-Muster vereinfacht die Codefreigabe und verbessert die Transparenz Ihrer Assets. Dies geht auf Kosten einer sauberen Commit-Historie, eines erhöhten Risikos von Merge-Konflikten und einer schlechten Unterstützung durch gängige Tools. Wenn das Monorepo wächst, können auch Leistungsprobleme auftreten.
Die Transparenz eines Monorepos ist nicht in allen Szenarien angemessen. Wenn Sie sich in einer streng regulierten Umgebung befinden, müssen Sie möglicherweise einzelne Repositorys verwenden, um geeignete Zugriffskontrollen durchzusetzen. Monorepos erhöhen auch das Risiko, wenn das Gerät eines Mitarbeiters verloren geht oder gestohlen wird. Personen mit physischem Zugriff könnten Ihren gesamten Code anzeigen, anstatt nur die für diese Person relevanten Projekte.
Die Entscheidung, ein Monorepo zu verwenden, sollte auf Ihren eigenen Projekten, ihren projektübergreifenden Abhängigkeiten, und Ihre Teammitglieder. Schauen Sie nicht auf die großen Tech-Unternehmen und erwarten Sie deren Erfolge in Ihren eigenen Projekten. Zu einer guten Codekultur gehört mehr als die Art des verwendeten Repositorys. Monorepos sind am sinnvollsten, wenn Menschen bereits freiwillig projektübergreifend zusammenarbeiten.