Come includere le modifiche al database durante la pubblicazione dell'applicazione

Posso dirti cosa ha funzionato per me. Potrebbero esserci motivi per cui non funziona per te.

Per prima cosa, ho scritto uno strumento per la diffusione di schemi. Era basato su uno strumento di reportistica di progettazione di database fisici che ho scritto anche che esamina un database e stampa un report di tutte le tabelle, colonne, relazioni, indici, vincoli, ecc. Lo strumento diff lo esegue semplicemente su due istanze di database e riporta eventuali differenze . Questo strumento diff mi consente di rilevare le differenze tra le cose che dovrebbero essere le stesse.

Il prossimo pezzo importante è l'igiene. Le modifiche non vengono mai apportate ad-hoc al database di produzione. Sono realizzati con un file SQL che esegue "l'aggiornamento" una volta che sappiamo che è sicuro applicare l'aggiornamento. Lo sappiamo perché l'abbiamo già eseguito sull'istanza di pre-produzione del database e abbiamo fatto alcuni test.

Quanti database hai a prescindere dalla produzione e dalla pre-produzione è davvero un problema di come il tuo progetto è organizzato e non è così rilevante oltre a mantenere la disciplina di non apportare modifiche ad-hoc (a parte l'aggiunta di utenti o dispositivi di archiviazione, ad esempio).

Il prossimo pezzo importante del sistema è il database di sviluppo. Con questo intendo il database utilizzato per testare il codice durante lo sviluppo immediatamente prima del rilascio. Questo è in genere condiviso dagli sviluppatori (che possono anche avere il proprio database per apportare modifiche ed esperimenti privati).

Durante lo sviluppo. ogni volta che viene apportata una modifica al database, aggiornare SQL build-from-scratch e creare un file SQL autonomo che applichi solo questa modifica.

Per fare un rilascio lo farei:

1. Crea un database vuoto (chiamerò questo PREV)
2. Applica lo script di installazione del database per la precedente versione
3. Carica i dati del test in esso (forse i dati campionati dalla produzione). Questo è importante per testare correttamente cose come vincoli e tipi di colonne.
4. Applica gli script SQL per eseguire l'aggiornamento (ovvero i file autonomi che ho menzionato sopra)
5. Esegui qualsiasi test di rilascio necessario su questo argomento, ma in parallelo:
6. Crea un secondo database vuoto (chiamerò questo SUCCESSIVO)
7. Esegui l'SQL di installazione da zero per creare il database in NEXT
8. Esegui lo strumento di confronto per confrontare PREV e NEXT. A parte il fatto che NEXT non ha dati, dovrebbero essere identici.
9. Se tutto è OK, esporta i dati da PREV perché ne avrai bisogno la prossima volta (come il passaggio 3).

Seguire questo processo significa avere sempre due cose a portata di mano: 1. Uno script di creazione da zero che può essere utilizzato per creare nuove istanze di database per nuovi usi (ad es. Per motivi di supporto, per clienti, ecc.) 2. Aggiornare gli script che sono garantiti per funzionare per portare il sistema di produzione in una corrispondenza esatta con i sistemi di sviluppo e di preproduzione (per evitare differenze impreviste nei database).

Per riassumere usando la terminologia della tua domanda, l'importante è assicurarti che anche il database di sviluppo venga modificato solo eseguendo script SchemaChange.sql e anche per assicurarti di disporre di un regime di test sufficientemente affidabile che i tuoi test ti dico quando questo non è accaduto per qualsiasi motivo.

Semplice, non apportare mai modifiche a un database in alcun modo se non attraverso uno script controllato da fonti. Se apporti modifiche utilizzando la GUI, è probabile che tu li dimentichi. Se scrivi uno script, è un codice, che salvi nel controllo del codice sorgente come qualsiasi altro codice. Quindi, in pratica, smetti di trattare le modifiche del database come se non fossero codice.

Vai a provare LiquidBase. Ho anche seguito il percorso di creazione manuale di script SQL con numero sequenziale, ma ora ho usato un il sistema di gestione delle modifiche del database come LiquidBase non mi fa tornare indietro.

Per il mio ambiente, ho creato uno strumento dedicato per la gestione degli aggiornamenti del database. Ho creato diverse tabelle di database per tracciare lo schema (tabella, campo, indice, indice, cronologia) e una schermata per gestire tali tabelle. Traccio anche i meta-dati come quando sono state apportate modifiche, l'ultima volta che è stata applicata una modifica dello schema, ecc.

I nostri sviluppatori ora usano questo programma ogni volta che vogliono modificare il nostro database. Per prima cosa apportano qualsiasi modifica necessaria alle tabelle. Quindi aprono una schermata di schema di applicazione che mostra un elenco di tabelle modificate e possono selezionare quali applicare al database. Possiamo quindi creare lo script di aggiornamento e applicare lo script di aggiornamento.

Quando stiamo costruendo una versione di produzione, gli sviluppatori possono quindi entrare e contrassegnare gli aggiornamenti della tabella che vogliono essere inclusi nella versione. Il nostro processo di rilascio creerà quindi & applica le modifiche allo schema per tali tabelle.

Mi piace usare Migrator.NET (e fluent migrator.net) per i miei progetti. Tutte le modifiche allo schema db fanno parte della soluzione, complete della logica di rollback. Ogni modifica o modifica logica viene implementata come una classe di "migrazione", quindi si tratta semplicemente di eseguire l'aggiornamento alla versione più recente o di eseguire il rollback a una versione specifica.

Migrator.NET memorizza la versione corrente della migrazione nel database del server SQL, quindi sa quale serie di migrazioni applicare a qualsiasi database per aggiornarlo.

Il modo in cui lo facciamo è

1. Lo schema del database è tutto memorizzato nel repository del codice sorgente.
2. Quando viene eseguita una compilazione, viene creato un database dagli script e a il backup è fatto dello schema vuoto e incluso nell'installazione MSI.
3. Quando MSI viene eseguito dal client, utilizziamo il confronto RedGate API per confrontare il backup pacchettizzato con il database dei clienti. Allora crea dinamicamente uno script di aggiornamento ed eseguito sul client.

Ci sono ancora un paio di passaggi, come il backup del database del client prima di eseguire gli script, ma questo è il succo di ciò.

La cosa più importante è il controllo della versione degli script e l'automazione del processo di aggiornamento. Quindi non molto può andare storto.