Codeblox Blog
O que é o Release Flow?
Sobre o Release flow
O Release flow é uma estratégia de branching divulgada pela Microsoft, que o utiliza para suportar o desenvolvimento de, ao menos, um de seus produtos - o Azure DevOps.
Em linhas gerais a estratégia se baseia na utilização de branches de integração rápida, que devem ser constantemente integradas ao ramo principal (geralmente denominado main ou, em alguns repositórios mais antigos, master).
Normalmente, cada membro do time cria a sua branch como um “diretório” (e.g.: users/tomblue) e a publica para o repositório remoto. Ela deve ser constantemente integrada ao ramo principal por meio de um PR (pull request), onde poderá receber validações adicionais (testes automatizados, aprovação por uma pessoa do time, etc.).
A prática deve estar alinhada a uma programação de sprints (ou iterações), que guiará o desenvolvimento do time nesse período.
Ao término de uma sprint, a partir da branch main, cria-se uma release branch que geralmente segue o seguinte padrão: releases/{versão}. Onde em {versão}, pode ser utilizado um código incremental, versionamento semântico, uma data ISO8601-like (sem os hífens 🤨) ou o que for convencionado entre o time.
Exemplo: entregando uma feature
Você acabou de ingressar em um projeto e precisa implementar um formulário de cadastro.
Após clonar o projeto por meio do comando git clone https://repositorio/projeto.git, você criará a sua branch para efetuar as alterações necessárias (git checkout -b users/meu-usuario).
Encerrado o desenvolvimento, você adiciona todos arquivos relacionados à sua alteração com o comando git add . e efetua o commit git commit -m "Cria cadastro para fornecedores".
Agora você deve subir suas alterações para o servidor remoto com o comando git push ou git push -u origin users/meu-usuario.
Finalmente, para integrar suas alterações ao ramo principal, você deve criar um novo PR (pull request). No Github, é feito assim.
Exemplo: corrigindo um bug de produção 🐛
Similarmente ao desenvolvimento de uma feature, você criará uma branch específica para a correção a partir da main. Ao finalizar os trabalhos, você deverá enviá-la para o servidor remoto e integrar a alteração, por meio de um pull request, na branch principal.
Mas por que integrar a correção na main e não na branch releases/{versão}?
A resposta é simples: se aplicarmos a correção inicialmente na branch de release em que ocorreu o problema, há grandes chances do patch não ser aplicado na branch principal, seja por esquecimento, seja por falta de conhecimento do profissional. No cenário apresentado, o deploy de um novo release (e.g.: releases/{versão 2}) irá fazer com que o bug reapareça em produção (regressão).
E como fazer para a correção ser aplicada na branch de release problemática?
Feita a integração na main, essa alteração deverá ser pontualmente transportada para o release alvo. Isso pode ser feito com o comando (git cherry-pick) diretamente na branch de release. Idealmente, espera-se que seja criada uma branch temporária específica para esse fim, sendo a integração realizada por meio de um PR. No Azure DevOps esse processo pode ser feito de forma automatizada na própria interface web.
Considerações finais e vantagens sobre o Git flow
Por contar com branches de integração rápida, que “orbitam” a main a CI ou Integração Contínua é facilitada e torna-se natural.
O uso do Git flow reconhecidamente promove/facilita a criação de branches de longa duração, que prejudicam a CI.
A ThoughtWorks, em seu technology radar, consistentemente advoga contra o uso do Git flow por conta do mesmo motivo. Sendo a recomendação mais recente realizada em Maio de 2020.
