Entendendo na Prática: o que e Feature Flag

O que e uma feature flag?

E uma chave que controla se uma funcionalidade esta ativa, sem precisar fazer um novo deploy.

Uma feature flag, também chamada de feature toggle, e um mecanismo que permite habilitar ou desabilitar funcionalidades em produção por configuração, sem alteração de código e sem novo deploy. Na sua forma mais simples, e um booleano: se verdadeiro, o usuário ve a nova funcionalidade; se falso, ve o comportamento antigo. Na prática, as flags ficam em um sistema de configuração centralizado, e o código consulta esse sistema em tempo de execução. O resultado e um controle muito maior sobre o que cada usuário ve e quando, desacoplando o momento do deploy do momento do lançamento real da feature.

Tipos de feature flags

Release, permissioning, experiment e ops: cada tipo tem um proposito específico.

Martin Fowler categoriza as flags em quatro tipos principais. Release toggles controlam a liberação gradual de novas funcionalidades, a feature vai para produção desativada e e habilitada progressivamente. Permissioning toggles controlam o acesso por tipo de usuário, plano ou grupo, beta testers, clientes premium ou funcionários internos veem features que outros não veem. Experiment toggles sustentam testes A/B, onde diferentes usuários recebem variantes de uma funcionalidade. Ops toggles controlam comportamentos operacionais em tempo real, como desligar uma feature que esta causando carga excessiva no banco, sem precisar de rollback do deploy.

Trunk-based development com flags

Flags eliminam a necessidade de branches de longa duração.

No trunk-based development, todos os desenvolvedores integram código na branch principal (main ou trunk) várias vezes por dia. Features incompletas são cobertas por uma flag desativada, o código esta em produção mas inacessível aos usuários. Isso elimina as longas feature branches que ficam semanas sem ser integradas e criam conflitos enormes no merge. Com flags, o código e integrado continuamente, testado continuamente e a funcionalidade só e revelada quando esta pronta. Essa prática e um dos pilares da entrega continua de alta performance, como documentado no State of DevOps.

Rollout gradual e canary releases

Liberar para 1%, depois 10%, depois 100% reduz o risco de lançamentos.

Com flags, e possível ativar uma nova funcionalidade para uma porcentagem dos usuários antes de liberar para todos. Isso e chamado de rollout gradual ou canary release. O time monitora métricas, erros e feedback durante cada fase. Se algo der errado com 1% dos usuários, o problema afeta uma parcela mínima antes de ser detectado e corrigido. Sem flags, um deploy vai para 100% dos usuários de uma só vez, e um rollback e sempre mais lento e arriscado do que simplesmente desativar uma flag. Plataformas como LaunchDarkly e DevCycle oferecem controles granulares de porcentagem, segmentação por pais, plano ou atributos do usuário.

A/B testing com flags

Experimentos controlados para tomar decisões baseadas em dados, não em opiniões.

Experiment toggles permitem que diferentes usuários recebam variantes diferentes de uma funcionalidade simultaneamente. O sistema registra o comportamento de cada grupo e as métricas são comparadas para decidir qual variante performa melhor. Isso substitui debates subjetivos sobre qual design e melhor por evidências de como usuários reais se comportam. A/B testing com flags exige instrumentação: eventos de analytics precisam ser disparados em cada variante para que a comparação seja significativa. Ferramentas como Optimizely, LaunchDarkly e GrowthBook integram o gerenciamento de flags com análise estatística dos resultados.

Feature flags versus feature branches

Flags mantem o código unificado; branches criam divergências que custam caro para reconciliar.

Feature branches isolam o desenvolvimento de uma funcionalidade em um galho separado do repositório. O problema e o custo do merge quando a branch fica ativa por semanas: o código principal evolui, a branch diverge e a integração final se torna um trabalho considerável. Feature flags resolvem isso mantendo todo o código na branch principal desde o inicio, com a funcionalidade inacessível até estar pronta. A flag e o mecanismo de ocultação, não a branch. O código e integrado continuamente, os conflitos são menores e o histórico do repositório fica muito mais limpo e linear.

Limpeza de flags antigas

Flags abandonadas são divida técnica, acumulam como código morto e tornam o sistema fragil.

Cada flag ativa e um caminho de execução adicional no código. Com o tempo, flags que deveriam ter sido removidas após o rollout completo permanecem no código, criando branches condicionais que ninguem mais sabe se podem ser removidos. Esse e um dos tipos mais insidiosos de divida técnica. A solução e um processo de limpeza: ao ativar uma flag para 100% dos usuários, criar imediatamente uma tarefa de remoção do código de fallback e da própria flag. Equipes maduras estabelecem datas de expiração para cada flag no momento da criação e tratam flags expiradas como bugs a serem corrigidos.

Ferramentas especializadas

LaunchDarkly, DevCycle e Unleash oferecem controle granular para feature flags em produção.

Embora seja possível implementar flags com uma tabela simples no banco ou com variáveis de ambiente, ferramentas especializadas oferecem muito mais: interface visual para ativar flags sem deploy, segmentação por atributos do usuário, rollout percentual configurável, auditoria de mudancas, integração com analytics e kill switches instantaneos. LaunchDarkly e a ferramenta mais estabelecida no mercado enterprise. DevCycle e uma alternativa open-source compatível com OpenFeature. Unleash e self-hosted e popular em empresas que não podem enviar dados de flags para terceiros. O OpenFeature e um padrão aberto que permite trocar de ferramenta sem mudar o código da aplicação.

Exemplo em e-commerce

Como flags controlam lançamentos de alta visibilidade sem risco.

Em um e-commerce com cinco milhões de usuários, lancar uma nova página de checkout e sempre de alto risco. Com feature flags, o time pode ativar a nova página primeiro para funcionários internos, depois para 0,1% dos usuários, monitorar a taxa de conversão e de erros, depois para 5%, depois para 25% e finalmente para 100%. Se em qualquer fase a conversão cair ou os erros subirem, a flag e desativada em segundos e 100% dos usuários voltam ao checkout antigo. Sem flags, esse mesmo rollout exigiria deploys múltiplos, coordenação entre times e um processo de rollback muito mais lento e sujeito a erros.

Resumo

Feature flags separam deploy de lançamento e dao ao time controle real sobre o que usuários veem.

Feature flags transformam a forma como times de produto e engenhária colaboram. O código vai para produção continuamente, mas as funcionalidades são reveladas de forma controlada. Rollouts graduais reduzem o risco. A/B testing substitui opiniões por dados. Trunk-based development elimina o custo das longas feature branches. O cuidado principal e a limpeza: flags abandonadas são divida técnica que precisa ser paga. Com um processo claro de criação, monitoramento e remoção de flags, o time ganha velocidade de entrega e confianca para lancar com frequência sem medo de quebrar o sistema para todos os usuários de uma vez.