Come gestite le revisioni del database su un progetto di medie dimensioni con filiali?

Question

Al lavoro abbiamo 4 persone che lavorano insieme su alcuni progetti diversi. Per ogni progetto ognuno di noi ha una copia locale su cui lavoriamo e poi c'è uno sviluppo, una gestione temporanea e una distribuzione live, insieme a tutti i rami che abbiamo (usiamo la sovversione). Il nostro database è MySQL.

Quindi la mia domanda è: qual è un buon modo per gestire quali revisioni al database sono state fatte ad ogni distribuzione (e per gli sviluppatori le loro copie locali). In questo momento ogni modifica va in un file di testo che è timestamp nel nome e messo in una cartella sotto il progetto. Ad essere onesti, questo non funziona molto bene. Ho bisogno di una soluzione che mi aiuti a tenere traccia di ciò che è stato applicato dove.

Answer 1

Se il tuo database si associa perfettamente a una serie di oggetti di accesso ai dati, considera l'utilizzo di "migrazioni". L'idea è di archiviare il modello di dati come codice dell'applicazione con i passaggi per spostarsi avanti e indietro in ciascuna versione del database.

Credo che Rails lo ha fatto per primo .

Java ha almeno un progetto .

Ed ecco una libreria di migrazione .NET .

Per cambiare versione, esegui un semplice script che passi attraverso tutte le versioni su o giù per arrivare alla versione desiderata. Il bello è che controlli le tue migrazioni nello stesso repository di origine del codice dell'app: è tutto in un unico posto.

Forse altri possono suggerire altre librerie di migrazione.

Saluti.

Modifica: vedi anche https://stackoverflow.com/questions/313/net-migrations-engine e Riepilogo dello strumento di migrazione del database .NET (dal precedente post).

Answer 2

http://odetocode.com/Blogs/scott /archive/2008/01/30/11702.aspx

Il blog sopra ci ha portato al nostro attuale sistema di controllo della versione del database. In poche parole, non vengono apportate modifiche al DB senza uno script di aggiornamento e tutti gli script di aggiornamento si trovano nel nostro repository di controllo del codice sorgente.

Gestiamo solo le modifiche allo schema ma potresti anche essere in grado / disposto a considerare di mantenere disponibili i dump dei tuoi dati anche nel controllo della versione; la creazione di tali file è un esercizio piuttosto banale usando mysqldump.

La nostra soluzione differisce dalla soluzione presentata nel blog in un modo chiave: non è automatizzata. Dobbiamo applicare manualmente gli aggiornamenti del database, ecc. Sebbene ciò possa richiedere un po 'di tempo, ha posticipato lo sforzo richiesto da un sistema completamente automatizzato. Una cosa che abbiamo automatizzato, tuttavia, è stata il tracciamento della versione db nel software: questo era piuttosto semplice e assicura che il nostro software sia a conoscenza del database su cui è in esecuzione e funzionerà SOLO se conosce lo schema con cui sta funzionando.

La parte più difficile della nostra soluzione è stata come unire gli aggiornamenti dai nostri rami nel nostro trunk. Abbiamo impiegato del tempo per sviluppare un flusso di lavoro per affrontare la possibilità che due sviluppatori cercassero di unire le filiali con gli aggiornamenti DB contemporaneamente e come gestirlo. Alla fine abbiamo deciso di bloccare un file nel controllo versione (il file in questione per noi è in realtà una versione del software di mappatura delle tabelle alla versione db che assiste nella nostra strategia di gestione manuale), proprio come faresti con una sezione critica di un thread e lo sviluppatore che ottiene il blocco comporta l'aggiornamento del trunk. Una volta completato, l'altro sviluppatore sarebbe in grado di bloccare ed è loro responsabilità apportare tutte le modifiche necessarie ai propri script per garantire che le collisioni di versione previste e altri juju difettosi siano evitati.

Answer 3

Manteniamo tutti gli script del nostro database (dati e schema / ddl) sotto controllo della versione. Manteniamo anche un catalogo centrale delle modifiche. Quando uno sviluppatore apporta una modifica a un file schema / DDL o aggiunge uno script che modifica i dati in qualche modo, tali file vengono aggiunti al catalogo, insieme al numero di commit SVN.

Abbiamo messo insieme una piccola utility che legge le modifiche al catalogo e crea un grande script di aggiornamento basato sul contenuto del catalogo, afferrando i contenuti di ogni revisione nel catalogo e applicandoli. Il concetto è abbastanza simile allo strumento DBDeploy , che credo provenga originariamente da Thoughtworks , quindi potresti essere in grado di utilizzarlo. Ti darà almeno un buon punto di partenza, da quel momento puoi personalizzare una soluzione più direttamente adatta alle tue esigenze.

Buona fortuna!