GitAny Flow: Por que nunca pensamos na QA?
Muitos de nós já estão acostumados com versionamento de arquivos e sabemos todas as vantagens do uso, principalmente quando se trabalha em times.
Com o passar do tempo, começaram a ser criados diversos processos para trabalhar com o Git. Vou mostrar dois dos mais famosos:
GitFlow:
Onde a maioria das interações são feitas em uma branch develop e são criados releases a partir dela para a master. É uma estratégia que funciona muito bem com o scrum-by-the-book, mas quando se precisa fazer mais de um deploy por dia e garantir a entrega contínua, os release branches podem acabar desacelerando o processo. Quero destacar que tudo que estiver na develop vai para a release branch. Então o fluxo seria mais ou menos assim:
- Cria branch à partir da
develop; - Faz ̶o̶ ̶g̶a̶t̶o̶ o que tem que fazer e abre a PR;
- Aprovou a PR? Taca-le pau no merge pra
develop; - Cria a release branch a partir da
develop; - Umas correções e show, tá na master e vai pra deploy. Mas demooooora.
Github Flow:
O Github flow é bem mais simples, e agiliza muito o processo de CI/CD.
- Cria a feature branch a partir da
master; - Faz ̶o̶ ̶p̶a̶s̶t̶e̶l̶ e abre a PR (pra
master); - O coleguinha pede pra você arrumar a indentação na linha 146, você arruma e boa: PR aprovado;
- Dedão no "Merge pull request". E deploy.
O botão é verdão, atraente, eu te entendo. A vontade de clicar nele é gigante. Mas agora aguenta coração.
Você mergeia na master. E o bugzinho tá lá só esperando o deploy.
Mas e a QA? 🤔
Alguns dos flows mais famosos já adicionaram uma etapa de "deploy from a branch" para fazer um teste da branch, porém não explicam muito bem como. Se liga na explicação:
With GitHub, you can deploy from a branch for final testing in production before merging to master.
Once your pull request has been reviewed and the branch passes your tests, you can deploy your changes to verify them in production. If your branch causes issues, you can roll it back by deploying the existing master into production.
Lá no guide do Github Flow.
Parece esclarecedor pra você? Meio vago talvez? É…
A etapa de QA é tão importante quanto a de planejamento ou de desenvolvimento do código, e no mundo ideal deve ser feita tanto antes (BDDs) quanto depois (testes exploratórios/automatizados) da etapa de desenvolvimento. E se @ QA testou e falou que não vai subir…
Como resolvemos isso na Kovi:
Em um ambiente onde rolam dezenas de deploys diariamente, certamente contamos com um CI para orquestrar tudo, no nosso caso usamos o Seed, mas não vou falar dele nesse artigo. Porém ele ( e/ou a maioria das outras ferramentas de CI/CD do mercado) têm uma parte importante nesse processo.
Na Kovi, adaptamos o Github Flow, adicionando a nebulosa etapa de QA.
- Cria a branch a partir da master;
- Faz aquele refactoring que você tava salivando pra fazer há tempos;
- Abre a PR;
- Aprovaram? Segura a marimba aí mon amour!
No nosso caso, conseguimos disparar deploys atômicos selecionando a branch para algum dos nossos ambientes, o que torna o trabalho muito mais fácil.
Para os CIs que não possuem essa feature, há outra forma simples de fazer o deploy para QA: através de releases do Git.
Para isso, basta criar um trigger no CI para rodar o deploy para QA, por exemplo, nos releases que possuírem a tag com o prefixo qa-*. E gerar esse release selecionando o branch (target) desejado:
Voltando aos nossos passos:
- Aprovaram o PR. Show! Deixa lá aprovadinho;
- Sobe a branch no ambiente de QA (dá teus pulo);
- QA testa. Bugou? Corrige. Mas não se preocupa com a PR agora;
- QA testa. Passou? Verifica se o PR não precisa de um novo review;
- Tudo certinho? Respira fundo, deixa esse vídeo no gatilho, e senta o dedo no merge, faz o deploy e dá o play!
Conclusão: a dor e a delícia de usar os 'flows'
Infelizmente não existe um flow bala-de-prata que resolve todos os nossos problemas de uma vez. E todos eles têm um custo. Alguns desaceleram o processo de entrega contínua, outros exigem um profundo conhecimento sobre git de todo o time (rebase, cherrypick, squash, etc). E nenhum dos que vi até hoje tem um processo de QA claramente definido para antes de o código ser mergeado. Disse lá em cima e reafirmo: A etapa de QA é tão importante quanto a de planejamento ou de desenvolvimento do código. E a branch master deve estar sempre pronta para deploy em produção. Logo, o código não deve ser mergeado enquanto não for aprovado por QA.
Recomendo fortemente o uso de alguma ferramenta de CI/CD para isso, hoje em dia temos várias com planos gratuitos e integração bastante fácil.
É isso galera, valeu, é nóis.
