Come posso mettere un database sotto git (controllo versione)?

Sto facendo un'app Web e ho bisogno di creare un ramo per alcune importanti modifiche, il fatto è che queste modifiche richiedono modifiche allo schema del database, quindi vorrei mettere anche l'intero database in git.

Come lo faccio? esiste una cartella specifica che posso conservare in un repository git? Come faccio a sapere quale? Come posso essere sicuro di mettere la cartella giusta?

Devo essere sicuro, perché questi cambiamenti non sono compatibili con le versioni precedenti; Non posso permettermi di sbagliare.

Il database nel mio caso è PostgreSQL

Modificare:

Qualcuno ha suggerito di eseguire i backup e di mettere il file di backup sotto il controllo della versione invece del database. Ad essere sincero, lo trovo davvero difficile da ingoiare.

Deve esserci un modo migliore.

Aggiornare:

OK, quindi non c'è modo migliore, ma non sono ancora del tutto convinto, quindi cambierò un po 'la domanda:

Vorrei mettere l'intero database sotto controllo di versione, quale motore di database posso usare in modo da poter mettere il database effettivo sotto controllo di versione anziché il suo dump?

Sqlite sarebbe git-friendly?

Dato che questo è solo l'ambiente di sviluppo, posso scegliere qualunque database io voglia.

Edit2:

Quello che voglio davvero non è tenere traccia della mia storia di sviluppo, ma essere in grado di passare dal mio ramo "nuovi cambiamenti radicali" al "ramo stabile corrente" ed essere in grado, ad esempio, di correggere alcuni bug / problemi, ecc. Con l'attuale ramo stabile. In modo tale che quando cambio i rami, il database diventa automaticamente magicamente compatibile con il ramo in cui mi trovo attualmente. Non mi interessa molto dei dati reali.

Prendi un dump del database e controlla invece la versione. In questo modo è un file di testo piatto.

Personalmente suggerisco di mantenere sia un dump di dati sia un dump di schema. In questo modo usando diff diventa abbastanza facile vedere cosa è cambiato nello schema da revisione a revisione.

Se si stanno apportando grandi modifiche, è necessario disporre di un database secondario in cui apportare le modifiche al nuovo schema e non toccare quello precedente poiché, come si è detto, si sta eseguendo una diramazione.

Dai un'occhiata ai database di refactoring ( http://databaserefactoring.com/ ) per una serie di buone tecniche per mantenere il tuo database in parallelo con le modifiche al codice.

Basti dire che stai facendo le domande sbagliate. Invece di mettere il database in git, dovresti scomporre le modifiche in piccoli passaggi verificabili in modo da poter migrare / ripristinare le modifiche dello schema con facilità.

Se si desidera avere la completa recuperabilità, è necessario considerare l'archiviazione dei registri WAL di Postgres e utilizzare il PITR (recupero temporizzato) per riprodurre le transazioni avanti / indietro verso specifici stati noti.

Sto iniziando a pensare a una soluzione davvero semplice, non so perché non ci avevo pensato prima !!

• Duplica il database (sia lo schema che i dati).
• Nel ramo per le novità principali, è sufficiente modificare la configurazione del progetto per utilizzare il nuovo database duplicato.

In questo modo posso cambiare filiale senza preoccuparmi delle modifiche allo schema del database.

MODIFICARE:

Per duplicato, intendo creare un altro database con un nome diverso (come my_db_2); non fare una discarica o qualcosa del genere.

Usa qualcosa come LiquiBase che ti consente di mantenere il controllo di revisione dei tuoi file Liquibase. puoi etichettare le modifiche solo per la produzione e far sì che lb mantenga aggiornato il tuo DB per la produzione o lo sviluppo (o qualunque schema tu voglia).

Di fronte a esigenze simili ed ecco cosa hanno messo a punto le mie ricerche sui sistemi di controllo della versione del database:

1. Sqitch - open source basato su perl; disponibile per tutti i principali database, incluso PostgreSQL https://github.com/sqitchers/sqitch
2. Mahout - solo per PostgreSQL; controllo versione schema schema database open source. https://github.com/cbbrowne/mahout
3. Liquibase - un altro sw di controllo della versione db open source. versione gratuita di Datical. http://www.liquibase.org/index.html
4. Datical - versione commerciale di Liquibase - https://www.datical.com/
5. Flyway di BoxFuse - sw commerciale. https://flywaydb.org/
6. Un altro progetto open source https://gitlab.com/depesz/Versioning L' autore fornisce una guida qui: https://www.depesz.com/2010/08/22/versioning/
7. Red Gate Change Automation - solo per SQL Server. https://www.red-gate.com/products/sql-development/sql-change-automation/

C'è un grande progetto chiamato Migrations under Doctrine che è stato creato proprio per questo scopo.

È ancora nello stato alfa e costruito per php.

http://docs.doctrine-project.org/projects/doctrine-migrations/en/latest/index.html

Mi sono imbattuto in questa domanda, poiché ho un problema simile, in cui qualcosa che si avvicina a una struttura di directory basata su DB, memorizza i "file" e ho bisogno di git per gestirlo. È distribuito, attraverso un cloud, usando la replica, quindi il suo punto di accesso sarà via MySQL.

L'essenza delle risposte di cui sopra, sembra suggerire allo stesso modo una soluzione alternativa al problema chiesto, che tipo di errore manca il punto, di usare Git per gestire qualcosa in un database, quindi cercherò di rispondere a questa domanda.

Git è un sistema che in sostanza memorizza un database di delta (differenze), che può essere riassemblato, al fine di riprodurre un contesto. L'uso normale di git presuppone che il contesto sia un filesystem e che i delta siano diff in quel file system, ma in realtà tutto ciò che è git è un database gerarchico di delta (gerarchico, perché nella maggior parte dei casi ogni delta è un commit con almeno 1 genitori, disposti in un albero).

Finché è possibile generare un delta, in teoria git può memorizzarlo. Il problema è normalmente che git si aspetta che il contesto, su cui sta generando delta, sia un file system, e allo stesso modo, quando si controlla un punto nella gerarchia di git, si aspetta di generare un filesystem.

Se vuoi gestire il cambiamento, in un database, hai 2 problemi discreti e li affronterei separatamente (se fossi in te). Il primo è lo schema, il secondo sono i dati (anche se nella tua domanda, dichiari che i dati non sono qualcosa di cui ti preoccupi). Un problema che avevo in passato era un database Dev e Prod, in cui Dev poteva apportare modifiche incrementali allo schema e tali modifiche dovevano essere documentate in CVS e propagandate a vivere, insieme a aggiunte a uno dei numerosi "statici" tabelle. Lo abbiamo fatto avendo un terzo database, chiamato Cruise, che conteneva solo i dati statici. In qualsiasi momento lo schema di Dev e Cruise poteva essere confrontato e avevamo uno script per prendere il diff di quei 2 file e produrre un file SQL contenente istruzioni ALTER, per applicarlo. Allo stesso modo qualsiasi nuovo dato, potrebbe essere distillato in un file SQL contenente comandi INSERT. Finché i campi e le tabelle vengono aggiunti e mai eliminati, il processo potrebbe automatizzare la generazione delle istruzioni SQL per applicare il delta.

Il meccanismo con cui git genera delta è diffe viene chiamato il meccanismo con cui combina 1 o più delta con un file merge. Se riesci a trovare un metodo per differenziare e fondere da un contesto diverso, git dovrebbe funzionare, ma come è stato discusso potresti preferire uno strumento che lo fa per te. Il mio primo pensiero verso la risoluzione è questo https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#External-Merge-and-Diff-Tools che spiega come sostituire il diff interno di git e strumento di unione. Aggiornerò questa risposta, mentre trovo una soluzione migliore al problema, ma nel mio caso mi aspetto di dover gestire solo le modifiche dei dati, in quanto un archivio basato su DB potrebbe cambiare, quindi la mia soluzione potrebbe non essere esattamente quello di cui hai bisogno.

Dai un'occhiata a RedGate SQL Source Control.

http://www.red-gate.com/products/sql-development/sql-source-control/

Questo strumento è uno snap-in di SQL Server Management Studio che ti permetterà di posizionare il tuo database nel controllo del codice sorgente con Git.

È un po 'caro a $ 495 per utente, ma è disponibile una versione di prova gratuita di 28 giorni.

NOTA Non sono affiliato con RedGate in alcun modo.

Voglio fare qualcosa di simile, aggiungere le modifiche al mio database al mio sistema di controllo della versione.

Seguirò le idee in questo post di Vladimir Khorikov "Best practice per il controllo delle versioni del database" . In sintesi lo farò

• memorizzare sia il suo schema che i dati di riferimento in un sistema di controllo del codice sorgente.
• per ogni modifica creeremo uno script SQL separato con le modifiche

Nel caso in cui aiuti!

• Irmin
• Flur.ee
• Crux DB

Ho cercato la stessa funzionalità per Postgres (o database SQL in generale) da un po ', ma non ho trovato abbastanza strumenti adeguati (semplici e intuitivi). Ciò è probabilmente dovuto alla natura binaria di come sono archiviati i dati. Klonio sembra ideale ma sembra morto. Noms DB sembra interessante ( e vivo ). Dai un'occhiata anche a Irmin (basato su OCaml con proprietà Git).

Anche se questo non risponde alla domanda in quanto funzionerebbe con Postgres, controlla il database Flur.ee. Ha una funzione di "viaggio nel tempo" che ti permette di interrogare i dati da un punto temporale arbitrario. Immagino che dovrebbe essere in grado di funzionare con un modello "ramificato".

Questo database è stato recentemente sviluppato per scopi blockchain. A causa della natura delle blockchain, i dati devono essere registrati in incrementi, esattamente come funziona git. Stanno prendendo di mira una versione open source nel secondo trimestre del 2019 .

Poiché ogni database Fluree è una blockchain, memorizza l'intera cronologia di ogni transazione eseguita. Questo fa parte di come una blockchain garantisce che le informazioni siano immutabili e sicure .

Aggiornamento : controlla anche il database Crux , che può eseguire query nella dimensione temporale degli inserti, che potresti vedere come "versioni". Crux sembra essere un'implementazione open source del Datomic molto apprezzato.

Crux è un database bitemporal che memorizza i tempi di transazione e le cronologie valide. Mentre un database [uni] temporale abilita l'interrogazione "viaggi nel tempo" attraverso la sequenza transazionale degli stati del database dal momento della creazione del database allo stato corrente, Crux fornisce anche interrogazioni "viaggi nel tempo" per un asse temporale discreto valido senza inutili complessità di progettazione o impatto sulle prestazioni. Ciò significa che un utente Crux può popolare il database con informazioni passate e future indipendentemente dall'ordine in cui le informazioni arrivano e apportare correzioni alle registrazioni passate per costruire un modello temporale in costante miglioramento di un determinato dominio.

Non puoi farlo senza atomicità e non puoi ottenere atomicità senza usare pg_dump o un filesystem snapshot.

La mia istanza di postgres si trova su zfs, che ogni tanto faccio un'istantanea. È approssimativamente istantaneo e coerente.

Quello che vuoi, nello spirito, è forse qualcosa come Post Facto , che memorizza le versioni di un database in un database. Controlla questa presentazione .

Apparentemente il progetto non è mai andato da nessuna parte, quindi probabilmente non ti aiuterà immediatamente, ma è un concetto interessante. Temo che farlo correttamente sarebbe molto difficile, perché anche la versione 1 dovrebbe avere tutti i dettagli giusti per far sì che le persone si fidino del proprio lavoro.

Ho rilasciato uno strumento per sqlite che fa quello che stai chiedendo. Utilizza un driver diff personalizzato sfruttando lo strumento di progetti sqlite 'sqldiff', UUID come chiavi primarie e lascia il rowid sqlite. È ancora in alpha, quindi il feedback è apprezzato.

Postgres e mysql sono più complicati, in quanto i dati binari sono conservati in più file e potrebbero non essere nemmeno validi se si fosse in grado di eseguirne uno snapshot.

https://github.com/cannadayr/git-sqlite

Penso che X-Istence sia sulla buona strada, ma ci sono alcuni altri miglioramenti che puoi apportare a questa strategia. Innanzitutto, utilizzare:

$pg_dump --schema ... 

per scaricare le tabelle, le sequenze, ecc. e posizionare questo file sotto il controllo della versione. Lo utilizzerai per separare le modifiche di compatibilità tra i tuoi rami.

Quindi, eseguire un dump di dati per l'insieme di tabelle che contengono la configurazione richiesta per il funzionamento dell'applicazione (probabilmente dovrebbe saltare i dati dell'utente, ecc.), Come i valori predefiniti del modulo e altri dati non modificabili dall'utente. Puoi farlo in modo selettivo usando:

$pg_dump --table=.. <or> --exclude-table=..

Questa è una buona idea perché il repository può diventare davvero grosso quando il database arriva a 100 Mb + quando si esegue un dump di dati completo. Un'idea migliore è eseguire il backup di un set di dati più minimo necessario per testare l'app. Se i tuoi dati predefiniti sono molto grandi, ciò può comunque causare problemi.

Se è assolutamente necessario posizionare backup completi nel repository, prendere in considerazione la possibilità di eseguirlo in un ramo all'esterno dell'albero di origine. Un sistema di backup esterno con qualche riferimento alla svn rev corrispondente è probabilmente il migliore per questo.

Inoltre, suggerisco di utilizzare i dump in formato testo su binari a scopo di revisione (almeno per lo schema) poiché sono più facili da diff. Puoi sempre comprimerli per risparmiare spazio prima del check-in.

Infine, dai un'occhiata alla documentazione di backup di Postgres se non l'hai già fatto. Il modo in cui stai commentando il backup del "database" piuttosto che di un dump mi fa chiedermi se stai pensando ai backup basati su file system (vedere la sezione 23.2 per le avvertenze).

Questa domanda ha praticamente una risposta, ma vorrei integrare la risposta di X-Istence e Dana the Sane con un piccolo suggerimento.

Se è necessario un controllo di revisione con un certo grado di granularità, ad esempio ogni giorno, è possibile associare il dump del testo di entrambe le tabelle e lo schema a uno strumento come rdiff-backup che esegue backup incrementali. Il vantaggio è che invece di archiviare le istantanee dei backup giornalieri, è sufficiente archiviare le differenze rispetto al giorno precedente.

Con questo hai sia il vantaggio del controllo di revisione che non sprechi troppo spazio.

In ogni caso, usare git direttamente su file flat di grandi dimensioni che cambiano molto frequentemente non è una buona soluzione. Se il tuo database diventa troppo grande, git inizierà ad avere dei problemi nella gestione dei file.

Ecco cosa sto cercando di fare nei miei progetti:

• dati separati e schema e dati predefiniti.

La configurazione del database è memorizzata nel file di configurazione che non è sotto controllo di versione (.gitignore)

L'impostazione predefinita del database (per l'impostazione di nuovi progetti) è un semplice file SQL sotto il controllo della versione.

Per lo schema del database, creare un dump dello schema del database sotto il controllo della versione.

Il modo più comune è di avere script di aggiornamento che contengano istruzioni SQL, (ALTER Table .. o UPDATE). Devi anche avere un posto nel tuo database in cui salvi la versione corrente del tuo schema)

Dai un'occhiata ad altri grandi progetti di database open source (piwik o il tuo sistema cms preferito), usano tutti gli script di aggiornamento (1.sql, 2.sql, 3.sh, 4.php.5.sql)

Ma questo è un lavoro che richiede molto tempo, devi creare e testare gli script di aggiornamento ed è necessario eseguire uno script di aggiornamento comune che confronta la versione ed esegua tutti gli script di aggiornamento necessari.

Quindi teoricamente (ed è quello che sto cercando) potresti scaricare lo schema del database dopo ogni modifica (manualmente, conjob, git hook (forse prima del commit)) (e solo in alcuni casi molto speciali creare script di aggiornamento)

Dopodiché, nel tuo common script di script (esegui i normali script di aggiornamenti, per i casi speciali), quindi confronta gli schemi (dump e database corrente) e quindi genera automaticamente le istruzioni ALTER nessesary. Ci sono alcuni strumenti che possono già farlo, ma non ne ho ancora trovato uno valido.

Consiglierei neXtep per la versione che controlla il database che ha una buona serie di documentazione e forum che spiega come installare e gli errori riscontrati. L'ho testato per PostgreSQL 9.1 e 9.3, sono stato in grado di farlo funzionare per 9.1 ma per 9.3 non sembra funzionare.

Quello che faccio nei miei progetti personali è, immagazzino tutto il mio database su dropbox e quindi punto MAMP, flusso di lavoro WAMP per usarlo da lì .. In questo modo il database è sempre aggiornato dove mai ho bisogno di fare un po 'di sviluppo. Ma questo è solo per gli sviluppatori! I siti live utilizzano il proprio server per questo fuori rotta! :)

Memorizzare ogni livello di modifiche al database sotto il controllo di versione di git è come spingere l' intero database ad ogni commit e ripristinare l'intero database ad ogni pull. Se il tuo database è così soggetto a cambiamenti cruciali e non puoi permetterti di perderli , puoi semplicemente aggiornare i tuoi hook pre_commit e post_merge . Ho fatto lo stesso con uno dei miei progetti e puoi trovare le indicazioni qui .

Ecco come lo faccio:

Poiché puoi scegliere liberamente il tipo di DB, utilizza un DB basato su file come ad esempio firebird.

Crea un DB modello che abbia lo schema adatto al tuo ramo attuale e memorizzalo nel tuo repository.

Quando esegui la tua applicazione a livello di codice, crea una copia del tuo DB modello, memorizzala altrove e lavora con quella copia.

In questo modo puoi mettere il tuo schema DB sotto controllo di versione senza i dati. E se cambi lo schema devi solo cambiare il DB modello

In passato gestivamo un sito Web social, con una configurazione LAMP standard. Avevamo un server Live, un server di prova e un server di sviluppo, nonché i computer degli sviluppatori locali. Tutti sono stati gestiti utilizzando GIT.

Su ogni macchina c'erano i file PHP, ma anche il servizio MySQL e una cartella con Immagini che gli utenti avrebbero caricato. Il server Live è cresciuto fino ad avere circa 100K (!) Utenti ricorrenti, il dump era di circa 2 GB (!), La cartella Image era di circa 50 GB (!). Quando me ne sono andato, il nostro server stava raggiungendo il limite della sua CPU, Ram e, soprattutto, i limiti della connessione di rete simultanea (Abbiamo anche compilato la nostra versione del driver della scheda di rete per massimizzare il server 'lol'). Non potremmo ( né dovresti supporre con il tuo sito Web ) inserire 2 GB di dati e 50 GB di immagini in GIT.

Per gestire facilmente tutto ciò sotto GIT, ignoreremmo le cartelle binarie (le cartelle che contengono le Immagini) inserendo questi percorsi di cartelle in .gitignore. Avevamo anche una cartella chiamata SQL al di fuori del percorso documentroot di Apache. In quella cartella SQL, inseriremmo i nostri file SQL dagli sviluppatori in numerazioni incrementali (001.florianm.sql, 001.johns.sql, 002.florianm.sql, ecc.). Questi file SQL sono stati gestiti anche da GIT. Il primo file sql conterrebbe infatti un ampio set di schemi DB. Non aggiungiamo dati utente in GIT (ad es. I record della tabella degli utenti o della tabella dei commenti), ma i dati come le configurazioni o la topologia o altri dati specifici del sito sono stati mantenuti nei file sql (e quindi da GIT). Principalmente sono gli sviluppatori (che conoscono meglio il codice) che determinano cosa e cosa non è gestito da GIT per quanto riguarda lo schema e i dati SQL.

Quando è arrivato a una versione, l'amministratore accede al server dev, unisce il ramo live con tutti gli sviluppatori e i rami necessari sulla macchina dev in un ramo di aggiornamento e lo ha inviato al server di test. Sul server di prova, controlla se il processo di aggiornamento per il server Live è ancora valido e, in rapida successione, indirizza tutto il traffico in Apache verso un sito segnaposto, crea un dump DB, punta la directory di lavoro da "live" a "update ', esegue tutti i nuovi file sql in mysql e reindirizza il traffico al sito corretto. Quando tutte le parti interessate hanno concordato dopo aver esaminato il server di prova, l'amministratore ha fatto la stessa cosa dal server di prova al server live. Successivamente, unisce il ramo attivo sul server di produzione, al ramo principale in tutti i server e ha riformulato tutti i rami attivi.

Se si sono verificati problemi sul server di prova, ad es. le fusioni hanno avuto troppi conflitti, quindi il codice è stato ripristinato (riportando il ramo funzionante su "live") e i file sql non sono mai stati eseguiti. Nel momento in cui sono stati eseguiti i file sql, questa è stata considerata come un'azione non reversibile al momento. Se i file SQL non funzionavano correttamente, il DB è stato ripristinato utilizzando il dump (e gli sviluppatori lo hanno informato, per aver fornito file SQL non testati).

Oggi manteniamo sia una cartella sql-up che sql-down, con nomi di file equivalenti, in cui gli sviluppatori devono testare che entrambi i file sql di aggiornamento possano essere ugualmente declassati. Questo alla fine potrebbe essere eseguito con uno script bash, ma è una buona idea se gli occhi umani continuassero a monitorare il processo di aggiornamento.

Non è eccezionale, ma è gestibile. Spero che questo dia un'idea di un sito nella vita reale, pratico e relativamente disponibile. Sia un po 'obsoleto, ma ancora seguito.

Utilizza uno strumento come iBatis Migrations ( manuale , breve tutorial video ) che ti consente di controllare la versione delle modifiche apportate a un database durante il ciclo di vita di un progetto, piuttosto che il database stesso.

Ciò consente di applicare selettivamente le singole modifiche a diversi ambienti, tenere un registro delle modifiche in quali ambienti, creare script per applicare le modifiche da A a N, modifiche di rollback, ecc.

Vorrei mettere l'intero database sotto controllo di versione, quale motore di database posso usare in modo da poter mettere il database effettivo sotto controllo di versione anziché il suo dump?

Questo non dipende dal motore di database. Da Microsoft SQL Server ci sono molti programmi di controllo della versione. Non penso che il problema possa essere risolto con git, devi usare un sistema di controllo della versione dello schema specifico di pgsql. Non so se esiste una cosa del genere o no ...

Aggiornamento 26 agosto 2019:

Netlify CMS lo sta facendo con GitHub, un esempio di implementazione può essere trovato qui con tutte le informazioni su come lo hanno implementato netlify-cms-backend-github