A realidade é que o que queremos é este: http://www.liquibase.org/
O Liquibase é uma biblioteca independente de banco de dados de código aberto (Apache 2.0 Licensed) para rastrear, gerenciar e aplicar alterações no banco de dados. Ele é construído com base em uma premissa simples: todas as alterações no banco de dados são armazenadas em um formato legível por humanos e ainda rastreável e verificadas no controle de origem.
No entanto, nosso processo de desenvolvimento não o suporta. Normalmente não modificamos o banco de dados através de scripts discretos que escrevemos, usamos plugins que ativamos. Nós não escrevemos scripts DML para modificar os dados de pesquisa que verificamos no controle do código-fonte, usamos uma interface do usuário na página de administração e, portanto, não temos código-fonte para uso posterior na replicação dessa alteração durante a migração.
No entanto, podemos emular parte disso - usando algumas das ferramentas listadas nesta página:
/programming//q/225772/149060
Por exemplo, o liquidbase possui um recurso diff que também inclui opcionalmente alterações nos dados. Poderíamos, potencialmente, gerar a saída do esquema e dos dados para um script, excluindo (quanto possível) determinadas tabelas que provavelmente incluíssem dados de teste (por exemplo, pós, etc.) e depois aplicá-lo ao banco de dados de produção.
O MySQLDiff (discutido na questão StackOverflow) faz diffs de esquema, e seu autor recomenda mysql_coldiff para diffs de dados em tabela - ambos são implementados em perl, se as ferramentas java (liquidbase) são muito pesadas em recursos para seus servidores - embora tragam ambos os bancos de dados locais e executar a ferramenta no seu PC resolve esse problema ...
Se realmente queremos fazer isso corretamente, devemos registrar qualquer sql relacionado a configurações, opções ou outras alterações de configuração e quaisquer alterações de esquema - e converter o código registrado em um script de migração para jogar contra o nosso servidor de produção. Jogue o script de migração no servidor, copie os arquivos do site wordpress (excluindo uploads, se aplicável) e somos o ouro.
Então, parece-me que a melhor saída é o plug-in de migração-construtor de desenvolvedores que intercepta o sql de que precisamos, o armazena e gera um script de migração a partir do código registrado, em vez de criar uma maneira de mesclar bancos de dados entre preparação e produção. Parece um problema mais simples de resolver também.
Se olharmos para o código do gancho de instrumentação do @bueltge chama o plug-in para obter inspiração: https://gist.github.com/1000143 (obrigado a Ron Rennick via G + por me apontar na direção de SAVEQUERIES e do gancho de desligamento, esse leve-me a encontrá-lo)
- altere para obter a saída SAVEQUERIES
- executar apenas enquanto estiver no admin
- filtrar todas as seleções
- salve os resultados na tabela no gancho de desligamento
- podemos alternar seletivamente a captura de saída com base no que estávamos fazendo no momento.
Por exemplo:
Nome da captura: Ative e configure o plug-in XYZ
Alternar estado de captura - ativado
... instalar e configurar o plug-in XYZ
Alternar estado de captura - desativado
Exportar script de migração para: Ativar e configurar o plug-in XYZ
Pressione o botão Exportar - para produzir um campo de texto pop-up com o SQL interceptado filtrado - idealmente pré-formatado como um script de shell com chamada de linha de comando para o mysql. Copie e cole na pasta de código de migração e adicione ao seu repositório de código-fonte.
Atenção cuidadosa para ativar e desativar a captura enquanto estiver trabalhando e você poderá gerar o script de migração perfeito para levar seu banco de dados de produção para uma configuração equivalente ao seu banco de dados temporário.
O que é melhor, você terá um script (ou série do mesmo) que poderá TESTAR. Imagem com scripts de migração replicáveis, testáveis!
Eu já estou apaixonado.
Alguém mais?