Minha equipe e eu estamos trabalhando com um cliente que possui um site existente do WordPress com um bom conteúdo e um tema personalizado que eles criaram. É um blog de grupo, o que significa que tem vários blogueiros ao redor do mundo que estão adicionando & editando conteúdo o tempo todo.
Nosso trabalho é criar um tema totalmente novo, com alguns recursos novos. Alguns desses recursos exigirão novos widgets personalizados, plug-ins e campos de banco de dados.
Atualmente estamos trabalhando em nossas próprias máquinas de desenvolvimento e integrando-as em um único servidor de desenvolvimento. Todo o código é versionado no SVN. Nosso DBA nomeado está mesclando manualmente qualquer alteração de banco de dados no banco de dados dev no momento, embora esperamos que ele seja capaz de automatizar isso em breve.
Acabamos de começar a falar sobre nosso processo de lançamento de produção. O que significa: quando terminarmos, como vamos obter todo o nosso código personalizado no servidor de produção (o live) sem problemas e com o mínimo de interrupção possível?
Temos alguns planos em mente, mas eu adoraria ouvir como os outros abordaram essa questão também. Há alguma melhor prática a seguir ou armadilhas conhecidas a serem evitadas?
Se você seguir o conselho de SethMerrick, poderá reduzir bastante o tempo de troca diminuindo o TTL nos registros DNS apropriados para 5 minutos ou mais várias horas (dependendo do TTL atual) antes de alterar o endereço IP.
Ao fazer isso, você está instruindo os servidores DNS remotos a armazenar em cache o endereço por 5 minutos. Depois de alterar o IP, você pode aumentar o TTL para o que era antes. Para minimizar ainda mais o efeito, faça a transição durante um período de baixo tráfego.
Não tenho certeza se isso é aplicável, mas passei por um processo semelhante de migração e atualização simultâneas de um site de tráfego intenso.
A estratégia básica era trabalhar em um servidor de teste e, quando tudo estivesse pronto, fazer um mysql dump no servidor live, importá-lo para o servidor de temporariedade, fazer qualquer limpeza necessária e apontar os registros DNS para o servidor de temporariedade , fazendo com que o servidor intermediário se torne o novo servidor ativo.
O bit complicado é mesclar todos os dados que se acumulam durante a propagação do DNS no servidor de temporariedade (que agora é o servidor ativo). Em outras palavras, se 30 horas se passarem entre o momento em que você faz seu mysql dump / update DNS e quando a propagação do DNS estiver completa, você terá que mesclar seletivamente 30 horas de registros do site antigo para o novo.
Não é um processo contínuo, mas quando chegamos a uma semana na estrada, todas as dobras se suavizaram.
@Mike Lee: Ótima pergunta, e um dos mais sagrados grails do WordPress (ou qualquer um dos principais CMSs de código aberto com os quais eu esteja familiarizado, como Drupal, Joomla, etc.)
Embora certamente não se destine a abordar seu caso de uso, verifique minha resposta a uma questão relacionada que descreve um plugin de nível beta que acabei de disponibilizar via WordPress Answers Exchange chamado WP Migrar Webhosts (sim, Eu sou péssimo quando se trata de nomeação criativa.)
Mas também quero resolver o caso de uso que você descreve com um plug-in e estou pensando em como fazer isso. Estou pensando que a maneira de abordá-lo é desistir de resolvê-lo genericamente e, em vez disso, abordar os padrões conhecidos que existem no WordPress e permitir que qualquer outra pessoa "conecte meu plug-in" a casos de uso especiais. Eu também estou pensando que uma abordagem é para serializar os dados e estruturas no WordPress como dados em um arquivo PHP para que um futuro plugin possa aplicar essas mudanças como deltas como um sistema de controle de código-fonte aplica deltas para chegar à versão atual da fonte código.
Então, enquanto eu não estou respondendo ou resolvendo o seu problema na íntegra, espero que eu esteja lhe dando uma boa comida para pensar e também esperando que você ou alguém mais queira colaborar em uma eventual solução.
Tags migration