Distribuzione di database SQL Server da Test a Live

Question

Mi chiedo come gestite la distribuzione di un database tra 2 SQL Server, in particolare SQL Server 2005.Ora c'è uno sviluppo e uno vivo.Poiché questo dovrebbe far parte di uno script di compilazione (batch di Windows standard, anche con l'attuale complessità di tali script, potrei passare a PowerShell o giù di lì in seguito), Enterprise Manager/Management Studio Express non conta.

Vuoi semplicemente copiare il file .mdf e allegarlo?Sto sempre un po' attento quando lavoro con dati binari, poiché questo sembra essere un problema di compatibilità (anche se sviluppo e live dovrebbero eseguire sempre la stessa versione del server).

Oppure, data la mancanza di "EXPLAIN CREATE TABLE" in T-SQL, fai qualcosa che esporti un database esistente in script SQL che puoi eseguire sul server di destinazione?Se sì, esiste uno strumento in grado di eseguire automaticamente il dump di un determinato database in query SQL e che viene eseguito dalla riga di comando?(Anche in questo caso, Enterprise Manager/Management Studio Express non contano).

E infine, dato che il database live contiene già dati, la distribuzione potrebbe non comportare la creazione di tutte le tabelle ma piuttosto il controllo della differenza nella struttura e ALTER TABLE quelle live, il che potrebbe anche richiedere la verifica/conversione dei dati quando cambiano i campi esistenti.

Ora, ho sentito un sacco di cose fantastiche su Porta Rossa prodotti, ma per i progetti hobbistici il prezzo è un po' alto.

Quindi, cosa stai utilizzando per distribuire automaticamente i database SQL Server da Test a Live?

Answer 1

Ho iniziato a codificare manualmente tutte le mie istruzioni DDL (crea/modifica/elimina), aggiungendole al mio .sln come file di testo e utilizzando il normale controllo delle versioni (usando subversion, ma qualsiasi controllo di revisione dovrebbe funzionare).In questo modo, non solo ottengo il vantaggio del controllo delle versioni, ma l'aggiornamento in tempo reale da dev/stage è lo stesso processo per codice e database: tag, rami e così via funzionano allo stesso modo.

Altrimenti, sono d'accordo che Redgate sia costoso se non hai un'azienda che lo acquista per te.Se riesci a convincere un'azienda a comprartelo, ne vale davvero la pena!

Answer 2

Per i miei progetti alterno SQL Compare di REd Gate e Database Publishing Wizard di Microsoft che puoi scaricare gratuitamenteQui.

La procedura guidata non è efficace come SQL Compare o SQL Data Compare, ma funziona.Un problema è che gli script generati potrebbero richiedere una riorganizzazione e/o modifica per fluire in un colpo solo.

Il lato positivo è che può spostare schema e dati, il che non è male per uno strumento gratuito.

Answer 3

Non dimenticare la soluzione di Microsoft al problema: Edizione del database di Visual Studio 2008.Include strumenti per la distribuzione di modifiche ai database, la produzione di differenze tra database per modifiche di schemi e/o dati, test unitari, generazione di dati di test.

È piuttosto costoso ma ho usato l'edizione di prova per un po' e ho pensato che fosse geniale.Rende il database facile da utilizzare come qualsiasi altro pezzo di codice.

Answer 4

Come Rob Allen, utilizzo SQL Compare/Data Compare di Redgate.Utilizzo anche la procedura guidata di pubblicazione del database di Microsoft.Ho anche un'app console che ho scritto in C# che accetta uno script SQL e lo esegue su un server.In questo modo puoi eseguire script di grandi dimensioni con comandi "GO" da una riga di comando o in uno script batch.

Utilizzo le librerie Microsoft.SqlServer.BatchParser.dll e Microsoft.SqlServer.ConnectionInfo.dll nell'applicazione console.

Answer 5

Lavoro allo stesso modo di Karl, mantenendo tutti i miei script SQL per creare e modificare le tabelle in un file di testo che conservo nel controllo del codice sorgente.Infatti, per evitare il problema di dover fare in modo che uno script esamini il database live per determinare quali ALTER eseguire, di solito lavoro in questo modo:

• Nella prima versione, inserisco tutto durante il test in uno script SQL e tratto tutte le tabelle come CREATE.Ciò significa che finisco per eliminare e leggere molte tabelle durante i test, ma non è un grosso problema all'inizio del progetto (dato che di solito hackero comunque i dati che sto utilizzando a quel punto).
• In tutte le versioni successive, faccio due cose:Creo un nuovo file di testo per contenere gli script SQL di aggiornamento, che contengono solo gli ALTER per quella versione.E apporto le modifiche all'originale, creo anche un nuovo script di database.In questo modo un aggiornamento esegue semplicemente lo script di aggiornamento, ma se dobbiamo ricreare il DB non abbiamo bisogno di eseguire 100 script per arrivarci.
• A seconda di come sto distribuendo le modifiche al DB, di solito inserirò anche una tabella delle versioni nel DB che contiene la versione del DB.Quindi, invece di prendere decisioni umane su quali script eseguire, qualunque sia il codice che ho eseguendo gli script di creazione/aggiornamento utilizza la versione per determinare cosa eseguire.

L'unica cosa che questo non farà è d'aiuto se parte di ciò che stai spostando dal test alla produzione sono dati, ma se vuoi gestire la struttura e non pagare per un pacchetto di gestione DB carino ma costoso, non è davvero molto difficile.Ho anche scoperto che è un ottimo modo per tenere traccia mentale del tuo DB.

Answer 6

Se un'azienda lo acquista, Toad di Quest Software ha questo tipo di funzionalità di gestione integrata.Si tratta fondamentalmente di un'operazione con due clic per confrontare due schemi e generare uno script di sincronizzazione dall'uno all'altro.

Hanno edizioni per la maggior parte dei database più diffusi, incluso ovviamente Sql Server.

Answer 7

Sono d'accordo sul fatto che scrivere tutto in uno script sia la strada migliore da percorrere ed è ciò che sostengo al lavoro.Dovresti creare script per tutto, dalla creazione di DB e oggetti al popolamento delle tabelle di ricerca.

Tutto ciò che fai solo nell'interfaccia utente non verrà tradotto (specialmente per le modifiche...non tanto per le prime implementazioni) e finirà per richiedere strumenti come quello offerto da Redgate.

Answer 8

Utilizzando SMO/DMO, non è troppo difficile generare uno script del tuo schema.I dati sono un po' più divertenti, ma comunque fattibili.

In generale, adotto l'approccio "Script It", ma potresti prendere in considerazione qualcosa in questo senso:

• Distinguere tra sviluppo e staging, in modo da poter sviluppare con un sottoinsieme di dati...in questo modo creerei uno strumento per estrarre semplicemente alcuni dati di produzione o generare dati falsi per quanto riguarda la sicurezza.
• Per lo sviluppo del team, ogni modifica al database dovrà essere coordinata tra i membri del team.Le modifiche allo schema e ai dati possono essere mescolate, ma un singolo script dovrebbe abilitare una determinata funzionalità.Una volta che tutte le funzionalità sono pronte, le raggruppi in un singolo file SQL e lo esegui con un ripristino della produzione.
• Una volta che la fase di staging ha superato l'accettazione, esegui nuovamente il singolo file SQL sulla macchina di produzione.

Ho usato gli strumenti Red Gate e lo sono Grande strumenti, ma se non te lo puoi permettere, costruire gli strumenti e lavorare in questo modo non è troppo lontano dall'ideale.

Answer 9

Sto utilizzando il meccanismo di migrazione di Subsonic, quindi ho solo una DLL con classi in ordine sequenziale che hanno 2 metodi, su e giù.Esiste un hook di script di integrazione/costruzione continua in nant, in modo da poter automatizzare l'aggiornamento del mio database.

Non è la cosa migliore del mondo, ma è meglio della scrittura di DDL.

Answer 10

RedGate SqlCompare è una strada da percorrere secondo me.Eseguiamo regolarmente l'implementazione di DB e da quando ho iniziato a utilizzare questo strumento non mi sono mai guardato indietro.Interfaccia molto intuitiva e alla fine fa risparmiare molto tempo.

La versione Pro si occuperà anche dello scripting per l'integrazione del controllo del codice sorgente.

Answer 11

Mantengo anche gli script per tutti i miei oggetti e dati.Per la distribuzione ho scritto questa utility gratuita: http://www.sqldart.com.Ti consentirà di riordinare i file di script e eseguirà l'intero lotto all'interno di una transazione.

Answer 12

Sono d'accordo nel mantenere tutto nel controllo del codice sorgente e nello scriptare manualmente tutte le modifiche.Le modifiche allo schema per una singola versione vengono inserite in un file di script creato appositamente per quella versione.Tutti i processi, le visualizzazioni, ecc. archiviati dovrebbero essere inseriti in file individuali e trattati proprio come .cs o .aspx per quanto riguarda il controllo del codice sorgente.Utilizzo uno script PowerShell per generare un grande file .sql per aggiornare gli elementi di programmabilità.

Non mi piace automatizzare l'applicazione delle modifiche allo schema, come nuove tabelle, nuove colonne, ecc.Quando eseguo una versione di produzione, mi piace eseguire lo script di modifica comando per comando per assicurarmi che ognuno funzioni come previsto.Non c'è niente di peggio che eseguire uno script di grande modifica in produzione e ottenere errori perché hai dimenticato qualche piccolo dettaglio che non si era presentato durante lo sviluppo.

Ho anche imparato che gli indici devono essere trattati proprio come file di codice e inseriti nel controllo del codice sorgente.

E dovresti sicuramente avere più di 2 database: sviluppo e live.Dovresti avere un database di sviluppo che tutti utilizzano per le attività di sviluppo quotidiane.Quindi un database di staging che imita la produzione e viene utilizzato per eseguire i test di integrazione.Quindi forse una copia recente e completa della produzione (ripristinata da un backup completo), se ciò è fattibile, in modo che l'ultimo ciclo di test di installazione vada contro qualcosa che sia il più vicino possibile alla realtà.

Answer 13

Eseguo tutta la creazione del mio database come DDL e quindi avvolgo quel DDL in una classe di manutenzione dello schema.Potrei fare varie cose per creare il DDL in primo luogo, ma fondamentalmente eseguo tutta la manutenzione dello schema nel codice.Ciò significa anche che se è necessario fare cose non DDL che non si adattano bene a SQL, è possibile scrivere la logica procedurale ed eseguirla tra grumi di DDL/DML.

I miei dbs hanno quindi una tabella che definisce la versione corrente in modo da poter codificare una serie di test relativamente semplice:

1. Il DB esiste?Altrimenti crealo.
2. Il DB è la versione attuale?In caso contrario, esegui i metodi, in sequenza, che aggiornano lo schema (potresti voler chiedere all'utente di confermare e, idealmente, di eseguire i backup a questo punto).

Per un'app per utente singolo, lo eseguo semplicemente sul posto, per un'app Web attualmente blocchiamo l'utente se le versioni non corrispondono e disponiamo di un'app di manutenzione dello schema autonoma che eseguiamo.Per il multiutente dipenderà dall'ambiente particolare.

Il vantaggio?Ebbene, ho un livello molto elevato di certezza che lo schema per le app che utilizzano questa metodologia sia coerente in tutte le istanze di tali applicazioni.Non è perfetto, ci sono dei problemi, ma funziona...

Ci sono alcuni problemi quando si sviluppa in un ambiente di squadra, ma questo è comunque più o meno scontato!

Murph

Answer 14

Attualmente sto lavorando alla stessa cosa con te.Non solo la distribuzione dei database SQL Server dal test al live, ma include anche l'intero processo da Locale -> Integrazione -> Test -> Produzione.Quindi ciò che può rendermi facile ogni giorno è farlo Attività NAnt con confronto SQL Red-Gate.Non lavoro per RedGate ma devo dire che è una buona scelta.