Dicas para melhorar o workflow de desenvolvimento WordPress - Parte 1

Publicado por Filipe Mateus do Nascimento no dia dev

WorkFlow WordPress

Meu primeiro contato com WordPress foi como freelancer. No início, meu workflow de desenvolvimento não era nada legal. O processo era o mesmo em todos os projetos: baixava o WordPress e subia no servidor através de FTP. Como eu ainda não sabia desenvolver temas quando comecei, comprava algum tema na internet e jogava na pasta de temas. Tudo funcionava perfeitamente, em algumas horas tinha um site rodando. Se eu quisesse fazer alguma alteração em algum arquivo, era só entrar no FTP, baixar o arquivo, editar e subir de volta para o servidor.

Trabalhei desta forma durante algum tempo, em projetos pequenos e simples. Mas depois comecei a desenvolver temas, plugins e trabalhar em equipe nos projetos. Essa forma de trabalho se tornou ineficiente.

Ainda é comum encontrar agências e freelancers trabalhando desta forma. Não é interessante trabalhar assim, principalmente se você desenvolve seus próprios temas e plugins.

Quais os problemas em trabalhar deste jeito?

  • Não tem controle de versão, se você modificou o arquivo errado e quer reverter, não vai conseguir.
  • Dificulta o backup.
  • Não é legal desenvolver diretamente em produção.
  • Não é escalável, se mais pessoas estiverem trabalhando em um único arquivo, um irá sobrescrever o arquivo do outro.

Existem outros problemas, mas acredito que estes sejam os principais, e os que mais dão dor de cabeça.

Aqui na Resultados Digitais, adotamos algumas práticas para ter um workflow mais ágil e seguro, e preparamos algumas dicas:

1. Utilize um ambiente de desenvolvimento local

Parque de Diversões

Este é o problema mais fácil de resolver. Talvez você esteja acostumado(a) a baixar o WordPress e configurá-lo direto no servidor (assim como fiz durante algum tempo). Não faça mais isso. Ninguém quer entrar no seu site, por exemplo, e ver um projeto inacabado, em processo de desenvolvimento no ar, certo? Crie um ambiente de desenvolvimento local e configure o projeto no seu computador primeiro.

Todas as alterações, correções, adições de novas funcionalidades, desenvolvimento de temas e plugins, serão feitas neste ambiente. Este será o nosso parque de diversões.

Existem algumas ferramentas para criar um servidor local e rodar nossos projetos. Algumas destas ferramentas rodam seu ambiente local em uma máquina virtual, como o Vagrant e o Docker. Você também pode optar por fazer de seu computador um verdadeiro servidor, instalando softwares como o MAMP/XAMP/WAMP ou instalando o PHP, MySQL e Apache diretamente em seu computador.

2. Faça o controle de versão do seu projeto

Controle de Versão

Já tenho um ambiente de desenvolvimento local configurado. Posso desenvolver meus plugins/temas, fazer as alterações e colocar o site no ar, certo? Errado! Você precisa fazer controle de versão do seu projeto. Aqui nós fazemos o controle de versão com GIT, e mantemos os repositórios dos nossos projetos no GitHub.

Por que utilizar controle de versão?

Se você digitar essa pergunta no Google, certamente irá encontrar um mar de links, explicando como o controle de versão funciona, e dando várias razões para utiliza-lo. Trarei aqui os que fazem mais sentido pra nós, desenvolvedores WordPress.

Vamos imaginar a seguinte situação: você baixou o WordPress e instalou no seu ambiente de desenvolvimento e precisa criar um tema. Você está desenvolvendo o tema, testando no ambiente local e jogando direto no ar (ambiente de produção), mas entraram mais duas pessoas na equipe para trabalhar no mesmo projeto. Como eles fariam?

Não seria nada legal cada um deles entrar no ambiente de produção e copiar o projeto que você está desenvolvendo, certo? Até porque você vai continuar trabalhando naquele projeto e a versão que eles copiaram vai ficar desatualizada (e a sua também, em relação à deles). Quando os três subirem os arquivos para o servidor, provavelmente haverá algum conflito. Reverter isso é um problema, pois os arquivos do servidor já foram sobrescritos. Você acabou de arrumar uma dor de cabeça.

Se você utilizasse controle de versão nesse caso, os outros desenvolvedores poderiam clonar seu projeto do GitHub, fazer as devidas modificações (cada um no seu ambiente de desenvolvimento) e commitar de volta para o GitHub.

Desta forma, todos estariam sempre com os projetos atualizados, a chance de conflitos seria muito menor e, mesmo que acontecesse um conflito, seria muito mais fácil de resolver e você não perderia os arquivos anteriores, porque o GitHub mantém os arquivos antigos salvos no repositório.

Observou quantos problemas podem ser evitados com controle de versão? Além disso, fica muito mais fácil identificar os erros, os outros desenvolvedores podem revisar o seu código e se o código tiver erros, você pode reverter para a versão anterior.

Caso você queira criar repositórios privados de graça, uma alternativa ao GitHub é o Bitbucket.

3. Utilize um ambiente de homologação

Ambiente de Homologação

Você já está desenvolvendo em ambiente local e já está fazendo controle de versão. O processo está muito melhor agora. Depois de testar no ambiente de desenvolvimento e fazer o commit das alterações no GitHub, poderíamos colocar o site no ar, já que está tudo certo. Mas ainda existe uma etapa muito importante: a homologação.

Tudo pode parecer perfeito para você, desenvolvedor(a). Mas alguém precisa testar as funcionalidades, layout, etc. Você já deve ter testado isso no ambiente local enquanto desenvolvia, mas algo pode ter passado despercebido por você. Outras pessoas precisam testar e validar o que foi feito. Essa pessoa pode ser um(a) tester, outro(a) desenvolvedor(a), ou até mesmo o(a) cliente.

O ambiente para fazer estes testes e validações, é conhecido como ambiente de homologação, ou somente staging. Este ambiente também nos livra de algumas dores de cabeça. Imagine, por exemplo, que você só perceba que o cadastro de usuários não está funcionando depois de algumas semanas com o site no ar, ou que determinada página está com o layout quebrado em dispositivos móveis.

Fail

Precisamos entender a forma como os usuários irão usar as funcionalidades do site, e deixar isso sempre alinhado com eles. Pode acontecer de você desenvolver uma funcionalidade esperando determinado comportamento do usuário e no fim ele se comportar de outra maneira.

4. Só coloque o projeto no ar quando tudo estiver perfeito

Salada de Frutas

Foram algumas etapas até aqui, já validamos e testamos o projeto em dois ambientes diferentes (local e staging). As funcionalidades que você desenvolveu já foram testadas por terceiros em staging. Outros(as) desenvolvedores(as) do projeto já revisaram seu código (possivelmente algum(a) QA também) e você já revisou o deles. Está tudo organizado e nada de conflitos. Então finalmente você pode colocar o projeto no ar (ambiente de produção).

Nenhum erro deve chegar até aqui. Passamos por todas estas etapas para deixar tudo perfeito. Qualquer erro que chegar até aqui, poderá afetar vários usuários. Dependendo do erro e do projeto, pode trazer muito prejuízo a empresa e ao cliente. Muito cuidado e muita atenção.

5. Mantenha os ambientes sincronizados

Ambientes sincronizados

Configuramos 4 ambientes até o momento: desenvolvimento, GitHub, staging e production. Tome muito cuidado para que nenhum membro do time pule alguma das etapas, pois pode causar inconsistência nos arquivos. Isso é difícil de acontecer, mas pode acontecer e pode fazer com que os ambientes fiquem diferentes.

Se todos trabalharem da forma correta, seguindo o fluxo, os ambientes estarão sempre sincronizados.

6. Dê adeus ao FTP

Adeus FTP

Muitos de nós desenvolvedores(as), em algum momento já tivemos uma relação de amor e ódio com o FTP. Se você começar a trabalhar seguindo nossas dicas, não precisará mais dele. Talvez você goste de usar o Filezilla ou qualquer outro software de transferência de arquivos, mas eles não precisam mais fazer parte da sua rotina de trabalho.

Todas essas transferências entre os ambientes, seriam um tanto quanto trabalhosas, se tivéssemos que transferir os arquivos usando um desses softwares de transferência de arquivos. E se pudéssemos copiar o projeto de um ambiente para o outro com apenas um comando? Então… Podemos!

Como aplicar isto na prática?

Iremos abordar os detalhes práticos na parte 2 deste post. Veremos na prática cada parte do processo e mostraremos algumas ferramentas que podem auxiliar, desde o download do WordPress até o deploy no ambiente de produção. As coisas passarão a fazer mais sentido.

A ideia nesta primeira parte foi passar algumas dicas e esclarecer algumas coisas sobre um workflow de desenvolvimento mais moderno com WordPress. Trouxemos algo muito próximo da nossa realidade aqui na Resultados Digitais.

É importante acompanhar as tecnologias e sempre evoluir com elas, para facilitar, agilizar e deixar o trabalho com mais qualidade.

Existe algo que gostaria de compartilhar conosco? Como é o seu workflow de desenvolvimento? Deixe um comentário.

Filipe Mateus do Nascimento

Filipe Mateus do Nascimento

Full Stack Developer

Comentários