database di gestione dei processi di build

Question

Quali opzioni esistono per gestire script di database e fare un nuovo sviluppo per il database:

Ad esempio, il database utilizzato da un certo numero di applicazioni e ci sono un certo numero di sviluppatori che lavorano con il database, quale sarà essere le migliori opzioni per mantenere la base di dati aggiornati con le ultime modifiche e quale dovrebbe essere il processo di cambiamenti di distribuzione per la produzione

vedo due opzioni:

1. Microsoft visual Studio ha un progetto di database, in modo che tutti database script dovrebbero essere aggiungono nel progetto e del database possono essere ricostruire da Visual Studio
2. Ripristinare database dal backup e si applicano solo i nuovi script per database di

ciò che esiste un'altra possibilità? Come posso gestire lo sviluppo del database, quali sono le migliori pratiche? quali saranno i vantaggi e gli svantaggi delle opzioni che scrivo sopra? Come mantenere nuovi script sql?

Capisco quindi che il sistema di controllo del codice sorgente debba essere utilizzato, ma con gli script DB non è così facile come con l'applicazione.

Credo non sarà una soluzione universale, ma almeno sono interessante per gli sviluppatori di DB che pensano come è implementato nella vostra azienda.

Answer 1

Liquibase IMHO è lo strumento migliore. È brutalmente semplice nel suo approccio, che è uno dei motivi per cui funziona così bene.

È possibile leggere sul sito come funziona, ma in pratica crea e gestisce una tabella semplice che memorizza un hash di ogni script per determinare se ha già eseguito uno script o meno. Ci sono anche pre e post-sql, e puoi ignorare le condizioni ... fa praticamente tutto quello che vuoi o di cui hai bisogno. Ha anche l'integrazione Maven, quindi può facilmente diventare parte della tua build.

L'ho usato con successo su un grande progetto (8 sviluppatori) e ora non userei nient'altro.

Ed è gratuito!

Answer 2

Attualmente utilizziamo SVN e disponiamo di una cartella "UpgradeScripts" in cui tutti gli sviluppatori eseguono il commit dei loro script.

Ogni script ha un prefisso generato nel formato upg_yyyymmddhhmmss_ScriptName.sql - Quindi quando vengono distribuiti vengono eseguiti in un ordine predefinito; mantenere il database coerente.

Questo viene generato attraverso lo SQL sotto ed eseguite attraverso un pre commit gancio:

select 'upg_' + convert(varchar, SYSUTCDATETIME(), 112) 
    + replace(convert(varchar, SYSUTCDATETIME(), 8), ':', '') 
    + '-' 
    + 'MeaningfulScriptName' 

Un'altra tecnica pratica usiamo è assicurarsi che la differenza tra i dati statici e non statici è chiaro; così nel nostro database c'è lo schema standard "dbo" - che indica i dati non statici che possono cambiare tra gli ambienti, e uno schema "statico". Tutte le tabelle in questo schema hanno l'id statico, quindi gli sviluppatori sanno che possono usarle in enumerazione e fare riferimento agli script di id.

Se stai cercando qualcosa di più formale, Red Gate ha un'utilità chiamata SQL Source Control.

Oppure è possibile utilizzare Data Tier Application framework.

Answer 3

Utilizziamo DBGhost per controllare la versione del database. Gli script per creare il database corrente sono memorizzati in TFS (insieme al codice sorgente) e quindi DBGhost viene utilizzato per generare uno script delta per aggiornare un ambiente alla versione corrente. DBGhost può anche creare script delta per qualsiasi dato statico/di riferimento/codice.

Richiede uno spostamento della mente dal metodo tradizionale ma è una soluzione fantastica che non posso raccomandare abbastanza. Sebbene si tratti di un prodotto di terze parti, si adatta perfettamente al nostro processo di creazione e distribuzione automatizzato.