O que é deploy?
Primeiro, o que é deploy? Deploy é o processo de “empacotar” o trabalho de desenvolvimento e transportá-lo de um ambiente para outro, por exemplo, quando um programador termina uma atualização de um sistema e vai disponibilizá-la para os usuários.
Essa entrega precisa acontecer sem comprometer o serviço atual, o site não pode cair, também é importante não consumir muitos recursos do servidor e nem levar muito tempo, em muitos casos é preciso reverter (rollback) o processo caso surja algum erro, para evitar correria para apagar incêndios. Pensa no site da sua empresa, se ele cair quando a TI fizer uma atualização é provável erro de deploy.
Minha experiência pessoal
Fazer deploy com WordPress tem sido umas das minhas maiores dificuldades como desenvolvedor, pois as linguagens e pastas do sistema são uma “bagunça”, temos PHP, misturado com JavaScript, HTML, CSS inline e arquivos separados, muitas configurações em locais diferentes, podem estar no código e no banco de dados. Pastas que são substituídas totalmente com atualizações do WordPress e pastas que não são tocadas.
Nos meus projetos pessoais, antes de ter uma “estrutura de deploy”, entre 1998 e 2010, fazia os updates da forma mais tradicional (e ainda usada por muitas empresas em 2020), terminava algum update e utilizava um sistema de FTP, que listava os arquivos alterados mais recentemente. Assim bastava subir e trocar, por FTP, os arquivos. Eficiente, econômico, mas sem controle de versão, além de não permitir múltiplas pessoas trabalharem no mesmo projeto ao mesmo tempo (de forma eficiente).
Uma solução inicial, ainda em 2011, foi utilizar o Dropbox na minha máquina local de desenvolvimento e instalar o Dropbox no servidor, todas as mudanças eram transferidas automaticamente, existia controle de versão de arquivos, porém sofria por muitos aspectos, deletar um arquivo acidentalmente podia derrubar o sistema inteiro, não conseguia trabalhar em arquivos e fazer as entregas por partes, antes da funcionalidade inteira estar pronta, poderia derrubar o sistema, o que acontecia era os temidos “testes em produção”.
Assim, ao final de 2012 me foi finalmente apresentado o git, sistema de versionamento de projetos, ali a minha mente “explodiu”, finalmente entendi como grandes empresas trabalham com grandes projetos. Aprendi o básico, commits, push, pull e o básico do básico de branchs.
Neste projeto de cliente aprendi a commitar na branch master e o gestor de TI dava o pull em produção quando tudo estava pronto. Ainda havia um grande problema, sendo WordPress e o banco de dados? Muitos vão rir, mas colocava o dump na raíz do git, funciona e não é tão estúpido, se tiver numa pasta acima do conteúdo público, trabalhoso sim, mas versiona.
Então basicamente não tinha uma estrutura de deploy muito boa, copiei esse sistema para os meus projetos pessoais, optava por velocidade e facilidade de deploy, abrindo mão de alguns quesitos de segurança. Migrei todos os meus projetos para o git ao longo de 2013, este conhecimento de git me alavancou e me fez conseguir uma boa colocação no mercado, trabalhei em uma empresa com muitos profissionais no mesmo projeto. Ali tinha review de pull request.
Houve um hiato de programação na minha carreira durante meu mestrado entre 2014-2016, voltei a estudar programação pois em 3 anos fiquei muito desatualizado. Retomei meus projetos pessoais e decidi criar um sistema próprio para deploy (em shell) de banco de dados chamado F5 Sites WordPress MySQL Manager (que uso até hoje). Percebi que 90% das configurações ficam na tabela wp_options, então com esse sistema subia para produção uma cópia desta tabela de forma inovadora, fazia um dump específico desta tabela (prefixo do projeto)_options, comprimia, enviava via SSH para o servidor, conectava no servidor e fazia um cópia de segurança da tabela e import do dump. Em paralelo com um script simples de push e pull em máquina de dev e produção, a velocidade de entrega disparou.
Esteira de Deploy: Jenkis, SonarQube e GitFlow e live
Tudo ia mais ou menos bem, alguns problemas contornáveis, como git no servidor de produção (!), porém para o nível de requerimento exigidos para um projeto pessoal de uma pessoa só, tudo ok. Um novo projeto aparece no radar, um grande portal WordPress de um cliente como forte estrutura de TI.
Com uma equipe de especialistas, recursos e investimentos pesados por anos, uma estrutura conhecida como “esteira” foi implementada pela equipe. Conheci novas tecnologias, promissoras, parrudas, inteligentes e funcionais. Com o Jenkis é possível fazer uma estrutura de deploy realmente automatizada, fazendo diversos processos testes antes da entrega antes do servidor de produção.
SonarQube permite uma análise automática de qualidade de código e brechas de seguranças antes do pull request, pelo próprio pipeline do BitBucket. GitFlow é uma técnica interessante de organizar commits e merges de branches de dev, homolog, produção e hotfixes. E git live é um forma de manter cópias de gits sem a pasta .git no servidor remoto.
Assim em 2020 conheci um processo muito forte, mas não a prova de bugs e erros. Ainda fica a minha premissa pessoal que sistema ou processo nenhuma vale mais que um profissional experiente e/ou atencioso.
Referências:
https://roselleebarle.com/wordpress-auto-deploy-using-git-jenkins/
https://www.digitalocean.com/community/tutorials/how-to-install-jenkins-on-ubuntu-16-04
https://www.digitalocean.com/community/tutorials/how-to-configure-jenkins-with-ssl-using-an-nginx-reverse-proxy
https://www.digitalocean.com/community/tutorials/how-to-set-up-continuous-integration-pipelines-in-jenkins-on-ubuntu-16-04
https://www.google.com/search?q=deploy+wordpress+with+git
https://tableless.com.br/deploy-usando-git-pull-e-hooks/
https://git-scm.com/book/en/v2/Git-Tools-Submodules
https://git-scm.com/docs/git-submodule
https://www.ostraining.com/blog/wordpress/deploy-git-wordpress/
http://www.saintsjd.com/2011/01/what-is-a-bare-git-repository/
https://github.com/vicenteguerra/git-deploy
https://wppusher.com/wordpress-git-course
https://medium.com/@jmarhee/running-multiple-web-applications-on-a-docker-host-with-apache-85f673f02803
https://www.atlassian.com/git/tutorials/comparing-workflows
https://www.atlassian.com/git/tutorials/comparing-workflows
