Cosa succede se una funzionalità unita allo sviluppo viene posticipata dalla direzione?

53

Di recente abbiamo avuto un problema per cui una funzione per la nostra webapp (registrazione automatica) è stata posticipata dalla direzione perché ritenevano che l'inizio fosse troppo "freddo", ma volevano che tutte le altre funzionalità su cui stavamo lavorando fossero attive.

Il problema è che questa funzionalità è stata unita allo sviluppo quando è stata completata insieme a tutte le altre funzionalità che ci aspettavamo di pubblicare dal vivo alla prossima versione in modo da non poter semplicemente unire dev -> test -> master come facciamo di solito.

Come abbiamo potuto evitare questo problema?

project-management git gitflow

— Steve
fonte

A seconda del tuo punto di vista su come vuoi risolverlo, questa domanda è più adatta al posto di lavoro, se non stai cercando una soluzione tecnica.

— Malavos,

74

Un approccio è la funzionalità che lo contrassegna. Può vivere nella base di codice ma può essere disabilitato dalla configurazione.

Un'altra opzione è quella di effettuare un commit di ripristino che ripristina l'unione della funzione in modo che non sia più in fase di sviluppo. È possibile creare un nuovo ramo che ripristina il ripristino ed essere lasciato in sospeso per unire in seguito. Se stai usando le richieste pull di Github, puoi farlo facilmente con il pulsante "ripristina unione" su una richiesta pull unita.

— Daenyth
fonte

9

Il flag di configurazione non implica un raddoppio dello sforzo di test per quel codice? Devi testare entrambi i percorsi.

16

In questo caso, dal momento che non si attiverà quella bandiera in produzione, ora è possibile testare il caso spento per il rilascio, quindi testare il caso acceso quando è pronto per andare in prod. Dovrebbe essere approssimativamente lo stesso lavoro di testare un ripristino e ricominciare.

— Alan Shutko,

4

Il termine comune è Feature Toggle . Se esiste un piccolo "punto di accesso alle funzionalità", ciò può probabilmente essere fatto dopo la decisione della direzione. Altrimenti, si avranno problemi con questo metodo e anche con qualsiasi metodo.

— Doc Brown,

3

Abbiamo funzionalità in sviluppo da oltre 6 mesi che sono nascoste da Feature Toggling, come lo chiamava Doc Brown. Questo ci consente anche di testare la funzionalità (o l'assenza di essa) in ambienti non di produzione. A volte queste funzionalità si aggiungono alle funzionalità esistenti, nel qual caso dovremmo avere test unitari sia per il set di funzionalità vecchio che per quello nuovo. Ogni test unitario imposterebbe la bandiera su qualsiasi cosa sia necessaria per eseguire il test corrente.

— ps2goat,

25

Come abbiamo potuto evitare questo problema?

Dal punto di vista del processo, capire:

Chi era il decisore per iniziare questo lavoro?
Perché la decisione di rilasciare questa funzione è cambiata?
- Aspettative mancate?
- Problemi di comunicazione?
- Supporto aziendale inadeguato?
- Nessun coinvolgimento del cliente?

Molto probabilmente ci sono state cadute nella comunicazione lungo la strada. Questo è importante perché, quando non funziona, i tuoi processi di sviluppo saranno basati su una comprensione errata e errata dei requisiti aziendali.

— enderland
fonte

9

+10. Non appena il management ha iniziato a dubitare del rilascio della funzionalità, avrebbe dovuto informare gli sviluppatori, in modo che la possibile rimozione avrebbe potuto essere presa in considerazione quando si è deciso di unire la funzionalità allo sviluppo.

— Bart van Ingen Schenau,

14

Questa non è una risposta molto costruttiva - a volte le cose vanno di lato per tutti i motivi. Certo, scoprire che non dovrebbe essere unito prima o poi è importante, ma ciò non significa che alla fine una funzionalità verrà estratta all'ultimo minuto. Forse i cambiamenti del contratto, forse il tuo cliente non paga, forse appaiono problemi legali .. devi ancora gestire il problema invece di indicare il dito della colpa

— gbjbaanb

11

Se ci sono persone nella tua organizzazione che sono sufficientemente potenti da rifiutare di ammettere la colpa e anche sufficientemente infantili da non voler evitare i difetti, allora dovresti comunque avere problemi post mortem per le tue informazioni. Non vuoi dirglielo (o scriverlo in modo troppo esplicito). Detto questo, Enderland non usa la parola "colpa", e se l'organizzazione interpreta questo consiglio come "scopri chi è la colpa", allora questo è di per sé un problema su cui l'organizzazione deve lavorare. Tutto ciò dice "capire perché si è verificato il problema", che è essenziale per evitarlo in futuro.

— Steve Jessop,

2

Sono completamente d'accordo, questo è un errore di gestione, non uno di sviluppo.

— durron597,

3

@enderland il mio punto è che non puoi evitare alcuni problemi, quindi devi considerare come riparare la situazione. Spero che non arrivi molto spesso, ma prima o poi è destinato a succedere, quindi pianifica di conseguenza.

— gbjbaanb,

19

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

Immagino che dichiareresti "la disabilitazione della registrazione automatica per configurazione" semplicemente come una funzionalità aggiuntiva (è solo una forma di Toggle Feature ), quindi questo dovrebbe integrarsi senza problemi nel tuo flusso di lavoro. È possibile stimare lo sforzo, se lo si desidera, è possibile utilizzare un ramo di funzionalità per esso (oppure no, se non si utilizzano i rami di funzionalità per tali problemi). E puoi sicuramente usare il flusso usuale "unisci dev -> test -> master" che hai descritto.

Ed è proprio così che 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 direzione per la versione 1.0 o se la richiesta di modifica è un nuovo desiderio del cliente per la versione 2.0.

— Doc Brown
fonte

Fowler ha un output davvero buono, ma non posso supportare questo metodo per l'introduzione delle funzionalità. Lo sforzo coordinato per tali interruttori sembra un onere inutile. Io posso sostenere l'aggiunta di funzionalità alterna a rimuovere funzionalità dopo l'unione, ma la costruzione di un interruttore come parte del requisito mi mette a disagio.

— Gusdor,

@Gusdor: guarda la mia modifica.

— Doc Brown,

1

Questo è il problema esatto che ho con gitflow e GitHub e sembra che con le applicazioni web ciò accada spesso - o più come la norma. Sembra che risolveresti questo problema in modo retroattivo (menzionato sopra) o in modo proattivo (esempio sotto).

Ho creato "rami raggruppati" in aggiunta ai rami gitflow standard. Il bundle è composto da tutte le funzionalità che sono pronte per uat / qa. Viene creato un elenco di funzionalità uat / qa. Questi vengono uniti nel bundle temporaneo e quel bundle viene distribuito in uat / qa. Qualsiasi correzione di bug si verifica sul ramo della funzione originale e questo viene rimesso nel bundle e distribuito. Ciò separa la prossima versione e consente di testare queste funzionalità insieme prima che trovino la strada per il ramo di sviluppo. I rami approvati ottengono una richiesta pull in sviluppo - seguendo il processo gitflow. Le funzionalità di test pronto possono essere aggiunte o rimosse dal ramo del bundle temporaneo e ridistribuite.

Ciò mantiene il master che riflette sempre lo stato pronto per la produzione (può automatizzare con il hook)
Develop riflette sempre l'ultimo candidato rilasciato (e testato) della prossima versione

I contro comprendono la gestione dell'elenco bundle e l'aggiunta di un altro tipo di filiale; tuttavia, oltre alla correzione retrò, che ritengo sia troppo tardi, questa sembra essere la soluzione più praticabile.

Con un componente aggiuntivo GUI, potrebbe essere ottimale spuntare i rami delle caratteristiche per distribuzione del pacchetto, tenendo presente l'automazione.

— David Latty
fonte