Come gestire più progetti in un Git Monorepo

1

Sto pensando di mettere alcuni file in un repository git più grande ma ho la sensazione che git non sarà adatto.

Questo è ciò che inserirò nel repository:

  1. Vari script sui server.
  2. Alcuni progetti più grandi in var / www.
  3. Alcuni progetti più grandi altrove.

Tutti questi programmi a un certo punto parlano tra loro e si chiamano a vicenda, per questo ho pensato che un monorepo sarebbe stata una buona idea.

Tuttavia alcuni possibili problemi:

  1. Come controllare determinate directory? Soprattutto su altri server.

Ad esempio, cosa succede se voglio dare un'occhiata a un singolo script su un altro server da git, non voglio avere probabilmente 500mb di codice seduto su quel server.

Se non git, c'è un altro controllo di versione che si adatta meglio alle mie esigenze?

Ho preso in considerazione di cambiare la nostra pipeline di sviluppo, ad esempio, il repository potrebbe vivere su un server di sviluppo e usiamo script rsync per inviare file da e verso altri server.

Quello che sto cercando sono le possibili soluzioni e l'esperienza delle persone con questo problema.

Per essere più precisi, il mio problema è che attualmente gestisco circa 20-30 repository minori e penso che saltare su questi repository non sia molto efficiente.

Il punto chiave è che abbiamo così tanti programmi su server diversi e molte cartelle all'interno di quei server, ma tutto questo codice è essenzialmente a parte un grande sistema.

    
posta Joseph 02.09.2016 - 10:10
fonte

2 risposte

3

Sei consapevole che puoi effettuare il checkout solo dell'ultima versione? link che rimuove almeno tutta la cronologia in modo da ottenere meno dispiegamento.

Quindi sui repository: se fanno tutti parte di una soluzione con una distribuzione, li raggrupperei in un unico repository.

Un'alternativa sarebbe creare un nuovo repository per soluzione. Quindi diciamo che hai librerie 1-30 (i tuoi repository attuali). Crei un nuovo repository per il servizio Web e per l'app per dispositivi mobili.

L'unica cosa che fanno i repos è solo tirare la soluzione insieme:

Servizio Web

  • Libreria 1
  • Libreria 2
  • Libreria 3

App per dispositivi mobili

  • Libreria 2
  • Libreria 3
  • Libreria 4
  • Libreria 5
  • Libreria 6

ecc. Quindi questi nuovi repository combinano tutte le cose per ottenere una versione completa. Pertanto, la pipeline di distribuzione (e ad esempio i test end-to-end) crea solo tali repository. Avrai bisogno di un posto centrale per testare e distribuire comunque la soluzione.

Ciò ti mantiene più flessibile e puoi essere sicuro che un set fisso di librerie su specifiche versioni venga distribuito. E impedisce che tu debba modificare tutte le librerie.

Se i repository non sono coerenti, potresti volerli strutturare un po 'per diventare più uguali nell'interfaccia. Ciò migliorerà ulteriormente il codice base. I microservizi fanno molto questo, hanno un modo generale di chiamarsi l'un l'altro in modo da non dover pensarci ogni volta in modo personalizzato.

    
risposta data 02.09.2016 - 10:40
fonte
1

Il problema qui sembra essere quello di confondere il tuo sistema per il rilascio del codice di produzione con il sistema per lo sviluppo di quel codice. Git è un ottimo strumento per uno sviluppatore o un sistema di build per afferrare tutta la fonte e iniziare a costruire e testare. Non è sempre lo strumento migliore per la distribuzione di quel codice una volta confermato che funziona.

Avere il proprio sistema di compilazione (automatico o manuale) crea i singoli prodotti che si desidera distribuire in qualsiasi modo sia il modo migliore per quella specifica implementazione. Ecco alcuni esempi:

  • Invia un singolo file al server di produzione tramite scp .
  • Invia un set di file a un punto di staging (ad esempio, un server Web, un'unità condivisa, un bucket Amazon S3) e chiedi al server di estrarli.
  • Creare un file tar dei file necessari e inviarlo a un server oa un punto di sosta; il server quindi li decomprime dopo averli ricevuti. (Se mantieni le versioni precedenti dei tarball questo può rendere i rollback facili.)
  • Costruisci un pacchetto per un sistema di packaging appropriato (pacchetto Python, Ruby Gem, pacchetto Debian, RPM) e distribuiscilo.
  • Crea un'immagine Docker che viene copiata sul server o su un repository centrale da cui i server la richiamano.
  • Alcuni server continuano a sfruttare l'intero repo, se utilizzano molti file e ciò è più semplice.
risposta data 20.04.2018 - 02:45
fonte

Leggi altre domande sui tag