Como mesclar alterações de uma cópia de desenvolvimento do site para o site ao vivo sem perder novo conteúdo?

Qual é o melhor procedimento para mesclar o trabalho realizado em uma cópia de desenvolvimento de um site com a cópia de produção ao vivo? Muitas vezes, muitos conteúdos foram adicionados ao site desde o início do desenvolvimento dos novos recursos. E a maioria das adições a um site envolverá alterações no banco de dados. Portanto, copiar qualquer novo arquivo é fácil, mas e o banco de dados? Como você mescla suas alterações com o banco de dados de produção existente sem perder o novo conteúdo que foi adicionado desde a última atualização do site de produção? Existem módulos que ajudam com isso?

Para tipos de conteúdo, visualizações e alterações de estrutura no site de desenvolvimento, use o Features para exportar o banco de dados para o código.

Para a migração de conteúdo, existem muitas opções, mas nenhuma solução sólida. Um exemplo é o conjunto de implantação .

Adotei basicamente duas escolas de pensamento aqui (uma terceira escola de pensamento, fazendo diferenças de banco de dados, não discutirei porque a complexidade é bastante alta).

1) Implante eliminando o banco de dados de produção e importando um mysqldump do banco de dados de desenvolvimento. Opcionalmente, execute um regex find / replace antecipadamente em qualquer link absoluto codificado que faça referência ao URL do desenvolvedor no dump SQL. Após importar o dev db para o prod, execute automaticamente as instruções SQL (geralmente via script) posteriormente para alterar as configurações diferentes para prod do que dev (por exemplo, talvez você tenha na tabela de variáveis ​​algumas configurações de conexão para conectar-se a sistemas externos que você precisa mude para apontar para sistemas externos de prod em vez de para a versão dev).

2) Use o módulo Recursos , conforme mencionado pela budda, para configurações de administrador e use o módulo Exportação de nó para exportação / importação de conteúdo em combinação com o módulo Excluir tudo . Portanto, o fluxo de trabalho é:

1. use node_export e recursos para exportar nós / recursos para arquivos
2. Controle de versão opcional (e esperançosamente)
3. Carregar arquivos no sistema prod
4. Use a interface drush ou admin para carregar recursos
5. Use a interface drush delete-all ou admin para excluir todos os nós dos tipos que você deseja importar
6. Use drush ne-import ou a interface administrativa para importar os nós do arquivo que você exportou.

Uma observação, eu sugeriria a adoção de um fluxo de trabalho padrão, onde o conteúdo segue apenas uma direção. Dev -> Prod ou Prod -> Dev (eu prefiro este).

Eu fiz isso e estou fazendo isso em alguns sistemas grandes, com resultados razoavelmente bons, mas sempre haverá muitas maneiras de fatiar esta maçã, escolha a maneira que funcionar melhor para você.

Despejar bancos de dados de cópia do site ao vivo e cópia de desenvolvimento do site no arquivo SQL (use os mesmos parâmetros e configurações para os dois despejos).
Em seguida, compare os dois arquivos SQL usando uma pequena ferramenta de comparação ExamDiff . Ele exibirá as diferenças dos arquivos lado a lado com cores diferentes. Você também pode pular diretamente para as diferenças (sem rolar). Examine as diferenças e adicione / edite linhas no arquivo SQL do site ativo. Verifique se não há caminho / URL absoluto do ambiente de desenvolvimento nesse arquivo. Isso é feito! Hora de restaurar o banco de dados para o site ativo.
Facilite sua vida:Na primeira etapa, despeje apenas as tabelas que foram alteradas. Por exemplo, se você editou um módulo na cópia de desenvolvimento que tem como alvo uma tabela separada, despeje apenas esta tabela. Se você não tiver certeza sobre uma tabela específica, o despejo de banco de dados inteiro é bom.