Verifica degli aggiornamenti del framework

4

A causa di molte rivelazioni sulle vulnerabilità, abbiamo dovuto aggiornare il nostro framework principale, da cui dipendono gran parte del nostro sistema. (Nel nostro caso, era la versione del framework Spring dalla 4.3.16., Ma questo è solo un esempio, probabilmente meno importante.)

Abbiamo risolto alcuni dei problemi di compatibilità con le versioni precedenti nella nuova versione.
(Ad esempio: nuovi metodi nelle interfacce implementati nel nostro progetto)

Come verificare se questo non causa alcun problema?
Mi chiedo se potrei seguire qualsiasi approccio per assicurarmi che non causi altri problemi da rilevare successivamente durante il runtime.

Inoltre, questa potrebbe essere una preoccupazione comune per qualsiasi aggiornamento della libreria. Ci sono pratiche o procedure che dovrebbero essere fatte per eliminare tali preoccupazioni?

    
posta Procrastinator 22.06.2018 - 05:11
fonte

2 risposte

5

Test. E poi ne provi ancora un po '. E poi fai un altro test.

Ovviamente è un po 'generale, ma è la risposta. Più in dettaglio:

  • Assicurati che i tuoi test unitari vengano superati (i test dell'unità non funzionanti dovrebbero sempre bloccare la build)
  • Assicurati che i tuoi test di integrazione passino
  • Assicurati che i test automatici end-to-end superino
  • Fai alcuni test sperimentali sul sistema. C'è qualcosa che non va?
  • Esegui il piano di test di regressione formale.

Ripeti tra i vari ambienti (sviluppo, QA interno, UAT, qualunque sia il tuo processo) fino a quando non hai abbastanza fiducia nel cambiamento.

Infine, distribuisci in produzione.

    
risposta data 22.06.2018 - 08:15
fonte
2

Troppe volte vedo questo processo per l'aggiornamento dei framework:

  1. Arresta tutto lo sviluppo di nuove funzionalità
  2. Framework di aggiornamento
  3. Verifica manualmente
  4. Continua a testare e correggere
  5. Continua a testare e correggere
  6. Distribuisci in un ambiente di pre-produzione ... e continua a testare e correggere
  7. Ripeti per ogni ambiente
  8. Distribuisci in produzione
  9. Prega per qualsiasi divinità in cui credi
  10. 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:

  1. 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

  2. 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.

  3. Ripeti i passaggi 1 e 2.

  4. Aggiorna il framework.

  5. Fai passare i test unitari

  6. Scarica i test funzionali.

  7. 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.

  8. Revisione del codice team. Fagli fare domande. Rispondili in modo dettagliato.

  9. Controlla il codice e assicurati che la generazione dell'integrazione continua passi.

  10. Assist i compagni di squadra con fusioni e correzioni di errori per lavori in corso.

  11. Distribuire in un ambiente di pre-produzione per il test manuale. Avere già un piano di test manuale.

  12. Distribuisci al prossimo ambiente di pre-produzione, seguito da altri test.

  13. 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.

    
risposta data 22.06.2018 - 14:58
fonte

Leggi altre domande sui tag