Deploy e lançamento costumam acontecer no mesmo clique: o código chega à produção e, naquele instante, todos os usuários recebem o comportamento novo. Quando alguma coisa falha, o time precisa reverter o pacote inteiro ou produzir outro deploy sob pressão.
Feature flags quebram esse acoplamento. O código pode entrar desligado, ser ativado para a equipe, chegar a uma fatia do tráfego e só depois virar padrão. O deploy continua sendo uma mudança técnica. O lançamento vira uma decisão operacional.
O raio de explosão diminui porque a exposição é controlada
Uma flag de release permite integrar trabalho incompleto sem criar uma branch eterna. Uma flag operacional pode desligar uma rotina pesada quando a fila cresce. Uma flag de experimento divide usuários para medir resultados. Todas parecem booleanos, mas têm ciclos de vida e riscos diferentes.
O rollout progressivo é a aplicação mais visível. Ative para contas internas, observe erros e latência, avance para 1%, 10% e 50%. Se a métrica degrada, volte a flag sem desfazer outras mudanças saudáveis do mesmo deploy. Isso é reduzir o raio de explosão: menos pessoas expostas e recuperação mais rápida.
Uma flag não substitui teste nem rollback
O caminho desligado precisa funcionar, e o caminho ligado também. Em produção, vale testar pelo menos a configuração atual e a configuração que se pretende liberar. Em áreas críticas, a combinação de flags relevantes precisa entrar no plano de testes. Testar todas as combinações possíveis costuma ser inviável; ignorar as combinações que o rollout realmente usará é pedir surpresa.
Também não conte com a flag para recuperar qualquer mudança. Migração destrutiva de banco, alteração incompatível de evento e remoção de API exigem estratégia própria. O código antigo precisa continuar disponível enquanto a flag puder ser desligada. Um bom rollback operacional começa no desenho da compatibilidade.
O custo escondido é carregar decisões antigas
Cada flag cria pelo menos dois caminhos no código. Se ela fica para sempre, ninguém lembra qual configuração é possível, os testes multiplicam estados e uma regra temporária vira arquitetura. Por isso, toda flag deveria nascer com dono, propósito, data de criação e condição de remoção.
- Release: curta duração; remova depois que o rollout estabilizar.
- Operacional: pode durar mais, mas precisa de runbook e métrica associada.
- Experimento: encerre quando houver decisão, não quando alguém lembrar.
- Permissão: trate como regra de produto e autorização, não como improviso de release.
O painel da flag faz parte da observabilidade
Durante um incidente, “qual configuração estava ativa?” é uma pergunta tão importante quanto “qual versão estava no ar?”. Registre avaliações relevantes em logs ou traces, exponha a configuração efetiva e guarde auditoria das alterações. Um gráfico de erros dividido pela variante da flag evita culpar o deploy inteiro por uma falha concentrada.
Vale ainda evitar que a aplicação conheça detalhes do fornecedor. Uma camada de avaliação pequena, com nomes e contexto de negócio, facilita trocar serviço ou operar uma alternativa local. O OpenFeature oferece uma API independente de fornecedor para esse ponto de integração, sem resolver por você a governança das flags.
Um começo saudável
Escolha uma funcionalidade reversível, defina a métrica que autoriza avançar e combine antes os degraus do rollout. Dê nome positivo e claro à flag, faça o estado padrão seguro e abra a tarefa de remoção junto com a implementação. Depois do lançamento, apague o caminho morto.
Feature flag não deixa mudança sem risco. Ela transforma um salto único em uma sequência observável de passos pequenos. Isso costuma ser exatamente o que falta quando todo deploy virou uma cerimônia tensa.