Regola del pollice per quando utilizzare una correzione rapida?

Question

Regola del pollice per quando utilizzare una correzione rapida?

#1 da (4 voti)
#2 da (1 voti)
#3 da (1 voti)

1

Un commento su una risposta precedente mi ha fatto riflettere sulla nostra politica di aggiornamento rapido. Ad esempio, un progetto attuale viene utilizzato da circa 300 utenti in tutto il mondo. Una posizione ha trovato uno strano bug in cui hanno emesso un numero specifico in una casella combinata. Ciò ha provocato un errore completo del server (la sessione è stata ripristinata con un errore http 500). Ero come: "Sì, hotfix appena possibile!" Tuttavia, non ne sono più sicuro poiché questo errore interessa solo una posizione specifica e un numero specifico. Di solito non mi importava troppo e l'ho appena risolto. Poiché questa domanda Hotfix con un ramo di rilascio aperto mentre questa versione è attualmente testata Ho deciso di essere più subdolo quando si tratta della decisione relativa all'hotfix.

Esiste una regola empirica quando utilizzare una correzione anziché una semplice correzione per la prossima versione?

release-management workflows

posta OddDev 25.08.2016 - 10:58

fonte

3 risposte

Leggi altre domande sui tag release-management workflows

Quali sono i requisiti di licenza per un programma che compilo usando GCC? API che prende una lista e restituisce una lista

score 4 · Answer 1

Non sono sicuro che ci sia una regola empirica per essere onesti.

Nella situazione ideale, stai eseguendo micro versioni di singole funzioni, un'architettura basata su servizi con CI e test automatici. Quindi, tornare indietro è una decisione facile da prendere, in quanto perdi una singola funzione e puoi rilasciare una nuova versione quasi immediatamente a basso rischio.

Tuttavia, in pratica, questo è raro che sia, se fai uscite mensili e devi tornare indietro, anche subito dopo il rilascio, perdi un sacco di funzionalità che tutti stavano aspettando. Forse sono stati persino commercializzati ai clienti! La prossima versione è un altro mese di distanza, quindi è una chiamata difficile da fare. Ehi, che la prossima versione potrebbe avere un altro bug e dovrai anche ripristinarlo, la pressione per l'hot fix aumenterà solo nel tempo.

Non puoi muoverti lentamente verso l'ideale, e ciò significherà molto lavoro di refactoring e DevOps. Ma puoi fare una smorfia quando vengono richieste correzioni rapide e tenere traccia di quante ne fai, e quanto tempo è trascorso a farle.

score 1 · Answer 2

Ci sono diversi fattori da considerare IMO;

L'hot fix deve essere distribuita al client o puoi "silenziosamente" riparare il server per gestirlo?
- Quanto è coinvolto un aggiornamento del client? Automatico? Due ore di attenta migrazione?
- Quanto spesso accade e a quanti utenti? (Dici 1/300, ma è un dato di fatto, o i rapporti che hai ottenuto?)
- Quanto prestigio metti nella qualità del tuo prodotto? È accettabile che tu abbia un crash casuale (per l'utente) in diretta fino al prossimo aggiornamento programmato? O vale il costo di una correzione rapida per guadagnare la buona volontà di un supporto rapido?

score 1 · Answer 3

Non esiste una regola empirica. Diverse organizzazioni gestiscono diversamente. Alcuni si rifiuteranno di correggere problemi significativi e attenderanno un futuro (possibilmente diversi rilasci) per risolvere il problema. Altri sono proattivi nel risolvere il problema sulla versione di produzione.

Ho lavorato a un progetto in cui abbiamo applicato attivamente correzioni alla versione corrente. Ogni correzione è stata tracciata nel ramo di rilascio con uno dei tre risultati (i primi due si sono verificati più o meno con la stessa frequenza):

Applica patch invariata. (Applicabile quando la correzione è stata completata.)
Applica una soluzione completa nella versione. (Applicabile quando è stata utilizzata una correzione / soluzione incompleta.)
Rilascia la correzione. (Caso estremamente raro in cui la funzionalità con patch non esisteva nel rilascio.)

Le patch rilasciate alla versione corrente dovrebbero diventare meno frequenti man mano che la prossima versione si avvicina al rilascio. Questo è il trade-off di molteplici fattori.

È improbabile che tu abbia un caso limite che si applica a un solo valore in un sito. Potrebbe essere un caso limite applicarsi in alcuni casi, o forse essere abbastanza comune. Ho trovato casi di errore che si applicano a porzioni significative degli utenti per i quali nessun utente ha segnalato un problema. Finché non avrai identificato la causa, non saprai quanto sia comune.