Feature flags em 2026: tipos, ferramentas e testes A/B

Feature flags (também chamadas de feature toggles) são chaves em tempo de execução que separam o deploy do código do lançamento de uma funcionalidade. Em 2026 elas são o mecanismo padrão para entrega progressiva, kill switches, entitlements e testes A/B, e o OpenFeature tornou a escolha de fornecedor reversível. Este guia cobre os quatro tipos de flag, deploy, testes A/B, ferramentas e higiene.

O que são feature flags e os quatro tipos de flag

Uma feature flag é uma condicional cujo valor vem da configuração, não do build. O código pergunta "new-checkout está habilitada para este usuário?" e regras que você pode mudar em tempo de execução respondem. O caminho de código vai para produção; a flag decide se alguém chega até ele.

As flags se dividem em quatro tipos, com tempos de vida, perfis de risco e donos diferentes. Confundi-los é a causa raiz da maior parte da dívida de flags.

Tipo	Propósito	Tempo de vida típico	Frequência de mudança	Dono
Flag de release	Levar código inacabado ou arriscado para produção desligado e depois liberar aos poucos	Dias a semanas	Raramente, depois é apagada	Time da funcionalidade
Flag de experimento	Distribuir usuários aleatoriamente em variantes para medir um efeito	Duração do experimento	Nunca durante o teste	Produto + dados
Flag operacional / kill switch	Desligar uma dependência, degradar com elegância, limitar carga	Permanente	Raramente, durante incidentes	Plataforma / SRE
Flag de permissão	Entitlements: planos, coortes de beta, usuários internos	Permanente	Mudanças por cliente	Produto / suporte

Uma flag de release que ainda está no código seis meses depois é um bug; um kill switch que ainda está lá seis anos depois está fazendo seu trabalho. Flags de permissão são lógica de negócio que por acaso usa o SDK de flags e precisam dos mesmos testes e trilha de auditoria de qualquer regra de autorização.

Por baixo, um plano de controle (dashboard, regras, log de auditoria) alimenta os SDKs. SDKs de servidor baixam o conjunto de regras completo e avaliam no próprio processo, então uma verificação custa microssegundos e sobrevive a uma queda do plano de controle. SDKs de cliente recebem valores já avaliados, porque enviar as regras para um navegador vazaria segmentos e critérios de segmentação.

Como feature flags mudam sua estratégia de deploy

Sem flags, deploy e release são o mesmo evento. Com flags, o deploy vira um não-evento: o binário chega à produção com o caminho novo desligado, e o lançamento acontece depois, num dashboard, uma coorte de cada vez. Esse desacoplamento é o que torna o trunk-based development viável: código inacabado vai para a main todo dia porque está atrás de uma flag.

Flags complementam as abordagens de infraestrutura do nosso post sobre deploys blue-green, canário e rolling. A diferença é a granularidade:

• Um deploy canário direciona uma porcentagem do tráfego para um novo binário. Ele pega crashes e regressões de latência no build inteiro.
• Um rollout por flag expõe uma porcentagem dos usuários a um novo caminho de código dentro do mesmo binário. Ele isola uma funcionalidade e pode segmentar por atributo: funcionários primeiro, depois uma região, depois 10% de todo mundo.

Uma sequência prática:

1. Faça o deploy com a flag desligada. Confirme que o caminho novo emite telemetria e não faz nada para os usuários.
2. Habilite para funcionários e QA. Corrija o que eles encontrarem sem outro deploy.
3. Aumente por porcentagem com atribuição fixa (sticky), acompanhando taxa de erro, latência e a métrica de negócio da funcionalidade a cada passo.
4. Chegue a 100%, espere um ciclo de release, apague a flag e o caminho antigo.

Reverter um deploy leva minutos e afeta todas as mudanças do build; virar uma flag leva segundos e afeta uma funcionalidade. Num pipeline de CI/CD, isso significa menos releases de emergência.

Uma flag só é um rollback seguro se o caminho antigo ainda funciona. Migrações de banco de dados são a armadilha usual: aplique-as no estilo expand-and-contract, para que os dois caminhos rodem sobre o mesmo schema. Nosso guia de migrações de banco de dados em produção cobre o padrão.

Feature flags vs testes A/B: onde fica a linha

Flags e testes A/B são camadas, não concorrentes. Um teste A/B é uma flag mais três coisas que flags não fornecem: aleatorização, medição e estatística.

Aspecto	Rollout por feature flag	Teste A/B
Pergunta respondida	"É seguro lançar isto?"	"Isto é melhor do que o que tínhamos?"
Atribuição	Progressiva, por atributo ou porcentagem	Aleatória, fixa durante todo o teste
Mudanças durante a execução	Aumentar ou reverter à vontade	Não mexa na divisão
Métricas	Operacionais: erros, latência	De produto: conversão, retenção, receita
Termina quando	100% e limpeza	O tamanho de amostra combinado é atingido
Exige estatística	Não	Sim

A parte que o marketing dos fornecedores pula: a maioria dos times não tem tráfego para testes A/B na maioria das funcionalidades. Detectar uma mudança pequena numa taxa de conversão exige dezenas de milhares de usuários por variante, às vezes muito mais, e a amostra cresce rapidamente conforme o efeito diminui. Um produto B2B com alguns milhares de usuários ativos mensais não consegue rodar um teste significativo sobre um ajuste no checkout; deve decidir com feedback qualitativo e um rollout por flag.

Se você tem o tráfego, as regras são simples de enunciar e fáceis de quebrar:

• Fixe a métrica primária, o efeito mínimo detectável e o tamanho da amostra antes de começar; GrowthBook e PostHog incluem calculadoras.
• Não espie nem pare cedo. Rode até a amostra planejada ou use um método sequencial que a ferramenta suporte explicitamente.
• Adicione métricas de guarda (taxa de erro, tempo de carregamento, tickets de suporte) para pegar uma variante "vencedora" que quebra alguma coisa.
• Faça o hash da atribuição a partir de um ID de usuário estável, para que o usuário receba a mesma variante em todas as sessões e dispositivos.
• Rode um experimento por superfície de cada vez, a menos que a ferramenta gerencie exclusão mútua.

Se uma ferramenta oferece "experimentação" sem orientação de tamanho de amostra e intervalos de confiança, trate-a como uma ferramenta de rollout com um gráfico anexado.

Ferramentas de feature flags comparadas em 2026

O mercado se consolidou em torno de algumas plataformas comerciais, alguns projetos open source fortes e o OpenFeature como camada de API neutra.

Ferramenta	Modelo de hospedagem	Cobertura de SDK	Segmentação	Experimentação	Modelo de preço	Open source
LaunchDarkly	SaaS (relay proxy para avaliação on-prem)	A mais ampla: servidor, cliente, mobile, edge	Segmentos ricos, contextos, mudanças agendadas	Nativa, com motor de estatística	Por assento mais uso; foco em enterprise	Não
Unleash	Self-hosted (Docker/Helm) ou nuvem gerenciada	SDKs de servidor e cliente para as principais linguagens	Estratégias, restrições, segmentos	Variantes básicas; estatística via ferramentas externas	Núcleo OSS gratuito; recursos enterprise e nuvem pagos	Sim
Flagsmith	Self-hosted ou SaaS	Servidor, cliente, mobile, edge	Segmentos, identidades, overrides	Flags multivariadas; analytics por integrações	Plano gratuito; faixas por requisição e por assento	Sim
GrowthBook	Self-hosted ou SaaS	Servidor, cliente, mobile	Segmentação por atributo, grupos salvos	A estatística OSS mais forte: frequentista e bayesiana, testes sequenciais, nativa do data warehouse	OSS gratuito; nuvem e enterprise pagos	Sim
PostHog	SaaS ou self-hosted	Servidor, cliente, mobile	Propriedades de pessoa, coortes	Integrada ao product analytics; estatística incluída	Por uso, por requisição de flag	Sim
OpenFeature	Não é um serviço: uma especificação e SDKs	Todas as principais linguagens; providers para as ferramentas acima	Delegada ao provider	Delegada ao provider	Gratuito	Sim (CNCF)
Solução própria	Seu banco de dados ou arquivo de configuração	O que você escrever	Normalmente booleana ou porcentagem	Nenhuma	Tempo de engenharia	N/A

Como ler isso:

• LaunchDarkly é a referência em escala, governança e amplitude de SDKs, e a mais cara; o custo escala com assentos e contextos mensais.
• Unleash é a escolha pragmática self-hosted para times que querem flags dentro da própria rede. A experimentação é rasa por design.
• Flagsmith é mais leve, com overrides por identidade que servem bem a produtos B2B que habilitam funcionalidades por cliente.
• GrowthBook é a escolha quando experimentos importam mais que flags; ele lê métricas direto do seu data warehouse.
• PostHog faz sentido se você também quer product analytics e session replay de um único fornecedor e aceita cobrança por uso.
• OpenFeature não é concorrente. Programe contra a API dele e trocar de fornecedor depois vira uma troca de provider, não uma reescrita.
• Solução própria significa uma tabela features e uma página de admin. Funciona para uma dúzia de flags sem segmentação; no momento em que alguém pede "10% dos usuários na Alemanha", você está reconstruindo o Unleash com menos testes.

Higiene de flags: como feature flags viram dívida técnica

Toda flag é um branch que precisa ser entendido, testado e, eventualmente, removido. Times sem um processo de limpeza acabam com centenas, ninguém sabe quais são seguras de apagar, e o dashboard vira fonte de incidentes. Estas são as práticas que importam.

Toda flag tem um dono e uma data de expiração. Registre os dois na criação, nos metadados da ferramenta ou num manifesto no repositório. Flags de release expiram de duas a quatro semanas depois do rollout completo planejado, flags de experimento junto com o experimento, e flags permanentes são marcadas como permanentes para que um script de limpeza nunca toque nelas.

O nome codifica a intenção. release-new-checkout, exp-pricing-page-cta, ops-disable-recommendations, perm-advanced-reporting. Um revisor sabe pelo nome se a flag ainda deveria existir.

A remoção faz parte da funcionalidade. Um PR que adiciona uma flag de release não é mergeado sem um ticket para removê-la.

Automatize a cobrança. LaunchDarkly, Unleash e GrowthBook reportam flags obsoletas; envie isso semanalmente ao time dono. Um script que compara as chaves de flag no código com as da ferramenta pega o caso inverso: flags apagadas no dashboard mas ainda avaliadas no código.

Mantenha a contagem visível. Flags vencidas ficam ao lado de lead time e taxa de falha de mudança. Se ela sobe, a limpeza está perdendo para o trabalho de funcionalidades.

Remova em vez de manter "por via das dúvidas". Depois que o caminho novo ficou a 100% por um ciclo de release, o caminho antigo não é um plano de rollback. O controle de versão tem ele.

Testes com feature flags

Flags multiplicam caminhos de código, e caminhos não testados chegam à produção. Três níveis mantêm isso sob controle.

Testes unitários usam um provider em memória. Nunca acesse o serviço de flags real a partir dos testes. Com o OpenFeature, o InMemoryProvider permite que um teste rode o código com new-checkout true e depois false. Os dois ramos são cobertos explicitamente.

Suítes de integração e E2E rodam contra os estados que vão existir em produção. Não todas as combinações; isso explode combinatoriamente. Muitos times rodam o E2E duas vezes no CI: com o conjunto de flags padrão e com todas as flags de release forçadas para ligado, o estado após a próxima liberação.

Teste a configuração, não só o código. Uma regra de segmentação é um dado que pode estar errado. Gerencie flags como código (Unleash, Flagsmith e LaunchDarkly têm providers para Terraform) para que as mudanças passem por revisão, e verifique no pipeline que o padrão de cada flag é o seguro: comportamento antigo para flags de release, "habilitado" para um kill switch que protege uma dependência que você quer ligada. Num sistema distribuído, uma flag mal configurada em um serviço se propaga em cascata.

Segurança: flags não são autorização

Uma avaliação de flag no cliente pode ser lida e modificada pelo usuário; o payload do SDK fica visível no DevTools. Isso é aceitável quando a flag esconde uma UI beta. É uma vulnerabilidade quando a flag é a única coisa entre um usuário e uma funcionalidade paga ou os dados de outro tenant.

• Aplique no servidor. O frontend usa a flag para mostrar o botão "Exportar relatório"; a API verifica a mesma flag, ou melhor, o entitlement real, antes de devolver a exportação. Nunca confie na avaliação no cliente para autorização.
• Sem segredos ou dados pessoais nas regras de flag. Nomes de segmento e chaves de flag vão para os SDKs de cliente.
• Restrinja quem pode virar o quê. Kill switches e flags de permissão precisam de um papel específico ou de um segundo aprovador, e de um log de auditoria consultável.
• Trate mudanças de flag como mudanças em produção. Elas passam por fora do CI. Uma flag virada às 17h55 de uma sexta-feira é um deploy sem pipeline; o plantão deve vê-la ao lado dos deploys e alertas.

Entitlements que dependem de contratos e cobrança pertencem a um modelo de autorização, não a uma flag; nosso post sobre autenticação moderna e zero trust cobre onde essas verificações vivem.

Um exemplo curto com OpenFeature

O OpenFeature dá uma única API independente do backend. Trocar o LaunchDarkly pelo Unleash depois significa mudar só o provider.

import { OpenFeature } from "@openfeature/server-sdk";
import { InMemoryProvider } from "@openfeature/server-sdk";
// Em produção: importe um provider de fornecedor, ex.: @openfeature/launchdarkly-server-provider

const provider = new InMemoryProvider({
  "new-checkout": {
    disabled: false,
    variants: { on: true, off: false },
    defaultVariant: "off",
    contextEvaluator: (ctx) => (ctx.plan === "enterprise" ? "on" : "off"),
  },
});

await OpenFeature.setProviderAndWait(provider);
const client = OpenFeature.getClient();

export async function checkout(user: { id: string; plan: string }) {
  const useNewCheckout = await client.getBooleanValue(
    "new-checkout",
    false, // padrão seguro quando o provider está indisponível
    { targetingKey: user.id, plan: user.plan }
  );

  return useNewCheckout ? newCheckoutFlow(user) : legacyCheckoutFlow(user);
}

Três detalhes importam mais que a sintaxe: o padrão (false) é o que roda se o provider cair, então precisa ser o caminho seguro; targetingKey é o ID estável que torna os rollouts fixos por usuário; e o contexto carrega só os atributos que as regras precisam.

Checklist de decisão

Escolhendo uma ferramenta

• Segmentação além de liga/desliga e porcentagem? Se não, um arquivo de configuração ou uma tabela pequena basta por enquanto.
• Testes A/B de verdade, com tráfego suficiente para significância? Coloque GrowthBook, PostHog ou LaunchDarkly na lista. Se não, não pague por experimentação.
• Os dados das flags precisam ficar na sua rede? Unleash ou Flagsmith self-hosted; LaunchDarkly com o relay proxy se o orçamento permitir.
• Funcionalidades habilitadas por cliente (B2B)? Priorize overrides por identidade e uma API que as ferramentas de suporte possam chamar.
• Programe contra o OpenFeature desde o primeiro dia; é o seguro contra lock-in mais barato que você vai comprar.
• Conte os assentos do dashboard. Preço por assento fica caro quando produto, suporte e QA precisam de acesso.

Adicionando uma flag

• Qual dos quatro tipos ela é? Nomeie de acordo.
• Quem é o dono e quando ela expira?
• Qual é o padrão seguro se o serviço de flags estiver inacessível?
• O caminho de código antigo ainda funciona depois de qualquer mudança de schema?
• Existe verificação no servidor se a flag controla acesso, e não só UI?
• Existe um ticket para removê-la?

Recomendação

Adote feature flags primeiro para controle de release, com dono e expiração desde o primeiro dia; só isso já elimina a maior parte da ansiedade de deploy e viabiliza o trunk-based development. Programe contra o OpenFeature para que o fornecedor seja substituível. Escolha Unleash ou Flagsmith se as flags precisam ficar self-hosted, LaunchDarkly se você precisa de governança enterprise e pode pagar por ela, GrowthBook ou PostHog se experimentos são o objetivo. Rode testes A/B só onde o tráfego os torna significativos, e diga isso quando não for o caso. Mantenha a autorização no servidor e apague flags com a mesma deliberação com que as adiciona. Na Arvucore, costumamos recomendar começar com uma ferramenta open source self-hosted atrás do OpenFeature e fazer upgrade só quando uma capacidade específica justificar.