Você voltou de uma feature branch que viveu três semanas separada da main. O diff tem 47 arquivos. Dois colegas mexeram nos mesmos módulos que você, cada um com sua própria interpretação de como aquela parte do sistema deveria ficar. Você passa a tarde inteira resolvendo conflitos que não são técnicos, e sim de design: vocês três construíram soluções diferentes para o mesmo problema porque ninguém viu o código do outro até agora.
Essa dor é real e comum. E é a razão pela qual trunk-based development soa tão atraente quando descrito em uma palestra ou em um post de blog: todo o time integra na main o tempo todo, as branches vivem horas, não semanas, e os conflitos gigantes desaparecem porque nunca se acumulam.
O problema é que trunk-based development não é uma política que se liga. É uma consequência de já contar com uma infraestrutura que suporta uma integração constante. Se sua equipe não tem essa infraestrutura e migra assim mesmo, você não vai ter menos conflitos. Vai ter os mesmos conflitos, além de uma main quebrada metade do tempo.
O que é trunk-based development, em uma frase que realmente importa
Trunk-based development significa que todos os desenvolvedores integram seu código em uma branch principal (trunk, geralmente main) pelo menos uma vez por dia, em vez de manter feature branches que vivem dias ou semanas antes de serem mergeadas. O código incompleto fica escondido atrás de feature flags, não atrás de branches.
É só isso. Não tem cerimônia extra, não tem processo novo para aprender. Mas essa simplicidade é enganosa: para que "integrar todo dia" não vire um desastre, cada integração precisa ser segura. E é aí que a maioria das equipes que tentam percebe que não estava pronta.
O CI que você tem não é o CI que você precisa
Todo time diz que tem CI. Poucos têm o CI que trunk-based development exige. A diferença não é filosófica, é de velocidade e de confiança.
Se sua suite de testes demora 25 minutos para rodar e vários desenvolvedores estão mergeando na main várias vezes por dia, você vai ter uma fila de builds esperando a vez enquanto o time continua trabalhando em cima de uma main que ninguém sabe se está saudável. Com feature branches longas esse problema não aparece, porque cada branch é testada sozinha, no seu próprio tempo, sem competir com ninguém.
Pior ainda: se seu CI tem testes flaky (aqueles que falham aleatoriamente sem que o código tenha mudado), em um modelo de branches longas eles são ignorados, você tenta de novo, e segue em frente. Em trunk-based development, um teste flaky na main bloqueia todo o time ou, pior, as pessoas aprendem a ignorar as falhas do CI porque "sempre falha alguma coisa". Nesse dia, a rede de segurança deixa de existir e ninguém avisa.
O que é preciso antes de migrar não é "ter CI". É ter um pipeline que rode em minutos, não em dezenas de minutos, com uma taxa de falsos positivos perto de zero, e com a disciplina de equipe de que uma main quebrada se arruma na hora, não no final do dia.
Feature flags: a parte que todo mundo subestima
Sem branches longas, onde vive o código de uma feature que ainda não está pronta para produção? A resposta correta é: atrás de um feature flag. A resposta real em equipes que migram sem pensar é: pela metade, na main, comentado, ou protegido por um if (false) que alguém vai esquecer de remover.
Um sistema de feature flags sério não é uma biblioteca que se adiciona numa tarde. Implica pensar em:
- Como os flags são avaliados em runtime sem degradar a performance, porque agora cada request potencialmente consulta o estado de dezenas de flags ativos ao mesmo tempo.
- Quem é dono do ciclo de vida de um flag: quem o cria, quem decide quando o código antigo é apagado. Os flags que ninguém limpa se acumulam por meses e o código acaba cheio de ramificações condicionais que ninguém entende, o que é exatamente o tipo de dívida técnica que trunk-based development prometia evitar.
- Como se testa código com múltiplos flags combinados. Se há cinco flags independentes, tecnicamente existem 32 combinações possíveis de estado. A suite de testes não roda as 32, então o time está decidindo, mesmo sem ter discutido isso, quais combinações são aceitáveis de não cobrir.
Se sua equipe ainda não tem um sistema de flags maduro, migrar para trunk-based development não elimina o problema de "como esconder código incompleto". Só muda onde ele fica escondido: de uma branch isolada para a produção, misturado com tudo o mais.
Testes automatizados: a parte que decide se isso funciona ou explode
Com feature branches longas, uma suite de testes medíocre é um problema tolerável. Há tempo: a branch vive semanas, há code review extenso, há QA manual antes do merge. Com trunk-based development, esse tempo não existe. O código que sobe hoje pode estar em produção, ou perto disso, em horas.
Isso significa que a cobertura de testes não pode ser aspiracional. Ela precisa cobrir de verdade os fluxos críticos, rodar rápido, e sobretudo, ser confiável: um teste que falha porque o código está errado deve falhar sempre, e um que passa deve significar que aquele caminho realmente funciona.
Aqui aparece uma tensão que pouca gente antecipa: trunk-based development empurra as equipes para testes menores e isolados (unitários, de integração rápida) e afasta dos end-to-end pesados que demoram meia hora para rodar contra um ambiente completo. Se a estratégia de testes depende em grande parte de e2e lentos, é preciso redesenhá-la antes de migrar, não durante a migração.
E se sua equipe simplesmente não tem cultura de testes (alguns PRs com testes, outros sem, cobertura desigual entre módulos), trunk-based development não vai melhorar isso. Vai expor isso, rápido, em produção.
A parte cultural que ninguém coloca no diagrama de arquitetura
Tudo isso até aqui é infraestrutura. Existe uma parte que é puramente de equipe, e é a que mais se subestima.
Trunk-based development exige que o code review seja rápido. Se a norma atual é que um PR espera dois dias pela primeira revisão, e trunk-based development pede para integrar em horas, essas duas contas não fecham. Ou o review vira superficial (o que corrói a qualidade), ou os desenvolvedores evitam pedir review e mergeiam direto (o que corrói a confiança), ou simplesmente o modelo colapsa e todo mundo volta, em silêncio, a manter suas mudanças sem mergear por mais tempo do que o processo "oficial" permite.
Também exige que a equipe tolere ver código incompleto na main o tempo todo, protegido por flags, e confie que esse código não vai ser ativado por acidente. Esse é um salto de confiança que, em equipes com histórico de incidentes de produção, alta rotatividade ou senioridade mista, não acontece de um dia para o outro. Ou se constrói, ou não se tem.
E exige uma definição compartilhada do que significa "pronto para mergear". Em um modelo de branches longas, essa definição pode ser mais flexível porque sobra tempo para corrigir depois. Em trunk-based development, "flexível" significa "quebrado" para todo mundo, na hora.
Quando simplesmente ainda não vale a pena
Há situações em que a resposta honesta é esperar. Se seu CI demora mais de dez minutos e ninguém na equipe tem o mandato nem o tempo dedicado para arrumar isso, migrar só vai transferir a dor das branches para o pipeline. Se seu produto não tem, ou não pode ter por razões regulatórias ou de arquitetura, um sistema de feature flags viável, você vai estar escondendo trabalho incompleto em produção sem nenhuma rede de segurança. Se sua cobertura de testes é baixa e ninguém está disposto a investir em aumentá-la primeiro, cada integração diária é uma aposta, não uma prática de engenharia.
E se a equipe é nova, distribuída em fusos horários muito diferentes sem sobreposição real, ou ainda não tem acordos claros sobre o que é código mergeável, adicionar a pressão de integrar constantemente não resolve a falta de coordenação. Ela a amplifica.
Nada disso é uma rejeição ao trunk-based development como ideia. É reconhecer que ele é consequência de outras coisas bem-feitas, não um atalho para consegui-las. As equipes que adotam com sucesso não fazem isso para consertar seu CI, seus testes ou sua cultura de review: adotam porque essas coisas já estavam resolvidas, e trunk-based development foi o passo lógico que veio depois. Se sua equipe ainda está resolvendo essas coisas, esse é o trabalho de verdade. Trunk-based development pode esperar.
