Implantação de Dev, Stage e Production para sites do WordPress?

Tenho uma configuração da qual tenho muito orgulho e funciona muito bem para a minha equipe.

Estrutura Geral

Eu mantenho toda a instalação sob o git. Todas as alterações, seja uma atualização do sistema, adicionar / atualizar um plug-in, adicionar / atualizar um tema, passar pelo mesmo fluxo de trabalho. As alterações podem ser revertidas a qualquer momento. Eu tenho um servidor de implantação (um antigo desktop P4) rodando gitosis mas você pode facilmente usar o github ou gitolite . No git, eu tenho dois ramos "especiais", master e develop (explicado mais abaixo). Meus servidores de produção e de teste são baseados em nuvem.

Ambientes de desenvolvimento

Todo desenvolvedor executa seu próprio servidor de desenvolvimento em sua própria máquina. Em termos de bancos de dados, a necessidade de dados ao vivo quase nunca foi um problema. Usamos principalmente os dados de teste de unidade de tema . Caso contrário, exportar e importar cobre a maioria das coisas. Se a peça DB fosse crucial, você poderia configurar a replicação ou configurar algo para sincronização sob demanda. Quando eu configurei inicialmente essa estrutura, achei que isso seria crucial, então comecei a escrever um conjunto de ferramentas para fazer isso, mas para minha surpresa, eles realmente não eram necessários. (nota: como eles não eram necessários, eu nunca os aprimorei, então há bugs, por exemplo, ele substituirá o domínio em dados serializados).

Ambiente de armazenamento temporário

Quando as confirmações são enviadas da ramificação develop para a gitosis, elas são automaticamente implantadas em nosso servidor de armazenamento temporário. O banco de dados de preparo é um escravo do banco de dados de produção.

Ambiente de produção

Quando as confirmações são enviadas para a gitosis na ramificação master , ela é automaticamente implantada no servidor de produção.

O problema wp-config.php

Você deseja que wp-config.php seja exclusivo de servidor para servidor, mas também deseja mantê-lo sob controle de versão. Minha solução foi usar .gitignore para ignorar wp-config.php e armazenar as versões de preparação e produção como arquivos com nomes diferentes. Então, em cada servidor, eu faço symlink, por exemplo %código%. Cada usuário mantém seu próprio banco de dados com suas próprias credenciais, com suas próprias configurações wp-config.php (sem rastreamento).

Outras Notas

Eu uso a Rackspace Cloud , que é fenomenal e barata. Com ele, posso manter meus servidores de preparação e produção idênticos. Eu também estou escrevendo plugins agora que usam sua API para permitir que eu controle meus serviços diretamente do WordPress, é maravilhoso.

Diretórios de cache, diretórios de upload de arquivos, etc., são adicionados a .gitignore. Se você quisesse, você poderia configurar uma tarefa Cron para checar os uploads rotineiramente e empurrá-los para a gitosis, mas isso nunca pareceu necessário para mim.

A estrutura master / develop está configurada para imitar parcialmente o modelo de ramificação de Vincent Driessen . Eu também uso sua extensão git git-flow e eu sugiro que também.

Eu tenho 10 ou mais desenvolvedores trabalhando nesta estrutura há mais de um ano e tem sido um sonho trabalhar com eles. Confiável, seguro, rápido, funcional e ágil, você não pode pedir muito mais!

Primeiro, acho importante considerar o que você está indo para o Controle de versão. Eu recomendaria contra colocando todo o diretório do WP em VC. Eu acho que faz mais sentido colocar wp-content / themes / YourThemeName em VC. Para um site grande com um alto número de plugins complexos eu pude ver o caso incluindo também o wp-content / plugins. Se você fosse absolutamente necessário, você poderia incluir wp-content / uploads. As respostas abaixo mudam um pouco, dependendo do controle de versão.

Dado que, aqui está o que eu uso:

Local: configure uma pilha LAMP na sua máquina. Use o mesmo URL do seu site de desenvolvimento. Use entradas do arquivo VirtualHosts e .host para simular o ambiente de desenvolvimento do ponto de vista da URL. Se você está apenas VC seu tema, considere usar o SSHFS para vincular ao wp-content / plugins, wp-content / uploads. Considere usar o banco de dados em sua instalação de desenvolvimento do projeto, a menos que você esteja realmente fazendo um trabalho pesado.

Desenvolvimento: Faça o check-out de uma cópia de trabalho do seu Repo no seu ambiente WP. Configure um Gancho POST-COMMIT no SVN para atualizar este repositório em cada confirmação. Isso irá mantê-lo sincronizado. (Considere a integração contínua de um homem pobre.)

Produção: confira uma tag de versão com nome representando um candidato final. Quando você precisar usar uma nova versão, mude a tag e atualize o repositório.

Recentemente, descobrimos RAMP . Nota: isso é apenas uma parte de todo o processo, mas a sincronização de bancos de dados de conteúdo entre servidores é provavelmente a parte mais difícil dela.

Eu faço isso com o git e o mercurial, apenas certifique-se de usar um repositório privado.

Opção 1.

O único problema é o config.php, que você pode dizer ao git para ignorar no push ou antes do init.

Use .gitignore ou git update-index --assume-unchanged config.php (leia um pouco sobre o comando assumido inalterado antes de usá-lo)

Opções 2.

Use uma condicional no arquivo config.php que verifica a url e aplica as credenciais corretas, ao longo das linhas de "if server url = dev então use as credenciais A, senão use as credenciais B", etc.

Mark explica isso melhor, enlace

ps. Você também pode servidor os arquivos diretamente de um repositório remoto em vez de ter um "servidor de arquivos" tradicional. (vídeo realmente chato que eu fiz sobre esse enlace )