A migração é do ambiente local para o ambiente de produção. O ambiente de produção demorou algum tempo e criou muitos artigos.
Para adicionar coisas novas ao meu site, adicionei um tema personalizado e instalei o CCK, Views e outros módulos no meu ambiente de teste local. Agora que o ambiente de teste local está concluído, como faço para migrá-lo para o ambiente de produção, sem destruir o conteúdo do banco de dados?
Esse é um problema não trivial para o qual quase todo mundo tem uma resposta diferente: não existe uma maneira canônica do Drupal de lidar com a preparação para os impulsos de produção. Dries Buytaert, o cara que dirige o programa Drupal, fez dele uma das principais iniciativas do Drupal 8 . É claro que o Drupal 7 acabou de ser lançado, então levará um tempo até que dê frutos.
O problema pode ser dividido em dois problemas separados:
O primeiro pode ser tratado principalmente pelo módulo de Recursos , que pega a configuração do site e o transforma em um módulo que você pode adicionar à sua instalação do Drupal: dessa forma, você pode adicioná-lo ao seu sistema de controle de versão e não ter que se preocupar com isso. sendo surpreendido quando você migra seu conteúdo.
O último é realmente complicado, porque em um site ativo, é provável que o conteúdo seja alterado na produção, mesmo após a sincronização inicial com o ambiente de desenvolvimento. Isso evita a substituição por atacado de conteúdo durante a preparação, como você pode fazer na configuração.
Além disso, o Drupal não usa identificadores universalmente exclusivos (UUIDs) para conteúdo: toda vez que um nó ou usuário é adicionado, o ID aumenta em um. Portanto, o que pode ser o nó 45 no seu site de desenvolvimento pode ser o nó 90 no seu site de produção.
Infelizmente, não tenho uma ótima solução para isso: a preparação do conteúdo é uma verdadeira fraqueza do Drupal. O que eu pessoalmente faço é adicionar conteúdo apenas no site de produção. Se um cliente quiser ver a aparência do conteúdo antes de ser publicado, configurarei um clone do site de produção que é acessível apenas ao cliente. Então, uma vez aprovadas, as mesmas alterações são feitas diretamente na produção.
Há outra alternativa que é lançada: o módulo Deploy . Ele deve alavancar os Serviços para tornar o conteúdo da preparação relativamente indolor. Mas não posso garantir sua eficácia e ele não possui uma versão do Drupal 7.
Em nosso processo.
Estamos usando o Hudson para reconstruir nossas ramificações de desenvolvimento / teste para sincronizar ramificações ao vivo e dev.
Como estamos usando o Git, todas as tarefas que realizamos têm sua própria ramificação e, quando passadas para o controle de qualidade, a mesclamos para dominar como nosso servidor de teste para testes de regressão.
Quando o master está pronto, fazemos uma versão de teste para o nosso,
Release Serverque é uma réplica do live (configuração, hardware, etc.).Usamos o
Featuremódulo para implantar configurações. Alguns materiais ainda não são suportados pelo recurso, portanto, usamos hook_update_N e, em seguida, executamos updatedb.php oudrush -vd updbdrush fra --yes) para reverter todos os recursos substituídos.Como estamos usando o Boost (movendo-se para o Varnish) e o Memcache, precisamos limpar o cache (
drush cc all).Estamos usando o rsync para sincronizar nossas imagens / vídeo etc ...
fonte
Para migrar de um servidor XAMPP para outro servidor, segui as instruções neste site .
Certifique-se de manter a mesma estrutura em seu servidor de produção como em seu servidor de desenvolvimento. Também precisei editar alguns arquivos no painel de administração do Drupal, localizado em: admin / config / media / file-system
Verifique se o caminho do sistema de arquivos público e o diretório temporário têm os locais corretos definidos.
fonte