Come gestite le distribuzioni delle modifiche al database?

Oggi abbiamo discusso delle tecniche di distribuzione del database, avendo avuto un paio di recenti errori nel nostro processo attuale e visto situazioni in cui vorremmo ripristinare una distribuzione, ma la vecchia versione dell'applicazione non era mai stata testata rispetto alla nuova versione del Banca dati.

Da un lato, ci sono distribuzioni in stile Migrazione, in cui hai un'istruzione version-up e un'istruzione version-down (che siano scritte in SQL o nella tua lingua dell'applicazione) e la tua app sa a quale versione deve arrivare.

Questi sono semplici e, poiché non eseguiremo il rollback spesso, gli sviluppatori sono appassionati di semplice. Tuttavia, ci sono dei rischi quando si aggiunge un campo / tabella e quel campo viene popolato prima del rollback. O peggio, dove si rilasciano dati rilevanti per la versione precedente.

D'altra parte, possiamo considerare un approccio di aggiornamento, rollback e rollforward in cui il rollback non è così drastico come con le migrazioni. Ad esempio, l'aggiornamento può aggiungere un campo non annullabile; il rollback lo rende nullable in modo che alla vecchia app non interessi; rollforward popola i campi null e li rende nuovamente non annullabili.

Ciò conserva i dati ma è complicato sia per il codice che per il test (purtroppo i nostri test di integrazione automatizzata sono praticamente inesistenti e, mentre lo stiamo correggendo, nel frattempo abbiamo un problema).

Ci sono modi sicuri per mitigare i problemi con questi? Ci sono altre opzioni che dovrei prendere in considerazione? Hai avuto brutte esperienze che vorresti condividere che mi possono salvare il dolore in seguito?

Le modifiche al database devono essere gestite come tutte le altre modifiche e distribuite come script come parte della distribuzione (e ovviamente salvate nel controllo del codice sorgente). Poiché sono distribuiti con il codice per la stessa versione dell'applicazione, sai esattamente cosa deve essere eseguito il rollback. Puoi divertirti e scrivere uno script per annullare ogni modifica nel momento in cui scrivi lo script del database ma se i rollback non sono comuni, potresti non volerlo fare. Se viene popolata una nuova colonna, si perderanno i dati se si ritorna al database originale.

In SQL Server è possibile eseguire un'istantanea appena prima di una distribuzione e quindi restituirla immediatamente se la distribuzione non riesce. Ciò presuppone che la distribuzione NON avvenga quando gli utenti si trovano sul sistema (non si desidera perdere le modifiche ai dati). Ciò è molto utile durante un'importante versione in cui potrebbe essere necessario arrestare temporaneamente l'intero sistema per eseguire l'aggiornamento. In alternativa, è comunque possibile acquisire l'istantanea ed eseguire un confronto tra l'istantanea e il database per vedere le differenze se è necessario eseguire il rollback. Uno strumento come SQLCompare può persino generare il codice per tornare alla struttura dell'istantanea. Non so cosa sia disponibile per altri database.

Le modifiche a una struttura di database devono essere automatizzate / gestite da script e testate utilizzando un ambiente di test. Le modifiche manuali sono troppo rischiose in un ambiente di produzione

L'unica ragionevole strategia di rollback (quella con la minima probabilità di peggiorare le cose) è tornare a un'istantanea pre-aggiornamento. Se le cose andranno male, accadrà abbastanza rapidamente da rendere gestibile il ritorno all'istantanea o troppo tardi per un rollback (il rapporto di fine settimana successivo non riesce a causa di problemi nel database).

Le modifiche possono essere eseguite in modo incrementale (come l'aggiunta di un campo) e quindi testate dal vivo con meno rischi rispetto a quando vengono eseguite tutte in un unico passaggio.

Con la pianificazione, è possibile apportare modifiche al database per supportare diverse versioni imminenti, invece di dover confrontare l' aggiornamento del software e del database con ciascuna versione.

Preparati ad essere in modalità di emergenza i giorni seguenti un aggiornamento del database, proprio come faresti se si trattasse di un aggiornamento del software.

Resistere alla tentazione di correggere manualmente i problemi. Usa la tua strategia di emergenza (rollback, snapshot) e poi pensa al motivo per cui le cose sono andate male prima di provare di nuovo l'aggiornamento.