Feature Flag

Lançar uma funcionalidade nova para todos os usuários ao mesmo tempo é um ato de fé. O código foi testado, mas nunca foi testado em produção real, com o comportamento imprevisível de usuários reais, na escala real do sistema. Se algo der errado, o caminho de volta é um rollback de deploy — processo que pode levar minutos ou horas, durante os quais todos os usuários estão expostos ao problema.

Feature flag — também chamada de feature toggle — é a técnica que separa o deploy do código do lançamento da funcionalidade. O código é deployado em produção com a feature desativada. Quando chega a hora de lançar, a flag é ativada — sem novo deploy. Se algo der errado, a flag é desativada imediatamente — sem rollback, sem deploy de emergência, sem cerimônia.

O que parece uma técnica de engenharia simples tem implicações que afetam como equipes de produto desenvolvem, testam e lançam software.

Rollout progressivo (canary release): em vez de ativar a feature para 100% dos usuários de uma vez, ativar para 1%, observar métricas de erro e performance, depois 5%, depois 20%, até 100%. Se em qualquer etapa algo der errado, a flag volta para o percentual anterior instantaneamente. O risco de um lançamento é distribuído ao longo do tempo em vez de concentrado num único momento.

Testes A/B e experimentação: dois grupos de usuários recebem versões diferentes da mesma feature — variante A versus variante B. As métricas de comportamento (conversão, engajamento, retenção) determinam qual versão é melhor. Feature flags são a infraestrutura que permite rodar múltiplas variantes simultaneamente sem deploys separados.

Lançamento segmentado: ativar a feature apenas para determinados segmentos — usuários beta, clientes enterprise, usuários de determinada região, colaboradores internos. Permite validar com audiência menor antes de lançar para todos.

Kill switch: mecanismo para desativar funcionalidade problemática em produção em segundos, sem rollback de deploy. Para funcionalidades que dependem de serviços externos ou que têm comportamento imprevisível sob carga, ter um kill switch é segurança operacional.

Trunk-based development: times que trabalham com integração contínua frequente (todos no mesmo branch principal) usam feature flags para fazer merge de código incompleto sem que ele seja visível para usuários. O código existe em produção, mas a feature só aparece quando a flag é ativada.

Release flags: controlam se uma funcionalidade está ativa ou não para usuários. Tipicamente de vida curta — ativadas no lançamento e removidas do código quando a feature é estável. O tipo mais comum.

Experiment flags: suportam testes A/B e multivariate. Randomizam usuários entre variantes, registram exposição e permitem análise estatística de qual variante performa melhor.

Ops flags: controles operacionais para desativar features com problema de performance ou dependência externa instável. "Se o serviço de recomendação estiver fora do ar, mostrar lista estática em vez de retornar erro." Costumam ser de vida longa.

Permission flags: controlam acesso a features por tipo de conta, plano, papel do usuário. "Exportação para PDF disponível apenas para plano Pro." Parte da lógica de entitlement do produto.

Feature flags têm custo técnico que precisa ser gerenciado. Cada flag adiciona uma condição no código — if (isFeatureXEnabled()) { ... }. Flags que nunca são removidas depois que a feature está estável acumulam complexidade no codebase.

O cenário clássico de dívida de feature flag: o sistema tem centenas de flags, algumas ativas, algumas inativas, muitas sem dono claro. Ninguém sabe o que acontece se cada flag for ativada ou desativada. O código tem ramificações para cenários que nunca mais vão existir. Cada novo desenvolvedor precisa entender não só o código, mas o estado atual de cada flag para entender como o sistema se comporta.

A gestão de feature flags exige processo: flags com owner definido, data de expiração prevista para release flags, processo de remoção quando a feature está estável. Plataformas de feature flags (LaunchDarkly, GrowthBook, Flagsmith, Unleash) ajudam com governança — inventário de flags, quem pode ativar, auditoria de mudanças.

A implicação mais significativa de feature flags para organizações não é técnica — é cultural. Feature flags tornam possível tratar o produto como experimento contínuo em vez de série de lançamentos.

Empresas como Amazon, Netflix e Airbnb rodam centenas de experimentos simultâneos — variantes de UI, algoritmos de recomendação, fluxos de checkout — com feature flags e análise de dados como infraestrutura. Decisões de produto são tomadas por dados de comportamento real de usuários, não por opinião ou intuição.

Para PMEs que desenvolvem produto digital, a adoção de feature flags e cultura de experimentação não exige a escala da Amazon. Exige infraestrutura mínima (plataforma de flags) e processo de definir hipótese, medir resultado e tomar decisão com base no dado.

Feature flags são uma das práticas de engenharia com maior impacto em segurança de lançamento — o tipo de impacto que gestores sentem quando um deploy de sexta-feira quebra produção às 18h, antes de todo mundo ir embora. Separar deploy de lançamento significa que o código pode ir para produção no horário mais conveniente tecnicamente; o lançamento para usuários acontece quando a equipe está pronta para monitorar.

Para times que ainda fazem deploys como eventos de risco — janelas de manutenção, deploys noturnos, rituais de rollback — feature flags são parte da infraestrutura que torna deploy rotineiro e seguro. Não é o único componente necessário (testes automatizados, pipeline de CI/CD e monitoramento são igualmente críticos), mas é o que torna o rollback um kill switch de segundos em vez de um processo de horas.