Che cosa accade se una funzione incorporata nello sviluppo viene posticipata dalla direzione?

Un approccio è la funzione che lo segnala. Può vivere nella base di codice ma essere disabilitato dalla configurazione.

Un'altra opzione per fare un commit di ripristino che ripristina l'unione di feature in modo che non sia più in sviluppo. È possibile creare un nuovo ramo che ripristina il ripristino e lasciare in sospeso per unire più tardi. Se utilizzi le richieste pull di Github, puoi farlo facilmente con il pulsante "ripristina unione" in una richiesta di pull unita.

How could we have avoided this issue?

Dal punto di vista del processo, scopri:

• Chi era il decisore per iniziare questo lavoro?
• Perché la decisione di rilasciare questa funzione è cambiata?
  • Aspettative perse?
  • Miscommunication?
  • Supporto aziendale inadeguato
  • Nessun coinvolgimento del cliente?

Più che probabile c'erano cali di comunicazione lungo la strada. Questo è importante perché quando non funziona, i processi di sviluppo si baseranno su una comprensione errata e sbagliata dei requisiti aziendali.

Dimentica per un momento il problema con la tua gestione e immagina di avere la "funzione di registrazione automatica" già nella tua ultima versione di produzione, profondamente integrata nella tua base di codice. Ora si ottiene il nuovo requisito di aggiungere un "off-switch" per "registrazione automatica". Come gestiresti questo nel tuo flusso di lavoro Git?

Suppongo che dichiareresti "disabilitazione dell'iscrizione automatica per configurazione" semplicemente come una funzionalità aggiuntiva (è solo una forma di Attiva / disattiva funzionalità ), quindi questo dovrebbe integrarsi perfettamente nel tuo flusso di lavoro. È possibile stimare lo sforzo, se lo si desidera è possibile utilizzare un ramo di funzionalità (oppure no, se non si utilizzano i rami di funzionalità per tali problemi). E puoi sicuramente usare il flusso usale "unisci dev - > test - > master" che hai descritto.

E questo è in realtà il modo in cui puoi gestirlo nella tua situazione attuale. Dal punto di vista del flusso di lavoro git, non dovrebbe importare se la richiesta di modifica proviene dalla gestione per la versione 1.0 o se la richiesta di modifica è un nuovo desiderio del cliente per la versione 2.0.

Questo è il problema esatto che ho con gitflow e flusso GitHub, e sembra che con le applicazioni web questo avvenga spesso - o più come la norma. Sembra che tu risolverai questo problema retroattivamente (menzionato sopra) o in modo proattivo (esempio sotto).

Ho creato "rami bundle" oltre ai rami gitflow standard. Il pacchetto comprende tutte le funzionalità pronte per uat / qa. Viene creato un elenco di funzionalità uat / qa. Questi sono uniti nel bundle temporaneo e quel bundle viene implementato in uat / qa. Qualsiasi bug fix si verifica sul ramo della caratteristica originale e viene nuovamente rimandato nel bundle e distribuito. Questo separa la prossima versione e consente di testare insieme quelle caratteristiche prima che trovino la loro strada verso il ramo di sviluppo. I rami approvati ricevono una richiesta di pull in fase di sviluppo, seguendo il processo gitflow. Le funzionalità pronte per il test possono essere aggiunte o rimosse dal ramo del bundle temporaneo e ridistribuito.

• Questo fa sì che il master rifletta sempre lo stato pronto per la produzione (può automatizzarsi con il gancio)
• Develop riflette sempre l'ultimo candidato della prossima release consegnato (e testato)

I contro includono la gestione dell'elenco di bundle e l'aggiunta di un altro tipo di ramo; tuttavia, oltre alla correzione retro, che ritengo sia troppo tardi, questa sembra essere la soluzione più valida.

Con un addon della GUI, potrebbe essere ottimale spuntare i rami delle funzionalità per implementazione del bundle, tenendo presente l'automazione.