Quindi sto sviluppando un flusso di lavoro con vagabondo + git ... ha senso?

Il tuo piano sembra fantastico! Penso che tu stia andando davvero bene.

Il mio unico consiglio riguarda il flusso di lavoro degli sviluppatori. Penso che il tuo dev branch possa diventare problematico, perché gli sviluppatori uniranno il codice willy-nilly quindi loro pensano che sia pronto.

Se entrambe le branchA e branchB, C e D sono unite in dev , e fallisce, non puoi essere certo delle parti che stanno necessariamente fallendo. Inoltre, se qualcuno spinge qualcosa con un conflitto, non sai chi fosse. La follia e la pazzia sono inevitabili.

Se una funzione risulta non essere pronta e il codice deve essere escluso da dev , altri sviluppatori avranno già abbattuto le loro aggiunte. Questi sviluppatori si fonderanno nuovamente in dev , reintroducendo involontariamente il codice danneggiato. La follia e la pazzia sono inevitabili.

Avrai bisogno di un paio di passaggi di separazione per mantenere il codice non testato lontano dal codice testato.

Tutto dipende dai set di abilità del tuo team e da come lavori effettivamente insieme. Quello che segue è la mia soluzione ai problemi di un gruppo in rapida espansione con diversi livelli di conoscenza git e diversi livelli di affidabilità del codice degli sviluppatori.

Cerco sempre di dire alle persone di non pensare semplicemente al flusso di lavoro degli sviluppatori, ma alla procedura di test e al processo di rilascio. Tutti devono essere pianificati come parte di un processo singolare.

1. Lead Dev o Release Mngr (chiunque) crea un nuovo ramo release basato su master . Questo ramo sarà un contenitore per tutto ciò che accade nella prossima versione.
2. Lead / ReleaseMngr crea integration branch basato sul rilascio.
3. Lo sviluppatore crea un nuovo ramo di funzionalità (o ramo di argomento, qualunque cosa tu voglia chiamarlo), basato sul ramo di rilascio corrente.
4. Gli sviluppatori eseguono test localmente, sono contenti.
5. Gli sviluppatori dispongono di un ramo distribuito da qualche parte e testato dal QA indipendentemente di qualsiasi codice non testato.
6. Il QA accetta la funzione: viene unito a un ramo integration . (idealmente, IMHO, solo dopo che il ramo della funzione è stato ribaltato su release , per forzare le risoluzioni di conflitto)
7. Il QA verifica il ramo integration che è solo il ramo release + questa unica caratteristica.
8. Il QA funziona - l'integrazione si fonde con il rilascio (se non è disattivata, l'integrazione viene spazzata via e ricreata sulla base di release ). Questo è il motivo per integration . Nessuno tira da questo ramo e può essere spazzato via se necessario.
9. Ora la funzione è in versione e può essere condivisa con altri sviluppatori rendendo le funzionalità basate su release branch.
10. Il rilascio è buono, si fondono per padroneggiare. Distribuisci, crea un nuovo ramo di rilascio basato su master.

So che sembra molto, ma in realtà ti salverà dai mal di testa e, secondo la mia esperienza, sono inevitabili con grandi progetti con log di persone con diversi livelli di conoscenza.

Se hai una piccola squadra con un semplice processo di rilascio, o una squadra che ha molta esperienza - tutto questo potrebbe non essere necessario - ma sii consapevole del problema inerente con il test del codice di più persone contemporaneamente nella tua dev branch.

Tutto ciò che ho detto, è a mio avviso che il team di GitHub consente a tutti di unirsi direttamente al master (dopo una breve revisione del codice) e di distribuire automaticamente ~ 30 volte al giorno.

Lo schema generale suona bene. L'unica cosa che cambierei è che gli stessi box di base dovrebbero essere autoaggiornanti. Presumibilmente anche gli script di provisioning vivono in git così da poter aggiornare automaticamente le caselle con uno script di /etc/rc.local correttamente configurato. La base box dovrebbe avere solo il minimo necessario per iniziare e quindi scaricare tutti i pezzi necessari per la configurazione. In questo modo si disaccoppia la distribuzione delle scatole dal processo di aggiornamento effettivo e non è necessario spedire un'intera nuova base box ogni volta che si apportano modifiche, eccetto ovviamente gli aggiornamenti del sistema operativo.