Sites de preparação, como você gerencia a sincronização de atualizações no banco de dados?

É amplamente aceito que os desenvolvedores devem testar as atualizações através de um site intermediário antes de liberá-las para o servidor ativo, no entanto, uma vez que as atualizações de desenvolvimento exigem modificações no Wordpress DB, as coisas ficam complicadas, pois os usuários no site ativo também atualizam o banco de dados.

O único fluxo (confuso) que posso imaginar é o seguinte:

1. Teste em um servidor local (WAMP, XAMP, etc)
2. Quando estiver pronto para implantar, coloque o site ativo no modo de manutenção
3. Site ativo de backup (duplicador, sqldump, etc.)
4. Crie um clone do site ativo bloqueado para o site intermediário
5. Carregar modificações do ambiente local para o site intermediário
6. Teste o site intermediário
7. Envie o site de preparação para a exibição.
8. Remover modo de manutenção

Desvantagens do fluxo acima:

• os tempos de inatividade podem ser maiores do que o esperado para os usuários enquanto o desenvolvedor está testando cuidadosamente as atualizações no site de preparação;
• pode exigir gerenciamento manual de modificações: por exemplo, layouts de construtor de páginas originais ou de site são armazenados no banco de dados; portanto, uma vez que um layout é modificado, ele deve ser importado manualmente no site temporário; nesse caso, pode ser adequado simplesmente soltar e importar páginas no site intermediário e, se estiver funcionando, importá-las no site ativo

Gostaria de saber se existe uma maneira melhor e mais automatizada de conseguir isso.

O que você acha?

EDIT, conforme solicitado, algumas soluções foram propostas no passado, mas nenhuma oferece uma solução definitiva:

• 9/2010 - Sincronização de banco de dados entre desenvolvimento / preparação e produção
• 12/2011 - Implantando plug-ins atualizados ou novos que modificam a tabela wp_options
• 9/2014 - Como fazer upload de alterações locais em um servidor ativo sem substituir novas postagens / páginas?
• 1/2015 - Como manter os blogs do site wordpress em produção e preparação?

Os provedores de hospedagem mais recentes que atendem especificamente ao WordPress geralmente possuem ferramentas para aliviar essa dor. Coloquei meus clientes no Pantheon, que possui esse fluxo de trabalho puro habilitado para Git , onde o código apenas sobe (do dev para o preparo para a produção) e o material do banco de dados apenas desce (vice-versa do código). Copiar um banco de dados da produção para a preparação é um clique com a interface. Desde que esse fluxo de trabalho seja respeitado, isso praticamente elimina o problema de sempre atrapalhar o banco de dados de produção, permitindo que eu sempre teste minhas alterações em um novo clone dos dados do banco de dados de produção em qualquer etapa do desenvolvimento.

Não é necessário usar o Pantheon - você pode adotar uma abordagem semelhante em seu processo usando suas próprias ferramentas (Git + um plug-in de clonagem de banco de dados como o WP Migrate DB). Eu só acho que dessa maneira funciona bem para mim.

Pergunta: por que você colocaria seu site de produção em modo de manutenção durante o teste de preparação? Não deveria haver necessidade disso na maioria dos casos. O único caso em que posso pensar é em ter algum tipo de sistema muito frágil, altamente sensível a dados adicionais do usuário sendo alimentados nele, com um bug catastrófico para inicializar - mas isso provavelmente indicaria um problema diferente e maior, onde seria necessário repensar toda a arquitetura de seus produtos.

Dê uma olhada no VersionPress, que traz a versão do GIT para todo o processo (arquivos e banco de dados)

Conforme descrito em seu site:

O VersionPress fornece estadiamento indolor . Isso significa que você pode criar facilmente um ambiente de teste seguro para suas alterações e uni-las apenas quando estiverem prontas. Mesclar é a palavra-chave aqui - o VersionPress lida com situações em que seu site ao vivo apresenta novos conteúdos enquanto isso.