Migrazione da SVN a Git. Più progetti dipendenti per l'integrazione continua

Naviga le tue risposte
0

Sono incaricato di cambiare la nostra base di codice di 10 anni da SVN a Git. Attualmente disponiamo di un unico repository monolitico contenente tutti i nostri progetti. Abbiamo condiviso librerie e progetti multipli usando dette librairie.

Ho cercato un modo per ospitare tutti i nostri progetti in repository separati. Ho esaminato sia i sottomoduli che i sottoalberi per la soluzione, ma non so quale scegliere a partire da ora. Una delle nostre core librairie è il nostro framework di database (vecchio e casalingo) che deve essere sempre aggiornato in ogni progetto che lo utilizza poiché tutte le nostre applicazioni funzionano con un database single-central.

A partire da ora, i rilasci sono tutti eseguiti manualmente dall'amministratore del repository. L'obiettivo è, in ultima analisi, quello di configurare il nostro server TFS in modo da avere un CI e accelerare il processo di distribuzione delle nostre applicazioni. Ecco un esempio di quello che sarebbe lo scenario migliore (penso). Ma prima, solo una breve lista di come appaiono le deprezze del progetto:

WebProject-A utilizza FrameworkLibrary-B
FrameworkLibrary-B
WebProject-C utilizza FrameworkLibrary-B
WindowsService-D utilizza FrameworkLibrary-B

Sto lavorando per aggiungere nuove funzionalità a WebProject-A. Queste funzionalità richiedono alcune nuove modifiche al modello dati, forse una nuova tabella o una nuova colonna. Ciò significa che ho bisogno di apportare modifiche a FrameworkLibrary-B. Ora anche WebProject-C e WindowsService-D sono collegati a FrameworkLibrary-B. Ciò significa che, al momento del check-in per FrameworkLibrary-B, ho bisogno di costruire A, B, C e D e distribuire A, C e D. Durante il check-in per il progetto A, ho bisogno di costruire A e B e distribuire A.

Molti dei nostri sviluppatori hanno poca esperienza con il controllo del codice sorgente (svn update, svn commit). L'obiettivo sarebbe quello di avere qualcosa di potente per la gestione dei sottoprogetti e, comunque, qualcosa che non spaventerà gli sviluppatori di Git. Avete qualche raccomandazione su quale sarebbe la soluzione migliore per la gestione del repository Git in questa istanza.

    
posta jutrec 12.12.2016 - 20:05
fonte

2 risposte

0
  1. "... qualcosa che non spaventerà gli sviluppatori di Git ..." potrebbe esistere, ma - piangerai comunque
  2. La gestione delle dipendenze non è compito di alcun SCM, devi trovare e selezionare il tuo strumento speciale (da molti) e successivamente usare Git in modalità compatibile con lo strumento
  3. I sottotitoli sono in senso buono rispetto ai sottomoduli, almeno in termini di tempo sprecato: per i sottomoduli che devi adottare per Git senza sottomoduli e Git con sottomoduli due diversi flussi di lavoro, per i sottoalberi puoi un solo comune flusso di lavoro per entrambi i casi d'uso (con + senza)
risposta data 12.12.2016 - 21:16
fonte
0

Sono d'accordo sulla creazione di un repository git per ciascun progetto, servizio e libreria separatamente.

Ma invece di usare git submodules o subtrees, hai bisogno di uno strumento di gestione dei pacchetti per gestire le dipendenze.

Ce ne sono alcuni disponibili su Internet. Puoi iniziare a cercare quello che si adatta al linguaggio utilizzato nella tua azienda.

Qui puoi trovare un elenco di strumenti comuni . In generale hanno una buona compatibilità con i sistemi CI.

Inoltre puoi configurare i trigger per ricostruire o ridistribuire i progetti non appena la loro libreria viene aggiornata, con git-hooks o altre azioni di attivazione della CI.

es. quando viene unita la nuova versione della Libreria C, viene generato un evento di trigger per ricostruire se stesso, quindi ricostruire e distribuire il servizio A, C e D.

    
risposta data 12.12.2016 - 22:01
fonte

Leggi altre domande sui tag

Se il modello lato client contiene chiavi esterne per estrarre i dati già sul client Cambiamenti tra repository e nomi di filiali - Best Practice