Go with the GitFlow

Confesso que sou fã de Queens of the Stone Age, por isso o título deste artigo baseado na música Go With The Flow.

A plataforma da Stored nasceu em 2007 e evoluiu sob a demanda de clientes, ou seja, solicitações distintas, idéias e sugestões que faziam sentido serem implementadas, porém o prazo também era definido pelo cliente. Caíamos então num modelo de desenvolvimento chamado Waterfall, era um desenvolvimento em cascata junto com uma enxurrada de demandas.

Com o passar dos anos, vimos que não era um desenvolvimento muito organizado, muitas start-ups devem ter sido criadas neste modelo desenfreado, o que não é ruim para o início da empresa no momento de growth (crescimento).

Começamos então a estudar alguns conceitos de metodologia agile e scrum, que traziam certa organização, principalmente para a equipe.

Recentemente a aplicação do scrum funciona muito bem, traz segurança tanto para a equipe, quanto para o cliente. São definidos sprints de 2 semanas, temos a planning (planejamento do sprint) na segunda-feira, fazemos a sagrada daily, todos os dias, e no final do sprint temos o sprint review, que é uma revisão do que foi feito.

Conseguimos nos organizar, mas ainda faltava algo.

A equipe estava bem, não ficavam mais demandas para trás ou até mesmo perdidas no limbo. Conseguimos ter uma melhoria nos prazos e previsões de entregas mais certeiras. Mas e a qualidade de código?

Isto era mais um item que precisávamos melhorar: qualidade de código.

Queríamos ter controle do que é um bugfix, o que está sendo desenvolvido naquele momento, o que é uma melhoria do sistema etc.

Conhecemos então o GitFlow, criado por Vincent Driessen, que nada mais é do que um modo de padronizar a nomenclatura de branches no Github.

Isso mudou a nossa maneira de trabalhar.

Basicamente consiste em termos 5 tipos de branches:

  • master: é o branch que mantém o código de produção.
  • develop: branch que contém o código para o próximo deploy. Após novas features serem finalizadas e testadas, elas se unem ao branch develop, são realizados novos testes e somente depois ele se use a branch release.
  • feature/*: são branches que nascem a partir do branch develop. Por convenção, ele deve começar o nome feature/, por exemplo: feature/18-facebook-login. Neste exemplo, o número 18 se refere ao número da issue no Github. Finalizada a nova feature, ela se use ao branch develop.
  • hotfix/*: são branches que nascem a partir do branch master, normalmente é criado para correção de um bug que esteja em produção. Após a correção, o branch se une ao branch master e develop. Por convenção, ele deve começar com o nome hotfix/, ex: hotfix/32-facebook-avatar.
  • release: é o branch que possui um nível de confiança maior que o branch develop. Nesta etapa, as novas features já foram testadas em develop, testes unitários também já foram realizados e está pronto para se unir ao branch master.

Na imagem abaixo é possível ver de forma simples como o GitFlow é aplicado:

Além de implementarmos o GitFlow, nenhum programador consegue colocar o código dele direto no branch develop, a não ser que tenha sido revisado e aprovado por outro programador da mesma equipe via pull-request.

O Vincent criou uma extensão para o Git, nós não usamos, mas caso queiram conhecer, segue o link:

Espero que tenham gostado. Críticas e sugestões são sempre bem vindas! :)

Até a próxima,
Leo Berdu.