La realtà è che ciò che vogliamo è questo: http://www.liquibase.org/
Liquibase è una libreria open source (con licenza Apache 2.0), indipendente dal database per tracciare, gestire e applicare le modifiche al database. È basato su una premessa semplice: tutte le modifiche al database sono archiviate in una forma leggibile ma tracciabile e controllate nel controllo del codice sorgente.
Tuttavia, il nostro processo di sviluppo non lo supporta. In genere non modifichiamo il database tramite script discreti che scriviamo noi stessi, utilizziamo plugin che attiviamo. Non scriviamo script DML per modificare i dati di ricerca che poi controlliamo nel controllo del codice sorgente, utilizziamo un'interfaccia utente nella pagina di amministrazione e quindi non abbiamo un codice sorgente per un uso successivo nella replica di tale modifica durante la migrazione.
Tuttavia, possiamo emularne alcuni, utilizzando alcuni degli strumenti elencati in questa pagina:
/programming//q/225772/149060
Ad esempio, liquidbase ha una caratteristica diff che include, facoltativamente, modifiche ai dati. Potremmo, potenzialmente, generare lo schema e i dati diff a uno script, escludendo (il più possibile) alcune tabelle che potrebbero includere dati di test (ad esempio post, ecc.) E quindi applicare lo script al database di produzione.
MySQLDiff (discusso sulla domanda StackOverflow) fa differenze nello schema, e l'autore raccomanda mysql_coldiff per differenze di dati a livello di tabella - entrambi sono implementati in perl, se gli strumenti java (liquidbase) sono troppo ricchi di risorse per i tuoi server - anche se porta entrambi i database locali e l'esecuzione dello strumento sul PC risolve questo problema ...
Se vogliamo davvero farlo nel modo giusto, dovremmo registrare qualsiasi sql relativo a impostazioni, opzioni o altre modifiche alla configurazione e qualsiasi modifica dello schema - e convertire il codice registrato in uno script di migrazione da riprodurre sul nostro server di produzione. Riproduci lo script di migrazione sul server, copia i file del sito wordpress (esclusi i caricamenti, se applicabile) e siamo in oro.
Quindi, mi sembra che la migliore via d'uscita sia il plug-in di migrazione-builder di uno sviluppatore che intrappola il sql di cui abbiamo bisogno, lo memorizza e quindi genera uno script di migrazione dal codice registrato, piuttosto che creare un modo per unire i database tra messa in scena e produzione. Sembra anche un problema più semplice da risolvere.
Se guardiamo il codice del plug-in di strumenti strumentali di @bueltge chiama l'ispirazione: https://gist.github.com/1000143 (grazie a Ron Rennick tramite G + per avermi indirizzato nella direzione di SAVEQUERIES e il gancio di spegnimento, che portami a trovarlo)
- modificalo per ottenere invece l'uscita SAVEQUERIES
- Esegui solo mentre sei in admin
- filtra tutte le selezioni
- salva i risultati sulla tabella nel gancio di spegnimento
- potremmo attivare selettivamente il trapping dell'output in base a ciò che stavamo facendo al momento.
Per esempio:
Nome acquisizione: attiva e configura il plugin XYZ
Capture State Attiva / disattiva
... installa e configura il plugin XYZ
Capture State Attiva / disattiva
Esporta script di migrazione per: Attiva e configura plugin XYZ
Premere il pulsante Esporta - per produrre un campo di testo popup con l'SQL intrappolato filtrato - idealmente preformattato come uno script di shell con chiamata da mysql da riga di comando. Copialo e incollalo nella cartella del codice di migrazione e aggiungilo al repository del codice sorgente.
Attenta attenzione a attivare e disattivare l'acquisizione mentre lavori e sarai in grado di generare lo script di migrazione perfetto per portare il tuo database di produzione in una configurazione equivalente al tuo database di gestione temporanea.
Cosa c'è di meglio, avrai uno script (o una serie dello stesso) che puoi TESTARE. Imaging con script di migrazione replicabili, verificabili !!
Sono già innamorato.
Chiunque altro?