Preparare un rilascio software con modifica del database
Tornare al vecchio codice non ripristina la compatibilità con un database modificato. Un caso completo mostra cosa verificare nel cambio e nel ritorno.
Un rilascio software modifica talvolta applicazione e database insieme. Il ritorno deve quindi considerare più della precedente versione del programma. Registri quale combinazione di codice, configurazione e struttura dati funziona insieme.
Il seguente esempio ipotetico di portale è un caso di test pianificato. Non descrive modifiche a un database cliente reale.
Verificare il ritorno sullo stesso stato dei dati
L’applicazione esistente V1 legge i nomi cliente da customer_name. La nuova applicazione V2 dovrà leggere display_name. Nel piano iniziale viene eliminata la colonna precedente. Poi la nuova applicazione non parte per una configurazione mancante.
Passaggio | Database dopo il passaggio | Esito nell’esempio |
|---|---|---|
Prima del cambio | È presente la vecchia colonna del nome | L’applicazione esistente funziona |
Dopo la modifica prevista | È presente solo la nuova colonna | La nuova applicazione non parte per la configurazione |
Ridistribuire solo il vecchio codice | Rimane solo la nuova colonna | La vecchia applicazione non trova la colonna attesa |
Ridistribuire il vecchio codice non ripristina la struttura dei dati. Un pulsante di rollback nello strumento non risolve da solo questa incompatibilità.
Pianificare una transizione compatibile
Un’alternativa è una transizione graduale: mantenere prima la vecchia colonna e aggiungere la nuova. I valori esistenti vengono trasferiti in modo tracciabile. Il team definisce quale campo è autorevole e come mantenere coerenti le modifiche durante la transizione.
In un ambiente separato si verificano entrambe le versioni con lo stato intermedio. Va incluso modificare un nome e rileggerlo correttamente dalle due versioni. Una copia iniziale non basta se i valori successivi vengono scritti in un solo campo.
La rimozione del vecchio campo viene pianificata soltanto dopo la conferma della transizione, quando la versione precedente non serve più come ritorno. Cambiano così di nuovo le vecchie versioni ancora utilizzabili. Il passaggio richiede una decisione propria.
Considerare i dati arrivati dopo il cambio
Un backup precedente può contenere la vecchia struttura. Se nel frattempo sono stati accettati ordini nuovi, potrebbero mancare nel backup. Il ripristino non deve scartarli senza renderlo evidente. Dati successivi e loro riconciliazione fanno parte del piano di recupero.
A seconda della modifica, una finestra di manutenzione o una correzione mirata della nuova versione può essere più adatta. La transizione graduale non promette genericamente aggiornamenti senza interruzioni.
Registrare il risultato della prova
Documenti versione verificata, configurazione, stato dei dati e chi decide in caso di errore. Nel test, segua un ordine fino alla conferma nella destinazione, poi provi il ritorno previsto. Annoti dati conservati e limiti.
Prima del cambio in produzione diventa così visibile se il ritorno previsto è davvero compatibile con applicazione e dati.
Fonti
Continuate a leggere
Tutti gli articoli
Cloud & gestione con ASES
Hosting, deployment, manutenzione e assistenza