Mantenere il database WP sincronizzato tra più sviluppatori usando git

Sto lavorando per migliorare il mio flusso di lavoro git in quanto si applica ai miei progetti di sviluppo di WordPress. Spesso, durante lo sviluppo di un sistema di gestione dei contenuti, creerò un server di sviluppo (come http://dev.finalsitename.com) contenente i tipi di post personalizzati e le tassonomie che verranno utilizzati nella versione di produzione. Ciò consente al mio cliente di iniziare ad aggiungere i propri contenuti al sito.

Mentre stanno lavorando su questo compito, di solito sto costruendo l'aspetto e i plug-in di programmazione personalizzati che verranno utilizzati nel mio ambiente localhost. Per assicurarmi di non sovrascrivere nessuno dei loro aggiornamenti, generalmente tiro giù una copia del loro database e sostituisco il mio. Tuttavia, ci sono momenti in cui ho solo bisogno di saltare nell'area di amministrazione di WP e cambiare un'impostazione o qualcos'altro di piccolo ...

Se ci sono più sviluppatori che lavorano su un progetto WordPress, ciascuno di noi esegue un dump del database (timestamp) della nostra versione del sito e lo includiamo nella directory principale prima di eseguire il commit e il push del ramo locale nel repository remoto. Il problema con questo approccio è che i database sono spesso fuori sincrono senza un modo semplice per determinare quale utilizzare.

Che cosa stanno facendo gli altri sviluppatori per mantenere sincronizzati i loro database pur consentendo a più sviluppatori (e clienti / produttori di contenuti) di lavorare allo stesso progetto?

Ci sono 3 opzioni dalla più semplice ->

1. Utilizzare solo un database remoto a cui tutti si connettono con molti backup. In questo modo devi solo preoccuparti dei file e non del db.

2. Usa la funzionalità di importazione ed esportazione integrata in WordPress e gettala nel controllo della versione direttamente nella radice di wp (come in una nuova cartella). Certo ci vogliono alcuni minuti in più, ma è semplicissimo e puoi automatizzarlo, ma soprattutto entrerà a far parte del controllo della versione.

3. Utilizzare uno script di aggiornamento personalizzato per eseguire la versione della sincronizzazione effettiva del database. Sinceramente non so come gestirlo con git perché è solo uno script e non sa davvero cosa sta succedendo, so che ci sono strumenti di terze parti che lo fanno pubblicamente e gratuitamente ( http: // www. liquibase.org/ ).

Se è necessario mantenere completamente sincronizzati i database, ad es. schema e dati, è possibile sviluppare un sistema di controllo delle versioni personalizzato basato su backup.

Oppure, se si desidera mantenere i dati dalla produzione ma evolvere il suo schema, è possibile lavorare con una soluzione personalizzata (un file con versione con tutte le modifiche dello schema) o con una soluzione standard basata sul concetto di migration. Puoi trovare molte informazioni in questo thread di StackOverflow: meccanismi per tenere traccia delle modifiche dello schema db .

Mi dispiace se questo sembra incredibilmente ovvio, ma se tutti voi doveste avere la stessa copia del database con la stessa struttura, non avrebbe senso avere un server SQL centralizzato / ufficio e usarlo? Clonalo localmente se devi sperimentare ma mantienilo come lo standard defacto autorevole e esegui i backup di quel server e solo di quel server.

Altrimenti, quando lavoro su un progetto di gruppo, abbiamo le nostre configurazioni con contenuti diversi. Il codice si occupa dell'aggiornamento e della migrazione delle strutture delle tabelle e possiamo accedere alle installazioni locali di ognuno del codice in esecuzione sui nostri computer tramite la LAN, quindi non è necessario che condividiamo i contenuti.

Se stiamo inserendo contenuto, lo eseguiamo su un server di prova che possiamo quindi esportare e importare nel server live, oppure possiamo migrare direttamente sul server di produzione se non esiste attualmente un'istanza live.

Se in qualsiasi momento hai bisogno di una separazione di dati live test e WIP, usa semplicemente un ramo live, test e sviluppo nel tuo repository