Teile einer Monorepo teilen

Wir haben derzeit ein komplexes und ineffizientes Build-System, das aus vielen SVN- und Git-Repos (jeweils ca. 50%) besteht, darunter eines, das ein Git-Submodul-Repo ist. Wir haben auch selbstgemachte Skripte, die das Ganze mehr oder weniger gut verwalten.
Ein wesentlicher Punkt unserer (Closed-Source-) Codebasis ist, dass sie eng gekoppelt ist und jedes Projekt zur gleichen Zeit unter derselben Version veröffentlicht wird.

Wir möchten dies auf ein einfacheres System und ein einzelnes VCS migrieren und erwägen verschiedene Optionen, einschließlich: Git-Submodule, Google Repo und Monorepos. Das endgültige VCS ist noch nicht definiert (mit Ausnahme der Optionen, die es erfordern) und könnte svn, git oder sogar etwas anderes sein, wenn dies besser zu unserer Situation passt.

Wir versuchen, das Plus und Minus jeder Lösung aufzulisten, und eines der Hauptprobleme bei Monorepos ist, dass es nicht einfach erscheint oder sogar möglich ist, nur einige Module für eine externe Entität freizugeben. Wir möchten, dass diese Leute in der Lage sind, diese Module zu überprüfen und normal zu bearbeiten, aber nicht auf den Code oder den Verlauf des restlichen Repos zugreifen können. Es ist nicht etwas, was wir im Moment oft oder ausgiebig tun, aber wir könnten es in Zukunft tun, und wir wollen nicht, dass dies ein Albtraum wird, weil wir hier eine schlechte Entscheidung getroffen haben.

Existiert ein solches Berechtigungsverwaltungssystem in einem VCS-System?
Oder gibt es eine Möglichkeit, dieses Problem zu beheben?

Nach Ihrer Beschreibung haben Sie hier einige Möglichkeiten:

1. Verwenden Sie Git-Submodule - mit einem Dienst wie GitHub (oder etwas anderem) können Sie Berechtigungen pro Projekt verwalten und Ihren Bereitstellungsprozess entkoppeln. Ich habe jedoch gehört, dass Git-Submodule im Laufe der Zeit große Schmerzen bereiten. Automatisierte Skripte zum sauberen Reinitialisieren / erneuten Herunterladen Ihrer Git-Submodule könnten hier Abhilfe schaffen.
2. Teilen Sie Ihr Repo in unabhängige Services auf. Auf diese Weise können Sie sich gleichzeitig weiterentwickeln, verursachen jedoch auch erhebliche Probleme, wenn Sie sich Gedanken über die Serviceerkennung, die Bereitstellung mehrerer Services, Entwicklungsumgebungen, die kontinuierliche Integration / Bereitstellung und all die anderen kleinen Freuden machen müssen, die sich aus der Verwaltung von a ergeben Microservice-Architektur.
3. Verwenden Sie ein formales Paketverwaltungssystem wie pip für Python, npm für Node.js, Maven für Java usw. Stellen Sie die benötigten Codeteile im Repository bereit und verwenden Sie sie gegebenenfalls in Ihrem Haupt-Repository, um die erforderlichen Funktionen zu erhalten um sie zu versionieren. Abhängig von der Kopplung zwischen Ihren Modulen und Ihrem Haupt-Repository können Sie die untergeordneten Module möglicherweise nicht unabhängig voneinander extrahieren, ausführen oder testen. Wenn Sie dies jedoch können , ist dies ein guter Weg, um mehrere Repositorys zu verwalten und gleichzeitig Ihre Pakete zum Zeitpunkt der Erstellung zu integrieren, indem Sie sie von einem Remote-Repository aus installieren.

Leider ist keine dieser Optionen perfekt, aber sie sind alle gültig, abhängig vom Status Ihrer Codebasis. Ihre Beschreibung hört sich so an, als würde Option 3 hier am besten funktionieren.