Trunk-Based Development

Olá pessoal!

Geralmente utilizamos algum fluxo git como estratégia de desenvolvimento em nossos times. Normalmente 3 branches:

• main ou master
  • Código que roda em produção
  • Protegida
  • Geralmente utilizada só para fazer o deploy, pois todos todos os testes foram feitos na branch de staging.
• staging ou release
  • Código que roda em ambiente de staging (pré-produção)
  • Protegida
  • Utilizada para testes de funcionalidade em condições reais, detecção de bugs e problemas, validação de configurações, teste de integração, carga, etc.
• develop
  • Somatário das novas funcionalidades vindas de todos os times e hotfixes encontrados em produção.

Geralmente temos um fluxo parecido com isso que é a idéia do gitflow e muito bem aceita hoje em dia.

Mas já ouviu falar na estratégia Trunk-Based Development (TBD)?

Trunk-Based Development (TBD) é uma estratégia de desenvolvimento de software em que todos os desenvolvedores colaboram em uma única branch principal (geralmente chamada de "trunk" ou "master/main") e fazem commits frequentes diretamente nela.

Exige muito mais concetração e rigor e por isso é recomendado um pipeline de CI apurado no trunk.

No caso de prójetos open source, os desenvolvedores não podem criar branches no repositório onde temos o trunk. O desenvolvedor é obrigado a criar um fork do projeto e depois e quando finalizado sua contribuição criar um PR trunk to trunk ou manter seu fork atualizado com o fork do projeto principal e desenvolver em uma branch no seu repositório e pedir criar o PR.

Os desenvolvedores trabalhando eu seus próprios repositórios não quebram a compilação com nenhum commit. É função dos desenvolvedores assumirem o hábito de provar que o commit é bom.

Em um projeto empresarial podemos criar branches no mesmo repositório para desenvolvimento das features e fazer um PR direto para o trunk.

Um trabalho somente é considerado concluído se estiver mergeado no trunk do projeto principal.

Novas branches serão criadas pelos mantenedores do repositório para uma branch de release que viverá por um período pequeno. Esta branch será substituída por outra branch de release no futuro, ou não caso queira manter o histórico dependendo do projeto.

Não existe uma regra bem definida, já vi casos que somente são criadas tags para marcações sem branches de release.

Ainda é possível que exista somente uma branch trunk e ponto final, tudo depende do tipo de projeto.

Caso use branches de release, um bug deve ser corrigido no trunk e mesclado ao branch de release somente pelo mantenedores.

Trabalhar com TBD no Git exigi uma cultura de desenvolvimento disciplinada, com práticas como code reviews, testes automatizados rigorosos e uma boa comunicação entre a equipe, mas os benefícios em termos de qualidade e velocidade de entrega podem ser significativos. Uma pipeline robusta é extremamente necessário.

Vantagens

• Integração Contínua e Rápida: Como todos estão trabalhando na mesma branch, as mudanças são integradas frequentemente, o que ajuda a detectar problemas de integração rapidamente. Isso reduz o risco de surpresas desagradáveis no final do ciclo de desenvolvimento.

• Simplicidade no Controle de Versão: Com menos branches long-lived, o gerenciamento do repositório se torna mais simples e fácil de manter. Isso reduz o overhead de merges complexos e conflitos difíceis de resolver.

• Feedback Rápido: As mudanças são testadas e integradas de forma contínua, permitindo que problemas sejam identificados e corrigidos rapidamente. Isso acelera o ciclo de feedback e aumenta a qualidade do código.

• Facilita o DevOps e o Continuous Delivery: TBD é uma prática que se alinha bem com as práticas de DevOps, como Continuous Integration (CI) e Continuous Deployment (CD), já que o código está sempre em um estado pronto para deploy.

• Redução de Branches Longas e Conflitos de Merge: Como o foco é em commits frequentes na branch principal, você evita a criação de long-lived branches que podem causar grandes conflitos de merge. Isso também reduz a possibilidade de "merge hell".

• Estimula a Colaboração: TBD incentiva a colaboração e a comunicação frequente entre os membros da equipe, já que todos estão constantemente revisando e integrando o trabalho uns dos outros.

• Agilidade na Resolução de Bugs: Bugs podem ser corrigidos rapidamente, sem a necessidade de fazer cherry-pick ou backport para outras branches, já que o código está centralizado.

• Maior Transparência e Visibilidade: Com todos trabalhando na mesma branch, é mais fácil para todos os membros da equipe terem visibilidade do estado atual do projeto.

Desvantagens

• Risco de Instabilidade na Branch Principal: Como todos os desenvolvedores estão fazendo commits frequentes na mesma branch, há um maior risco de introduzir bugs ou problemas que afetam toda a equipe. Isso pode causar instabilidade, especialmente se os testes não forem rigorosos.

• Maior Necessidade de Disciplina e Boas Práticas: A equipe precisa ter uma disciplina rigorosa em relação a práticas como code reviews, testes automatizados e controle de qualidade. Recomendo o uso do sonarqube para ajudar no processo de qualidade.

• Complexidade em Equipes Grandes: Pode ser difícil coordenar e gerenciar o trabalho sem que ocorram conflitos frequentes com pessoas trabalhando no mesmo ponto do código.

• Dependência de Testes Automatizados Fortes: TBD depende fortemente de uma suite de testes automatizados robusta. Se os testes não forem abrangentes o suficiente ou se houver falsos positivos/negativos estes serão integrados à branch principal.

• Menos Isolamento de Funcionalidades: Em metodologias onde se usa feature branches, as novas funcionalidades podem ser desenvolvidas e testadas de forma isolada antes de serem integradas, não no caso do TBD.

• Dificuldade em Gerenciar Releases: Em projetos onde há necessidade de gerenciar múltiplas versões ou releases simultâneos, TBD pode ser mais desafiador, pois todas as mudanças vão direto para a branch principal. Isso pode complicar a criação de hotfixes ou versões anteriores. Não é muito recomendado para este cenário.

• Curva de Aprendizado: Para equipes acostumadas a trabalhar com long-lived branches e merges tradicionais, a transição para TBD pode exigir uma mudança significativa na mentalidade e nas práticas de trabalho, o que pode levar algum tempo para se adaptar e onboarding maiores e mais treinamento por parte da empresa.

• Menos Flexibilidade em Ciclos de Desenvolvimento: Em cenários onde certas funcionalidades precisam ser lançadas separadamente ou em cronogramas diferentes, a abordagem de TBD não é muito bem adaptada.