Condivisione di parti di un monorepo

Question

Condivisione di parti di un monorepo

#1 da (3 voti)

11

Al momento disponiamo di un sistema di build complesso e inefficiente costituito da molti repository SVN e Git (circa il 50% ciascuno), incluso uno che è un repo dei sottomoduli git. Abbiamo anche script fatti in casa che gestiscono più o meno bene l'intera cosa.
Un punto importante del nostro codebase (a codice chiuso) è che è strettamente accoppiato, e ogni progetto viene rilasciato contemporaneamente con la stessa versione.

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

Stiamo cercando di elencare il più e il meno di ogni soluzione e uno dei maggiori problemi che abbiamo attualmente con monorepos è che non sembra facile, o addirittura possibile condividere solo alcuni moduli con un'entità esterna. Vogliamo che queste persone siano in grado di effettuare il checkout e lavorare normalmente su quei moduli, ma non di poter accedere al codice o alla cronologia del resto del repository. Non è qualcosa che facciamo spesso o estensivamente al momento, ma potremmo farlo 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 esiste un modo per mitigare questo problema?

version-control migration

posta Leherenn 22.02.2017 - 16:19

fonte

1 risposta

Leggi altre domande sui tag version-control migration

Come pubblicare app Android a pagamento se non provieni da Stati Uniti / Regno Unito Memorizzazione di password per l'utilizzo negli script

score 3 · Answer 1

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

Utilizza 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 automatici per reinizializzare / scaricare di nuovo correttamente i tuoi sottomoduli git potrebbero aiutarti qui.
Rompere il repository in servizi indipendenti. Ciò consente di sviluppare contemporaneamente, ma introduce anche una grande quantità di dolore, come è necessario iniziare a pensare alla scoperta dei servizi, all'implementazione di più servizi, agli ambienti di sviluppo, all'integrazione / distribuzione continua e a tutte le altre piccole gioie derivanti dalla gestione di un architettura microservice.
Utilizzare un sistema di gestione dei pacchetti formale come pip per Python, npm per Node.js, Maven per Java, ecc. Distribuire i pezzi di codice necessari nel repository e consumarli nel repository principale secondo necessità, il che dovrebbe dare tu la possibilità di metterli in versione. A seconda dell'accoppiamento tra i moduli e il repository principale, potrebbe non essere possibile estrarre, eseguire o testare in modo indipendente i moduli di livello inferiore. Se puoi , tuttavia, questo è un buon modo per far funzionare bene quel gel con più repository pur essendo in grado di integrare i tuoi pacchetti in fase di compilazione installandoli da un repository remoto.

Sfortunatamente nessuna di queste opzioni è perfetta, ma sono tutte valide in base allo stato della base di codice. La tua descrizione sembra che l'opzione 3 funzioni meglio qui.