Mantenere il database di WordPress sincronizzato tra più sviluppatori utilizzando git
Sto cercando di migliorare il mio flusso di lavoro con git per i progetti di sviluppo WordPress. Spesso, durante lo sviluppo di un sistema di gestione dei contenuti, creo un server di sviluppo (come http://dev.finalsitename.com
) contenente i custom post type e le tassonomie che verranno utilizzati nella versione di produzione. Questo permette al cliente di iniziare ad aggiungere i propri contenuti al sito.
Mentre lavorano a questa attività, io solitamente sviluppo l'aspetto grafico e la programmazione personalizzata/plugin che verranno utilizzati nel mio ambiente locale. Per evitare di sovrascrivere i loro aggiornamenti, generalmente scarico una copia del loro database e sostituisco il mio. Tuttavia, ci sono momenti in cui devo semplicemente accedere all'area di amministrazione di WP per modificare un'impostazione o qualcos'altro di piccolo...
Quando ci sono più sviluppatori che lavorano a un progetto WordPress, ognuno di noi effettua un dump del database (con timestamp) della propria versione del sito e lo include nella directory principale prima di eseguire il commit e push del branch locale sul repository remoto. Il problema con questo approccio è che spesso i database non sono sincronizzati senza un modo semplice per determinare quale utilizzare.
Cosa fanno altri sviluppatori per mantenere i database sincronizzati mentre permettono a più sviluppatori (e clienti/produttori di contenuti) di lavorare sullo stesso progetto?

Ci sono 3 opzioni dalla più semplice alla più complessa:
Utilizzare un unico database remoto a cui tutti si connettono, con molti backup. In questo modo devi preoccuparti solo dei file e non del database.
Usare la funzionalità di importazione ed esportazione integrata in WordPress e inserirla nel controllo versione direttamente nella root di wp (ad esempio in una nuova cartella). Certo, richiede qualche minuto in più ma è estremamente semplice e puoi automatizzarlo, soprattutto diventerà parte del controllo versione.
Usare uno script personalizzato per aggiornare la sincronizzazione del database. Onestamente non so come gestirlo con git perché è semplicemente uno script e non sa realmente cosa sta succedendo, so che esistono strumenti di terze parti sia commerciali che gratuiti che fanno questo ( http://www.liquibase.org/).

Se hai bisogno di mantenere i database completamente sincronizzati, cioè sia lo schema che i dati, potresti sviluppare un sistema di versioning personalizzato basato sui backup.
Oppure, se vuoi mantenere i dati della produzione ma evolvere il suo schema, potresti lavorare con una soluzione personalizzata (un file versionato con tutte le modifiche allo schema), o con una soluzione standard basata sul concetto di migration
. Puoi trovare molte informazioni in questa discussione su stackoverflow: Meccanismi per tracciare le modifiche allo schema del database.

Anche qui una semplice http://stackoverflow.com/questions/825787/how-to-automate-migration-schema-and-data-for-php-mysql-application

Mi scuso se sembra incredibilmente ovvio, ma se avete tutti bisogno di avere la stessa copia del database con la stessa struttura, non avrebbe più senso avere un server SQL centrale in ufficio e utilizzare quello? Clonatelo localmente se avete bisogno di sperimentare, ma mantenete quello come standard autorevole di fatto e fate i backup solo di quel server.
Altrimenti, quando lavoro su un progetto di gruppo, ognuno ha la propria configurazione con contenuti diversi. Il codice si occupa di aggiornare e migrare le strutture delle tabelle e possiamo accedere alle installazioni locali del codice in esecuzione sulle nostre macchine tramite la LAN, quindi non c'è bisogno di condividere i contenuti.
Se stiamo inserendo contenuti, li eseguiamo su un server di test che possiamo poi esportare e importare nel server live, oppure possiamo migrare direttamente sul server di produzione se non esiste un'istanza live al momento.
Se in qualsiasi momento avete bisogno di separare i dati live, di test e quelli in lavorazione, basta utilizzare un branch live, test e sviluppo nel vostro repository.

Per coloro che non trovano le soluzioni sopra indicate abbastanza semplici, un'ottima soluzione a pagamento è il plugin WP Migrate DB Pro.
Ti permette di spingere e tirare i database tra diverse istanze di WordPress. Non offre ancora un sistema simile a git per i tuoi database, ma se hai un server di staging centrale che rappresenta la "verità" per i database e dove le modifiche dovrebbero essere apportate, funziona in modo eccellente.
(Suggerimento deprecato qui sotto - Grazie a Elmar nei commenti)
Oppure potresti valutare Version Press che dichiara di offrire una gestione simile a git per file e database. Non ho utilizzato personalmente questo plugin, ma lo osservo da tempo ed è ancora attivo.
