Bastidores do Software #1: Git Flow, entregas contínuas e colaboração

illustrations

Neste artigo você vai entender o fluxo do git, ou git flow, e como desenvolvedores, equipe comercial, clientes e usuários podem dialogar durante o desenvolvimento de um projeto de software com entregas contínuas.

Publicado em 23/07/2020 por Felipe Regino

Git e a analogia da Fotografia

Quando explico sobre o uso do git para alguém, sempre gosto de fazer a analogia da fotografia, se seu software fosse um grupo de modelos em um palco, você poderia usar o git para tirar uma foto deles nesse exato momento, se você decide adicionar mais um modelo ao palco, e então tira mais uma foto, com o git, você não só conseguiria congelar esses dois momentos no tempo tirando essas fotos, como conseguiria ver a diferença entre eles, no nosso caso: um modelo de diferença. Porque o git é uma ferramenta de controle de versão, com ele você controla as modificações no seu projeto.

Fotografia e GIT

Seguindo nossa analogia da fotografia, existe outro importante conceito do git antes de falarmos de git flow: as branches. Uma branch é a possibilidade de duplicar os modelos e o palco criando uma ramificação que você modifica sem alterar o projeto original, dessa forma você pode testar diferentes posições dos modelos, retirá-los, colocá-los novamente, sempre mantendo a versão inicial intacta, e no fim, caso você chegue a uma versão definitiva, você pode mesclar as alterações feitas na sua branch, com o projeto inicial.

Com esses conceitos em mente, vou falar um pouco sobre a razão de usar um fluxo de git para trabalhar em projetos com entregas contínuas, o git flow, que nada mais é do que uma forma de organizar as branches de um projeto de forma que elas sigam um fluxo, como na imagem:

GitFlow

Entendendo Git flow: as branches

Agora vamos por partes, vou falar de cada branch do fluxo e motivo de a usarmos (perceba que isso não é uma regra, você pode adaptar para o que for melhor pra você).

Develop e Release: tecnologia e comercial

Começando pela branch de dev que contém a versão mais atualizada do sistema, é dela que vão sair as branches para a criação de novas features e para correção de bugs, sendo assim na branch develop teremos tudo que já foi desenvolvido no sistema, mas ainda não foi testado.

Em seguida a branch de release que é a que mais varia entre as empresas, na branch release contém o código mais recente já testado, a variação citada anteriormente surge com a questão: quem é que testa o código? Bom, na Quickup é o comercial, que está diretamente alinhado com o cliente. Após todo o código ser enviado para dev, com o aval do líder técnico, uma nova release é iniciada, então o nosso comercial analisa checando se não há problemas, e se está conforme o solicitado pelo cliente, caso esteja tudo ok, o código é enviado para release.

Master e Hotfix: cliente e usuários

Agora chegamos na master. Em um projeto com entregas constantes, é esperado que se tenha um contato direto e próximo do cliente, e o cliente vai ter um papel muito importante no nosso fluxo do git. A master é a branch que contém o código em produção, já homologado pelo cliente, o que isso quer dizer? Isso significa que aquele código que foi enviado para release agora vai ser apresentado para o cliente e ele deve dar um sinal verde para que esse código seja enviado para a master e com isso para o público que usará o sistema, caso o cliente não dê esse sinal, voltamos para dev com as novas exigências.

Por fim não podemos deixar de comentar as branchs de hotfix, essa é uma branch que a gente deseja nunca precisar usar, mas as vezes é necessária. A hotfix serve para aquele momento em que parecia tudo bem, o cliente aprovou, o sistema já está em produção e um usuário encontra um bug! Caso o bug seja muito grande a ponto de não dar pra esperar ele ser resolvido na próxima release, usamos da hotfix pra apagar esse incêndio.

Branches

O que eu gosto sempre de apontar quando falo do git flow, é como ele cria alguns marcos no nosso código deixando muito mais fácil navegar pelo fluxo de desenvolvimento. Por exemplo, caso queira saber o que está sendo mostrado para os usuários, basta olhar para a master, caso queria saber o que já foi feito e aprovado pelo comercial, basta olhar para release, caso queria saber quais features já foram desenvolvidas, basta olhar para dev. E todo esse processo torna o próprio projeto uma parte da documentação do sistema.