Gestione degli ambienti
Penso che sicuramente non vuoi essere forzato in una singola versione del database. Hai abbastanza sviluppatori che avrai inevitabilmente più flussi di lavoro di sviluppo e requisiti per applicare patch all'attuale ambiente di produzione indipendentemente dai flussi di lavoro di sviluppo.
È possibile utilizzare Liquibase o un processo manuale per produrre script di patch per aggiornare le versioni. Suggerisco di iniziare con un processo manuale e di utilizzare lo strumento di confronto dello schema per il QA sulle patch. La sincronizzazione pulita, automatizzata e trasparente di un database non banalmente complesso è un po 'utopica.
Il tuo modello di dati centrale può essere mantenuto in qualunque sistema desideri. Ho usato di tutto, dai noiosi strumenti di repository enterprise per creare script di tabelle. Creare script di tabelle si gioca bene con i normali strumenti di controllo del codice sorgente come sovversione e non tutti gli strumenti di repository fanno un buon lavoro di controllo delle versioni.
Qualunque cosa tu usi come repository del modello di dati master, hai bisogno di un meccanismo abbastanza pulito per distribuire un ambiente da quel modello. Dovrebbe essere strutturato in modo tale che l'implementazione in un ambiente sia semplice. È inoltre necessario un meccanismo per applicare patch da una versione rilasciata alla successiva.
Quello che ho fatto
Ho fatto quanto segue in passato quando gestivo gli ambienti di sviluppo. Non è particolarmente high-tech, ma è suscettibile di controllo delle versioni e build automatizzate, quindi rende facile implementare un ambiente su una versione specifica e mantenere un gran numero di ambienti è abbastanza pratico.
Mantenere un repository centrale: potrebbe trattarsi di un set di script per la creazione di database contenuti in un sistema di controllo versione o di un modello di repository in uno strumento di modellazione dei dati. Fai la tua scelta. Questo modello dovrebbe avere un meccanismo di compilazione che consenta di implementare un ambiente dagli script senza molto intervento manuale.
Se disponi di molti dati di riferimento, dovrai disporre di un meccanismo di caricamento. A seconda di come lo si desidera, è possibile mantenerlo in un database o in un set di file. Il vantaggio dei file è che possono anche essere versionati ed etichettati dallo stesso sistema di controllo della versione della tua base di codice. Un gruppo di file CSV e script del caricatore di massa in un repository di controllo del codice sorgente può farlo abbastanza facilmente.
Un'opzione per la distribuzione di ambienti di sviluppo è quella di prendere i backup del database di produzione patchati alla versione appropriata e renderli disponibili per gli sviluppatori per ripristinarli in un ambiente di sviluppo.
Semplifica l'implementazione: come ogni processo di compilazione di elementi della configurazione, il database deve essere distribuibile da un singolo script. Configurarlo in modo che le connessioni al database possano essere paramaterizzate o che lo script sia indipendente dalla posizione e possa essere semplicemente eseguito attraverso la connessione.
Script di patch: sarà necessario eseguire il roll forward e probabilmente ripristinare gli script da ciascuna versione rilasciata.
Crea ambienti di test dal modello di repository: questo garantisce che lo sviluppo su ambienti non sincronizzati con il repository venga bloccato nei test.
Testare il processo di distribuzione: gli script di patching automatizzati, tuttavia vengono creati, dovrebbero essere verificabili. Gli strumenti di confronto degli schemi sono abbastanza buoni per questo, anche se non li usi per generare gli script di patch.
Crea un ambiente di riferimento con la build del modello di repository su cui hai provato
Crea un ambiente di prova del fumo con un backup della versione di produzione o una build basata sulla versione rilasciata corrente.
Esegui lo script di patch sull'ambiente test fumo.
Utilizzare lo strumento di confronto degli schemi per confrontare l'ambiente del test del fumo con l'ambiente di riferimento. Lo script di patch dovrebbe risultare identico nei due database, in modo da poter esaminare eventuali differenze.
Quello che mi piace di questo processo
Questo è un po 'pesante ed è stato progettato per essere distribuito in ambienti di produzione abbastanza burocratici e opachi. Tuttavia, ha i seguenti punti di forza:
Gli sviluppatori possono armeggiare dove devono.
È possibile accogliere più rami e flussi di sviluppo.
Gli script di distribuzione stessi possono essere testati in modo ripetibile. Questo è molto utile per chiudere i combattimenti di schieramento, in quanto la ripetibilità può essere dimostrata.
Gli strumenti di confronto degli schemi forniscono QA sulla distribuzione stessa.
I test vengono sempre eseguiti in base a ciò che dovrebbe essere rilasciato e ciò consentirà di rilevare i problemi derivanti da ambienti non sincronizzati.
La distribuzione basata su modelli di repository e script di patch significa che l'immondizia incontrollata non viene migrata accidentalmente dagli ambienti di sviluppo alla produzione.
Gran parte del processo può essere automatizzato, sebbene sia spesso preferibile preparare e testare manualmente gli script delle patch di distribuzione.
Gli ambienti sono economici e facili da implementare senza dover saltare attraverso i cerchi.
Gli sviluppatori sono costretti a creare un sistema adatto a un semplice processo di compilazione e distribuzione.
Gli sviluppatori sono costretti ad apprendere le attività di amministrazione di base del database, ma gli ambienti di test e produzione sono isolati da errori noob.
Come risponde alle tue esigenze
Gli sviluppatori dispongono di una copia locale dei dati per eseguire il codice di sviluppo contro
Gli script di distribuzione o le immagini DB indicano che possono configurare un ambiente da qualsiasi versione disponibile.
In grado di ripristinare la struttura del database su un changeset precedente
Ancora una volta, ordinati per script di distribuzione. Tramite DDL o testando le immagini di backup del database create attraverso un processo controllato, gli sviluppatori possono creare un ambiente per qualsiasi versione specifica in tuo possesso.
In grado di separare le nuove modifiche dello schema delle funzionalità rispetto alle modifiche delle correzioni della progettazione dello schema Le
patch per una versione comune possono essere gestite in un fork separato nella struttura svn. Se i backup del database vengono utilizzati come ambienti di riferimento, devono essere archiviati da qualche parte con la stessa struttura di cartelle della diramazione dei progetti di controllo del codice sorgente.
In grado di modificare la struttura del database a livello locale per i test
Il semplice processo di distribuzione consente agli sviluppatori di armeggiare e ripristinare facilmente un ambiente a uno stato locale, oppure di creare un ambiente di riferimento per fare confronti e apportare modifiche.