Ich habe festgestellt, dass ich eine Java-FW im Mono-Repo entwickle, daher werde ich die Operation in Betracht ziehen.

Einführung

Dieser Artikel ist ein Artikel, der den Repository-Betrieb berücksichtigt, um die Vorteile der Monorepo-Entwicklung in einem Projekt zur Entwicklung von Java FW zu nutzen.

Was ist Monorepo?

Einfach ausgedrückt handelt es sich um eine Repository-Betriebsstrategie, mit der Code modulübergreifend in einem Repository verwaltet wird. Es gibt die folgenden zwei Denkweisen über Monorepo, aber in diesem Artikel werden wir die ** letztere ** betrachten.

1. Die Idee, den gesamten Unternehmenscode in einem Repository zu verwalten
2. Die Idee, den gesamten Code eines Projektmoduls in einem Repository zu verwalten

Ist das ein Mono Repo?

Mein Team entwickelt Java FW. Die FW bestand aus mehreren Modulen, die in einem Git-Repository entwickelt wurden. Nach Bestätigung der Umstände mit dem Team wurde gesagt, dass das Repository im Bereich der Qualitätssicherung als Produkt erstellt wurde. Zu dieser Zeit hatte ich wenig Erfahrung mit Git, daher fühlte ich mich nicht unwohl, aber es scheint, dass der Betrieb eines solchen Repositorys als Monorepo bezeichnet wird. Daher werde ich untersuchen, ob es sich um einen Vorgang handelt, der die Vorzüge des Monorepo-Vorgangs nutzt.

Vorteile von Monorepo

Wenn Sie sich auf das Dokument von Nx beziehen, das ein Toolset für die Monorepo-Entwicklung ist, können die folgenden vier Punkte als die Vorzüge der Monorepo-Operation genannt werden.

1. Code ist einfach wiederzuverwenden, da sich der gesamte Code im selben Repository befindet und voneinander referenziert werden kann.
2. Die Auswirkungen von Moduländerungen sind im selben Repository vollständig und können mit 1PR behoben werden.
3. Konsistente Build- und Testverfahren für Module mit verschiedenen Tools und Technologien.
4. Abhängigkeiten für jedes Modul können auf einen einzelnen Satz festgelegt werden, und Sie werden später nicht von Abhängigkeitskonflikten gestört.

Schauen Sie sich das Java-Repository des Teams noch einmal an

Aus den folgenden beiden Punkten lässt sich ableiten, dass das Repository die Vorteile von Monorepo genießt. Tatsächlich werfen wir PR nicht in verschiedene Repositorys, während wir Funktionen entwickeln und ändern, und wir müssen uns nicht um Abhängigkeiten als Konsolidierungstest kümmern.

1. Die Module, aus denen das Produkt besteht, werden im selben Repository verwaltet

Die Module, einschließlich des Testcodes, werden im selben Repository entwickelt, und Sie können aufeinander verweisen und die Auswirkungen der Änderungen überprüfen (* Die Bildstruktur ist ein Bild). Wenn das Repository eine Datei enthält, die einen Pipeline-Job (.gitlab-ci.yml) definiert, z. B. GitLab CI / CD, die Pipeline Ein weiterer Vorteil ist, dass Jobs leicht wiederverwendet werden können.

2. Abhängigkeiten werden in der Gradle-Datei eindeutig verwaltet

Produktabhängigkeiten werden in einer einzigen Gradle-Datei verwaltet.

dependencies {
	implementation("org.aspectj:aspectjrt:1.9.4")
	implementation("org.aspectj:aspectjweaver:1.9.4")
	implementation("com.fasterxml:classmate:1.4.0")
	implementation("commons-beanutils:commons-beanutils:1.9.3")
	implementation("commons-betwixt:commons-betwixt:0.8") {
		exclude module: "commons-beanutils-core"
	}
    //Unterlassung
}

Betrieb von Mono Repo

Wie oben erwähnt, konnten wir bestätigen, dass das Team vom Mono-Repo profitiert hat. Lassen Sie uns als nächstes über die Überlegungen zum Monorepo-Betrieb nachdenken, um die Vorteile von Monorepo zu maximieren und die betrieblichen Probleme von Monorepo anzugehen. Dies basiert auf den Referenzen. Siehe auch die Referenzen am Ende dieses Artikels.

** 1. Umgang mit der Zunahme der Größe des physischen Repositorys ** Das Repository ist aufgebläht, da der gesamte Code in einem einzigen Repository verwaltet wird. Ganz zu schweigen von der Größe, sollten Sie sich mit der erhöhten Build- und Testzeit befassen. Im Allgemeinen wird gesteuert, um nur den Einflussbereich aufzubauen und zu testen.

** 2. So schützen Sie Module, die Sie nicht manipulieren möchten ** Wenn alle Module in einem einzigen Repository gespeichert sind, kann ein anderes Team sie zerstören. Berücksichtigung der Kontrolle für jedes Team für das Modul.

** 3. Wie viel kann ein einzelner Standard jedes Modul durchdringen ** Wenn der Codierungsstil, die Qualitätskontrollstandards und die Abhängigkeitssätze für jedes Modul unterschiedlich sind, gehen die Vorteile von monorepo verloren und die Verwaltung wird kompliziert. Die Problemumgehung besteht darin, den De-facto-Standard für das Modul durchzusetzen.

** 4. Können Moduländerungen schnell im gesamten Repository verteilt werden **? Der Vorteil des Mono-Repo-Betriebs besteht darin, dass alle Entwickler auf den neuesten Code aller Module verweisen können. Daher wird eine auf CI / CD basierende trunkbasierte Entwicklung für den Repository-Betrieb als vorzuziehen angesehen.

Rückblick auf den Java-Repository-Betrieb des Teams

Im Vergleich zum Betrieb des Mono-Repo ist die Bewertung des Repository-Betriebs des Teams wie folgt.

1. Das Repository und das Entwicklungsteam sind nicht riesig.
2. Aufgrund der Art des Projekts wird es nicht unter Beteiligung vieler Teams entwickelt.
3. Als Produkt ist eine ** strenge Qualitätskontrolle ** festgelegt, und bestimmte Standards sind unter den Modulen vereinheitlicht.
4. Entwickelt von Feature Branch.

Das Team beschleunigt die Reflexion von Codeänderungen, indem es CI / CD für die Qualitätskontrolle fördert. Darüber hinaus kann gesagt werden, dass es aufgrund der Größe des Repositorys oder des Umfangs der Entwicklung keine Probleme gibt, da die Entwickler mit einer kleinen Anzahl von Teams die Kontrolle über das gesamte Repository in der Entwicklung haben.

Zusammenfassung

Wir haben die Vorzüge und die Funktionsweise der Entwicklung mit Mono-Repo erläutert und das Mono-Repo des Teams und dessen Betrieb bestätigt. Zusammenfassend lässt sich sagen, dass das Repository des Teams keine größeren Probleme hinsichtlich des Monorepo-Betriebs aufwies und dass die Entwicklung fortgesetzt wurde, während die Vorteile erhalten wurden. In einem von einem kleinen Team entwickelten Repository kann gesagt werden, dass es nicht viele Probleme gibt, die durch die Erstellung eines Monorepo verursacht werden.

Abgesehen davon fühlt es sich etwas seltsam an, wenn das Repository und das Repository in einer Reihe stehen.

Verweise

In Bezug auf das Mono-Repo werden die Vorzüge und Betriebsstudien anhand der folgenden Referenzen beschrieben.

--Nx-Dokumentation: https://nx.dev/angular/getting-started/why-nx

• Misconceptions about Monorepos: Monorepo != Monolith：https://blog.nrwl.io/misconceptions-about-monorepos-monorepo-monolith-df1250d4b03c
• Übersetzung: https://www.graat.co.jp/blogs/ck1099bcoeud60830rf0ej0ix
• Monolith → MultiRepo → MonoRepo Repository-Strategie: https://slides.com/kotamat/repository-strategy