WordPress e fluxo de trabalho Git

Sei que essa pergunta foi feita mil vezes, mas estou realmente tentando descobrir como tirar o melhor proveito do Git ao trabalhar com o WordPress.

Examinei a web e li dezenas de artigos, tudo o que parece cobrir o tópico brevemente. Aqui estão alguns dos mais notáveis ​​que li recentemente.

- Controle de versão do WordPress

- Gerenciando implantações de temas do WordPress com o Git

- Gerencie seu tema WordPress personalizado usando git em vez de FTP

Atualmente, meu fluxo de trabalho se parece com isso.

• Instale o WordPress localmente
• Desenvolver Tema
• Exportar bancos de dados do WordPress do servidor local
• Importar banco de dados do WordPress para servidor remoto
• Carregar arquivos e temas do WordPress via FTP
• Cliente faz alterações
• Baixe arquivos e temas do WordPress via FTP e exporte os bancos de dados do WordPress de um servidor remoto
• Substituir arquivos localmente
• Faça alterações no desenvolvimento
• Faça o upload novamente via FTP, exporte e importe o banco de dados para o servidor remoto

Sei que o Git pode otimizar esse processo. Parece que a melhor maneira de fazer isso é ter um arquivo .gitignore que ignore determinados diretórios que não precisam ser rastreados, além de ter um arquivo wp-config.php local e remoto.

Mas como você lida com os bancos de dados? Os clientes geralmente fazem alterações (posts / páginas / plugins). Ainda preciso exportar do banco de dados remoto e importar novamente no meu servidor local?

Alguém pode sugerir o melhor fluxo de trabalho para mim aqui? E me guie pelos degraus.

Além disso, eu provavelmente gostaria de usar o Bitbucket porque os repositórios privados com eles são gratuitos, diferente do GitHub.

Qualquer ajuda seria apreciada.

Desde já, obrigado!

Sou um dos desenvolvedores do WP Migrate DB Pro e gostaria de responder à pergunta de @ Ennui:

"Você sabe se o script db url replace leva em consideração as seqüências serializadas?"

Sim, ele lida com dados serializados. De fato, essa é a principal razão pela qual desenvolvi a versão gratuita do plugin em 2009. :)

Infelizmente, só tenho uma reputação de 41, por isso não pude responder ao comentário de @ Ennui. Desculpe por isso.

Estou na fronteira para votar para encerrar isso como "não construtivo", pois parece ser o tipo de coisa que solicitará debate e opinião, em vez de respostas. Mas...

Não é assim que o meu fluxo de trabalho se parece e torna minha abordagem (e resposta) diferente da maioria das demais respostas até agora.

1. Instale o WordPress localmente
   1. Isso é clonado a partir de um repositório Git bare local que contém a última versão estável.
   2. Também mantenho uma cópia local da versão mais recente de alguns plugins que quase sempre instalo.
2. Crie o tema e todos os plugins necessários
3. Carregar em um servidor de armazenamento temporário público
   1. O cliente recebe acesso, mas não pode alterar o código e informou que as edições do banco de dados não serão transferidas para o site de produção.
   2. Isso significa que não há motivo para baixar o código novamente no servidor de desenvolvimento.
   3. E não há razão para ressincronizar o banco de dados local
4. Faça alterações no site local com base em nossa equipe e nos comentários do cliente.
5. Carregar alterações
6. Repita conforme necessário (mas com crescente resistência :))
7. Se estivermos fornecendo conteúdo, o que nem sempre é o caso, nós (não o cliente) limparemos o banco de dados no servidor intermediário e carregaremos o conteúdo.
8. Implante fazendo o upload do código local no site de produção.
9. Se criamos conteúdo, o conteúdo é exportado do site intermediário por meio da ferramenta de exportação de baunilha e importado para o site de produção.
   1. Essa é a única vez que tenho que mover o banco de dados e isso é feito com ferramentas bastante padrão. Vou usar veludo dos azuis Atualização URLs para limpar o banco de dados, se necessário.
10. Depurar
11. O fim

Basicamente, eu mantenho o cliente longe das minhas coisas o máximo possível até entregarmos o site.

O código se move de uma maneira - do local para a preparação ou produção. Nunca se move para o outro lado. Isso elimina alguns de seus passos e me dá um pouco de tranquilidade. Não quero ser responsabilizado pelo conserto do cliente no meu código e não quero importar algum arquivo invadido, o que é uma possibilidade diferente de zero.

E o banco de dados se move apenas uma vez, se houver, o que reduz bastante o problema. Então, acho que gerencio o problema de "movimentação do banco de dados", reduzindo ou removendo a necessidade de mover o banco de dados. Também reduz os problemas de corrupção do banco de dados que podem surgir e as chances de importar um hack.

É verdade que preciso configurar o site de produção - links permanentes, menus etc. -, mas isso me obriga a trabalhar no site de produção, por isso considero uma espécie de depuração. Isso me ajuda a confirmar que as coisas funcionam no local de produção da maneira que deveriam.

https://github.com/nathanielks/Wordpress-Capistrano-Deploy

Eu não tentei isso sozinho (ainda), mas ele afirma implantar tudo - inclusive o DB.

Há também um tutorial para acompanhá-lo: Tutorial parte 1 | parte 2

Dê uma olhada na pilha de terra firme . Ele usa o compositor para gerenciar a versão do Wordpress e plugins de terceiros, e também inclui o capistrano para implantações, e vagrant / ansible para configurar servidores, incluindo servidores virtuais locais para desenvolvimento.

Recentemente, fiz muitos testes com relação a isso e aqui está o fluxo de trabalho que eu uso, que faz praticamente o que você está pedindo:

• Eu uso o wp-cli para gerenciar o núcleo do wordpress e atualizar o wordpress.
• Eu uso o compositor junto com o http://wpackagist.org para gerenciar dependências de plugins e temas.
• Eu uso o git e coloco os arquivos principais do wp no .gitignore. Então, principalmente o wp-config.php e os arquivos de tema filho estão no git.

Não estou familiarizado com as ferramentas de migração de banco de dados, mas seria um ótimo complemento para esse fluxo de trabalho.

Aqui estão os detalhes completos no fluxo de trabalho http://geekpad.ca/blog/post/maintainble-portable-wordpress-using-composer-wp-cli

Em relação à "clonagem" do banco de dados, eu uso o WP Migrate DB Pro: http://deliciousbrains.com/wp-migrate-db-pro/

É um serviço pago, mas não custa muito, e permite facilmente puxar ou enviar seu banco de dados do seu dev para o servidor ativo e vice-versa. Ele muda os URLs e tudo o mais que precisa ser alterado no caminho.