O que é Trunk Based Development: Guia Prático para Times

Quando você busca 'o que e trunk based development', a resposta curta é que é uma estratégia de branching onde todo desenvolvedor faz merge para uma única branch compartilhada, geralmente chamada de main ou trunk, pelo menos uma vez por dia. Não há branches de longa vida. O código permanece em estado pronto para produção o tempo todo. Se uma feature não está pronta, um feature flag a mantém oculta dos usuários, não uma branch isolando-a do time.

Essa é a versão curta. A versão mais longa envolve entender por que seu workflow atual pode estar gerando mais risco do que você percebe.

Por que branches de longa vida se tornam um problema

A maioria dos times aprende versionamento através de branches de features: uma branch por ticket, mergeada após review. Parece organizado.

Quando uma branch vive mais de 24 horas, cada commit que seus colegas fazem na main é um conflito futuro que você ainda não viu. Num time de oito engenheiros, cada um mantendo uma branch de duas semanas, você não está rodando uma integração. Está gerenciando oito mundos paralelos que divergem um pouco mais cada dia. O dia do merge não é uma tarefa: é uma negociação.

A pesquisa DORA, o maior estudo longitudinal de performance de delivery de software realizado com milhares de times, desenha uma linha clara aqui: branches que vivem mais de 24 horas são sinal preditivo de frequência de deploy menor e taxa de falhas de mudança maior. Times de elite integram múltiplas vezes por dia. Os outros fazem merge quando a feature está "pronta", o que frequentemente significa nunca de forma limpa.

O custo oculto não é o conflito de merge em si. É a mudança de contexto necessária para resolvê-lo três semanas depois que o código foi escrito. Ninguém lembra qual era a intenção.

Como trunk based development realmente funciona

A mecânica é direta. Você puxa main. Faz uma pequena mudança coerente. Roda a suite de testes. Faz push para main. Tudo isso acontece antes de você sair para almoçar.

Para um contribuidor solo num repo pequeno, já é assim que funciona. Para um time de vinte num monorepo de 300K LOC, requer três práticas trabalhando juntas:

Branches de curta vida (opcional mas comum): Alguns times permitem branches de até dois dias antes de forçar um merge. Isso preserva cultura de code review sem criar divergência de múltiplas semanas. A branch é um veículo para review, não um mecanismo de isolamento.

Integração contínua em cada push: Todo commit na main dispara uma build completa e suite de testes. Se quebra, quebra em minutos, não depois que uma branch de feature de duas semanas cai na sexta-feira às 16h.

Feature flags para trabalho incompleto: Features inacabadas vão para produção atrás de uma flag. Usuários não veem nada. O time integra tudo. Essa é a peça que a maioria dos times pula, por isso seu primeiro experimento com TBD falha.

Nenhuma dessas práticas é exclusiva do trunk based development. A diferença é que TBD torna todas três obrigatórias em vez de opcionais.

Feature flags: o mecanismo que faz TBD funcionar

Um feature flag é um condicional no seu código que é avaliado em runtime. Quando uma flag está off, o novo caminho de código não executa. Quando está on, para um usuário específico, uma porcentagem de tráfego, ou a base de usuários toda, executa.

Isso soa trivial. A implicação não é: você pode separar deployment de release. Código vai para produção continuamente. Features lançam quando estão prontas, ou não lançam nunca se o rollout der errado e você precisar matá-la em dez segundos em vez de fazer rollback de três semanas de commits.

O setup mínimo viável requer três coisas: uma forma de definir flags, uma forma de avaliá-las em runtime, e uma forma de mudá-las sem fazer redeploy. Um arquivo JSON simples funciona para um time de três. Um serviço dedicado de gerenciamento de features justifica sua complexidade em torno de dez engenheiros ou quando flags começam a precisar de regras de targeting como "habilitado para usuários no cohort beta na Alemanha".

Uma coisa para acompanhar: débito de flags. Flags que nunca são limpas depois que a feature vai ao ar viram spaghetti condicional. Um time fazendo TBD corretamente retira cada flag dentro de um sprint depois que a feature está completamente rolled out. Trate flags como scaffolding temporário, não como configuração permanente.

TBD vs Gitflow: comparação direta para 2026

Gitflow foi desenhado em 2010 para software boxed entregue num ciclo trimestral. Modela releases como branches de longa vida. Para times que fazem deploy a cada dia ou a cada hora, aquele modelo não mapeia mais.

Aqui está o que a comparação parece para um time rodando CI/CD:

Lifetime da branch: Gitflow roda dias a semanas. TBD roda horas com máximo de 1-2 dias.

Conflitos de merge: Gitflow produz conflitos frequentes, alta-severidade. TBD produz raros, baixa-severidade porque as gaps de integração são horas, não semanas.

Frequência de deploy: Gitflow amarra deployment a uma release branch. TBD desacopla deployment de release completamente.

Mecanismo de rollback: Gitflow faz rollback revertendo um merge de branch. TBD faz rollback desligando uma feature flag.

Complexidade de onboarding: Gitflow requer entender convenções develop/main/hotfix. TBD tem uma branch: main.

Investimento CI necessário: Gitflow é baixo (branches absorvem o risco). TBD é alto (main deve ficar verde o tempo todo).

Gitflow não é errado em todo contexto. Se você entrega um app mobile para uma App Store e não pode fazer push de hotfixes em minutos, um modelo de release branch faz sentido. Se você roda um SaaS onde você controla deployments, a estrutura de branching extra é overhead que adiciona custo de coordenação sem adicionar segurança.

O que DORA metrics dizem sobre estratégias de branching

A pesquisa DORA State of DevOps acompanha performance de delivery de software desde 2014. Dois achados dos dados são diretamente relevantes aqui.

Primeiro, trunk based development é uma das 24 capacidades que predizem performance de delivery de software no modelo DORA. Fica sob o cluster "continuous delivery", que significa DORA trata como prática de infraestrutura, não preferência de time.

Segundo, times de elite fazem deploy múltiplas vezes por dia. Low performers fazem deploy uma vez por semana ou uma vez por mês. Branches de longa vida e integração infrequente aparecem na ponta mais lenta daquela distribuição através de múltiplos anos de dados.

O que a pesquisa não afirma: que TBD causa performance de elite. Times que adotam TBD com sucesso tendem já a ter testes automatizados, um pipeline de CI funcional, e um hábito de commits pequenos. Trunk based development expõe aquelas gaps imediatamente se estiverem faltando. Um time sem CI e 40% de test flakiness não vai se beneficiar de mudar para TBD. Vai só quebrar main mais frequentemente.

Onde trunk based development para de fazer sentido

Três cenários onde TBD cria mais problemas do que resolve:

Ambientes altamente regulados com portas obrigatórias de aprovação pré-release: Se todo release precisa de sign-off de compliance antes de poder ir ao ar, continuous deployment para produção está bloqueado mesmo assim. O modelo de branching vira secundário. Você vai fazer batch de mudanças independentemente da estratégia de branching.

Suites de testes underpowered: TBD requer um pipeline de CI rápido e confiável. Se builds levam 45 minutos e têm 20% de flakiness, desenvolvedores vão fazer batch de commits para evitar esperar. Isso derrota o modelo. O constraint é a infraestrutura de testes, não a convenção de branching.

Times muito grandes com propriedade de código inconsistente: Em times de 50+ onde cada squad dono de um serviço distinto, TBD funciona bem no nível de serviço. Aplicar através de um monorepo compartilhado onde todo mundo toca tudo requer stricta convenções de linting e regras de propriedade de CI para manter main limpa.

Em todos os três casos, o fix não é uma estratégia de branching diferente. O fix é o problema de infraestrutura underlying. TBD só torna aquele problema visível mais rápido.

Como migrar sem parar entregas

A migração que a maioria dos times faz errado: anunciam TBD, deletam a convenção de feature branch, e veem main quebrar na primeira semana.

Um caminho mais seguro:

1. Mantenha branches existentes, adicione uma regra de lifetime: Nenhuma branch vive mais de 3 dias. Isso força a pressão de integração frequente sem desligar as luzes.

2. Instrumente seu CI primeiro: Antes de merge ficar rápido, merge precisa ficar seguro. Garanta que a suite de testes está verde, roda em menos de 15 minutos, e bloqueia a main branch em falha.

3. Pegue uma feature para gate com uma flag: Construa o músculo de gerenciamento de flags antes de precisar dele para cada feature inacabada.

4. Diminua lifetime da branch semana a semana: De 3 dias a 2 dias a 1 dia através de seis semanas. Acompanhe frequência de conflito de merge como indicador líder. Quando cair, o modelo está funcionando.

5. Retire a convenção antiga só quando a nova funciona: Convenções Gitflow ficam em lugar para qualquer coisa fora do pilot. Rodar ambos modelos por 6-8 semanas é fine.

O hábito que prediz se TBD vai se manter

Trunk based development não falha porque times não conseguem fazer merge para main. Falha porque desenvolvedores não têm o hábito de scoping de trabalho pequeno o bastante para entregar num dia.

A mudança underlying não é técnica. É como trabalho fica definido em planning. Uma story que diz "implementar o novo fluxo de pagamento" é uma branch de duas semanas esperando para acontecer. Uma story que diz "adicionar o route handler e retornar 501 atrás da flag payment-v2" é um commit de meia hora.

Isso requer envolvimento de PM e higiêne de backlog que a maioria dos times não construiu. A mudança de estratégia de branching leva um dia para anunciar. A disciplina de scoping leva seis meses para construir.

Se seu time já entrega software funcional para produção diariamente, TBD formaliza o que você já faz. Se seu time entrega a cada duas semanas com um big bang merge no final, TBD não vai estar confortável até os hábitos de entrega underneath mudarem.

Os times que se mantêm com TBD são os que investiram em três coisas antes de mudar: um pipeline de CI de menos de 15 minutos, um serviço de feature flag funcional, e cerimônias de sprint que produzem stories pequenas o bastante para fechar num dia. Sem esses três, a convenção de branching é a alavanca errada.

Ferramentas que ajudam times a rodar workflows de TBD

Rodar trunk based development no nível de time significa mais alinhamento síncrono: standups rápidos para pegar drift de integração, convenções documentadas para flags e regras de CI, e calls para pair-review em caminhos críticos.