O que significa integrar para não entregar na prática
A maioria dos times fala sobre integração contínua como se o objetivo final fosse liberar código todo dia. Na verdade, o que funciona de verdade é exatamente o oposto: você integra frequência, mas mantém o fluxo de entrega separado. Integrar para não entregar é sobre manter o código vivo no repositório, validando mudanças e evitando que nada apodreça em branches isolados, sem que isso signifique promoção para produção. Eu vi time de produto achar que trunk-based era sinônimo de deploy todo dia. Não era. Eles travaram releases durante três semanas porque ninguém percebia que a definição de "entregar" estava ambígua entre engenheiros e product managers. A solução foi simples: separar merge do branch principal de deploy. Feature flags resolveram o resto.
Integrar para não entregar: quando fazer isso e quando não fazer
Existem cenários onde essa abordagem faz sentido. Regras de negócio ainda não definidas, código que depende de parâmetros não finalizados, ou múltiplos releases que precisam existir simultaneamente em ambientes diferentes. Também funciona bem quando você tem um pipeline de qualidade que exige gate manual antes da promoção. Não funciona quando a equipe interpreta "não entregar" como "não se preocupar em melhorar". Branches que nunca são fundidos viram debt técnico encoberto. Eu recomendo que o prazo máximo de vida de um branch isolado seja duas semanas, independentemente do que aconteça depois.
Como implementar de verdade
O primeiro passo é configurar o repositório com branch protection rules que impeçam merges diretos. Você precisa de pelo menos dois aprovedores, CI passando obrigatoriamente, e testes de integração rodando antes do merge. Isso não é diferencial. É o mínimo aceitável. Depois disso, você decide a estratégia de feature flags. Existem duas abordagens principais. A primeira usa flags nativas do seu sistema de deployment, como LaunchDarkly, Split, ou os recursos internos de plataformas como AWS Device Farm e Google Firebase Remote Config. A segunda é mais manual: variáveis de ambiente controladas por tag de release, com switches condicionais no código que ativam funcionalidades conforme o ambiente.
Para o pipeline em si, o formato básico é este: git checkout main git pull origin main create feature branch develop merge PR feature flag on em staging deploy staging integration tests feature flag off in production (ou mantido off) release quando pronto
O detalhe que todo mundo erra é a parte de feature flag off em produção. Você precisa de um mecanismo que desative automaticamente após N dias sem uso, ou que trigger um rollback se métricas de erro subirem acima de X%. Sem isso, você está apenas adiando o problema.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Problemas comuns que ninguém conta
Testes de integração quebram frequentemente porque dependem de dados que só existem em produção. Minha solução foi criar um dataset sintético versionado que roda antes de qualquer PR tocar em branches de feature. Ele replica exatamente as dependências que a feature vai usar, sem expor dados reais. Outro problema é o custo de manter múltiplas versões ativas. Cada feature flag adicional consome memória no servidor de configuração e aumenta o tempo de cold start em até 400ms. Se você tem mais de cinquenta flags ativas, considere migrar para um sistema de canary deployment em vez de feature flags puras.
Também existe o problema de documentação. Quando alguém new join na equipe pergunta "essa feature já está no main?", a resposta correta é "depende". Sem um board centralizado de flags e seus status, o time perde horas rastreado qual branch contém qual mudança. Use uma tabela simples no README do repositório com colunas: feature, branch, flag name, status, responsável, data de criação.
Métricas que importam de fato
Lead time for changes: tempo desde o commit até o deploy em staging. Se isso estiver acima de quatro horas, seu pipeline de integração está lento. Deployment frequency: quantas vezes você integra contra quantas vezes entrega. A proporção ideal é algo em torno de dez integrações por deploy, mas varia conforme o tamanho do time.
Change failure rate: porcentagem de integrações que causam rollback ou hotfix. Acima de quinze por cento indica que os gateways de qualidade não estão funcionando. Mean time to recovery: quanto tempo leva para reverter uma feature flag problemática. Deve ser menor que cinco minutos. Se for maior, seu processo de flag toggle está mal estruturado.
Quando abandonar essa abordagem
Se sua equipe tem menos de cinco engenheiros e o produto é simples, feature flags podem ser overkill. Trunk-based development sem flags, com deploys frequentes e rollbacks rápidos, costuma ser mais eficiente. A complexidade adicional de gerenciar flags não compensa o ganho em cenários pequenos. Da mesma forma, se seu time já entrega semanalmente com qualidade aceitável, introduzir a camada extra de integração separada só adiciona overhead sem benefício real. Meça antes de decidir.
