Desenvolvimento, Teste e Liberação

Como você desenvolve, testa e implanta para viver seus sites Wordpress?

É sempre um pouco complicado, especialmente no que diz respeito aos bancos de dados - principalmente devido ao fato de que ter um site de teste precisa de um novo banco de dados para ser implantado, que às vezes pode ser EXATAMENTE o mesmo, exceto que todos os links foram alterados para o banco de dados. URL do site de teste, em vez do site ativo.

Da mesma forma, todos os envios enviados pelos usuários desde a última vez em que você precisou corrigir um erro ou desenvolver algo novo terão que ser copiados para o site de teste.

Como os outros fazem isso? Você apenas aguenta o faff? Você usa sistemas inteligentes de controle de versão que ajudam?

obrigado

testing

— Thomas Clayson
fonte

Se você faz um sistema girar em torno da alteração do arquivo hosts , não precisa mexer no banco de dados de teste. ( wordpress.stackexchange.com/a/10943/9142 )

— Alexander Bird

Há um pouco de filosofia pessoal que entra em um fluxo de trabalho de implantação. Não é uma pergunta fácil de responder sem conhecer sua experiência com servidores e controle de versão, sistema operacional, hospedagem, experiência do cliente e cultura de tecnologia, etc.

Aqui está uma pergunta semelhante que tem muitas explicações.
Para a implantação de conteúdo, você pode conferir o plug-in RAMP do Crowd Favorite .
O WP Hackers é um ótimo encadeamento para encontrar boas informações sobre implantações.

Pessoalmente, garanto que nunca codifico URLs absolutos nos meus temas. Use bloginfo () ou codifique URLs relativos. Eu uso muitos condicionais no meu arquivo wp-config.php. Aqui está uma versão básica das minhas edições wp-config.

switch($_SERVER['SERVER_NAME']){
    case 'dev.yourdomain.com':
        $db_host = '';
        $db_pass = '';
        //define debugging
        break;
    case 'stage.yourdomain.com':
        $db_host = '';
        $db_pass = '';
        break;
    default: //Live
        $db_host = '';
        $db_pass = '';
}
define('DB_PASSWORD', $db_pass);
define('DB_HOST', $db_host);

//You could also set this as a variable above
define('WP_HOME', 'http://'.$_SERVER['SERVER_NAME']));
define('WP_SITEURL', 'http://'.$_SERVER['SERVER_NAME']));

Eu trabalho em muitos sites que seguem as

local (hackers pessoais :) no servidor da web do meu laptop)>
dev (teste no servidor do cliente)>
stage (fonte estável para controle de qualidade - edição de conteúdo)>
produção (site ao vivo)

Por fim, sugiro que você use uma ferramenta de versão para ajudar em suas implantações, como GIT ou SVN. Facilita significativamente o processo e mantém a integridade da fonte entre os ambientes. O compromisso com o seu local é facilmente atualizado via linha de comando no palco e na produção. É melhor durante a descoberta definir qual controle de versão você e o cliente usarão desde o início, se tiverem desenvolvedores trabalhando no projeto. Eu pessoalmente uso o GIT para o meu controle de versão. No entanto, se um cliente usa SVN, eu faço uma mistura dos dois no meu local, para manter um repositório para mim e ao mesmo tempo comprometer-me com o repositório.

Raramente temos problemas ao migrar de um ambiente para outro. Fazemos uma busca / substituição no banco de dados para alterar a URL de acordo com a mídia incorporada, etc ...

— Brian Fegter
fonte

Isso é muito útil! :) Muito obrigado. Então, toda vez que você implanta em cada um dos diferentes servidores, você duplica o banco de dados do site ativo? Você diz que implanta em um servidor intermediário (stage.domain.com) para controle de qualidade e edição de conteúdo. O que acontece se o banco de dados for alterado enquanto você estiver executando o servidor de palco no site ativo? ou seja, você ou seu cliente entra no estágio e atualiza algum conteúdo, mas ao mesmo tempo um colaborador publica um novo artigo no site ativo? Você acabou de efetuar a edição de conteúdo novamente no site ao vivo? Como você lida com as mudanças na estrutura do banco de dados?

— Thomas Clayson

Desculpe por todas as perguntas! : p Sou muito grato pelo seu tempo e ajuda.

— Thomas Clayson

Em um novo conjunto de recursos, você pode retirar do palco prod>. Adicione o conteúdo para o novo recurso e empurre para trás o palco> prod. A partir daí, o palco é uma cópia de prod de alta fidelidade e você pode puxar o stage> dev. Não é sempre que puxamos o banco de dados do palco. A maioria das trocas com o banco de dados ocorre de estágio para produto, a menos que um recurso altere a arquitetura do banco de dados.

— Brian Fegter

Se você deseja usar o palco para a implantação de conteúdo e nunca tocar em prod, pode conferir o plug-in RAMP publicado anteriormente.

— Brian Fegter

Marque +1 acima, com a condição de que alguns plugins irritantes insistem em armazenar URLs em matrizes serializadas, o que pode atrapalhar a movimentação de coisas do banco de dados de um ambiente para outro. O problema é que matrizes serializadas armazenam comprimentos de seqüência de caracteres e são exibidas quando o comprimento é alterado. Portanto, eu recomendaria manter os nomes de domínio do env os mesmos, se possível, por exemplo, dev.example.com, tst.example.com, www.example.com etc.

— webaware