Liquibase é uma fonte aberta (Apache 2.0 Licensed), biblioteca independente de banco de dados para rastreamento, gerenciamento e aplicação mudanças no banco de dados. É construído sobre uma premissa simples: Todo o banco de dados as alterações são armazenadas em um formato legível e rastreável e verificadas no controle de origem.
No entanto, nosso processo de desenvolvimento não suporta isso. Normalmente não modificamos o banco de dados por meio de scripts discretos que escrevemos sozinhos, usamos plugins que ativamos. 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 algumas delas - usando algumas das ferramentas listadas nesta página:
Por exemplo, o liquidbase tem um recurso diff que também inclui, opcionalmente, alterações nos dados. Poderíamos, potencialmente, produzir o esquema e o diff de dados em um script, excluindo (sempre que possível) determinadas tabelas que provavelmente incluam dados de teste (ou seja, postar etc.) e depois aplicar o script ao banco de dados de produção.
MySQLDiff (discutido na questão do StackOverflow) faz diffs de esquema, e o autor recomenda mysql_coldiff para diffs de dados baseados em tabela - ambos são implementados em perl, se as ferramentas java (liquidbase) são muito pesadas para os seus servidores - apesar de trazer ambos os bancos de dados locais e executar a ferramenta em seu PC, resolve esse problema ...
Se realmente quisermos fazer isso da maneira correta, 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 em nosso servidor de produção . Jogue o script de migração contra o servidor, copie os arquivos do site wordpress (excluindo uploads, se for o caso) e somos ouro.
Então, parece-me, que a melhor saída é o plugin de desenvolvimento de migração do desenvolvedor que intercepta o sql que precisamos, armazena-o e gera um script de migração a partir do código registrado, em vez de criar um caminho para 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 plug-in de instrumentação do hook do @bueltge para inspiração: enlace (graças a Ron Rennick via G + por me apontar na direção de SAVEQUERIES e o gancho de desligamento, que me levou a encontrá-lo)
-- alter it to get the SAVEQUERIES output instead -- only run while in admin -- filter out all selects -- save results out to table in the shutdown hook -- we could selectively toggle output trapping based on what we were doing at the moment.
Por exemplo:
Nome da captura: ativar & Configurar o plugin XYZ
Alternar estado de captura - em
... instalar e configurar o plugin XYZ
Alternar estado de captura - desativado
Exportar script de migração para: Ativar & Configurar o plugin XYZ
Pressione o Botão Exportar - para produzir um campo de texto pop-up com o SQL bloqueado filtrado - idealmente pré-formatado como um script de shell com chamada de linha de comando para o mysql. Copiar & cole-o na sua pasta de código de migração e adicione ao seu repositório de código-fonte.
Atenção cuidadosa ao ativar e desativar a captura enquanto você trabalha e você poderá gerar o script de migração perfeito para levar seu banco de dados de produção a uma configuração equivalente ao seu banco de dados de preparo.
O que é melhor, você terá um script (ou série do mesmo) que você pode testar. Imagens com scripts de migração replicáveis e testáveis !!
Eu já estou apaixonado.
Alguém mais?