Flusso di lavoro GIT per lo sviluppo web

Question

Flusso di lavoro GIT per lo sviluppo web

#1 da (7 voti)

12

Molto tempo fa il piccolo team di sviluppatori web con cui ho iniziato ha iniziato a utilizzare git per lo sviluppo web. A quel tempo, ci siamo limitati a mettere in scena o master direttamente e quindi a unirli frequentemente tra i due. Era meglio di niente, ma era anche un casino.

Non molto tempo fa abbiamo adottato il flusso di lavoro gitflow. Mentre è sicuramente meglio del caos che è venuto prima, sembra piuttosto complicato ed eccessivamente orientato verso il rilascio / la pietra miliare. I miei colleghi sviluppatori mi chiedono spesso di chiarire come dovrebbe funzionare e cosa dovrebbe fondere e non dovrebbe. In generale, non sembra adatto per il lavoro di sviluppo web in cui stiamo implementando il codice frequentemente e senza tenere traccia di specifici traguardi per il rilascio.

Su un suggerimento recente di amici ho iniziato a consultare GitHub Flow . Leggendo il post di Scott Chacon qui raggiunge perfettamente il punto dolente con questo:

So, why don’t we use git-flow at GitHub? Well, the main issue is that we deploy all the time. The git-flow process is designed largely around the “release”. We don’t really have “releases” because we deploy to production every day – often several times a day.

FWIW, ho anche preso in considerazione questa bella carrellata di flussi di lavoro sul sito di Atlassian: link

Tuttavia sembrano TUTTE le scelte sbagliate per lo sviluppo web in un piccolo team e nuovamente orientate verso le principali versioni di applicazioni non frequenti / rilasci giornalieri.

Questa è una domanda su SE che chiede di confrontare git-flow con github-flow link

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

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

git web-development gitflow

posta jb510 15.08.2014 - 04:26

fonte

1 risposta

Leggi altre domande sui tag git web-development gitflow

Richiami diversi per errore o errore come primo argomento? Trova le nuove coordinate usando un punto di partenza, una distanza e un angolo

score 7 · Accepted Answer

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

Centralizzato ( Source ): Piuttosto simile a Flusso di lavoro SVN ma ora su un ambiente distribuito. Ogni sviluppatore lavora su una copia personale di master e invia le modifiche a origin/master direttamente o tramite richiesta pull.
Ramo di funzionalità ( Origine ): Bene, quello. Ogni sviluppatore che lavora su una particolare funzione dovrebbe lavorare su un ramo specifico dedicato solo a quella funzione. Questo ramo di funzionalità deve essere creato da master o da un altro ramo di funzione. Alla fine, tutto viene unito a master .
Gitflow ( Origine ): due rami principali traccia una cronologia del progetto, develop e master . Altri 3 rami chiamati hotfix , release e feature conservano le modifiche apportate direttamente a master per correggere bug di produzione critici, modificare il numero di versione e altri dettagli prima di un rilascio o lavorare su una particolare funzione come Ramo di funzionalità , rispettivamente.
Flusso GitHub ( Origine ): sviluppatori crea un ramo feature su master . Le modifiche vengono inviate tramite richiesta pull. Le modifiche accettate in master vengono distribuite immediatamente dal bot GitHub Hubot.

Per la parte di sviluppo della tua domanda, la risposta dipende dallo sfondo della tua squadra. Vengono da un ambiente SVN? Quindi dovresti seguire l'approccio centralizzato poiché è quello che somiglia di più a SVN. Si sentono a proprio agio lavorando con Git? Allora forse non dovresti provare ad 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. In che modo è composta la pipeline di distribuzione ? In " Consegna continua: rilasci di software affidabili attraverso l'automazione di generazione, test e distribuzione " gli autori identificano le possibili cause di raro distribuzioni, alcune delle quali sono:

Il processo di distribuzione non è automatizzato.
Il test richiede molto tempo.
Le persone non capiscono il processo build / test / deploy.
Gli sviluppatori non sono disciplinati dal mantenere l'applicazione funzionante apportando piccole modifiche incrementali e interrompendo così frequentemente funzionalità esistenti

Qualcuno di questi sembra qualcosa che potresti migliorare? Forse potresti dirci un po 'di più su come tu e il tuo team gestite questa parte del progetto.