Pianifichi regolarmente gli aggiornamenti delle app? E se sì, come gestisci i bug che lo compongono?

Question

Pianifichi regolarmente gli aggiornamenti delle app? E se sì, come gestisci i bug che lo compongono?

#1 da (5 voti)

3

Stiamo cercando di rendere più frequenti le nostre pubblicazioni. Come parte di ciò abbiamo bloccato un giorno della settimana in cui abbiamo detto agli utenti che faremo aggiornamenti. Simile a Microsoft ha Patch martedì.

Questo è per un'app Web che esegue completamente lato server, comunque. Quindi gli aggiornamenti non sono un grosso problema da implementare. Anche se possono richiedere molto tempo.

Occasionalmente un aggiornamento ha un bug che deve essere risolto prima che la prossima finestra di aggiornamento si svolga. Vedo due opzioni reali: annullare l'aggiornamento e ripristinare un backup della versione precedente oppure effettuare una correzione e distribuirla al di fuori dell'orario pianificato.

Fare una correzione sembra facile, ma spesso ci sono altre modifiche che sono state apportate al codice base. E la correzione ha bisogno di test prima che possa realisticamente uscire.

Il rollback non è una cattiva opzione, ma a volte rimuoverà le funzionalità recenti o almeno li ritarderà fino alla settimana successiva.

deployment

posta David Hogue 15.03.2012 - 21:08

fonte

1 risposta

Leggi altre domande sui tag deployment

Come rilevare se un'app era già stata installata in precedenza Qual è la migliore pratica per le API asincrone che restituiscono futures su Scala?

score 5 · Answer 1

Sembra che tu abbia un problema di sviluppo. Lo so perché hai detto:
Making a fix sounds easy, but often times there are other changes that have been made to the code base. And the fix needs testing before it can realistically go out.

Devi isolare i tuoi rilasci di produzione nel tuo sistema di controllo della versione (ne stai usando uno, giusto?). Crea un ramo per il tuo rilascio. I bug scoperti nella versione di produzione vengono risolti in quel ramo (e la correzione viene reimmessa nella linea di sviluppo principale). Bug corretti nello sviluppo principale hanno la correzione introdotta nel ramo se possibile (o una correzione parallela creata se non).

Questo garantisce che le correzioni al codice di produzione in esecuzione saranno minuscole soluzioni e facili da testare (quindi è veloce da implementare in caso di problemi) e, auspicabilmente, renderle meno dirompenti.

Al di fuori di questo ecco il miglior consiglio che posso offrirti:

Avere qualche tipo di ciclo di test interno.
Non rilasciare codice che non funziona, o almeno fallo prima su un piccolo gruppo di utenti.
(StackExchange utilizza meta.stackoverflow.com come scimmia scratch.)
Taglia le uscite quando sei ragionevolmente sicuro che funzionino (La suddetta ramificazione)
Correggere i bug prima di aggiungere funzionalità
(Liberamente rubato da Il test di Joel )
Non aver paura non di rilasciare qualcosa se non è pronto.
Meglio non spedire una patch su "patch day" piuttosto che rompere l'universo.
Non aver paura di ripristinare qualcosa se non funziona.
(Corollario: Sempre hai un piano di back-out! )
Imposta un programma di rilascio che puoi mantenere.
Una volta alla settimana è HARD . Una volta al mese è difficile se stai facendo di più che correggere i bug. Una volta un quarto è abbastanza facile.

Per riferimento, la mia azienda rilascia il software il fine settimana successivo al 15 di ogni mese di metà trimestre (vale a dire il fine settimana successivo al 15 febbraio, 15 maggio, 15 agosto, 15 novembre). Per varie ragioni normative il nostro ciclo di test è piuttosto rigoroso, e questo è il ritmo più veloce che possiamo mantenere mantenendo la qualità del software dove ne abbiamo bisogno. Le patch di correzione degli errori di emergenza vengono rilasciate quando necessario, di solito il venerdì (per darci un weekend in cui abbiamo un volume relativamente basso nel caso in cui la correzione interrompa qualcos'altro).