Gestione del database SQL Server con integrazione continua

Question

Diciamo che abbiamo un server di integrazione continua. Quando eseguo il check-in, il post-hook estrae l'ultimo codice, esegue i test, impacchetta tutto. Qual è il modo migliore per automatizzare anche le modifiche al database?

Idealmente, creerei un programma di installazione che potrebbe creare un database da zero o aggiornarne uno esistente usando un metodo di sincronizzazione automatica.

Answer 1

Se hai la possibilità di definire e controllare l'intero processo di gestione del database e di creazione del database, dai un'occhiata a DB Ghost - è più di un semplice strumento - è un processo.

Se ti piace e puoi implementarlo, otterrai grandi ritorni su di esso - ma è un po 'un "tutto o niente"; tipo di approccio. Consigliato.

Answer 2

Di recente mi sono imbattuto in un articolo , che potrebbe essere utile.

L'autore ha spiegato alcune delle migliori pratiche di integrazione continua tra cui test, elaborazione e automazione.

Ecco alcuni dei principali punti da asporto:

• In molti negozi il codice viene testato unitariamente al punto di commit. Per i database, è preferibile eseguire tutti i test unitari contemporaneamente e in sequenza su un database QA, rispetto allo sviluppo, come parte del passaggio Test
• Il passaggio del test è una parte fondamentale di qualsiasi processo CI / CD. Gli script di test, inclusi gli unit test stessi, dovrebbero anche essere sottoposti a versione nel controllo del codice sorgente, estratti al punto del passaggio Build ed eseguiti
• L'estrazione dei dati dalla produzione è interessante come espediente rapido, ma non è mai una buona idea
• L'approccio migliore consiste nell'utilizzare uno strumento o uno script per creare rapidamente, ripetutamente e in modo affidabile dati di test sintetici per le tabelle transazionali
• L'esecuzione di test unitari per produrre risultati di riepilogo manuali per il consumo umano vanifica lo scopo dell'automazione. Abbiamo bisogno di risultati leggibili meccanicamente, che possano consentire l'interruzione, la diramazione e / o la prosecuzione di un processo automatizzato.
• L'esecuzione di un processo CI, che richiede il 100% di tutti i test per passare, è simile al fatto di non avere CI, se la pipeline del flusso di lavoro è impostata atomicamente per arrestarsi in caso di fallimento, cosa che dovrebbe. Per infilare l'ago, i test dovrebbero avere soglie incorporate, che genereranno un errore basato sulla percentuale di test falliti o in alcuni casi, se alcuni test ad alta priorità falliscono.
• Tutti i processi dovrebbero in definitiva produrre un risultato booleano di passaggio o fallimento, ma alcuni processi non automatizzati possono facilmente trovare la strada nella pipeline del flusso di lavoro degli elementi della configurazione (ad esempio test delle unità). Il software dovrebbe essere plug-n-play in qualsiasi pipeline del flusso di lavoro, prendendo input noti e producendo output previsti - come pass, fail.
• Il processo CI / CD deve essere interrotto in caso di errore e deve essere inviata immediatamente un'e-mail di notifica anziché continuare a scorrere la pipeline.
• Il processo CI non dovrebbe ripetere il ciclo finché non vengono corretti errori nell'ultima build. In caso di fallimento, l'intero team dovrebbe ricevere la notifica di errore, includendo quanti più dettagli possibile su ciò che è fallito.
• Se una pipeline impiega 1 ora, dall'inizio alla fine, per completare, compresi tutti i test, tutti gli intervalli di compilazione devono essere impostati su non meno di un'ora e tutti i nuovi commit devono essere messi in coda e applicati al successivo costruire.
• Non dovrebbero esistere password in testo normale negli script di automazione

Answer 3

Vorrei mettere in guardia dall'utilizzare un backup db come artefatto di sviluppo, la maggior parte delle migliori pratiche CI suggerisce di gestire lo schema, le procedure, i trigger e le viste come artefatti di sviluppo di prima classe. Gli effetti collaterali sono che puoi fare un ulteriore passo avanti e usarli per creare un nuovo database ogni volta che vuoi, idealmente hai anche alcuni dati che possono essere inseriti nel database.

Ecco una versione scogliera per bagnare i piedi, ma ce n'è un sacco là fuori in questo spazio:   http://www.infoq.com/news/2008/02/versioning_database_series

Mi piacciono alcune delle idee che Scott Ambler ha anche qui, il sito è buono ma il libro è sorprendentemente profondo per una serie di problemi così difficili. http://www.agiledata.org/ http://www.amazon.com/exec/obidos/ASIN/0321293533/ambysoftinc

Answer 4

Red Gate è una soluzione abbastanza robusta e pronta all'uso. Ma la cosa migliore è che puoi integrarlo con il tuo processo di integrazione continua. Lo uso con Msbuild e Hudson. spiegando rapidamente come funziona: http://blog.vincentbrouillet.com/post / 2011/02/10 / Database-schema-sincronizzazione-con-Redgate

se hai bisogno di saperne di più, non esitare a chiedere

Answer 5

L'approccio di Red Gate che utilizza SQL Source Control e la riga di comando di SQL Compare Pro è dettagliato con esempi di codice qui: http://downloads.red-gate.com/HelpPDF/ContinuousIntegrationForDatabasesUsingRedGateSQLTools.pdf

Troy Hunt ha scritto un articolo su Simple Talk intitolato " Integrazione continua per database SQL Server " ;: http://www.simple-talk.com/content/article.aspx ? article = 1247

Answer 6

Hai guardato FluentMigrator ? Il download predefinito include script Nant che sarebbero facili da aggiungere a un elemento della configurazione. Gratuito, open source e facile da usare. Funziona con un'ampia varietà di database.

Answer 7

L'ultima versione (5.0) di DB Ghost non soffre del carattere "non ASCII" problema (significa solo che il file è codificato UTF8) e dovrebbe essere in grado di fare esattamente ciò di cui hai bisogno.

Inoltre, gli strumenti possono essere effettivamente utilizzati autonomamente per eseguire le varie funzioni (scripting, creazione, confronto, aggiornamento e packaging) se lo si desidera, è solo che utilizzarli tutti insieme fornisce un processo completo end-to-end rendendo quindi il valore complessivo maggiore della somma delle sue parti.

In sostanza, per apportare modifiche allo schema aggiorni gli script di creazione di singoli oggetti e gli script di inserimento per tabella (per i dati di riferimento) che sono mantenuti sotto il controllo del codice sorgente proprio come se stessi sviluppando un & # 8220; primo giorno & # 8221; database greenfield. Gli strumenti DB Ghost vengono utilizzati per abilitare il tutto creando questi script in un database nuovo di zecca (utilizzando l'integrazione continua se necessario) e quindi confrontando e aggiornando un database di destinazione, che può essere una copia del database di produzione. Questo processo produce uno script delta che può essere utilizzato sul database di produzione reale durante il go-live.

Puoi persino produrre un progetto di database di Visual Studio e aggiungerlo a qualsiasi soluzione tu abbia attualmente.

Malc

Answer 8

So che questo post è vecchio, ma abbiamo una nuova soluzione che adotta il seguente approccio:

1. Gli sviluppatori eseguono lo script di singole modifiche SQL e le commettono alla fonte controllo.
2. Il nostro programma ( OneScript ) estrae i file di script di modifica da     controllo del codice sorgente, li filtra e li ordina e genera un singolo     rilasciare il file di script.
3. Questo file di script di rilascio viene quindi applicato a         database per rilasciare una versione.

La nostra home page qui spiega questo processo in modo più dettagliato e ha un link a un esempio che fa questi passa automaticamente da un hook Subversion. Quindi, subito dopo un commit, lo sviluppatore riceve un'email che dice se la versione ha avuto successo o ha avuto errori. Il codice PowerScript è incluso.

Dichiarazione di non responsabilità: sto lavorando presso l'azienda che produce OneScript.