Trasferimento di cambiamenti da un DB dev per una produzione DB

Question

Dire che ho un sito web e un database di quel sito web ospitato in locale sul mio computer (per lo sviluppo) e un altro database ospitato (per la produzione) ... cioè prima faccio le modifiche sul db dev e poi faccio le modifiche al DB prod.

Qual è il modo migliore per trasferire le modifiche che ho fatto sul database locale al database ospitato?

Se è importante, sto utilizzando MS Sql Server (2008)

Answer 1

Il modo corretto per fare questo con Visual Studio e SQL Server è quello di aggiungere un database di progetto per la soluzione di web app. Il progetto di database deve avere i file SQL che possono ricreare l'intero database completamente su un nuovo server con tutte le tabelle necessarie, gli utenti procedure e ruoli.

In questo modo, essi sono inclusi nel controllo del codice sorgente per tutto il resto del codice pure.

Non è un modifiche sotto-cartella nel progetto di database in cui ho messo i file SQL che si applicano eventuali nuove modifiche o aggiunte al database per le versioni successive.

Lo SQL nei file deve essere scritto con una corretta "se esiste" blocchi in modo tale che possa essere eseguito in sicurezza più volte su un database già aggiornato senza errori.

Come regola generale, non si dovrebbe mai fare le modifiche direttamente nel database - invece modificare lo script SQL nel progetto e applicarlo al database per assicurarsi che il codice sorgente (i file SQL) è sempre aggiornato <. / p>

Answer 2

Lo facciamo nel (Ruby on) Rails mondo scrivendo "migrazioni", che cattura le modifiche apportate alla struttura di DB ad ogni punto. Questi vengono eseguiti con uno strumento di migrazione (un compito per rastrello), che scrive anche a una tabella DB in modo che sa se un particolare di migrazione è stato eseguito oppure no.

Si potrebbe fare una struttura come questa per la piattaforma dev (Net?), Ma penso che in altre risposte a questa domanda la gente suggerire strumenti disponibili per la gestione delle versioni del database nella vostra piattaforma di sviluppo, o forse per la tua specifica DB .

Non conosco nessuno di questi, ma visitate questa lista . Vedo un sacco di cose a pagamento là fuori, ma ci deve essere qualcosa di gratuito. Anche controllare questo fuori .

Answer 3

la migrazione modifiche tramite script di modifiche scritti dagli sviluppatori quando hanno testato / verificato i loro cambiamenti. (L'eccezione è lo spostamento di grandi di dati.) Tutti gli script sono memorizzati in un sistema di controllo di origine. e può essere verificata da amministratori di database.

Si è manuale, a volte richiede tempo, ma efficace, sicuro e controllato processo.

I database sono troppo vitale per copiare da dev.

Ci sono strumenti per aiutare a creare / verificare questi script. Vedere http://www.red-gate.com/ Ho usato i loro strumenti per confrontare 2 database per creare script. Brian

Answer 4

Se le modifiche sono piccole, a volte li faccio a mano. Per le modifiche più grandi, io uso SQL 's Gate Red Confronta per generare script di modifiche. Questi sono verificati a mano ed eseguire nell'ambiente QA prima per assicurarsi che non si rompono nulla. Per i grandi cambiamenti, corriamo un determinato backup prima di effettuare il cambio sia in QA e nella produzione.

Answer 5

Abbiamo usato per usare l'approccio fornito da Ron. Ha senso per un grande progetto con il team dedicato di DBA. Ma se non si dispone di uno sviluppatori dedicati che scrivono il codice solo per DB questo approccio è tempo e risorse costose .

L'approccio da utilizzare Redgate DB confrontare è, inoltre, non buona. Hai ancora un fare un sacco di lavoro manuale è possibile saltare qualche passaggio per errore .

Ha bisogno di qualcosa di meglio. Questo è stato il motivo per cui abbiamo costruito il "Agile DB Tempo libero / Importa / indietro / Export funzione" Lo strumento è gratuito.

I vantaggi: gli sviluppatori usi strumenti prefered per sviluppare DEV DB. Poi corrono il DB RIRE e rende reverseengeniring DB (tabelle, viste, proc stor, ecc) ed esportare dati in file XML. file XML è possibile mantenere in qualsiasi sistema di repository di codice.

E il secondo passo è quello di eseguire DB RIRE ancora una volta per generare script differenza tra la struttura ed i dati in file XML e nella produzione di DB.

Naturalmente è possibile fare più iterazioni di cui hai bisogno.