Existe um tipo de sofrimento que todo time de software conhece: a branch que ficou aberta por seis semanas e agora precisa ser integrada. O merge tem oitenta arquivos em conflito, ninguém lembra por que aquela linha foi alterada, os testes quebram por motivos não relacionados e alguém passa dois dias resolvendo em vez de entregar valor.
Esse sofrimento é evitável, e a causa não é a ferramenta. É a duração da branch. Quanto mais tempo ela vive separada, mais ela diverge, e a dificuldade do merge cresce muito mais rápido que o tempo.
O problema, em uma frase
Integração é uma dívida com juros compostos. Adiar por um dia custa pouco; adiar por um mês custa desproporcionalmente mais.
A consequência prática é perversa: como o merge dói, o time evita integrar; como evita, a branch fica mais tempo aberta; como fica mais tempo aberta, o merge dói mais. É um ciclo que se alimenta sozinho, e ele é a raiz de boa parte do que as pessoas atribuem a "problemas de processo".
Os dois modelos
Fluxo com branches longas — o padrão que ficou conhecido por separar branches de desenvolvimento, de funcionalidade, de release e de correção emergencial.
Ele foi desenhado para um contexto específico: software com versões distribuídas, múltiplas versões suportadas em campo, ciclos de release longos. Para isso, funciona bem e continua fazendo sentido.
Para aplicação web ou serviço entregue continuamente, ele adiciona cerimônia e incentiva branches longas — que é exatamente o problema.
Trunk-based — todo mundo integra na branch principal com frequência alta. Branches de funcionalidade existem, vivem um a dois dias, e são integradas. A branch principal está sempre pronta para deploy.
A diferença essencial não é o desenho do grafo; é a frequência de integração.
O que trunk-based exige antes
Adotar sem os pré-requisitos produz caos. Quatro condições:
1. Pipeline confiável e rápido. Se a branch principal está sempre pronta para deploy, o que protege é o pipeline. Ele precisa ser rápido — retorno em minutos — e confiável, sem testes instáveis que ensinem o time a ignorar falha.
2. Feature flags. É a peça que torna tudo possível. Código incompleto pode ser integrado desde que esteja desligado. Sem flags, trunk-based obrigaria a esperar a funcionalidade ficar pronta — e a branch voltaria a ser longa.
3. Revisão rápida. Pull request que fica dois dias esperando revisão é uma branch longa disfarçada. A meta razoável é revisão no mesmo dia, o que só é viável com pull requests pequenos — e pull requests pequenos são consequência natural de branches curtas. O ciclo, dessa vez, joga a favor.
4. Mudanças de banco compatíveis para trás. Se a branch principal pode ir para produção a qualquer momento, migração destrutiva não pode conviver com código antigo. É o padrão de expandir e contrair, aplicado por disciplina.
Como quebrar trabalho grande
A objeção mais comum: "minha funcionalidade leva três semanas, não cabe em dois dias".
Cabe — o que não cabe em dois dias é a entrega ao usuário, e ela não precisa coincidir com a integração do código. Técnicas que funcionam:
- Feature flag. Integre o código desligado. Ative quando estiver pronto.
- Ramificação por abstração. Crie uma camada, migre implementação por implementação, remova a antiga no fim. Cada passo é integrável isoladamente.
- De trás para frente. Entregue primeiro o que não é visível: modelo de dados, camada de serviço, testes. A interface vem por último e é pequena.
- Expandir e contrair no esquema. Estrutura nova convive com a antiga até a migração terminar.
Nenhuma dessas é complicada. Elas exigem pensar a decomposição antes de começar a escrever — que é um hábito bom por outras razões também.
Feature flags: o que dá certo e o que vira dívida
Flags resolvem o problema e criam outro se não houver disciplina. Uma base com duzentas flags esquecidas tem um número explosivo de combinações de comportamento que ninguém consegue testar, e o time volta a ter medo de fazer deploy — por um motivo diferente.
Quatro regras que mantêm o benefício:
- Toda flag tem dono e data de remoção. Registradas no momento da criação.
- Flags de liberação são temporárias. Nasceram para ativar algo; removidas em semanas depois de a funcionalidade estabilizar.
- Flags permanentes são outra categoria — configuração por cliente, interruptor de emergência. Poucas, documentadas, tratadas como parte da arquitetura.
- Revisão periódica. Uma lista mensal de flags com mais de 60 dias, com cobrança de remoção.
Vale distinguir os tipos, porque o tratamento difere: liberação (temporária), experimento (temporária, com prazo do experimento), operacional (interruptor de emergência, permanente) e permissão (por cliente ou plano, permanente).
Versionar e liberar
Com trunk-based, cada integração na principal pode gerar um artefato. Duas abordagens:
- Entrega contínua: todo commit na principal gera artefato pronto, e o deploy para produção é um botão. É o modelo mais comum e o mais recomendável para a maioria.
- Implantação contínua: todo commit aprovado vai automaticamente para produção. Exige maturidade alta de teste, monitoramento e rollback automático — e entrega o ciclo mais curto possível.
Para software que precisa manter versões antigas em campo, branches de release de vida curta a partir da principal continuam sendo o caminho, com correções feitas na principal e transportadas para a branch de release, nunca o contrário.
Como migrar sem trauma
A transição não precisa ser de uma vez:
- Meça a duração média das branches. É o indicador que você quer reduzir, e ele costuma revelar um número maior do que o time imagina.
- Estabeleça um limite — nenhuma branch vive mais de três dias — e torne visível quem está fora.
- Invista no pipeline antes de qualquer mudança de processo. Sem ele, o resto falha.
- Introduza feature flags em uma funcionalidade, para o time ver funcionar.
- Reduza o tamanho dos pull requests. Meta explícita de linhas alteradas ajuda mais do que parece.
- Elimine as branches intermediárias que não agregam, uma de cada vez.
- Acompanhe os indicadores certos — abaixo.
O que medir
Quatro números contam a história, e são os mesmos que a pesquisa de engenharia de software vem confirmando há anos:
- Frequência de deploy. Quantas vezes por semana chega em produção.
- Tempo do commit à produção. Quanto tempo o código pronto espera.
- Taxa de falha em mudanças. Percentual de deploys que causam incidente.
- Tempo de recuperação. Quanto leva para restabelecer depois de uma falha.
O achado que contraria a intuição: times que entregam com mais frequência falham menos, não mais. A explicação é simples — lote pequeno tem menos risco, é mais fácil de revisar e, quando falha, é trivial identificar a causa porque mudou pouca coisa.
Se você acompanhar um único número, acompanhe a duração média das branches. Ele prevê os outros quatro.
Erros comuns
- Branch de funcionalidade vivendo semanas.
- Pull request enorme, que ninguém revisa direito.
- Revisão demorando dias, transformando branch curta em longa.
- Adotar trunk-based sem pipeline confiável.
- Trunk-based sem feature flags, com código incompleto quebrando a principal.
- Flags sem dono nem prazo, acumulando combinações intestáveis.
- Não distinguir flag temporária de flag permanente.
- Migração destrutiva de banco convivendo com deploy contínuo.
- Manter fluxo de branches longas em produto entregue continuamente.
- Transportar correção da branch de release para a principal em vez do contrário.
- Medir linhas de código em vez de frequência e tempo de ciclo.
- Achar que entregar menos vezes é mais seguro.
Onde a Solvefy/Cloud entra
Estratégia de branches parece assunto de time de desenvolvimento e é, na prática, um problema de entrega — e é onde consultoria de DevOps atua. Fazemos o diagnóstico com os números do seu repositório: duração de branches, tamanho de pull request, tempo até a revisão, frequência de deploy e tempo de ciclo. A partir daí, tratamos os gargalos na ordem certa: pipeline rápido e confiável primeiro, feature flags com governança depois, e a simplificação do fluxo por último. Também implantamos a medição contínua desses indicadores.
Quanto tempo o código do seu time espera para chegar em produção? Diagnóstico gratuito, sem compromisso, em solvefy.cloud.
Solvefy/Cloud — Infraestrutura que cresce com você.