Git workflow per Microsoft SQL Stack

Question

Git workflow per Microsoft SQL Stack

#1 da (2 voti)

3

Il mio team di sviluppatori sta attualmente lavorando presso un cliente che ci ha richiesto di allontanarci da SVN e iniziare a utilizzare il loro programma di flusso di lavoro nativo. (Albero delle origini di Atlassian). Siamo sviluppatori di data warehouse e utilizziamo principalmente lo stack Microsoft SQL per lo sviluppo.
Lo stack è comunemente:

SQL Server Analysis Services (SSAS)
SQL Server Integration Services (SSIS)
SQL Server Management Studio (SSMS)

Utilizziamo anche uno strumento di visualizzazione dei dati denominato Tableau Server.

Al cliente questi strumenti sono usati per sviluppare simultaneamente in quattro aree tematiche, allo scopo di chiamarli Aree tematiche; W, X, Y e Z.

Ogni area tematica riceve le proprie soluzioni in tutti e tre i programmi SS e alcuni file associati a tableau.

Dal passaggio a sourcetree abbiamo avuto un flusso di lavoro di un ramo principale che riflette il lavoro che verrà migrato all'ambiente di produzione. Oltre a un ramo di sviluppo su cui tutti gli sviluppatori si impegnano frequentemente.

Dopo che un grosso bug è stato rilevato in una delle nostre aree tematiche, era necessario tornare all'ultima buona commit per l'ambiente di produzione. Questo era quasi impossibile a causa dell'elevato numero di commit e di fusioni e del nostro gitflow disorganizzato.

Questo mi porta alla domanda:
Qual è il modo ideale per gestire in effetti lo sviluppo di quattro aree tematiche attraverso quattro programmi contemporaneamente usando github?
Dalla mia lettura sembrerebbe che 18 rami (4 sottotitoli x 4 programmi + Master + Dev) siano una soluzione, ma questo sembra essere eccessivo.

Punti da notare:

Tutte le aree tematiche sono sviluppate contemporaneamente.
I programmi (SSMS / SSIS) sono sviluppati da più sviluppatori contemporaneamente in diverse aree tematiche.
Abbiamo cambiato il nostro ramo principale in modo da essere l'unico riflesso del nostro ambiente di produzione senza ulteriori commit.
Abbiamo accesso solo a un singolo repository.
Alcuni lavori su alcuni programmi (SSIS per Subject X) sono sviluppati ma mai uniti alla produzione. Tuttavia, questo lavoro deve essere mantenuto.

Poiché si tratta di una domanda soggettiva, qualsiasi opinione o ulteriore chiarimento è accolta favorevolmente.

git github sql-server

posta Michael Betterton 18.01.2015 - 11:32

fonte

1 risposta

Leggi altre domande sui tag git github sql-server

S3 image urls nel database Perché non tutti i metodi di controllo dell'interfaccia utente RunOnUIThread

score 2 · Accepted Answer

Riepilogo : Vanilla Git Flow è abbastanza sano. Per il codice che esiste l'uno accanto all'altro, utilizzare le directory anziché i rami. I rami delle caratteristiche dovrebbero avere vita breve e non introdurre ulteriori rami develop per ogni programma e soggetto.

Per progetti di una certa dimensione - e il tuo progetto è ben oltre quel punto -, il " Git Flow "descrive le best practice per la gestione delle filiali Git. Il ramo centrale è il ramo develop , che viene utilizzato per l'integrazione delle funzionalità. Se esegui test di integrazione continui, questo è il ramo da testare. Il ramo master è sempre in uno stato pronto per la produzione e elenca solo le versioni precedenti.

Per inciso: il ramo master pronto per la produzione non implica che il contenuto del ramo master sarà letteralmente distribuito in produzione. Sebbene a volte sia usato come uno, Git non è un sistema di distribuzione. Invece, il ramo master descrive gli stati del progetto che possono essere utilizzati per creare il deliverable effettivo. Questo processo di build (auspicabilmente automatizzato) può quindi ignorare soggetti, programmi o qualsiasi altro file che non è necessario per quella build.

Ora ci sono un paio di flussi di lavoro che compongono Git Flow:

Rilascio : quando vogliamo rilasciare, creiamo un ramo temporaneo da develop ed eseguiamo test di rilascio. Qualsiasi lavoro associato al rilascio (come correzioni minori o il bumping della versione) può essere eseguito su questo ramo. Una volta che tutto funziona, questo ramo viene unito in master e develop , e il commit di unione su master viene contrassegnato con il numero di versione. Quindi master rappresenta la versione corrente, master^ la versione precedente e così via.
Sviluppo : lo sviluppo avviene su rami di caratteristiche relativamente di breve durata. Questi sono biforcati di develop . Una volta completati, vengono uniti in develop . Se questi rami sono longevi, è una buona idea ribasare regolarmente il ramo della caratteristica su develop per evitare conflitti di fusione di grandi dimensioni. Inoltre, mantenere le funzionalità di piccole dimensioni è una buona strategia per rendere più piacevole l'unione.
Hotfix : non sono rilevanti qui.

Questo è al di fuori del campo di applicazione di Git Flow, ma può avere senso suddividere ulteriormente i rami di funzionalità, per grandi funzionalità che richiedono la collaborazione immediata di più persone (questo non è l'impostazione predefinita!). Il sottogruppo che lavora su questa funzione potrebbe trattare il ramo della funzione come se fosse un ramo di sviluppo locale e unire le proprie caratteristiche secondarie in questo ramo usando il normale flusso di lavoro di sviluppo. Una volta che la funzione è pronta, verrà unita al ramo develop principale. Tuttavia, questa suddivisione presenta alcuni pericoli: è probabile che il ramo della caratteristica e il develop principale si allontanino nel tempo. Questo può essere neutralizzato facendo in modo che uno sviluppatore di collegamento unisca regolarmente il develop principale nel ramo della funzione (che funge da sottogruppo% sub-team develop ). Ma quando questa mega-funzionalità viene unita al progetto principale, l'impatto per tutti gli altri sarà sostanziale e interromperà lo sviluppo regolare. Pertanto, tale eccessiva complicazione dovrebbe essere utilizzata solo come ultima risorsa. È preferibile avere molti piccoli rami di funzionalità.

Se proviamo a seguire Git Flow, non è consigliabile avere 4 soggetti × 4 programmi = 16 sviluppare rami. Molto probabilmente tutto ciò non dovrebbe essere nello stesso repository, ma se è necessario, basta usare diverse directory all'interno del repository. Non è necessario un ramo separato per ogni argomento (cioè soggetto, programma). Git Flow utilizza le filiali per tenere traccia di più thread di sviluppo (nel caso di branch di funzionalità) o per indicare lo stato del codice (nel caso di develop e master ).

Per analogia: sto memorizzando un blog su cani e gatti in un repository Git. Non ho due rami di lunga durata cat e dog in cui scrivo tutti i post su cani e gatti, rispettivamente. Invece, creerei un nuovo branch di funzionalità per ogni post, ma tutti i post relativi ai gatti sono mantenuti nella directory cat/ . Una volta completato il post, può essere unito nuovamente al ramo principale.