Come incorporare un database in un processo di controllo della versione per ramo?

Propongo di esaminare in code migrations per la tua lingua o tecnologia. Possiedo uno stack .NET e posso utilizzare Entity Framework Migrations in cui ogni modifica dello schema è una singola migrazione che può essere automaticamente applicata al database quando necessario. Ciò che è anche possibile è il downgrade del database, quindi il pattern per la migrazione di db è che hai un metodo per Up() e Down() questo è davvero un risparmio di tempo quando devi affrontare test, staging, produzione per mantenere le modifiche in un posto e don Non preoccuparti di aggiornare le cose manualmente.

Ma potresti aggiornare la domanda con lo stack tecnologico che hai a disposizione, quindi qualcuno potrebbe fornirti i dettagli specifici della tua tecnologia.

L'approccio che seguo si basa sui seguenti presupposti:

1. Gli sviluppatori non devono preoccuparsi dei dati di produzione. Questo è per il dipartimento delle operazioni di cui preoccuparsi.

2. I file di configurazione xml, gli script, ecc. devono essere mantenuti al minimo.

3. Tutto deve essere nel repository del codice sorgente.

4. Il repository del codice sorgente deve contenere solo file di testo diffetti, niente binari.

5. Gli RDBMS non sono altro che strumenti che utilizziamo per mantenere i nostri dati: esistono per servirci, non dovremmo perdere il nostro tempo per curarli.

Quindi, quello che faccio è che considero i file del database come qualcosa di completamente spendibile.

Ho una serie di classi che descrivono il mio "modello", da cui viene calcolato automaticamente lo schema del database, e dopo l'istanziazione il modello popola anche il database con tutti i dati predefiniti necessari se manca. Quindi, come sviluppatore, lavori sempre sul tuo database locale (che, per inciso, potrebbe essere HSQLDB per la velocità) e puoi in qualsiasi momento eliminare tutte le tabelle del tuo database, o anche l'intero catalogo, e eseguire l'applicazione, a quel punto l'applicazione ricreare tutto ciò che non trova esistere. Ciò significa che puoi tornare a qualsiasi revisione o passare a qualsiasi ramo in qualsiasi momento, e sei subito a posto.

I test creano anche i propri cataloghi a eliminazione diretta che compilano inoltre con i dati di esempio di cui hanno bisogno per essere eseguiti. Fanno uso delle classi del modello, quindi il database viene prima creato automaticamente per loro, e poi ognuno di essi aggiunge i dati di test di cui ha bisogno. Io uso il nome del pacchetto del test (nome dello spazio dei nomi in .Net parlance) come nome del catalogo per ciascun test, in modo che una suite di test non sporchi i dati di un'altra suite di test.

Il mantenimento dei dati aziendali effettivi per l'ambiente di produzione è responsabilità esclusiva del reparto operativo. Quando agli sviluppatori viene rilasciata una versione, sono le operazioni che devono convertire tutti i vecchi dati che hanno nel nuovo formato di database. Gli sviluppatori potrebbero in teoria aiutarli fornendo punti di ingresso che possono essere invocati per convertire una vecchia versione in una nuova versione, ma risulta che questo causa più problemi di quanti ne risparmia, quindi in realtà le operazioni vengono lasciate completamente da sole. Hanno ingegneri, sanno come scrivere script per l'RDBMS che usano, possono gestirlo bene. Sono anche quelli che hanno la conoscenza di come le vecchie informazioni dovrebbero essere convertite in nuove informazioni e quali tipi di valori sono adatti come valori predefiniti per le colonne introdotte di recente.

Da ciò segue che gli unici tipi di file che devono essere memorizzati nel sistema di controllo della versione sono il codice e una quantità minima di file di configurazione.

Un'altra cosa in più:

Potresti essere tentato di mantenere la struttura del tuo database come un file SQL contenente tutto il DDL necessario per descrivere il tuo schema e tutto il DML necessario per compilare il nuovo schema con dati predefiniti. Non farlo.

Le informazioni contenute nei file di configurazione e negli script non devono mai sovrapporsi o duplicare le informazioni rappresentate nel codice. Un file di schema che elenca le tabelle del database e le colonne di ogni tabella è malvagio, perché presumibilmente il tuo codice dovrà essere scritto per avere anche conoscenza di queste stesse entità, quindi alterare il file dello schema non ti farà bene a meno che il le modifiche corrispondenti sono fatte nel codice, e la modifica del codice è anche inutile senza riflettere le modifiche al file dello schema con scrupolosa attenzione a farlo esattamente nel modo giusto. Chiaramente, uno dei due deve andare. Non è possibile sbarazzarsi del codice, quindi il file dello schema è quello che deve andare.

Non solo "Codice prima", ma anche "Solo codice".