Feature Flags: o Guia Completo

Feature flag é o interruptor que separa o momento em que um código chega em produção do momento em que ele é, de fato, ligado para alguém. Este guia cobre o conceito do zero até a operação madura: os quatro tipos de flag, como fazer rollout progressivo sem drama, o comparativo neutro entre LaunchDarkly, Unleash, Flagsmith, PostHog e Statsig, e os riscos reais de dívida técnica que ninguém conta na hora de vender a ideia. Se você chegou aqui buscando especificamente a diferença entre feature flag e teste A/B, ou entre implementar a flag no cliente ou no servidor, veja os guias dedicados sobre feature flags x teste A/B e client-side x server-side.

O que é um feature flag, de forma direta

Um feature flag (também chamado de feature toggle, sinalizador de funcionalidade, ou simplesmente flag) é uma estrutura condicional no código, normalmente um booleano ou uma regra de segmentação, que decide em tempo de execução se um determinado caminho do programa é executado ou não. Na forma mais simples, é isto:

O nome “feature toggles” foi cunhado com esse sentido técnico por Pete Hodgson, num artigo de referência publicado no site de Martin Fowler que continua sendo a citação mais comum sobre o tema. A ideia central que eles descrevem é simples de enunciar e poderosa na prática: a flag desacopla duas decisões que, sem ela, ficam presas uma à outra por força do processo de deploy. Sem flag, “o código está em produção” e “a funcionalidade está disponível para o usuário” são a mesma coisa, acontecem no mesmo instante, decidido por quem aperta o botão de deploy. Com flag, são duas decisões independentes: engenharia decide quando o código sobe; produto, marketing ou o próprio sistema decidem quando (e para quem) ele liga.

Essa separação parece pequena na descrição, mas muda a temperatura de cada deploy. Sem flag, todo deploy de uma funcionalidade nova é um evento de risco binário: ou funciona para todo mundo, ou você corre para reverter o deploy inteiro (e, com ele, qualquer outra coisa que tenha subido junto). Com flag, o deploy vira um evento de baixo risco (o código está lá, mas desligado ou visível só para um punhado de contas internas) e a liberação vira um evento controlado, gradual, reversível em segundos.

Feature flag não é a mesma coisa que branch

Uma confusão comum de quem está começando: “para que serve uma flag, se eu já tenho branch no Git?” A resposta é que branch e flag resolvem problemas em momentos diferentes do ciclo de vida do código. Um branch existe antes da integração: enquanto seu código está isolado numa branch de feature, ele não afeta ninguém, mas também não está sendo testado junto com o resto do sistema, e quanto mais tempo ele fica isolado, mais doloroso fica o merge de volta (o problema clássico do “merge hell”). Uma flag existe depois da integração: o código já está no branch principal, já está rodando nos mesmos testes automatizados que tudo mais, já foi implantado, e a flag decide se ele está visível.

É essa propriedade que sustenta a prática de trunk-based development, integrar direto na branch principal várias vezes ao dia, mesmo com funcionalidades pela metade, porque a flag garante que código inacabado fica invisível até que esteja pronto. Fowler descreve isso como um dos usos centrais de feature toggles: permitir que times continuem entregando continuamente sem esperar que uma funcionalidade grande esteja 100% pronta para fazer merge.

Por que usar feature flags

A motivação central é reduzir o risco de cada mudança em produção, e ela se desdobra em quatro ganhos concretos que aparecem, com variações de nome, em praticamente toda documentação séria sobre o tema (LaunchDarkly, Unleash e Atlassian abordam variações dessas mesmas vantagens).

Deploy desacoplado de release

Como já descrito acima: você pode integrar e implantar código com a frequência que a engenharia exigir (várias vezes ao dia, no caso de times de entrega contínua madura), sem que isso signifique expor cada mudança a todo o público imediatamente. Isso rompe o vínculo perigoso entre “com que frequência eu deployo” e “quanto risco eu assumo por deploy”.

Rollback instantâneo, sem novo deploy

Se uma funcionalidade nova causa um problema em produção, desligar a flag reverte o comportamento em segundos, sem precisar abrir um novo pull request, esperar o pipeline de build e testes rodar de novo, e fazer um novo deploy sob pressão (o cenário mais propenso a erro que existe em engenharia). Esse é, segundo a documentação da própria LaunchDarkly e a literatura sobre continuous delivery, um dos maiores ganhos operacionais de flags: transformar um incidente que levaria minutos ou horas para reverter num clique.

Liberação segmentada e controlada

Em vez de “todo mundo vê ou ninguém vê”, a flag permite decidir exatamente quem vê: só a equipe interna, só uma conta beta específica, só 5% do tráfego, só usuários de um país, só quem está num plano específico. Essa granularidade é o que viabiliza validar uma funcionalidade de risco alto (uma reformulação de checkout, por exemplo) com exposição mínima antes de assumir o risco total.

Personalização e permissão de longo prazo

Nem toda flag é temporária. Algumas vivem para sempre, controlando o acesso a uma funcionalidade premium, a um recurso disponível só em determinado plano, ou a uma configuração que varia por cliente num produto multi-tenant. Essa categoria (que detalhamos abaixo como flag de permissão) não é sobre reduzir risco de deploy, é sobre modelar regra de negócio.

Os quatro tipos de feature flag

Nem toda flag serve ao mesmo propósito, e confundir os tipos é a raiz de boa parte da dívida técnica que aparece mais adiante neste guia. A categorização mais citada na literatura, incluindo o artigo de Fowler/Hodgson e a documentação da LaunchDarkly, organiza as flags por dois eixos: quanto tempo elas vivem (temporária x permanente) e quem decide o valor (uma pessoa, um sistema, ou o próprio código de negócio).

Release flags

Escondem uma funcionalidade incompleta ou não validada até que esteja pronta para todos. É o uso mais básico e mais comum: permitir que engenharia faça merge e deploy de trabalho em andamento sem afetar o usuário. Vida útil: curta, dias a poucas semanas. A flag deveria ser removida assim que a funcionalidade estiver 100% liberada e estável, o que raramente acontece na prática (mais sobre isso na seção de riscos).

Experiment flags

Dividem o tráfego entre duas ou mais variações para medir o efeito de cada uma numa métrica, com rigor estatístico (amostra calculada, significância, tempo mínimo de execução). É a categoria que sustenta o teste A/B: toda ferramenta de experimentação usa flags por baixo do capô para decidir qual variação cada usuário vê, mas nem toda flag é um experimento. A diferença conceitual entre as duas coisas, e quando uma vira a outra, está detalhada no guia sobre feature flags e teste A/B. Vida útil: curta e bem definida, o tempo do experimento (normalmente uma a poucas semanas), com decisão de “manter ou descartar” no final.

Ops flags (operacionais)

Controlam o comportamento operacional do sistema em produção: um kill switch que desliga uma integração externa problemática, um circuit breaker que corta uma chamada a um serviço terceiro instável, um controle de carga que reduz funcionalidade sob pico de tráfego. Diferente da release flag, o objetivo aqui não é esconder algo incompleto, é dar ao time operacional um botão de emergência. Vida útil: costuma ser longa, às vezes permanente, porque o risco operacional que ela mitiga (uma dependência instável, um pico sazonal) não desaparece.

Permission flags (entitlements)

Controlam o que um usuário específico, conta ou organização pode acessar, tipicamente por plano de assinatura, papel dentro da conta, ou contrato específico (um recurso liberado só para um cliente enterprise, por exemplo). Diferente das outras três categorias, aqui a flag não é sobre gerenciar risco de entrega, é sobre modelar uma regra de negócio, o que a LaunchDarkly chama de “entitlements” em sua documentação. Vida útil: permanente, enquanto a segmentação de plano existir.

Feature flags x teste A/B: onde a linha se cruza

Vale desfazer a confusão mais comum antes de seguir adiante, porque ela aparece em quase toda conversa sobre o tema: feature flag e teste A/B não são a mesma coisa, e um não é uma versão simplificada do outro.

A flag é o mecanismo: uma condicional que decide, para um dado usuário, qual caminho de código executar. O teste A/B é um método estatístico que usa esse mecanismo para responder uma pergunta específica: “a variação B converte mais do que a variação A, com confiança suficiente para eu confiar nisso?” Isso exige coisas que uma release flag comum nunca precisa ter: alocação aleatória e estável de cada usuário a um grupo, cálculo de tamanho de amostra antes de começar, e um teste de significância no final.

Na prática, isso significa que toda experimentação A/B usa flags, mas a maioria das flags de um sistema (as de release, ops e permissão, que são a maioria em qualquer produto maduro) nunca vira um experimento formal. Elas simplesmente ligam ou desligam um comportamento, sem estatística nenhuma por trás. É comum a confusão surgir porque a mesma ferramenta (LaunchDarkly, Unleash, um SaaS de A/B como a Donnu A/B) frequentemente oferece os dois recursos na mesma plataforma, o que borra a linha na cabeça de quem opera o produto no dia a dia.

Cobrimos essa fronteira com profundidade, incluindo quando uma release flag simples deveria virar um experimento de verdade e o que muda na implementação, no guia dedicado feature flags x teste A/B.

Client-side x server-side: onde a decisão da flag acontece

Outra decisão de arquitetura que aparece cedo em qualquer adoção de feature flags é onde o código avalia a flag: no navegador ou app do usuário (client-side) ou no seu backend (server-side). Não é só um detalhe de implementação, é uma escolha com implicações reais de segurança, performance e complexidade.

Client-side é mais simples de instalar (um SDK JavaScript, por exemplo) e é a escolha comum para marketing, onboarding e mudanças de interface. O custo: a lógica da flag (inclusive, em implementações ingênuas, os próprios valores de flags desligadas) viaja no bundle que chega ao navegador do usuário, o que é inaceitável para regras de negócio sensíveis ou dados que não deveriam vazar para quem não tem a flag ativa.

Server-side mantém a decisão inteiramente no seu backend: o cliente nunca vê o código nem os valores das flags que não se aplicam a ele, o que é o padrão recomendado para permissão, dados privados e qualquer lógica que não deveria ser inspecionável por quem abre o DevTools do navegador. O custo é uma chamada de rede a mais (ou uma sincronização periódica de configuração) e uma peça a mais de infraestrutura para manter no ar.

Times maduros normalmente usam os dois, cada um onde faz sentido: client-side para o que é visual e de baixo risco, server-side para o que é sensível ou decide acesso. O comparativo completo, com arquitetura de cada abordagem, latência típica e como as ferramentas do mercado resolvem o problema do “flicker” (a página piscar a versão errada antes de aplicar a flag), está no guia teste A/B client-side x server-side, que cobre a mesma dicotomia aplicada à experimentação.

Rollout progressivo e canary release

Rollout progressivo é a técnica de liberar uma funcionalidade para uma fatia crescente do público, em vez de trocar de 0% para 100% de uma vez. É onde uma release flag entrega o maior valor prático, porque transforma “vai funcionar em produção?” de uma pergunta que só se responde depois do fato consumado numa pergunta que se responde aos poucos, com dado real e exposição controlada.

Canary release é um caso específico e mais restrito de rollout progressivo: em vez de segmentar por porcentagem de usuários, você libera primeiro para um subconjunto de servidores ou instâncias (o termo vem dos canários usados em minas para detectar gás antes que afetasse os mineiros), observa a saúde da infraestrutura naquele subconjunto, e só então expande para o restante da frota. É uma técnica de deploy de infraestrutura tanto quanto de flag, e as duas se combinam bem: um canary release na infraestrutura, com uma release flag controlando quem, dentro daquele canary, de fato vê a funcionalidade nova.

O padrão de rollout progressivo mais citado segue etapas parecidas com estas, ajustadas ao volume de tráfego e ao apetite de risco do time:

Etapa	Público típico	O que se observa
Interno	Equipe e QA (dogfooding)	Bugs óbvios, antes de qualquer usuário real ver
1%	Fatia mínima de produção	Taxa de erro, latência, exceptions no log
5-10%	Amostra maior, ainda pequena	Métricas de negócio começam a ter significado
25-50%	Metade ou mais do público	Confirma que o comportamento se sustenta em escala
100%	Todo o público	Rollout completo; a flag pode começar a ser considerada para remoção

Cada avanço de etapa deveria ser condicionado a métricas de guarda (guardrail): taxa de erro, latência, e indicadores de negócio que não podem piorar. Se qualquer uma degrada, a resposta é reduzir a alocação de volta, não seguir em frente na esperança de que “estabiliza sozinho”.

Ferramentas do mercado (visão neutra)

Não existe “a melhor ferramenta de feature flag”, existe a certa para o seu contexto: tamanho do time, orçamento, se você já paga por analytics ou experimentação em algum desses provedores, e quanto controle de infraestrutura você quer manter internamente. Um retrato neutro do que cada uma oferece, segundo a documentação pública de cada fornecedor:

Ferramenta	Modelo	Foco declarado
LaunchDarkly	SaaS comercial	Plataforma de feature management madura, com segmentação avançada, experimentação integrada e forte ênfase em governança e auditoria para times grandes
Unleash	Open source (core) + SaaS opcional	Pode ser hospedado pelo próprio time (self-hosted) com o core sob licença open source; foco declarado em soberania de dados e ausência de vendor lock-in
Flagsmith	Open source + SaaS	Também oferece opção self-hosted; posiciona-se como alternativa com boas SDKs e API REST simples, plano gratuito generoso para times pequenos
PostHog	SaaS (com self-host)	Feature flags como parte de uma suíte de produto mais ampla (analytics, session replay, experimentos), útil para quem já usa PostHog para outras coisas
Statsig	SaaS comercial	Forte integração entre feature flags e experimentação estatística, com ênfase em métricas e testes A/B nativos sobre a mesma infraestrutura de flag

Critérios que costumam pesar mais na escolha, na prática, do que o nome da marca:

• Self-hosted x SaaS gerenciado: se dados sensíveis ou requisitos de residência de dados pesam, self-hosted (Unleash, Flagsmith) remove uma dependência externa; se o time prefere não operar mais um serviço, SaaS gerenciado (LaunchDarkly, Statsig) tira esse peso.
• Já usa a ferramenta para outra coisa? Times que já usam PostHog para analytics ou Statsig para experimentação ganham ao consolidar flags no mesmo lugar, em vez de somar mais uma ferramenta e mais uma integração.
• Precisa de experimentação estatística séria integrada? Se o objetivo inclui testes A/B com significância calculada, não só ligar/desligar, vale comparar o que cada ferramenta oferece nativamente nesse quesito versus o que exigiria uma ferramenta dedicada de experimentação ao lado.
• Tamanho do time e maturidade de governança: times grandes com múltiplos squads tendem a valorizar auditoria, permissões granulares e histórico de mudanças, recursos que aparecem com mais profundidade nos planos pagos de qualquer um desses fornecedores.

Este comparativo é um retrato do que cada fornecedor declara publicamente; preços, limites de plano gratuito e recursos específicos mudam com frequência, então vale confirmar na documentação oficial de cada um antes de decidir.

Riscos e boas práticas

Feature flag reduz risco de deploy, mas introduz um risco diferente se não for gerenciada: complexidade que se acumula silenciosamente até virar dívida técnica difícil de desfazer. Os riscos mais citados na literatura sobre o tema, e a prática que resolve cada um:

Flag zumbi (technical debt)

É o risco mais discutido de todos: uma flag que já cumpriu seu papel (a funcionalidade está 100% liberada e estável há meses) mas que ninguém removeu do código. Ela continua lá, com o if e o else inteiros, exigindo que qualquer pessoa lendo aquele trecho entenda os dois caminhos possíveis, mesmo que um deles nunca mais seja executado. Multiplicado por dezenas ou centenas de flags acumuladas ao longo de anos, o resultado é um código onde ninguém tem certeza de quais combinações de flags são sequer possíveis, e a superfície de teste explode.

Boas práticas para evitar:

• Toda flag tem um dono. A pessoa ou o time responsável por decidir quando ela deve ser removida, não só quem a criou.
• Toda flag temporária nasce com uma expectativa de expiração. Release e experiment flags deveriam ter uma data-alvo de remoção definida na criação, mesmo que aproximada.
• Rotina periódica de limpeza. Um relatório (manual ou automatizado, várias das ferramentas listadas acima oferecem isso nativamente) que lista flags há muito tempo em 100% ou 0%, candidatas óbvias à remoção.
• Ops e permission flags são a exceção esperada. Elas vivem por design; o alvo de limpeza são release e experiment esquecidas.

Explosão combinatória de estados

Cada flag ativa dobra, em teoria, o número de combinações possíveis de comportamento do sistema. Com poucas flags isso é irrelevante; com dezenas rodando ao mesmo tempo, torna-se impossível testar manualmente todas as combinações, e interações inesperadas entre duas flags (uma liga um fluxo novo, outra muda uma dependência daquele fluxo) se tornam uma fonte real de bugs em produção que só aparecem para uma fatia específica de usuários.

Mitigação: manter o número de flags simultaneamente ativas o menor possível (reforça o ponto anterior sobre remoção), documentar dependências conhecidas entre flags, e usar uma testing matrix (tabela de combinações relevantes, não todas as matematicamente possíveis) para os cenários que de fato importam para o negócio.

Consistência da experiência do usuário

Um usuário que alterna entre abas, dispositivos, ou recarrega a página não pode ver a funcionalidade aparecer e desaparecer de forma inconsistente. Isso exige uma unidade de segmentação estável (normalmente um hash determinístico do ID do usuário ou de um identificador anônimo persistente), a mesma preocupação que já existe em teste A/B para garantir que cada visitante sempre veja a mesma variação.

Governança e auditoria

Em times maiores, “quem mudou essa flag, quando, e por quê” precisa ter resposta. Ferramentas dedicadas de feature management resolvem isso nativamente com log de auditoria; soluções caseiras (uma tabela no banco, uma variável de ambiente) normalmente não têm isso de graça, e vale considerar adicionar antes que a ausência vire um incidente sem explicação.

Performance e ponto único de falha

A avaliação de uma flag não pode se tornar um gargalo nem um ponto de falha: se o serviço que resolve flags cai, o sistema precisa degradar para um comportamento padrão seguro (normalmente, a flag desligada), nunca travar a aplicação inteira esperando uma resposta que não vem. É o mesmo princípio de “falhar silenciosamente para o estado seguro” que qualquer snippet de terceiros embutido numa página deveria seguir.

Como feature flags se relacionam com o motor de experimentação da Donnu

Tudo o que este guia descreveu sobre release, ops e permission flags acontece antes de qualquer estatística entrar em cena: são decisões de ligar/desligar/segmentar, sem hipótese, sem amostra calculada, sem valor-p. O ponto em que uma flag comum vira experimentação de verdade é quando você para de perguntar “isso está ligado para quem eu quero” e passa a perguntar “essa variação converte mais do que a outra, com confiança suficiente para eu decidir com base nisso”.

É exatamente nesse segundo momento que entra o motor de teste A/B: a Donnu usa o mesmo mecanismo de segmentação estável de uma feature flag (cada visitante cai numa variação e permanece nela) para alimentar um teste com desenho estatístico honesto por trás, desde o cálculo do tamanho de amostra até a leitura bayesiana do resultado no final. Se você já usa feature flags para controlar releases e quer transformar uma delas num experimento com rigor, o guia de feature flags x teste A/B detalha exatamente essa transição.

Faça isso automático na Donnu

Você acabou de ver a diferença entre desligar uma funcionalidade por segurança e comparar duas variações com rigor estatístico: a primeira é gerenciamento de flag, a segunda é experimentação. A Donnu A/B foca na segunda parte: quando uma das suas flags de release ou experiment precisa virar uma decisão baseada em dado, com tamanho de amostra calculado, leitura bayesiana honesta e sem o flicker que arruína a experiência do usuário, você não precisa construir esse motor estatístico do zero.

Comece um teste grátis de 14 dias e veja como funciona levar uma funcionalidade de “está ligada” para “sabemos que funciona melhor”. Se quiser aprofundar antes, veja a diferença completa entre feature flags e teste A/B e o comparativo entre rodar a decisão no cliente ou no servidor.

Referências

• Fowler, M. & Hodgson, P. Feature Toggles (aka Feature Flags). martinfowler.com, 2017. martinfowler.com/articles/feature-toggles.html.
• LaunchDarkly. What are feature flags? e documentação de Entitlements. launchdarkly.com/blog/what-are-feature-flags.
• Unleash. What is a feature flag? e documentação de arquitetura open source. docs.getunleash.io/concepts/feature-flags.
• Flagsmith. Feature Flags Explained. flagsmith.com/feature-flags-and-remote-config.
• Atlassian. Feature flags (feature toggles): what they are & best practices. atlassian.com/continuous-delivery/principles/feature-flags.