Colocando a "casa em ordem" com Git Flow

You can do a lot of things with git, and many of the rules of what you *should* do are not so much technical limitations but are about what works well when working together with other people. So git is a very powerful set of tools.
Linus Trovalds

Os repositórios de código-fonte dos sistemas que uma empresa desenvolve são o “coração” da engenharia de software.

Empresas maduras na capability de engenharia de software têm repositórios “saudáveis”, ou seja, que facilitam a implementação ágil de mudanças (implementações e correções) nos sistemas – com baixo development lead-time e alta frequência de deploys – e facilitam a colaboração. Por outro lado, repositórios “doentes” dificultam a resolução de problemas do dia-a-dia, sendo, inclusive, difíceis de monitorar, impedindo a adoção de práticas reconhecidamente positivas, como continuous integration continuous deployment.

Continuous Integration (CI), Continuous Delivery e Continuous Deployment (CD)

Continouous Integration (CI) é uma prática de engenharia onde código é integrado em um repositório compartilhado com maior frequência possível – de preferência várias vezes ao dia. Cada integração geralmente é verificada por compilação e testes automatizados.

Continuous Delivery é uma extensão da Continuous Integration, pois implanta automaticamente todas as alterações de código em um ambiente de teste e/ou produção após o estágio de compilação.

Finalmente, Continuous Deployment (CD) vai um passo além da Continuous Delivery. Com essa prática, toda mudança que passa por todas as etapas do seu pipeline de produção é liberada para seus clientes. Não há intervenção humana e apenas um teste com falha impedirá que uma nova alteração seja implantada na produção.

Repositórios “doentes” raramente são produtos de tecnologias ou ferramentas ruins. Na prática, o que ocasiona problemas são a falta de políticas claras e conduta indisciplinada.
0
Considerações?x

Modernamente, a maioria das empresas utiliza alguma implementação de git como base tecnológica para controlar seus repositórios. Uma das abordagens mais efetivas para utilizar git do jeito certo é o git flow.

Git

Git  é um sistema de controle de versões distribuído, usado principalmente no desenvolvimento de software, mas pode ser usado para registrar o histórico de edições de qualquer tipo de arquivo (Exemplo: alguns livros digitais são disponibilizados no GitHub e escrito aos poucos publicamente).

O Git foi inicialmente projetado e desenvolvido por Linus Torvalds para o desenvolvimento do kernel do Linux, mas foi adotado por muitos outros projetos.

O que é e quando usar “Git flow”

O Git flow é um “modelo opinativo” de trabalho para equipes de engenharia de software que utilizam Git. Ele foi idealizado por Vincent Driessen em 2010 e se destaca pela fluidez que adiciona ao processo para desenvolvimento de novas funcionalidades, correções de bugs e lançamento de versões.

A successful Git branching model

Artigo original, escrito por Vincent Drissen em 2010, onde ele propõe o git flow. Trata-s de uma excelente referência, detalhada e ilustrada, do modelo.

Acessar artigo

O modelo proposto por Drissen, segundo o próprio autor, é ideal para projetos que utilizam versionamento semântico ou quando times precisam suportar várias versões, em produção, simultaneamente.

Definição: Semantic versioning

Semantic versioning é uma estratégia para determinação de versões, utilizando números, em um esquema, MAJOR.MINOR.PATCH, onde deve-se incrementar o major quando as mudanças implementadas geram incompatibilidade com versões anteriores, minor quando forem adicionadas funcionalidades mantendo a compatibilidade e, finalmente, patch quando há apenas correção de falhas.

Como funciona o “Git Flow

O Git Flow trabalha com duas branches principais, a Develop e a Main (antigamente Master), que são mantidas no repositório indefinidamente. Além delas recomenda-se manter uma branch para cada release que se deseja disponibilizar.

A partir das branches principais, podem ser criadas outros dois tipos de branches: Feature e Hotfix, temporárias e mantidas até serem mescaladas com as branches principais.

A branch Main armazena o histórico oficial de lançamentos, enquanto a branch Develop é base para integração. 

Toda vez que uma nova feature for desenvolvida, uma branch específica deve ser iniciada a partir da branch Develop. Idealmente, esta branch deverá ser nomeada conforme padrão fixo (ex: feature/<nro. do documento de solicitação). Ela deverá existir até que a implementação esteja concluída quando, então, deverá ser mesclada com a branch develop.

O número de branches Feature abertas corresponde ao número de funcionalidades que estão sendo desenvolvidas simultaneamente. Em times de engenharia que adotam kanban, elas ajudam a controlar o Work in Progress.

Sempre que uma correção imediata, em produção, for necessária, uma branch hotfix deve ser iniciada, a partir da Main. Idealmente, essa branch deverá ser nomeada conforme padrão fixo (ex: hotfix/<nro. do documento de solicitação>). Ela deverá existir até que a correção esteja implementada e pronta para ser integrada tanto na branch Main quanto Develop. Além disso, toda vez que for realizado um merge  com a Main, uma tag indicativa de versão deverá ser indicada.

O número de branches Hotfix abertas corresponde ao número de erros em produção que estão sendo corrigidos simultaneamente. A comparação entre a quantidade de branches Feature Hotfix serve como um “retrato” do momento do time.

Métricas! Métricas!

A adoção do git flow oferece excelentes alternativas para coleta duas métricas fundamentais: development lead-time e frequência de deploy.

Development lead-time pode ser “simplificado”, em projetos ativos, para o intervalo de tempo entre tags indicando versões que introduzem features. De forma análoga, a frequência de deploy pode ser medida a partir da quantidade de tags indicando versões que introduzem features em um determinado intervalo de tempo (por exemplo, em um mês).

Uma restrição importante

Git flow pode ser considerado burocrático demais para empresas com frequências de deploy muito altas (várias vezes ao dia, por exemplo). Tal restrição é sinalizada, inclusive pelo criador do modelo.
1
Considerações?x

Para pensar…

Git flow é um “primeiro passo seguro” para times de engenharia com processos de gestão do repositório desestruturados. Ele estabelece, imediatamente, a implantação de práticas saudáveis como controle efetivo de versões e coleta de métricas essenciais para a gestão.
0
Considerações?x

Mesmo com algumas limitações perceptíveis, entendo que o modelo ajuda organizações de engenharia a por a “casa em ordem”, habilitando trabalho simultâneo, colaboração e suporte para correções rápidas.

Compartilhe este capítulo:

Compartilhe:

Comentários

Participe da construção deste capítulo deixando seu comentário:

Inscrever-se
Notify of
guest
2 Comentários
Oldest
Newest Most Voted
Feedbacks interativos
Ver todos os comentários
Tiago Serra
Tiago Serra
1 ano atrás

Eu gosto de usar um git-flow, aonde trabalho por exemplo temos 3 branchs principais: Master, Development e Stagin.
 
Como trabalhamos com uma aplicação monolítica, ao qual todos os clientes utiliza o mesmo repositório GIT.

Toda branch de desenvolvimento sai da Development, após a conclusão sobe para Staging que no final quando QA válida em um ambiente comunitário, a branch é feita o merge na Development e posterior na Master. Caminho feliz rs…

Temos alguns problemas referente a este processo, quando um bug não mapeado sobe, sobe para todos. Posso dizer que a aplicação é “rolling release” rs.
 
A grande barreira que temos hoje é como criar um git-flow que nos atenda e não gere entregas de bugs no pool de clientes.
 
Meu resumo, acredito que o git-flow ajuda e muito, mas tendo uma pitada de ajustes de acordo com cada empresa ou projeto.

Douglas Picolotto
Douglas Picolotto
1 ano atrás
Feedback no conteúdo deste capítulo Git flow pode ser considerado burocrático demais para empresas com frequências de deploy muito altas (várias vezes ao dia, por exemplo).…" Ler mais »

Outro aspecto interessante é que Gitflow irá funcionar melhor quando o time trabalhar em um modelo de sprints, entregando batches de features ao final de cada iteração.

Fundador e CEO da EximiaCo, atua como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Consultoria e Assessoria em

Engenharia de Software

Adoção de práticas, políticas e ferramentas para o desenvolvimento de software.

ElemarJúnior

Fundador e CEO da EximiaCo, atua como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Podcast

Arquitetura de Software Online

55 51 9 9942 0609  |  me@elemarjr.com

+55 51 99942-0609 |  contato@eximia.co

+55 51 99942-0609  contato@eximia.co

2
0
Quero saber a sua opinião, deixe seu comentáriox
()
x