Pergunta

Ao lidar com ambientes diferentes para sites dev e live, como repassar as alterações que só são salvas no banco de dados para o outro ambiente sem precisar exportar o todo base de dados?Digamos, por exemplo, que eu desativei uma extensão, alterei o conteúdo de um bloco estático, criei uma nova página cms estática, adicionei um novo método de envio, regra fiscal ou o que quer que seja. Como passo pequenas alterações como essa para o site ativo sem precisar exportar e importar todo o banco de dados? Obviamente, há informações no site ativo que eu não gostaria que fossem substituídas.

Tenho certeza que alguém deve ter se deparado com isso, especialmente ao usar controle de versão.Implementamos o git, mas isso só funciona para alterações no nível do arquivo.Os arquivos em ambos os ambientes podem ser exatamente iguais, mas algumas configurações no banco de dados podem mudar, fazendo com que se comportem de maneira diferente.

Eu poderia acompanhar todas as alterações que faço no painel de administração e depois reproduzi-las no outro ambiente, mas isso parece muito pouco prático.O número de alterações pode ser bastante grande, pois estamos continuamente ajustando o site para nossa satisfação.Além disso, outros desenvolvedores também estão trabalhando, e até montamos um ambiente para desenvolvedores terceirizados e suporte técnico de provedores de extensões Magento.Não consigo acompanhar tudo o que eles fazem.

Já vi toneladas de postagens apenas sobre exportação de produtos, então esse não é realmente o problema.Eu gostaria do contrário. Talvez alguém tenha feito uma lista de todas as tabelas necessárias para clonar um site Magento sem produtos e pedidos e informações do cliente. Apenas tudo o que é configurável no painel de administração.

Alguém já fez isso antes?


ATUALIZAR: Para os leitores, estou marcando a resposta de @mbalparda sobre arquivos de implantação manual como aceita até que surja algo que faça conforme necessário.Eu vou impor regras para manter registros das alterações no painel de administração de todos os desenvolvedores envolvidos então temos uma lista unificada no final.Na verdade, não é a resposta para a pergunta, mas é o método que usarei para resolver isso até encontrar um processo melhor.

Foi útil?

Solução

core_config_data e core_resources são dois bons lugares para começar. CMS_ * deve ter a maioria das informações relevantes sobre blocos, cms e widgets. Além dessas tabelas, a maioria das tabelas Core_ * tem algumas informações relevantes sobre o site que você está executando.

A lista está longe de ser concluída.

Outra boa opção é manter uma versão do banco de dados no Git e usar uma ferramenta diff para ver o que mudou entre lançamentos, mas pode ter alguns problemas de segurança, uma vez que as informações pessoais podem estar no repo.

Uma boa prática que eu costumo usar é ter um arquivo de implantação manual para salvar todas as alterações que feitas em outro ambiente e uma vez que o código é implantado, a próxima etapa é verificar o arquivo de implante manual para ver se algo precisa ser feito. Isso é usado nos casos em que nem todas as alterações podem ser feitas com atualizações de SQL / Data, a maneira regular magenta para fazer alterações SQL / Data.

Como uma nota, movendo os bancos de dados entre ambientes nem sempre é a melhor escolha, uma vez que alterações de um administrador podem ter sido feitas no site ao vivo serão perdidas se não forem replicadas no DB que estiver usando no outro ambiente. .

Outras dicas

O banco de dados Magento não é o seu banco de dados normal.É grande e complicado.
Mover partes dele de um ambiente para outro não é uma tarefa fácil.
É por isso que geralmente evito alterar as configurações ou adicionar blocos e/ou páginas manualmente.
Deixei o cliente fazer isso apenas no servidor ativo.

O que preciso fazer durante o desenvolvimento é feito por meio de scripts de atualização.
Desta forma, tudo é versionado e portátil.
Eu sei que é meio chato escrever um script de atualização apenas para remover o modo de exibição de lista para páginas de produtos, por exemplo, mas não encontrei uma maneira melhor até agora.

Aqui está um pequeno exemplo de como você pode alterar uma configuração por meio do script de atualização.

O seguinte permite o envio de taxa fixa:

$path = 'carriers/tablerate/active';
$config = Mage::getModel('core/config_data')->load($path, 'path');
$config->setValue('1')->setPath($path);
$config->save();

Eu acho que isso poderia funcionar se você colocasse em um script de atualização dentro sql/[resource_name_here] mas para manipulação de dados eu uso data/[resource_name_here].

Aqui está outro script que adiciona um bloco estático.

$block = Mage::getModel('cms/block');
$block->setTitle('Some title here');
$block->setIdentifier('identifier_here');
$block->setContent('This is the content');
$block->setStatus(1);//enabled
$block->setStores(array(0)); //make it available in all stores
$block->save();

Basicamente, você pode fazer isso para cada entidade que possui.

Eu encontrei uma linda ferramenta para exportar e importar configurações de configuração https://github.com/zookal/Harrisstreet-Impex

Isso faz muito do que vocês e eu estão procurando por eu acho.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a magento.stackexchange
scroll top