Troppe volte vedo questo processo per l'aggiornamento dei framework:
- Arresta tutto lo sviluppo di nuove funzionalità
- Framework di aggiornamento
- Verifica manualmente
- Continua a testare e correggere
- Continua a testare e correggere
- Distribuisci in un ambiente di pre-produzione ... e continua a testare e correggere
- Ripeti per ogni ambiente
- Distribuisci in produzione
- Prega per qualsiasi divinità in cui credi
- Continua a testare e correggere
Il passaggio 2 dovrebbe effettivamente essere il passaggio 3. Il passaggio 1 dovrebbe essere del tutto inutile. Se hai bisogno di fare il passo 1, stai sbagliando.
Il passaggio 1 dovrebbe essere iniziare con l'unità e copertura di test automatizzata .
Facevo parte di un team agile che non solo era in grado di eseguire un aggiornamento del framework non compatibile, ma anche un aggiornamento non compatibile al linguaggio stesso. Era una grande applicazione di Ruby on Rails che aggiornava a Ruby 1.9. Quindi praticamente ogni framework, libreria e dipendenza che avevamo era anche aggiornato o sostituito.
In 4 settimane. In 4 ambienti, compresa la produzione. E abbiamo consegnato anche 4 nuove importanti funzionalità.
Questo è non un modo per dire "Ruby è meglio!" piuttosto, è una testimonianza della quantità di unità e copertura di test automatizzata che l'applicazione ha avuto. Abbiamo avuto oltre 1.200 test unitari e circa 600 test di cetriolo. È anche la testimonianza di un team affiatato e di grande comunicazione.
Quindi, il mio elenco modificato di passaggi per l'aggiornamento di un framework, o parte importante dell'infrastruttura software:
-
Scrivi molti test di unità. codice di rifattore se necessario in modo da poter scrivere test di unità per la logica di base della tua applicazione
-
Crea test funzionali automatizzati. Non tutto può essere testato con un test unitario, ma un test funzionale completo attraverso l'interfaccia utente è la cosa migliore. Scrivi molte di queste.
-
Ripeti i passaggi 1 e 2.
-
Aggiorna il framework.
-
Fai passare i test unitari
-
Scarica i test funzionali.
-
Tieni traccia dei cambiamenti di rottura che devi apportare. Invia un'email al team in merito a queste modifiche e a come possono risolvere i lavori in corso.
-
Revisione del codice team. Fagli fare domande. Rispondili in modo dettagliato.
-
Controlla il codice e assicurati che la generazione dell'integrazione continua passi.
-
Assist i compagni di squadra con fusioni e correzioni di errori per lavori in corso.
-
Distribuire in un ambiente di pre-produzione per il test manuale. Avere già un piano di test manuale.
-
Distribuisci al prossimo ambiente di pre-produzione, seguito da altri test.
-
Distribuisci in produzione.
La differenza fondamentale tra i due approcci è quando risolvi i nodi. Con l'approccio n. 1 si incontrano la maggior parte dei problemi durante il test manuale. Con l'approccio # 2 li incontri durante lo sviluppo, dove sono più facili da rintracciare e correggere.