Condivisione di parti di un monorepo

Al momento disponiamo di un sistema di compilazione complesso e inefficiente costituito da numerosi repository SVN e Git (circa il 50% ciascuno), incluso uno che è un repository di sottomoduli git. Abbiamo anche script fatti in casa che gestiscono più o meno bene il tutto.
Un punto importante della nostra base di codice (chiusa) è che è strettamente accoppiata e ogni progetto viene rilasciato contemporaneamente con la stessa versione.

Vogliamo migrare questo su un sistema più semplice e un singolo VCS e stiamo prendendo in considerazione diverse opzioni, tra cui: sottomoduli git, google Repo e monorepos. Il VCS finale non è ancora definito (tranne per le opzioni che lo obbligano), e potrebbe essere svn, git o anche qualcos'altro se ciò si adatta meglio alla nostra situazione.

Stiamo cercando di elencare i vantaggi e gli svantaggi di ciascuna soluzione e uno dei maggiori problemi che attualmente abbiamo con i monorepos è che non sembra facile o addirittura possibile condividere solo alcuni moduli con un'entità esterna. Vogliamo che queste persone possano effettuare il checkout e lavorare normalmente su quei moduli, ma non essere in grado di accedere al codice o alla cronologia del resto del repository. Non è qualcosa che facciamo spesso o ampiamente al momento, ma potremmo in futuro, e non vogliamo che questo diventi un incubo perché abbiamo preso una decisione sbagliata qui.

Esiste un tale sistema di gestione dei privilegi in un sistema VCS?
O c'è un modo per mitigare questo problema?

Dalla tua descrizione, penso che tu abbia un paio di opzioni qui:

1. Usa i sottomoduli git: con un servizio come GitHub (o qualsiasi altra cosa), puoi gestire le autorizzazioni per progetto e disaccoppiare il processo di distribuzione. Tuttavia, ho sentito che i sottomoduli git finiscono per essere un enorme dolore nel tempo. Gli script automatizzati per reinizializzare / scaricare nuovamente i sottomoduli git in modo chiaro potrebbero essere utili qui.
2. Suddividi il tuo repository in servizi indipendenti. Ciò consente di svilupparsi contemporaneamente, ma introduce anche una grande quantità di dolore poiché è necessario iniziare a pensare alla scoperta di servizi, alla distribuzione di più servizi, agli ambienti di sviluppo, all'integrazione / distribuzione continua e a tutte le altre piccole gioie che derivano dalla gestione di un architettura di microservizi.
3. Utilizzare un sistema di gestione dei pacchetti formale come pip per Python, npm per Node.js, Maven per Java, ecc. Distribuire le parti di codice necessarie nel repository e consumarle nel repository principale, se necessario, che dovrebbero offrire le funzionalità alla versione loro. A seconda dell'accoppiamento tra i moduli e il repository principale, potrebbe non essere possibile estrarre, eseguire o testare i moduli di livello inferiore in modo indipendente. Se è possibile , tuttavia, questo è un buon modo per andare bene che si gelifica con più repository pur essendo in grado di integrare i pacchetti in fase di costruzione installandoli da un repository remoto.

Sfortunatamente nessuna di queste opzioni è perfetta, ma sono tutte valide a seconda dello stato della tua base di codice. La tua descrizione sembra che l'opzione 3 potrebbe funzionare meglio qui.