Von einem einzigen Repo über Multi-Repos über Monorepo bis hin zu Multi-Monorepo

Die Evolution dieses Projekts spiegelt viele Softwareentwicklungsreisen wider: Einfach zu beginnen und dann an wachsende Komplexität anzupassen. Zunächst eine große monolithische Anwendung innerhalb eines einzelnen Repositorys und entwickelte sich in mehreren Phasen von Architektur Refactoring und Repository Management.

Stufe 1: Die Einfachheit der einzelnen Repository

Das Leoloso/Pop -Projekt begann als WordPress -Site und kombinierte Themen und Plugins in einem einzigen Repository. Dies bot eine anfängliche Leichtigkeit der Entwicklung, wurde aber schnell unhandlich, da mehr Websites mit ähnlichen Funktionen hinzugefügt wurden. Das Repo wuchs auf rund zehn Standorte und bildete einen Wartungsalptraum. Das Suchen und Austausch von Saiten über mehrere Websites hinweg erwies sich als unglaublich ineffizient.

Stufe 2: Die Multi-Repository-Herausforderung

Um die Skalierbarkeitsprobleme anzugehen, wurde die Anwendung in unabhängige PHP -Pakete, die vom Komponisten verwaltet wurden, umgestaltet. Dies erforderte eine Verschiebung zu einer Mehrwertstruktur, einem Repository pro Paket. Bei der Förderung der Wiederverwendbarkeit von Code und einer besseren Architektur wurde das Management von über 200 Repositorys äußerst belastend. Die Versioning -Abhängigkeiten und die Koordinierung von Pull -Anfragen in zahlreichen Repositorys erwiesen sich als unglaublich komplex. Das Fehlen eines zentralisierten Managementsystems behinderte die effiziente Entwicklung.

Stufe 3: die Monorepo -Effizienz

Die Lösung war ein Monorepo - ein einzelnes Repository -Hosting aller Pakete. Diese optimierte Versionskontrolle ermöglicht gleichzeitige Veröffentlichungen und vereinfachte Pull -Anfragen. Da Packagistin jedoch einzelne Repositories für das Veröffentlichung von Paketen verlangt, wurde ein zweigleisiger Ansatz verfolgt: das Monorepo für die Entwicklung und separate Repositories für die Verteilung. Dies erforderte einen Prozess, um den Monorepo mit dem Monorepo Builder -Tool zu "teilen". Diese Stufe verbesserte die Entwicklungsgeschwindigkeit insbesondere während des Refactorings erheblich. Die Möglichkeit, mehrere WordPress -Plugins gleichzeitig über angepasste GitHub -Aktionen zu veröffentlichen, verbesserte die Effizienz weiter.

Trotz seiner Vorteile präsentierte der Monorepo Einschränkungen: Durchsetzung einer einzigen Lizenz in allen Paketen, Verwaltung eines großen Ausgabes und der unabhängigen Versionierung von Paketen auch ohne Codeänderungen.

Stufe 4: Die Multi-Monorepo-Lösung

Die Notwendigkeit, sowohl den öffentlichen als auch den privaten Code zu verwalten, führte zur Einführung einer Multi-Monorepo-Architektur. Ein öffentliches Monorepo (Leoloso/Pop) dient als Upstream-Repository, während ein privates Monorepo (Leoloso/GraphQlapi-Pro) als nachgelagertes Repository fungiert und das öffentliche Monorepo als GIT-Submodul enthält. Auf diese Weise kann das private Repository auf die öffentliche Codebasis zugreifen und sie erweitern, wodurch die Erzeugung sowohl öffentlicher als auch privater Plugin -Versionen mithilfe eines einzelnen angepassten Workflows ermöglicht wird.

Dieser Ansatz führt jedoch Komplexitäten ein. Das nachgelagerte Repository muss explizit Submodules auschecken, um eine sorgfältige Verwaltung von Workflows zu erfordern und möglicherweise Änderungen im vorgelagerten Repository zu brechen. Dies erfordert eine sorgfältige Überprüfung und Kommunikation, um unbeabsichtigte Konsequenzen zu verhindern.

Schlussfolgerung: Eine fortlaufende Reise

Die Entwicklung der Repository -Struktur dieses Projekts unterstreicht die Bedeutung der Anpassung an sich ändernde Bedürfnisse. Jede Phase bot Vor- und Nachteile, was letztendlich zu einem Multi-Monorepo-Setup führte, das derzeit den Anforderungen des Projekts entspricht. Zukünftige Bedürfnisse können jedoch weitere Iterationen in der Strategie des Repository -Managements erfordern. Der "beste" Ansatz bleibt kontextabhängig und betont den iterativen Charakter der Softwareentwicklung und des Repository-Managements.

Das obige ist der detaillierte Inhalt vonVon einem einzigen Repo über Multi-Repos über Monorepo bis hin zu Multi-Monorepo. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!