Gitflow
Objetivo
O presente documento tem como objetivo apresentar o modelo de fluxo de trabalho git que os colaboradores do projeto PDF2CASH deverão seguir a fim de estarem de acordo com as necessidades exigidas pelo desenvolvimento ágil, bem como a integração/entrega contínua.
Modelo de workflow
O modelo escolhido para satisfazer estas necessidades baseia-se fortemente nos famosos modelos Github Flow e Gitflow. De cada um foram retirados aspectos que foram tidos como pertinentes ao atual cenário de desenvolvimento. Um exemplo do modelo pode ser visualizado na seguinte figura:
Branch de produção
É na branch Master onde o código 'pronto para produção' deverá residir. Isto quer dizer que o código só poderá ser enviado á branch Master quando estiver estável,válido e limpo. O HEAD desta branch sempre deverá estar apontando para tag commits.
Branch de homologação
A branch de homologação utilizada pelo projeto será a development. Será nela onde deverá residir o código usado para gerar builds para o ambiente de homologação/teste. Além disso é a partir da development que feature branchs deverão ser criadas.
Branch de feature
As branchs de features serão utilizadas para o desenvolvimento de novas funcionalidades. Uma vez que a funcionalidade estiver completa, um pull request à development deverá ser feito.
Branch de correção(hotfix)
Além das branchs usuais listadas acima, existem também as branchs de documentação e correção de bugs. As branchs de hotfix servem como uma forma de correção de bugs urgentes em produção. Consequentemente hotfix branchs devem ser criadas a da última versão da branch master.
Fluxos
Fluxo padrão de desenvolvimento.
- Inicia-se trabalho em uma nova issue.
- Cria-se uma nova feature branch a partir da development.
- Criam-se modificações(commits).
- Executam-se testes.
- Ocorrendo tudo bem no passo anterior publica-se a branch para o remoto(origin).
- Um pull request para a branch de homologação(development) deve ser feito e um revisor atribuído.
- O revisor deve realizar uma análise das alterações propostas.
- O revisor aceita o pull request caso seja válido ou notifica inconsistências encontradas por meio de comentários no pull request.
- A feature branch é integrada a development e por meio do deploy contínuo enviada ao servidor de homologação.
fluxo padrão de release
Assim que a branch de homologação(development) tiver acumulado mudanças válidas o suficiente que se adequem em uma nova versão de produção, deve-se fazer os preparativos para uma nova release. Para tanto deverá ser criada uma nova branch da development, uma release branch, para que uma verificação final seja feita(limpeza, mudança de versão, etc...). Uma vez que a branch de release estiver pronta, deverá ser integrada a master por meio de um merge. Esta por sua vez deverá receber uma nova tag e enviada ao servidor de produção via deploy contínuo.
Convenção de nomes
A excessão das branchs de produção e homologação que terão seus nomes fixos, as branchs de features,releases,hotfix e documentação deverão seguir a seguinte convenção:
- Branch de feature
feature/<feature_name> ex: feature/cv-parser
- Branch de release
release/<release_version> ex: release/1.4
- Branch de hotfix
hotfix/<hotfix_version> ex: hotfix/1.45
- Branch de documentação
documentation/<document_name> ex: documentation/vision
Aplicam-se a todas as branchs acima:
- Escolha nomes curtos e descritivos.
- Os nomes das branchs devem ser em inglês.
- Em caso de nomes compostos, a separação das palavras deve ser via hyphen case.
feature/create-filter
Referências bibliográficas
- https://nvie.com/posts/a-successful-git-branching-model/
- https://guides.github.com/introduction/flow/
- https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
- https://www.atlassian.com/continuous-delivery/continuous-delivery-workflows-with-feature-branching-and-gitflow