Fiz essa pergunta há mais de um ano e, durante esse período, adicionamos mais pessoas à nossa equipe e desenvolvemos um número muito maior de sites no WordPress. Eu queria percorrer nosso processo, caso isso pudesse ajudar mais alguém.
Tudo no Git
Isso era algo que eu estava fazendo enquanto fazia a pergunta, mas é bom destacar isso. O uso do Git não só nos ajudou a ser mais produtivo, mas também salvou nossas bundas coletivas várias vezes.
Você já precisou fazer grandes reformas estruturais em um site, obter aprovação de um cliente para essas reformas e, ao mesmo tempo, fazer pequenas atualizações na versão não renovada? Nós temos, e o Git nos deixou fazer isso. A descrição dessa configuração seria um pouco demorada, mas o básico é que criamos uma nova ramificação, puxamos essa ramificação para o servidor e anexamos um subdomínio a essa ramificação.
Também fomos salvos pelo Git. É claro que nos permite reverter as alterações, o que é ótimo, mas também permite recuperar versões antigas de arquivos. Isso significa que, se um cliente perguntar: "Lembra como essa parte do site funcionou cerca de um ano atrás? Podemos trazer isso de volta?", A resposta é sim - mesmo se a pessoa que está sendo solicitada não estiver nesse projeto há um ano atrás.
Além desses pontos, também significa que nunca ficamos presos sem os arquivos de que precisamos. Sempre podemos retirar a versão mais recente do site de qualquer máquina e começar a fazer alterações.
Use o Git para implantar
Fazemos nossa hospedagem WordPress no Media Temple e gostamos muito deles. Eles não são o provedor mais barato, mas seu serviço é excelente e seus servidores estão realmente bem configurados. O também fornece Git por padrão. Isso significa que podemos configurar o servidor como um repositório Git e extrair alterações dessa maneira, em vez de usar o SFTP. Isso também significa que o trabalho no servidor não corre o risco de ser sobrescrito (pois essas alterações podem ser mescladas e pressionadas novamente).
Como usamos o BitBucket como nosso host Git, há um pouco de trabalho extra necessário aqui. Primeiro, usamos os arquivos .ssh / config para podermos digitar coisas como ssh sitenamefazer login em nossos servidores (também usamos SSH sem senha , o que torna isso super fácil). Também garantimos o uso sempre de senhas ssh (o Mac OS X facilita muito isso, permitindo que você armazene sua senha no Keychain.app ). Finalmente, adicionamos a linha a ForwardAgent à entrada .ssh / config nos hosts dos quais queremos extrair. Isso significa que precisamos apenas da chave pública SSH de cada pessoa no BitBucket, e não da chave pública de cada servidor. Também garantimos manter o .gitdiretório um diretório acima do diretório HTML público.
Despejos de banco de dados automatizados
Quando o servidor estiver no modo de produção, faremos o backup automático do banco de dados, apenas por precaução .
Todo mundo tem seu próprio wp-config
Como todos nós temos nossos próprios nomes de usuário e senhas do banco de dados local e como podemos usar nomes e mecanismos de exibição diferentes, cada um de nós mantém seu próprio arquivo wp-config. Cada um deles é armazenado no Git com um nome como wp-config-gavin.php, e quando queremos usar essa configuração, fazemos o link simbólico para wp-config.php(que é ignorado pelo Git usando .gitignore ).
Isso também nos permite substituir a siteurlopção na wp_optionstabela do banco de dados da seguinte forma:
define('WP_SITEURL', 'http://sitename.localhost');
define('WP_HOME', 'http://sitename.localhost');
Isso impede que o WordPress procure no banco de dados o local do servidor e significa que não há diferenças estranhas no local entre as instalações local e do servidor.
Uma observação final sobre os arquivos wp-config.php: certifique-se de armazená-los acima do diretório HTML público e faça com que as permissões sejam lidas apenas para o usuário da web . Isso faz uma enorme diferença na proteção do WordPress.
O problema do banco de dados
Finalmente, a carne da questão.
O que eu tive que aceitar é que, ao usar o WordPress, não há uma boa maneira de "mesclar" as alterações no banco de dados. Em vez disso, precisávamos desenvolver regras de conduta para resolver isso. As regras são bastante simples e nos serviram bem até agora.
Durante o desenvolvimento, há uma única pessoa que "possui" o site. Essa pessoa geralmente faz a configuração (reunindo o pacote de hospedagem, iniciando o projeto Basecamp, dividindo o design, esse tipo de coisa). Quando essa pessoa estiver em um ponto razoável, despeje o banco de dados para a instalação do WordPress e coloque-o no Git. A partir desse momento, todo mundo que desenvolve o desenvolvimento usa esse despejo de banco de dados, e o proprietário é o único que faz alterações no banco de dados.
Depois que a compilação do site avança um pouco, o site é colocado em um servidor. A partir desse momento, o banco de dados do servidor é canônico. Todos (incluindo o proprietário) devem fazer todas as alterações no banco de dados no servidor e reduzi-las para desenvolvimento e teste local.
Este processo não é perfeito. Ainda é possível que alguém precise fazer alterações no back-end do WordPress localmente durante o desenvolvimento e depois fazer essas alterações novamente na produção. No entanto, descobrimos que esse tipo de coisa é rara e esse processo funciona razoavelmente bem para nós.