Feature flags vs deploy: quando usar cada um

O problema

Tem time que trata feature flag como solução universal.

Tem time que evita flag e tenta resolver tudo só com deploy.

Os dois extremos pioram a operação.

Porque deploy e flag mexem em alavancas diferentes.

Quando isso fica confuso, surgem sintomas chatos:

• código liberado, mas funcionalidade ainda “misteriosamente” desligada
• rollback técnico e rollback funcional misturados
• flag velha esquecida
• fluxo de produto virando árvore de if

Modelo mental

Separando de forma limpa:

• deploy decide qual versão do código está rodando
• feature flag decide se certa capacidade fica ativa, para quem e quando

Ou seja:

deploy move a base técnica

flag controla exposição funcional

Essas duas coisas podem andar juntas, mas não são a mesma ferramenta.

Quebrando o problema

Quando deploy basta

Se a mudança é simples e o time aceita liberação direta, um deploy pode resolver sozinho.

Exemplos:

• refactor interno
• ajuste sem comportamento novo exposto
• correções pequenas com baixo risco funcional

Aqui a flag pode ser só complexidade extra.

Quando flag ajuda muito

Flag faz bastante sentido quando você quer:

• habilitar funcionalidade aos poucos
• testar com grupo pequeno
• desligar rápido sem novo deploy
• separar entrega técnica de janela de negócio

Isso é especialmente útil quando a funcionalidade:

• é arriscada
• afeta receita
• depende de ativação coordenada
• precisa ser testada com público parcial

Flag também não substitui estratégia de deploy

Esse é um erro clássico.

Mesmo com flag, o código novo já foi parar em produção.

Se esse código introduz:

• custo de CPU
• bug em inicialização
• migração quebrando
• problema de compatibilidade

a flag sozinha não te salva.

Ela ajuda a controlar exposição funcional.

Não apaga todo risco técnico da versão.

Flag tem custo de manutenção

Cada flag adiciona:

• caminho condicional
• possibilidade extra de estado
• matriz de teste maior
• necessidade de limpeza depois

Flag velha esquecida vira legado escondido.

Por isso flag boa costuma ter:

• objetivo claro
• dono
• critério de remoção
• prazo de limpeza

Exemplo simples

Imagine um checkout novo.

O time quer subir o código antes da campanha de sexta.

Faz sentido:

1. deploy do código novo
2. funcionalidade ainda desligada por flag
3. ativação interna para teste controlado
4. rollout para 5%, 20%, 100%
5. kill switch rápido se o erro subir

Isso é diferente de usar flag para esconder código indefinidamente sem plano.

No primeiro caso, a flag ajuda o rollout.

No segundo, ela vira depósito de ambiguidade.

Erros comuns

• Tratar flag como alternativa completa a deploy.
• Esquecer de remover flag depois da estabilização.
• Criar flag para qualquer detalhe irrelevante.
• Usar flag como desculpa para não pensar em release.
• Misturar comportamento de produto com configuração técnica sem clareza.

Como um senior pensa

Quem tem mais experiência costuma perguntar:

“Eu preciso controlar a exposição da funcionalidade, a liberação do código ou as duas coisas?”

Essa pergunta organiza muito bem a decisão.

Porque evita colocar na flag um problema que era de deploy, ou colocar no deploy um problema que era de rollout funcional.

O que o entrevistador quer ver

Em entrevista, o avaliador quer ver se você distingue ferramentas de entrega.

Você sobe de nível quando:

• separa deploy de exposição funcional
• menciona rollout gradual e kill switch
• fala do custo de manter flags
• reconhece que flag não remove todo risco técnico

Uma resposta forte costuma soar assim:

“Deploy leva o código para o ambiente. Flag controla se aquela capacidade fica ativa. Eu usaria flag quando preciso de rollout gradual, experimento ou desligamento rápido, mas tomaria cuidado para não acumular caminho morto e complexidade desnecessária.”

Flag boa compra controle. Flag demais compra confusão parcelada.