WordPress e fluxo de trabalho Git

23

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!

realph
fonte
Como foi? Você descobriu isso? Tendo os mesmos problemas aqui.
QWERTY
3
Você poderia focar um pouco sua pergunta? Você pergunta sobre o git, mas depois pula para os bancos de dados e o git não é uma ferramenta para lidar com aqueles essencialmente.
Rarst
4
Eu acho que sua pergunta é válida. Eu tenho o mesmo fluxo de trabalho e conversando com outros desenvolvedores, percebemos que eles também têm o mesmo fluxo de trabalho. Mas consome muito tempo e abre muito espaço para erros. Eu também estaria interessado em uma solução melhor.
Gdaniel #

Respostas:

6

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.

Bradt
fonte
1
Tenho 50 agora :) Ótimo homem de plugins.
Andrew Bartel
4

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.

s_ha_dum
fonte
1
11. O fim - você nunca teve que manter / corrigir / melhorar um site WordPress?
Simon East
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.

rjmunro
fonte
2

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

Patrick Esqueça
fonte
1

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.

deadlyhifi
fonte
1
Você sabe se o script db url replace leva em consideração as seqüências serializadas? Uma consulta simples de atualização para substituir o URL é inválida porque quebra qualquer string serializada com um URL (a menos que o novo URL tenha o mesmo número de caracteres que o URL antigo, o que é raro, no mínimo). Isso quebra os widgets de texto e muitos plugins, entre outras coisas. Eu uso esse script agora, mas estaria interessado neste plugin se ele fizer a mesma coisa.
Ennui
Acabei de enviar um e-mail ao desenvolvedor para responder e responder a essa pergunta. Ainda não precisei disso.
Deadlyhifi 17/05
1
Eu uso esse plug-in para todas as minhas necessidades de migração e ainda não vi problemas com cadeias serializadas e a substituição do URL. Todos os campos personalizados são transferidos sem problemas. Lembre-se de que ele substitui TUDO por padrão. Isso inclui usuários / senhas / etc ...
hereswhatidid