Abbiamo discusso delle tecniche di distribuzione dei database oggi, avendo avuto un paio di recenti fallimenti nel nostro processo attuale e avendo visto situazioni in cui vorremmo ripristinare una distribuzione, ma la vecchia versione dell'applicazione non era mai stata testata contro il nuovo versione del database.
Da un lato, esistono distribuzioni in stile Migrazione, in cui si dispone di un'istruzione di versione e di un'istruzione di versione down (indipendentemente dal fatto che siano scritte in SQL o nella lingua dell'applicazione) e l'app conosce la versione di cui ha bisogno arrivare a.
Sono semplici, e poiché non eseguiremo il rollback spesso, gli sviluppatori sono desiderosi di semplicità. Tuttavia, ci sono dei rischi quando si aggiunge un campo / tabella e tale 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, 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 annullabile, quindi la vecchia app non interessa; rollforward popola i campi nulli e lo rende nuovamente non annullabile.
Conserva i dati ma è complicato sia per codificare che per testare (purtroppo i nostri test di integrazione automatizzati sono praticamente inesistenti e, mentre stiamo correggendo, abbiamo un problema nel frattempo).
Esistono metodi sicuri per mitigare i problemi con questi? Ci sono altre opzioni che dovrei prendere in considerazione? Hai avuto brutte esperienze che ti piacerebbe condividere, cosa che mi può far risparmiare tempo dopo?