fundo

Estou chegando à fase final de construção do meu primeiro site WordPress bastante grande e agora estou enfrentando algum atrito. Na maioria das vezes, o site foi desenvolvido na minha máquina local e eu enviava as alterações para um servidor intermediário para revisão ( consulte esta pergunta para obter mais informações ). A solução com que eu trabalhei funcionou muito bem quando era apenas eu editando o conteúdo, mas agora outras pessoas estão editando o conteúdo enquanto eu ainda tenho recursos a serem adicionados. A ideia era: poderíamos fazer as coisas mais rapidamente se os recursos e o conteúdo se juntassem em conjunto ... mas agora não tenho tanta certeza.

Atualmente, há um conteúdo diferente no banco de dados no servidor intermediário do que na minha máquina local. Tudo bem por si só, já que não preciso da cópia final do corpo na minha máquina local, mas preciso fazer mais desenvolvimentos que afetarão o banco de dados (instale / grave mais alguns plugins que precisam de suas próprias tabelas).

Minha pergunta é:

Existe uma maneira fácil de automatizar a mesclagem de bancos de dados para que várias pessoas possam trabalhar em uma instalação do WordPress? É claro que eu poderia exportar as tabelas que eu sei que foram alteradas na minha máquina local e enviá-las para o servidor intermediário, mas é possível que também haja coisas no servidor intermediário que eu gostaria de derrubar. Eu poderia pegar a saída SQL dos dois bancos de dados e diferenciá-los ... mas isso parece tedioso e hackish. Gostaria de saber se este é um problema que outros resolveram; se houver uma maneira aceita pela comunidade de lidar com esse tipo de coisa.

Obrigado!

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.

Eu trabalho nessa instalação e já respondi a perguntas como essa antes . Abaixo está minha configuração preferida para esse tipo de trabalho. Como você deseja mesclar bancos de dados em vez de substituir um banco de dados existente, eu acrescentaria a eles um cuidado para não usar o sinalizador --add-drop-table ao fazer o despejo do MySQL.

• Etapa 1. Mysqldump seu banco de dados de desenvolvimento
• Etapa 2. Substitua todas as instâncias de development.domain.com por production.domain.com ^^
• Etapa 3. Entre no MySQL, execute um comando SOURCE para importar dados, por exemplo source /path/to/file

^^ Como substituir todas as instâncias do domínio antigo por novas: (1) Copie o script abaixo. (2) chmod +xisso. (3) Execute-o.

Uso: ./script.sh development-dump.sql > production-dump.sql

#!/bin/sed -f
s/'\([^\\']*\)development.domain.com\([^\\']*\)'/'\1production.domain.com\2'/g

Estou experimentando soluções diferentes para esse mesmo problema agora. Definitivamente é complicado.

Minha solução atual é fazer um despejo mysql local usando o sinalizador --skip-extended-insert. Acredito que esse sinalizador faça com que uma instrução de registro de inserção seja gerada para cada linha do banco de dados, tornando o despejo um pouco mais amigável à mesclagem. Eu peguei esse truque neste artigo: http://www.viget.com/extend/backup-your-database-in-git/ .

Em seguida, controle o código-fonte .sql resultante usando o Git, juntamente com os arquivos de origem do site. Quando outro desenvolvedor obtém as alterações de código, o arquivo .sql é fornecido com ele. Ele então importa esse arquivo para sua versão local do banco de dados. Ambos configuramos nossos respectivos bancos de dados locais da mesma maneira em ambas as máquinas, usando o MAMP, portanto, não há necessidade de fazer nenhuma pesquisa e substituição.

Houve problemas de mesclagem, portanto, estamos tentando adotar uma abordagem de "revezamento" para qualquer coisa que cause uma alteração no banco de dados. Antes de fazer qualquer coisa no Wordpress que altere o banco de dados, garanto que ele fez o check-in no seu dump mais recente, puxe-o e importe-o e peço que ele não faça nenhuma alteração no banco de dados até que eu tenha feito e verificado o meu. Obviamente, isso não é o ideal e estou procurando uma solução melhor, mas é um começo. Também nos fornece controle de versão do banco de dados, o que é legal.

Posso acabar configurando um banco de dados de desenvolvimento compartilhado no servidor e tentar conectar nossas cópias locais do site até o mesmo banco de dados via tunelamento SSH. Essa abordagem, no entanto, terá problemas sempre que um de nós instalar um plug-in. Basicamente, os arquivos PHP e o MySQL DB estarão fora de sincronia.

Estou ansioso para saber como os outros estão lidando com esse problema.