MSBuild: automatizza la raccolta di script di migrazione db?

Question

Riassunto dell'ambiente.

• applicazione Asp.net web (fonte memorizzati in svn) banca dati
• SQL Server. (Schema del database (tabelle/sproc) memorizzato in svn)
• versione db è sincronizzata con la versione di assemblaggio dell'applicazione web. (memorizzato nella tabella 'CurrentVersion')
• Server hudson CI che estrae l'app Web dal repository e esegue il file msbuild personalizzato per pubblicare l'app/pacchetto.

Il mio script msbuild aggiorna la versione dell'assembly dell'app Web (Major.Minor.Revision.Build) su ogni build. La 'Revisione' è impostata sulla revisione svn correntemente selezionata e la 'Build' sul numero di build di hudson (incrementato su ogni build automatizzata).

In questo modo è possibile abbinare l'app a una specifica revisione del tronco e ottenere anche altre statistiche di build dal numero di build di hudson.

Mi piacerebbe automatizzare la raccolta di script di migrazione (sproc ecc aggiornati) da aggiungere al pacchetto zip. Immagino che confrontando la revisione svn del db che deve ancora essere distribuito, alla versione distribuita, posso trovare quali file db sono stati modificati nel trunk dall'ultima distribuzione a quel database/ambiente.

Questo potrebbe essere facilmente ottenuto chiamando manualmente il comando svn diff -r REVNO:REVNO per elencare i file .sql modificati. Questi file potrebbero quindi essere aggiunti manualmente al pacchetto. Sarebbe bello se questo potesse essere automatizzato.

Innanzitutto immagino che dovrò scrivere un'attività personalizzata per verificare la versione del db che deve ancora essere distribuita. Dopo di ciò sono abbastanza insicuro. Qualcuno ha qualche suggerimento su come questo sarebbe ottenuto attraverso un'attività di msbuild esistente o personalizzata?

Infine dovrò autogenare uno script da aggiungere al pacchetto che aggiorna la tabella delle versioni del database in modo da essere sincronizzato con l'applicazione.

Answer 1

Dai un'occhiata ai progetti di database SQL. In VS 2010 sono stati migliorati un po 'e hanno incorporato funzionalità di implementazione che possono sincronizzare il database DEV in altri ambienti.

Ecco alcuni buoni collegamenti con progetti DB in vs 2010: http://msmvps.com/blogs/deborahk/archive/2010/05/02/vs-2010-database-project-building-and-deployment.aspx

http://weblogs.asp.net/gunnarpeipman/archive/2009/07/29/visual-studio-2010-database-projects.aspx

Answer 2

Prova Examiner SQL: http://www.sqlaccessories.com/Howto/Version_Control.aspx

È possibile automatizzare script di raccolta con lo strumento da riga di comando SQL Examiner .

Answer 3

L'integrazione delle modifiche SQL in un processo di build/deploy automatico è HARD. Lo so, perché ci ho provato un paio di volte con scarso successo. Quello che stai cercando di fare è all'incirca sulla strada giusta, ma direi che in realtà è un po 'troppo complicato. Nella tua proposta, suggerisci di raccogliere gli specifici script SQL che devono essere applicati al tuo DB in fase di compilazione/pacchetto.Invece, dovresti impacchettare tutti gli i tuoi script delta (per l'intera cronologia del tuo database) con il tuo progetto e calcolare i delta che devono essere effettivamente applicati quando tu distribuisci - in questo modo, il tuo pacchetto deployable può essere distribuito in ambienti con database di versioni diverse. Esistono due parti di implementazione che è necessario per ottenere questo:

1) È necessario pacchettizzare i delta nel pacchetto distribuibile. Si noti che è necessario il pacchetto deltas - non i file statici che creano lo schema nel suo stato corrente. Questi script delta dovrebbero essere nel controllo del codice sorgente. Va bene mantenere lo schema statico anche nel controllo del codice sorgente, ma dovrai mantenerlo sincronizzato con i delta. È possibile utilizzare effettivamente uno strumento come SQLCompare di Red Gate o la versione del database VS per generare (la maggior parte) delta dallo schema statico. Per ottenere i delta nel tuo pacchetto distribuibile, e dato che stai usando svn - potresti voler guardare in svn: esterni come un modo per "linkare" gli script delta nel tuo progetto web. Lo script di build può quindi semplicemente copiarli nel pacchetto distribuibile.

2) È necessario un sistema in grado di leggere l'elenco dei file delta, confrontarli con un database esistente, determinare quali delta devono essere applicati a tale database e quindi applicare i delta (e aggiornare le informazioni di contabilità, come la versione del database). Esiste un progetto open source (sponsorizzato da ThoughtWorks) chiamato dbdeploy che lo porta a termine. Ho avuto un certo successo con quello strumento personalmente.

Buona fortuna - questo è un dado difficile da decifrare (correttamente).

Answer 4

le soluzioni oggi disponibili che colpiscono uno stack .NET/SQL Server sono:

• DBUp (open source)
• ReadyRoll (più profonda integrazione di Visual Studio, auto-generazione di script)

Quest'ultimo prodotto è uno di quelli che stiamo sviluppando attivamente qui a Redgate.