Sincronização do banco de dados entre dev / staging e produção

34

Eu tenho um problema com a sincronização de banco de dados do WordPress entre desenvolvimento e produção e estou pensando como outras pessoas resolvem isso. Estou ciente sobre esta questão mas realmente não cobre o caso de uso mais desagradável e mais realista.

Digamos que eu tenha um site WordPress ao vivo. Eu tirei uma cópia de tudo, replicando em nosso ambiente de desenvolvimento. Eu comecei a fazer mudanças. 1 semana depois, estou pronto para implantar minhas atualizações. Enquanto isso, o banco de dados no site de produção mudou (novos posts, novos comentários, etc.). Como faço para sincronizar as alterações entre produção e desenvolvimento durante o lançamento e é possível automatizar (pelo menos um pouco) esse processo?

    
por Alex 22.09.2010 / 15:18
fonte

4 respostas

9

Pode haver uma maneira melhor de estar ausente, mas vou dar a você duas opções:

1.Use XML Export para exportar seus novos posts 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 de desenvolvimento

É melhor importar para o dev e depois mover o banco de dados para a produção, porque quando você importar, baixará todos os novos arquivos de mídia da produção.

  

Nesse meio tempo, a produção mudou (novos posts, 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 a partir do dev. ou o comando REPLACE para sobrescrever 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 carregue o 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'

Não me sinto confortável com os comandos do MySql, por isso gostaria de ir com a opção 1.

    
por Chris_O 23.09.2010 / 03:45
fonte
2

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

Sempre me certifico de que tenho uma boa amostra dos dados do site, não de todos os posts, páginas, comentários do site ao vivo.

    
por curtismchale 22.09.2010 / 16:21
fonte
1

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

Neste caso, ainda é uma situação simples e você vai encontrá-lo para trabalhar com algumas limitações e 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, vários ambientes de teste, vários ambientes de aceitação, vários ambientes de aceitação de produção em todos os cantos do mundo.

Se você quiser fazer isso um pouco mais profissional:

a) anote uma lista de todos os Itens de Configuração que você encontrar, este pode ser o próprio código WordPress, plugins externos, conteúdo, metadados e decidir quais desses você deseja incluir em algum tipo de "gerenciamento", os que importam.

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

c) para trabalho paralelo primeiro descreva quais ICs você quer 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 ICs sob (a) escrever uma resolução. Por exemplo. para ALL que é texto (ou texto exportado, como arquivos php, mas também texto simples em arquivos XML), a fusão é possível. Isso realmente não é problema, mas você precisa de uma boa ferramenta de mesclagem. por exemplo. Com o ClearCase, você entraria em uma mescla de três maneiras nas seguintes situações:  1) mesclagens triviais: ele fará isso automaticamente  2) automático não trivial: ele fará isso automaticamente, mas você precisa verificá-lo  3) não trivial não automático: este é um conflito, por ex. na primeira linha, várias alterações foram feitas. Os não triviais são a parte mínima que você precisa cuidar manualmente, uma boa ferramenta de mesclagem o levará a isso, por exemplo. o que está em clearcase (que também faz fusão de palavras e onde você pode vincular em outras fusões comerciais ou não comerciais para tipos de arquivo específicos). Furtermore se você identificou em (a) arquivos que devem ser copiados somente, então seu comportamento seria não ser mesclado, mas apenas copiado de uma maneira, sobrescrevendo a outra versão sem uma mesclagem (por exemplo, plugins que você não modificou). Muitos desses tipos são possíveis com diferentes comportamentos. Mas anote as relações entre CI's,

Em seguida, para as mesclagens sem base em texto, você precisa tomar uma decisão sobre como lidar com elas. imagens que foram alteradas em 2 lugares. Você poderia decidir aqui que a produção sempre tem preferência (pelo menos é o que eu pensaria), o que torna simples.

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

Se você agora pode gerenciar esses fluxos em suas instalações do WordPress e sincronizá-los também com o conteúdo do banco de dados, etc ..., então você pode realizar as mesclagens na ferramenta CM / versioning e exportá-las de volta no outro ambiente.

A coisa é ... você precisa escrever isso primeiro. Este não é um hack técnico. É um padrão padrão ao redor do Config Management, então nada de estranho aqui também, mas você precisa anotá-lo. Você pode encontrar, por exemplo, que um plugin instalado faz mudanças no banco de dados com alguns dados que são diferentes em outro ambiente, então você precisa ter um procedimento extra em torno disso.

Tecnicamente quase sempre tudo é possível verificar enlace 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 CM.

em resumo: coloque uma camada de gerenciamento de versão sob ela, automatize as mesclagens e lide com os conflitos e, em seguida, importe para o ambiente de destino. Pense em uma estratégia de fluxo que se encaixa aqui e anote-a. Execute um pequeno gerenciamento de CM. Essa seria a solução profissional caso contrário, instalar alguns db copy hack, scripts etc ...

    
por edelwater 14.11.2010 / 22:55
fonte
1

Acabei de fazer uma postagem sobre como sincronizo os dados de produção com a nossa versão, confira a postagem do meu blog em: enlace

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

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

    
por Niklas 06.01.2012 / 00:21
fonte