Qual è la "definizione" di una funzionalità finita in Gitflow?

La funzionalità dovrebbe essere testata da sola prima che sia finita e unita al ramo di sviluppo. Tuttavia, penso che sia compito di ogni team usare gitflow per definire cosa significa finito. Ogni team dovrebbe determinare il numero di test da eseguire nel ramo di funzionalità rispetto a quanti test devono essere eseguiti dopo essere stati incorporati nel ramo di sviluppo.

Devono essere eseguiti test sia sul ramo di funzionalità che sul ramo di sviluppo. È ragionevole presumere che il ramo di sviluppo si trovi in uno stato diverso da quando hai creato il tuo ramo di funzionalità. Ciò significa che avrai bisogno di un nuovo ciclo di test per il ramo di sviluppo dopo aver terminato la funzione.

Se metti alla prova la tua funzionalità separatamente da eventuali modifiche apportate al ramo di sviluppo, se c'è un bug dopo aver terminato la funzione, puoi utilizzare questi risultati del test per concentrarti su dove stai eseguendo il debug del tuo codice.

Dipende esclusivamente da te e dal tuo team quanti test sono stati effettuati sul ramo delle funzionalità. Ma dovresti fare un test completo sul ramo di sviluppo dopo che la tua caratteristica si è fusa nel ramo di sviluppo. Ciò potrebbe portare te e il tuo team a eseguire meno test, ad esempio non eseguire un UAT completo e fare affidamento solo sui Test di unità per il ramo di funzionalità, oppure potrebbe significare qualche altra quantità di test.

È quando smetti di lavorarci. Dovrai elaborare i tuoi criteri. Spero che la tua decisione di fermarti sia che hai soddisfatto i requisiti o hai smesso di provare. Dovrai anche decidere come utilizzare il sistema se ci sono requisiti aggiuntivi o se sono cambiati.

Non ne so abbastanza di Gitflow per determinare se offrono solo uno strumento o se intendono una metodologia specifica per la gestione dello sviluppo del software. La maggior parte dei martelli non ti dice quali chiodi colpire, quanto duro o quanto profondo.

I team hanno standard diversi per considerare le funzionalità "fatte", ma questa parte è generalmente considerata quando lo sviluppatore è fatto. Ciò non significa che tu perdi la qualità comunque. Nella mia squadra ciò significa che ha superato una revisione del codice, ha una copertura del 100% di test unitario, ha test di integrazione automatizzati e tutti i test sono passati.

Il motivo è che c'è un costo per isolare un ramo troppo a lungo. Quanto più a lungo si procede prima di unire nuovamente in develop , tanto più grave è il rischio di gravi conflitti quando lo si fa. Inoltre, hai richieste di pull più grandi che sono più difficili da recensire a fondo. La durata ideale di un branch di funzionalità non supera i pochi giorni.

Con diversi team che lavorano a quella velocità, quel tempo di ciclo è troppo veloce per essere gestito dal QA, a meno che non si disponga di un'organizzazione di QA eccessivamente grande. Devi dare loro build da un ramo che aggrega le caratteristiche come una questione di pragmatismo. Nel modello gitflow, credo che di solito siano i release branches.

Questa definizione è, come ricordo, da Jessica Kerr, non git flow, ma una funzionalità finita è quella per cui il codice è stato rimosso in modo permanente dall'ambiente di produzione. Poiché Kerr dice , una volta che è stato smesso di essere utile e cancellato, "nessuno mai chiamarti e chiedertelo di nuovo ".