Flusso di lavoro GIT per lo sviluppo web

Molto tempo fa il piccolo team di sviluppatori web con cui lavoro ha iniziato a utilizzare git per lo sviluppo web. Allora ci siamo semplicemente impegnati nella messa in scena o nel master direttamente e poi ci siamo fusi frequentemente tra i due. Era meglio di niente, ma era anche un disastro.

Non molto tempo fa abbiamo adottato il flusso di lavoro di gitflow. Mentre è certamente migliore del caos che è venuto prima sembra un po 'ingombrante e eccessivamente orientato al rilascio / pietra miliare. I miei colleghi sviluppatori mi chiedono spesso di chiarire come dovrebbe funzionare e cosa dovrebbe fondersi e non dovrebbe. In generale sembra inadatto per il lavoro di sviluppo web in cui stiamo implementando il codice frequentemente e senza tenere traccia delle pietre miliari specifiche per il rilascio.

Su un recente suggerimento di amici ho iniziato a guardare GitHub Flow . Leggere il post di Scott Chacon qui colpisce perfettamente il punto dolente di questo:

Quindi, perché non usiamo git-flow su GitHub? Bene, il problema principale è che implementiamo continuamente. Il processo git-flow è progettato in gran parte attorno al "rilascio". Non abbiamo davvero "rilasci" perché implementiamo nella produzione ogni giorno, spesso più volte al giorno.

FWIW, ho anche visto questa bella carrellata di flussi di lavoro sul sito di Atlassian: https://www.atlassian.com/git/workflows#!workflow-feature-branch

Tuttavia, TUTTI sembrano scelte sbagliate per lo sviluppo web in un piccolo team e ancora una volta orientati verso le versioni principali di applicazioni non frequenti / giornaliere.

Questa è una domanda su SE che chiede di confrontare git-flow con github-flow /programming/18188492/what-are-the-pros-and-cons-of-git-flow-vs-github -flusso

Questa è una buona risposta in generale, ma come ho detto nel mio commento qui sotto meta.programmers.SE sembra indicare che le domande sulle migliori pratiche generali del flusso di lavoro appartengono qui e speravo in un elenco più ampio di possibili risposte oltre a git-flow e github -flow, pur essendo specifico per lo sviluppo web. Quindi penso che meriti una nuova domanda qui.

Con ciò, quale trova il flusso di lavoro basato su git migliore / preferito per un piccolo team di sviluppo web che lavora su progetti con una distribuzione abbastanza continua? È github-flow o qualcos'altro?

Per prima cosa vorrei fare un piccolo riassunto dei diversi flussi di lavoro che hai esaminato e pensi che non siano adatti al tipo di sviluppo a cui stai lavorando:

• Centralizzato ( sorgente ): praticamente come il flusso di lavoro SVN ma ora su un ambiente distribuito. Ogni sviluppatore lavora su una copia personale di mastere invia le modifiche origin/masterdirettamente o tramite richiesta pull.

• Ramo delle caratteristiche ( Fonte ): Bene, quello. Ogni sviluppatore che lavora su una particolare funzionalità dovrebbe lavorare su un ramo specifico dedicato solo a quella funzione. Questo ramo di funzionalità deve essere creato da mastero da un altro ramo di funzionalità. Alla fine tutto viene ricongiunto master.

• Gitflow ( sorgente ): due rami principali tengono traccia della cronologia di un progetto develope master. Altre 3 rami chiamati hotfix, releasee featurecambiamenti hold fatte direttamente masterper fissare bug critici di produzione, il numero di versione di modifica e altri dettagli prima di un rilascio o lavorare su una particolare funzione come ramo Caratteristica , rispettivamente.

• GitHub flow ( Fonte ): gli sviluppatori creano un featureramo di master. Le modifiche vengono inviate tramite richiesta pull. Le modifiche accettate master vengono implementate immediatamente dal bot Hubot GitHub.

Per la parte relativa allo sviluppo della tua domanda, la risposta dipende dallo sfondo del tuo team. Provengono da un ambiente SVN? Quindi dovresti seguire l'approccio centralizzato poiché è quello che assomiglia maggiormente a SVN. Si sentono a proprio agio nel lavorare con Git? Quindi forse non dovresti cercare di adattare il flusso di lavoro del tuo team a nessuno di questi, ma implementare il tuo, creato per soddisfare le tue esigenze che, se ho capito bene, sono flessibilità di sviluppo e implementazione rapida.

Penso anche che dovresti concentrarti sul miglioramento di quest'ultimo. Come è composta la pipeline di distribuzione ? In " Consegna continua: rilasci di software affidabili tramite automazione di build, test e distribuzione " gli autori identificano le possibili cause di distribuzioni non frequenti, alcune delle quali sono:

• Il processo di distribuzione non è automatizzato.
• Il test richiede molto tempo.
• Le persone non comprendono il processo di compilazione / test / distribuzione.
• Gli sviluppatori non sono disciplinati sul mantenimento dell'applicazione dell'applicazione apportando piccole modifiche incrementali e interrompendo così frequentemente la funzionalità esistente

Qualcuno di quelli suona come qualcosa che potresti migliorare? Forse potresti dirci qualcosa in più su come tu e il tuo team gestite questa parte del progetto.