Avere un ramo di produzione o utilizzare master?

Lavoro in un piccolo team con altri sviluppatori remoti su Railsun'applicazione. Stiamo iniziando a modificare il nostro gitflusso di lavoro. Abbiamo pensato a una struttura ramificata come di seguito:

(dev) -> (qa) -> (stag) -> (master)

Ma alcuni sviluppatori hanno pensato che potrebbe essere meno confuso per i nuovi sviluppatori che potrebbero spingere automaticamente alla produzione in master. Pensarono invece di far lavorare tutti i maestri e creare un ramo separato per la produzione.

(master) -> (qa) -> (stag) -> (prod)

Mi è stato insegnato che vuoi mantenere il master distribuibile e non usarlo come sviluppo e dai luoghi precedenti in cui ho lavorato master è sempre pensato per essere implementabile per la produzione.

Quali sarebbero alcuni degli svantaggi dell'utilizzo di una struttura di ramificazione in cui il master viene attivamente utilizzato per lo sviluppo e un ramo del prod separato è ciò che si utilizza per le distribuzioni?

Non ci sono né vantaggi né svantaggi di questo approccio. Il motivo per cui dico questo è semplice: per Git, non fa differenza se si sviluppa dal master o si rilascia dal master. Non è nemmeno necessario rilasciare rami; potresti invece contrassegnare un commit arbitrario e rilasciarlo, invece.

Il vero problema qui è di processo e procedura. Gli sviluppatori più anziani che sono preoccupati che farlo in un modo confondano gli sviluppatori più recenti devono essere pronti a investire il tempo per spiegare qual è il modello di rilascio e perché è così.

Finché tutti capiscono che il master è per lo sviluppo e qualche altro ramo arbitrario è per le versioni e il lavoro per mantenerlo è fatto , allora non ci dovrebbero essere problemi con questo approccio.

Vedo il tuo dilemma. Anch'io l'ho avuto, fino a quando non ho disimparato quello che ho sempre assunto sul maestro.

Mi è stato insegnato che vuoi mantenere il master distribuibile e non usarlo come sviluppo e dai luoghi precedenti in cui ho lavorato master è sempre pensato per essere implementabile per la produzione.

Dalla documentazione / libro di Git - Git branching

Il ramo "master" in Git non è un ramo speciale. È esattamente come qualsiasi altro ramo. L'unico motivo per cui quasi tutti i repository ne ha uno è che il comando git init lo crea per impostazione predefinita e la maggior parte delle persone non si preoccupa di cambiarlo.

Quindi, se si dispone di un flusso di lavoro preferito ed è difficile lavorare con esso perché diversi sviluppatori nel team hanno idee diverse su master. Potresti anche prendere in considerazione la ridenominazione masterper dire prode utilizzare un flusso di lavoro come di seguito:

(dev) -> (qa) -> (stag) -> (prod)

Ecco come si modifica il nome del ramo principale .

NON sto dicendo che devi cambiare il masternome del ramo. Ma se hai un flusso di lavoro preferito e aiuta a cambiare il masternome del ramo, fallo in tutti i modi :-)

In questo caso preferisco i controlli rispetto alle convenzioni. Ogni squadra contiene membri che sono più bravi ad avviare nuove funzionalità e altre persone che sono più brave a stabilizzare le cose per un rilascio.

Se ti manca quest'ultimo, allora le recensioni di codice aiuteranno (spesso, le persone più disciplinate vorranno comunque revisioni di codice).

Ecco perché configuriamo il nostro repository Git (stiamo usando Gitlab) in modo che solo alcune persone possano unire le richieste pull e ogni sviluppatore ottiene il proprio fork privato del repository principale.

Ciò risolve due problemi:

1. I nuovi sviluppatori non possono cambiare il ramo sbagliato (poiché non possono spingere il loro lavoro direttamente nel repository principale). Potrebbero eseguire masteril push sul proprio repository ma questo verrà risolto quando arriva la richiesta pull.

2. Le convenzioni sul codice si sono diffuse rapidamente attraverso il team poiché ogni commit è controllato da almeno un'altra persona che porta il loro punto di vista e le loro conoscenze.

Tutto dipende dal processo generale di sviluppo del software. La gestione della configurazione e il modo in cui viene creata una nuova versione non possono essere definiti senza conoscere l'intero processo.

C'è la fazione "agile" che opta per una "area di primo impegno sempre funzionante". Avrebbero gestito strutture automatizzate di costruzione e test costantemente contro quell'area e avrebbero cercato di avere un sistema funzionante "in ogni momento".

Vedrebbero il (master) -> (rilascio) con forse 1,2 passaggi intermedi come vantaggioso.

Poi c'è la fazione più "classica", che ha un processo guidato dalla pianificazione e da passaggi di integrazione pianificati verso le pietre miliari, in cui un rilascio di "unità di lavoro" è un'attività pianificata con requisiti come "rilascio solo quando è (unità) testato e dovrebbe adattarsi al prossimo traguardo previsto ". Lì, la pianificazione comprende il controllo delle versioni di "unità di lavoro" e in genere fanno di tutto per definire come dovrebbe apparire la prossima versione pianificata del prodotto in termini di funzionalità e correzioni. Per motivi di pianificazione, vogliono sapere che ciò che uno sviluppatore rilascia è "corretto" e un atto consapevole di commettere un'unità di lavoro.

Questo approccio classico non significa necessariamente che ci siano tempi più lunghi in cui non è disponibile una build completa del prodotto.

Quindi il flusso di lavoro "classico" sarebbe: (dev) -> (unità) -> (integrazione) -> (test / qa) -> (produzione).

Il ruolo dell'integratore è "accettare / acquistare" le unità rilasciate o rifiutarle se non soddisfano le esigenze della prossima versione imminente.

È anche possibile mescolare quei 2 approcci di base in modi opportuni.

In base alla mia esperienza (che riguardava principalmente l'uso dell'approccio "classico"), l'approccio "classico" ha funzionato decentemente in progetti di circa 4-50 persone in un team.