Workflow WordPress com Git

[vc_row][vc_column][vc_column_text]Qual seu workflow WordPress e Git ? Existe uma forma correta ou pelo menos mais adequada de versionar? Como garantir que uma atualização não cause instabilidade ou, como retornar ao estágio anterior em que tudo funcionava perfeitamente? Estas e outras perguntas serão respondidas agora. A intenção aqui é explanar os conceitos dos diferentes workflows do WordPress sendo versionado com Git. Não serão exibidos códigos ou dadas "receitas".

Como tudo começou

Uma das coisas que me chateia bastante no trabalho home-office é a falta de alguém para conversar. Com isso, vivo abrindo threads no slack, grupos de desenvolvimento no Facebook e WhatsApp. No canal que mais me sinto em casa é no slack. No slack os devs realmente participam, contribuem muito nas threads que eu e outros devs iniciam. O mais legal de tudo é que não me sinto sozinho, tenho alguém para conversar. A dúvida de qual a melhor forma de versionar WordPress surgiu após uma discussão via messenger com um dev front-end. Contratei ele para um projeto, concedi o acesso ao repositório e ele criticou muito a forma que eu versionava. Após esta crítica, decidi estudar sobre o assunto.

Pesquisa

Lancei a pergunta em grupos de Slack, WhatsApp e Facebook além de leitura de artigos da "gringa". Foram 5 artigos que li para concluir o seguinte: A forma que venho trabalhando há anos não é totalmente errada. Nesta pesquisa que fiz eu me deparei com os seguintes workflows: 1) Versionando somente o tema, 2) versionando core, tema, plugins e traduções, e 3) versionando tudo. A seguir explico o que encontrei de cada uma destas abordagens, os benefícios e problemas. Também expresso minha opinião pessoal sobre cada uma delas. Ao final menciono como eu trabalho atualmente. [quads id=1]

1) Versionando somente o tema

Em termos de utilização da ferramenta de versionamento, é de longe o meio mais reconhecido como correto. Assim, o WordPress, plugins, traduções, uploads e configurações ficam de fora do controle de versão, versiona-se somente o SEU código.

Benefícios

• Menos peso no versionamento;
• Utilização das melhores práticas do Git.

Problemas

• Publicação complexa. Tem que baixar um zip do WordPress e/ou transferir junto de plugins e traduções do seu ambiente de desenvolvimento;
• Entrada de um dev novo no time ou mesmo um terceirizado tem a mesma complexidade da publicação;
• Problemas em caso de atualizações de plugins que causam instabilidade da aplicação;
• Montagem de scripts para sincronizar plugins, banco de dados, arquivos e configurações.

Opinião

Sem sombra de dúvidas é a melhor forma de se trabalhar com relação à utilização do sistema de versionamento. Isso porque versiona-se somente o que você está desenvolvendo, deixando de fora todo e qualquer código de terceiros. No entanto a manutenção tende a ser mais complexa. Utilizei este workflow em 3 projetos recentemente. Para aplicações de longa data vale muito a pena. Cria-se scripts pra automatizar ou utiliza-se ferramentas de integração contínua ou containers do Docker. Porém para os projetos relâmpagos não acredito ser uma boa pedida. Entenda como projeto relâmpago algo muito rápido e que dificilmente terá manutenção futura. Vale a pena utilizar este workflow? Como tudo em software a palavra que reina aqui é "depende".

Concluindo

Um possível .gitignore para o seu repositório com este workflow seria mais ou menos desta forma:

# Ignorando tudo na raiz do projeto
/*

# removendo ignore de .gitignore (precisamos deste arquivo)
!.gitignore

# ignorando tudo dentro de wp-content primeiro
wp-content/*

# em seguida removendo o ignore de wp-content/themes
!wp-content/themes/

# ignorando temas específicos e o index da pasta themes
wp-content/themes/twenty*/
wp-content/themes/index.php

 

2) Versionando core, tema, plugins e traduções

Neste workflow, os arquivos importantes e pertinentes à aplicação são versionados, mesmo que seja código de terceiros que esteja ali. Na pesquisa que realizei, grande parte dos devs utiliza desta forma, quase que a maioria. Com este workflow o core do WordPres, tema, plugins e traduções são completamente versionados pelo git.

Benefícios

• Facilidade de publicação;
• Facilidade na entrada de novos membros no projeto;
• Integridade da aplicação - todo o código-fonte necessário para o funcionamento está sendo versionado;
• Maior segurança ao desenvolvedor. Caso uma atualização quebre algo, basta jogar fora (git checkout -f) e tudo estará funcionando como antes.

Problemas

• Repositório pesado;
• Fere as boas práticas de versionamento, pois versiona-se código que não é seu.

Opinião

Meu workflow com o WordPress atualmente é este e descreverei o que me motiva a utilizar desta forma. Cito um problema bem comum e que já aconteceu inúmeras vezes em projetos que trabalhei.

Cenário

Minha aplicação roda em cima do WordPress. Diferentemente de um framework, o WordPress não permite que em um composer.json trave a versão do mesmo. O mesmo para as libs de terceiros, neste caso, os plugins utilizados. Desta forma, qualquer pessoa com acesso ao painel admin e com a devida permissão pode realizar as atualizações. Atualizar o WordPress é uma coisa boa e necessária, principalmente quando falamos de segurança. Para tornar a atualização segura, no entanto, devemos sempre ler o changelog para saber em que pontos as atualizações podem impactar. Seguindo o raciocínio, esta mesma aplicação é um e-commerce que vende curso de inglês e os clientes pagam mensalmente. Com isso faz-se necessário o uso dos seguintes plugins: Woocommerce , Woocommerce Subscriptions e algum plugin de pagamento para o Woocommerce - neste caso usarei a Vindi como exemplo. O WordPress está com uma versão nova para ser lançada no dia de amanhã e o time do Woocommerce já se antecipou à tal atualização implementando/corrigindo o que precisava e sincronizando para que a atualização do plugin esteja disponível antes mesmo do WordPress lançar a sua. Já o plugin de subscriptions por sua vez não atualizou porque nada referente à esta atualização do WordPress e Woocommerce interfere no seu funcionamento. No entanto a equipe da Vindi, cujo plugin será afetado com tal atualização não conseguiu terminar os ajustes a tempo e lançará uma nova versão somente daqui 2 dias. Ligando os pontos: WordPress atualiza, Woocommerce também, Subscriptions não é afetado e Vindi é afetado mas a nova versão sai em 2 dias.

Oba, atualização!

No dia seguinte (na atualização do WordPress e do Woocommerce) o cliente acessa o painel e vê um badge com 2 atualizações. Sem pensar, nem ler o que mudou e sem sequer imaginar que aquilo pode causar erros, atualiza.

Opa, deu caca.

Assim que o primeiro cliente vai para o checkout, preenche todos os dados necessários, e é frustrado com um loading infindável e nenhum feedback compreensível para meros mortais. Isso porque algo no plugin da Vindi, que somente será atualizado no dia seguinte, quebrou devido às novas versões do WordPress e Woocommerce.

Como resolver?

Neste caso como o core do WordPress e os plugins foram atualizados, eu acesso o server e rodo o comando git checkout -f e o problema está prontamente resolvido. Aí com tempo e calma eu busco entender o que cada atualização faz, se existirão efeitos colaterais e se são realmente necessárias naquele momento. Neste cenário o fato de versionar elementos cruciais para o funcionamento do e-commerce, impactou positivamente. E complemento: Acredito que se o tema depende de um plugin para pleno funcionamento, é justo eu o versionar, afinal de contas de que adianta um tema de e-commerce sem o plugin e suas extensões para que o mesmo funcione adequadamente? Um claro exemplo disso são os temas comprados, com inúmeras funcionalidades incríveis. Para que o tema funcione plenamente ele requer diversos plugins, logo, acredito ser válido os colocar no meu repositório. O dev front-end que me criticou, em um dado momento disse isso: "Se o seu tema depende estritamente de um plugin é porque o projeto todo está errado.". Não concordo. Se o site é um e-commerce construído com o Woocommerce, é obvio que todo o meu tema e funcionalidades dependerão diretamente dele, não consigo ver erro aí.

Concluindo

Acredito ser esta a solução correta no workflow WordPress e git pelo simples fato de o .gitignore padrão do WordPress sugerir isso! No .gitignore são mantidos os arquivos do core do WordPress, temas e plugins. Isso pra mim é argumento suficiente pra entender este workflow como o correto. Afinal de contas, eu posso estar errado mas existem atualmente 7 contribuidores dizendo que isso é certo e de toda uma comunidade de devs WordPress, ninguém contesta. Basta criar um novo repositório no github e selecionar o .gitignore do WordPress que você terá o exato conteúdo que mostro no código a seguir. Veja a referência e tire suas próprias conclusões: https://github.com/github/gitignore/blob/master/WordPress.gitignore Diferente do .gitignore do primeiro Workflow, este lista somente alguns arquivos e pastas, deixando plugins, tema e o próprio core do WordPress para ser indexado no Git:

*.log
wp-config.php
wp-content/advanced-cache.php
wp-content/backup-db/
wp-content/backups/
wp-content/blogs.dir/
wp-content/cache/
wp-content/upgrade/
wp-content/uploads/
wp-content/mu-plugins/
wp-content/wp-cache-config.php
wp-content/plugins/hello.php

/.htaccess
/license.txt
/readme.html
/sitemap.xml
/sitemap.xml.gz

Como complemento, adiciono os temas padrões do WordPress (twenty*), pois quero versionar somente o(s) que posso de fato utilizar.

wp-content/themes/twenty*

 

3) Versionando TUDO

É a maneira que acredito ser a mais drástica e menos indicada. Porém como tudo em software, existe sua devida aplicação. Em um dos artigos que li o autor comenta que versiona tudo, incluindo wp-config.php, dump do banco de dados e uploads. Assustador não é? Nem tanto, já explico.

Benefícios

• Não precisa de scripts de sincronização ou ferramentas de Integração Contínua;
• Fácil publicação e manutenção, seja por você ou qualquer outro dev, pois tudo o que o site precisa pra funcionar está ali.

Problemas

• Peso do versionamento;
• Má prática no uso do Git.

Opinião

No artigo que li sobre isso, o autor não explicou com detalhes o cenário, mas em determindas situações concordo com essa abordagem, principalmente em sites que não serão mexidos tão logo, que você entregará e o cliente provavelmente não mais entrará em contato. Já tive situações assim. Quando trabalhava em uma agência chamada Redsuns, de 2012 a 2015, entregamos muitos sites institucionais, daqueles que todo o projeto (briefing, layout, front e back) duravam no máximo 1 semana. Na época utilizávamos o 2º workflow (versionando core, tema, plugins e traduções) mas vendo agora, creio que versionar tudo poderia ter sido o melhor caminho em casos como estes. Isso porque das dezenas de projetos semelhantes que tivemos uns 4 ou 5 entraram em contato diretamente comigo, anos depois, pra pedir o backup do banco de dados e as imagens do site porque estavam pagando pra um dev fazer a re-publicação em outro server. Em uma situação o cliente deixou de pagar a hospedagem, regularizou a situação meses depois mas hospedagem apagou todos os arquivos. Como não versionamos uploads nem dumps do banco de dados, não consegui ajudar, visto que o server da Redsuns também já não existia mais. Percebe novamente como dependendo do cenário, tudo pode ser válido?! O real problema é prever tais situações.

Concluindo

Acredito ser válido este workflow se realmente necessário versionar desta forma. Segue um trecho do artigo "No More Cowboy Coding: Improving Your WordPress Workflow" que li na minha pesquisa. Many people choose to have Git ignore their entire uploads folder and keep it in sync manually via FTP, or they write a separate script to handle uploading and downloading them automatically. Personally, I let Git handle the uploads and do the downloads manually. No caso dele, como explica mais pra frente no seu artigo, ele não tem "toneladas" de arquivos, usa alguns poucos e por este motivo, acha viável versioná-los também. As referências da minha pesquisa estão no final deste artigo.   [/vc_column_text][us_cta title="Interesse em TDD?" title_size="h3" color="custom" bg_color="#422b72" text_color="#ffffff" btn_link="url:https%3A%2F%2Ftddcomphp.com.br||target:%20_blank|" btn_label="Conheça meu livro" btn_size="20px" btn_style="4"]

Então meu livro é perfeito pra você!

Pra ficar melhor ainda, tenho um cupom de 15% de desconto. Clique em "Conheça meu livro" e pegue o seu![/us_cta][vc_column_text]

Minha experiência

Desde que comecei a trabalhar com o WordPress, utilizo o segundo workflow, versionando o que é crucial para o pleno funcionamento dos meus sites, mesmo que isso inclua código de terceiros. Perdi as contas de quantas vezes o cliente chegou no painel, viu uma quantidade X de atualizações, selecionou todas e mandou atualizar. O resultado as vezes era bom, nada de anormal, porém por diversas vezes algo que funcionava perfeitamente parou. Várias quebras, lançamentos de erros e excessões, e assim por diante.

Problemas com invasão

Em 2014 ainda na Redsuns, já mencionada, possuíamos um server dedicado com mais de 120 clientes. Um dos sites bem das antigas tinha uma vulnerabilidade e além de "trocentos" scripts maliciosos no site de origem, ainda foi criado um arquivo com o "belo" nome de satan.php. Este arquivo simplesmente tinha uma interface web com acesso à toda a pasta home do servidor. Como a empresa de hospedagem identificou a origem, acessei o server e descartei as alterações, retornando todos os arquivos ao estágio anterior. Resolveu nosso problema... naquele site. O problema é que o satan.php já estava em mais de 20 sites de todo o server. Sem contar em todos os scripts inline, disparadores de emails, downloads forçados de softwares e tudo mais que estavam fazendo por o servidor ter sido invadido uma primeira vez. Aí o fato de versionar código importante para os projetos foi uma mão na roda. Eu acessei todos os mais de 120 clientes e mandei descartar tudo! Desta forma, uma tarde de trabalho removeu 20 satan.php e centenas de scripts maliciosos. Posteriormente passamos um pente fino atualizando cada um dos clientes com WordPress.  

Conclusão

Como tudo em software, existem várias maneiras de se resolver o mesmo problema e com o workflow WordPress e Git não é diferente. Espero que tenha compreendido que a intenção deste post não é ser tendencioso e puxar para um lado só, mas sim, demostrar que em uma pesquisa que fiz durante algumas semanas eu identifiquei basicamente 3 formas de se trabalhar com WordPress e Git e as apresento aqui, citando prós e contras. No entanto, você deve identificar com qual delas se identifica (ou quem sabe nenhuma delas) e tirar o melhor proveito disso. Conforme apresentado, por mais que dois dos workflows firam boas práticas de versionamento com o git, podem ser aceitáveis no seu devido cenário. Caso tenha uma outra sugestão de workflow, deixa nos comentários que os demais leitores com toda certeza apreciarão a sua contrbuição, e eu também. Se você chegou até aqui, merece meus agradecimentos, isso demonstra que as semanas de pesquisa e discussões por aí junto das mais de 8h de criação deste texto valeram a pena.

Fontes

https://premium.wpmudev.org/blog/git-for-wordpress-development/ https://premium.wpmudev.org/blog/improve-wordpress-development-workflow-local-server/ https://www.sitepoint.com/wordpress-version-control-git/ https://deliciousbrains.com/storing-wordpress-in-git/ https://stevegrunwell.com/blog/keeping-wordpress-under-version-control-with-git/ Outras fontes foram discussões com diversos desenvolvedores principalmente no Slack. [/vc_column_text][/vc_column][/vc_row]