Sincronização de banco de dados entre desenvolvimento / preparação e produção

Eu tenho um problema com a sincronização do banco de dados WordPress entre desenvolvimento e produção e estou me perguntando como outras pessoas a resolverão. Estou ciente dessa pergunta, mas ela realmente não cobre o caso de uso mais desagradável e realista.

Digamos que eu tenha um site WordPress ao vivo. Tomei um despejo de tudo, replicando-o em nosso ambiente de desenvolvimento. Comecei a fazer alterações. 1 semana depois, estou pronto para implantar minhas atualizações. Enquanto isso, o banco de dados no site de produção mudou (novas postagens, novos comentários etc.). Como sincronizo as alterações entre produção e desenvolvimento durante o lançamento e é possível automatizar (pelo menos um pouco) esse processo?

Pode haver uma maneira melhor que eu esteja perdendo, mas eu vou lhe dar duas opções:

1. Use XML Export para exportar suas novas postagens e comentários. Em seguida, use o Importador do WordPress para importar as novas postagens e comentários de volta para o banco de dados dev

É melhor importar para o dev e, em seguida, mover o banco de dados para a produção, porque quando você importa, ele baixa todos os novos arquivos de mídia da produção.

Enquanto isso, a produção mudou (novas postagens, novos comentários etc.)

Isso resolveria seu problema de trazer qualquer conteúdo alterado.

2. Use o comando INSERT IGNORE INTO MySql para adicionar as novas tabelas do dev. ou o comando REPLACE para substituir linhas duplicadas na mesma tabela.

Antes de usar o MySql, faça um backup dos dois bancos de dados e mova o banco de dados gz para o servidor de produção e faça o upload do dump (altere o nome do dev se for o mesmo que produção.

INSERT IGNORE INTO `_wp_production_db`.`wp_cool_plugin_options`
SELECT *
FROM `_wp_dev_db`.`wp_cool_plugin_options`

Eu não estou confortável com os comandos do MySql, então eu iria com a opção 1.

Se for apenas mais do mesmo tipo de dados (algumas novas postagens no blog, novos comentários), não sei por que você realmente precisa sincronizá-los. Não é como se isso mudasse a maneira como o código no site funciona, pois é apenas mais do mesmo. Normalmente, não me preocupo com isso, a menos que seja um novo tipo de dados.

Eu sempre me certifico de ter uma boa amostra dos dados do site, nem todos os posts, páginas e comentários do site ativo.

Assim que você toca no tópico de fazer alterações em paralelo, toca na área de gerenciamento de configuração. Com muitos padrões, comunidades próprias (http://www.cmcrossroads.com/) e ferramentas não muito para gerenciamento de versões (como svn / git), mas para suporte ao gerenciamento de configurações (padrões) como clearcase. (áreas totalmente diferentes).

Nesse caso, ainda é uma situação simples e você encontrará que ele funciona com algumas limitações, algum trabalho manual e algumas listas.

O cenário em que estou pensando para torná-lo mais descritivo da solução ideal: vários desenvolvedores trabalhando na mesma base de código, múltiplos ambientes de teste, múltiplos ambientes de aceitação, múltiplos ambientes de aceitação de produção, possivelmente em todos os cantos do mundo.

Se você quiser fazer isso um pouco mais profissional:

a) escreva uma lista de todos os itens de configuração que encontrar, este pode ser o próprio código do WordPress, plugins de fontes externas, conteúdo, metadados e decidir quais desses você deseja incluir em algum tipo de "gerenciamento", quais são os importantes.

b) descrever os fluxos de trabalho que podem acontecer, por exemplo, o que acontece com uma correção, o que acontece com o desenvolvimento de algo novo, em que caso você altera o conteúdo do seu lado, como é chamado e quem o faz, quem é o proprietário dele por exemplo, um novo post ou um novo plugin.

c) para o trabalho paralelo, primeiro descreva quais ICs você deseja gerenciar, decida se o fluxo é sempre do desenvolvimento à produção ou se é realmente necessário fazer tudo isso de duas maneiras.

d) para cada um dos tipos de IC em (a) escreva uma resolução. Por exemplo, para ALL que é texto (ou texto exportado, como arquivos php, mas também texto sem formatação em arquivos XML), é possível mesclar. Isso realmente não é problema, mas você precisa de uma boa ferramenta de mesclagem. Por exemplo, com o ClearCase, você mescla de três formas as seguintes situações: 1) mesclagens triviais: elas são executadas automaticamente 2) automáticas não triviais: são executadas automaticamente, mas você precisa verificá-las 3) não triviais não automáticas: é um conflito, por exemplo, em 1 linha, várias alterações foram feitas. As coisas não triviais são a parte mínima com a qual você precisa cuidar manualmente; uma boa ferramenta de mesclagem o levará a isso, por exemplo, a que está em clearcase (que também faz a mesclagem de palavras e onde você pode vincular outras fusões comerciais ou não comerciais para um arquivo específico tipos). Além disso, se você identificou em (a) arquivos que devem ser copiados, somente o comportamento deles não deve ser mesclado, mas apenas copiado de uma maneira substituindo a outra versão sem mesclagem (por exemplo, plug-ins que você não modificou). Muitos desses tipos são possíveis com comportamentos diferentes. Mas anote as relações entre os ICs,

Então, para mesclagens não baseadas em texto, você precisa tomar uma decisão sobre como lidar com elas, por exemplo, imagens que foram alteradas em 2 lugares. Você pode decidir aqui que a produção sempre tem preferência (pelo menos é o que eu pensaria), o que simplifica.

Então ... para resolver esse problema, você precisa de uma ferramenta de gerenciamento de versões que suporte fluxos diferentes. Cada fluxo representaria uma parte. (isso pode ser imensamente complexo, dependendo de suas necessidades, mas, neste caso, acho que é muito simples).

Se agora você conseguir ter esses fluxos sob as instalações do WordPress e sincronizá-los também com o conteúdo do banco de dados, etc ..., poderá realizar as mesclagens na ferramenta CM / versioning e exportá-las novamente para outro ambiente.

A coisa é ... você precisa escrever isso primeiro. Este não é um truque técnico. É um padrão padrão no Gerenciamento de Configurações, então nada de estranho aqui também, mas você precisa anotá-lo. Você pode descobrir, por exemplo, que um plug-in instalado faz alterações no banco de dados com alguns dados diferentes em outro ambiente, portanto, é necessário um procedimento extra para contornar isso.

Tecnicamente, quase sempre tudo é possível, verifique http://www.cmcrossroads.com/forums para cenários que são dezenas ou centenas de vezes mais complexos, embora sempre usando a mesma abordagem e usando o mesmo conjunto de padrões de CM.

em resumo: coloque uma camada de gerenciamento de versão, automatize as mesclagens e lide com os conflitos e depois importe no ambiente de destino. Pense em uma estratégia de fluxo que se encaixe aqui e anote-a. Realize um gerenciamento minúsculo de CM. Essa seria a solução profissional, caso contrário, instale algum db copy hack, scripts etc ...

Acabei de fazer um post sobre como sincronizar os dados de produção com o nosso teste, confira minha postagem no blog em: http://blog.wp.weightpoint.se/2012/01/04/synchronizing-wordpress-multisite-database -de produção-para-ambiente-de-teste /

Se você deseja sincronizar o código e outras coisas também, eu recomendaria a criação de um repositório git ou mercurial com o arquivo ignorar relevante.

Se você deseja fazer atualizações diferenciais para prod desde a preparação, acho que criar scripts de migração é a maneira mais segura e melhor.