Elenco di controllo per gli aggiornamenti dello schema del database

Question

Dover aggiornare lo schema di un database rende l'installazione di una nuova versione del software molto più complicata.Quali sono le migliori pratiche per farlo?

Sto cercando un elenco di controllo o una sequenza temporale di azioni, come ad esempio

• 8:30 chiudi le app
• 8:45 modifica schema
• 9:15 installa nuove app
• 9:30 riavvio db

ecc., mostrando come ridurre al minimo i rischi e i tempi di inattività.Problemi come

• annullare l'aggiornamento se le cose vanno storte
• riducendo al minimo l'impatto sulle app esistenti
• Aggiornamenti "caldi" mentre il database è in esecuzione
• promozione dallo sviluppo al test fino ai server di produzione

sono particolarmente interessanti.

Answer 1

Ho molta esperienza con questo.La mia applicazione è altamente iterativa e le modifiche allo schema avvengono frequentemente.Eseguo un rilascio di produzione all'incirca ogni 2 o 3 settimane, con 50-100 elementi cancellati dalla mia lista FogBugz per ciascuno di essi.Ogni versione che abbiamo realizzato negli ultimi anni ha richiesto modifiche allo schema per supportare nuove funzionalità.

La chiave è provare le modifiche più volte in un ambiente di test prima di apportarle effettivamente sui server live.

Conservo un file di elenco di controllo della distribuzione che viene copiato da un modello e quindi modificato pesantemente per ogni versione con tutto ciò che è fuori dall'ordinario.

Ho due script che eseguo sul database, uno per le modifiche allo schema, uno per la programmabilità (procedure, visualizzazioni, ecc.).Lo script delle modifiche è codificato a mano e quello con le procedure è scritto tramite Powershell.Lo script di modifica viene eseguito quando tutto è spento (devi scegliere un orario che infastidisca il minor numero di utenti per questo) e viene eseguito comando per comando, manualmente, nel caso in cui qualcosa vada strano.Il problema più comune che ho riscontrato è l'aggiunta di un vincolo univoco che fallisce a causa di righe duplicate.

Quando mi preparo per un ciclo di test di integrazione, eseguo la mia lista di controllo su un server di test, come se quel server fosse di produzione.Quindi, in aggiunta a ciò, vado a prendere una copia effettiva del database di produzione (questo è un buon momento per sostituire i backup offsite) ed eseguo gli script su una versione locale ripristinata (il che è anche positivo perché dimostra la mia l'ultimo backup è audio).Sto prendendo un sacco di piccioni con una fava qui.

Quindi ci sono 4 database in totale:

1. Sviluppatore:tutte le modifiche devono essere apportate nello script di modifica, mai con studio.
2. Test:Il test di integrazione avviene qui
3. Copia della produzione:Pratica di distribuzione dell'ultimo minuto
4. Produzione

Hai davvero, davvero bisogno di farlo bene quando lo fai in produzione.Annullare le modifiche allo schema è difficile.

Per quanto riguarda gli hotfix, correggerò solo le procedure, mai gli schemi, a meno che non si tratti di un cambiamento molto isolato e cruciale per l'azienda.

Answer 2

Immagino che tu abbia considerato le letture di Scott Ambler?http://www.agiledata.org/essays/databaseRefactoring.html

Answer 3

Questo è un argomento di cui stavo proprio parlando al lavoro.Principalmente il problema è che, a meno che le migrazioni dei database non siano gestite bene dal tuo framework, ad esempio rails e i loro script di migrazione, allora è lasciato a te.

Il modo attuale in cui lo facciamo presenta evidenti difetti e sono aperto ad altri suggerimenti.

1. Disporre di un dump dello schema con dati statici che devono essere mantenuti aggiornati e nel controllo della versione.
2. Ogni volta che esegui un'azione di modifica dello schema, ALTER, CREATE, ecc.scaricalo in un file e inseriscilo nel controllo della versione.
3. Assicurati di aggiornare il dump del database SQL originale.
4. Quando esegui il push to live, assicurati che tu o il tuo script applichiate i file SQL al db.
5. Pulisci i vecchi file SQL che si trovano nel controllo della versione man mano che invecchiano.

Questo non è affatto ottimale e non è realmente inteso come un db di "backup".È semplicemente per facilitare la vita e mantenere gli sviluppatori sulla stessa lunghezza d'onda.Probabilmente c'è qualcosa di interessante che potresti configurare con Capistrano per quanto riguarda l'automazione dell'applicazione dei file SQL al db.

Il controllo della versione specifica del DB sarebbe davvero fantastico.Probabilmente c'è qualcosa che lo fa e se non c'è probabilmente dovrebbe esserci.

Answer 4

E se l'articolo di Scott Ambler stuzzica il tuo appetito, posso consigliare il suo libro con Pramod J Sadolage intitolato "Refactoring Databases" - http://www.ambysoft.com/books/refactoringDatabases.html

Ci sono anche molti consigli e informazioni utili nel gruppo Agile Database di Yahoo - http://tech.groups.yahoo.com/group/agileDatabases/

Answer 5

Due brevi note:

1. Va da sé...Quindi lo dirò due volte.
   Verifica di avere un backup valido.
   Verifica di avere un backup valido.

2. @mk.Guardare Il post sul blog di Jeff sul controllo della versione del database (se non l'hai già fatto)