O desenvolvimento baseado em troncos é uma das várias estratégias de branching frequentemente usadas por equipes que praticam integração contínua e entrega/implantação contínua (CI/CD).
Com o desenvolvimento baseado em troncos, você confirma as alterações diretamente no branch master (também conhecido como tronco), em vez de desenvolver recursos ou correções de bugs em branches separados e mesclá-los no master em algum estágio posterior.
A submissão de alterações no branch master aciona o pipeline de CI/CD. Se o pipeline sinalizar alguma falha, é responsabilidade de todos tentar consertá-la o mais rápido possível. O objetivo é manter o branch master em um estado implantável, com alterações sendo lançadas com frequência.
Se você já está familiarizado com os princípios de CI/CD, provavelmente reconheceu pela descrição anterior que o desenvolvimento baseado em troncos é uma boa opção para integração e implantação contínuas. Contanto que todos em sua equipe possam submeter suas alterações regularmente, você obtém os benefícios de visibilidade das alterações de todos, além de feedback regular e rápido sobre o que está sendo construído.
A primazia de manter o branch master íntegro e em um estado lançável incentiva todos a adicionar testes para suas alterações à medida que avançam. Monitorar as métricas de cobertura do teste ajudará você a ficar de olho nisso, garantindo todos compilem localmente (talvez também executando um conjunto básico de testes automatizados) antes da submissão, o que reduzirá o número de problemas encontrados no master.
Alguns defensores do desenvolvimento baseado em troncos argumentam que ela é a única maneira de obter integração contínua e que o uso de branches de desenvolvimento ou recursos apenas prejudica os benefícios da CI/CD. No entanto, o desenvolvimento baseado em troncos também tem suas desvantagens.
Embora seja uma ótima opção para implantação contínua, na qual as alterações de código que passam por todos os estágios do pipeline são lançadas automaticamente, o modelo funciona melhor para produtos de SaaS, nos quais há uma alta tolerância e até mesmo uma expectativa de atualizações contínuas.
Se você estiver construindo um produto instalado ou um aplicativo móvel, convém agrupar as alterações em lançamentos periódicos em vez de criar uma nova versão para cada atualização que surge no pipeline.
Nesse caso, o uso de branches torna mais fácil gerenciar o que está incluído em cada lançamento e fornece suporte contínuo para várias versões do produto.
Um desafio potencial do desenvolvimento baseado em troncos envolve como você lida com o desenvolvimento de recursos grandes ou complexos. Aplicar alterações ao master regularmente e, ao mesmo tempo, implantá-lo diretamente na produção requer uma maneira de gerenciar a funcionalidade que você ainda não deseja tornar visível para os usuários.
Para o desenvolvimento baseado em troncos, sinalizadores de recursos fornecem uma maneira de controlar a visibilidade dos recursos. Porém, pode ser complexo gerenciá-los. Uma alternativa é optar por uma estratégia de branching que inclui branches de recursos, para que você possa manter a funcionalidade separada até que esteja pronto para lançá-la.
Para equipes que são novas em CI/CD, submeter as alterações diretamente no master e ao mesmo tempo mantê-lo implantável pode ser um desafio antes que você tenha tempo de desenvolver um conjunto de testes robusto. Se o desenvolvimento baseado em troncos for adequado, vale a pena defini-lo como uma meta que você pode trabalhar conforme sua prática de CI/CD amadurece.
O desenvolvimento baseado em troncos é uma boa opção para integração contínua, e implantação que funciona melhor se você tiver um robusto conjunto de testes automatizados e não precisa oferecer suporte a várias versões de seu software ou agrupar atualizações em lançamentos. No entanto, certamente não é a única maneira, e outras estratégias de branching podem oferecer um ajuste melhor, dependendo das circunstâncias.