1
GMarux
3 min de leitura ·

O problema que Feature Flags resolve (e por que usamos ConfigCat)

Se você já passou por alguma dessas situações, este artigo é pra você:

  • Precisou fazer rollback de um deploy e isso bloqueou toda a equipe de subir código
  • Teve conflitos intermináveis na branch develop porque várias features estavam sendo desenvolvidas ao mesmo tempo
  • Quis testar uma funcionalidade em produção apenas com um grupo específico de usuários antes de liberar pra todos
  • Descobriu um bug crítico em produção e precisou esperar um novo deploy pra resolver

Feature Flags (ou Feature Toggles) resolvem todos esses problemas. Neste artigo, vou contar o contexto que nos levou a essa decisão e apresentar a arquitetura que adotamos. Na segunda parte, mostro a implementação passo a passo em Next.js com ConfigCat e React Context API.

O que são Feature Flags?

Feature Flags são interruptores que permitem ligar e desligar funcionalidades da sua aplicação sem precisar fazer deploy. O código da feature já está em produção, mas só é executado quando a flag está ativa.

Pense assim: é como ter um painel de controle onde você decide, em tempo real, o que cada usuário vê na aplicação.

O que você ganha com isso?

  • Deploy contínuo sem medo — suba o código com a feature desligada
  • Teste em produção com segurança — ligue apenas pro seu usuário
  • Kill switch instantâneo — desligou a flag, a feature some em segundos
  • Rollout gradual — libere pra 10%, depois 50%, depois 100%
  • Sem conflitos de branch — todo mundo sobe pra main/develop, a flag controla quem vê o quê

Por que ConfigCat?

Existem várias ferramentas de feature flags no mercado (LaunchDarkly, Unleash, Split.io). Escolhemos o ConfigCat por:

  1. Interface intuitiva — dashboard simples e direto ao ponto
  2. Suporte nativo a React — SDK com Provider e hooks prontos
  3. Targeting avançado — controle por usuário, atributos customizados, porcentagem
  4. Plano gratuito generoso — suficiente pra começar
  5. Polling automático — atualiza os valores das flags periodicamente sem você precisar fazer nada

Casos de uso reais que nos convenceram

Antes de falar de código, vale entender o que motivou a implementação. Esses são cenários que vivemos ou antecipamos ao adotar feature flags:

Deploy seguro

Você desenvolveu uma feature nova. Em vez de esperar pra fazer merge só quando estiver 100% pronta:

  1. Sobe o código com a flag OFF
  2. No dashboard, liga apenas pro seu email
  3. Testa em produção com dados reais
  4. Quando estiver pronto, liga pra todos

Zero conflito de branch. Zero rollback.

Kill switch

Feature causando problemas em produção?

  1. Abre o dashboard do ConfigCat
  2. Desliga a flag
  3. Em até uma hora (ou o intervalo de polling configurado), a feature desaparece

Sem deploy. Sem rollback. Sem estresse.

Apresentação para stakeholders

Quer mostrar uma feature nova só pros diretores antes de liberar?

  1. Cria uma regra de targeting com os emails dos diretores
  2. Liga a flag
  3. Eles veem a feature, o resto dos usuários não

Rollout gradual

Feature nova que pode impactar performance?

  • Dia 1: 10% dos usuários
  • Dia 3: 50% dos usuários
  • Dia 5: 100% dos usuários

Se em qualquer momento algo der errado, volta pra 0%.

Campanha ou conteúdo dinâmico

Um banner que muda conforme a campanha ativa. Em vez de fazer deploy a cada troca:

  1. Cria uma flag string activePromotion no ConfigCat
  2. Configura o valor como 'black-friday' quando a campanha começa
  3. Muda para '' (vazio) quando terminar

O componente reage automaticamente quando o polling detecta a mudança — sem deploy, sem acionar o time de infra.

Arquitetura da solução

A decisão mais importante da implementação: não acoplar a aplicação ao ConfigCat.

Se amanhã precisarmos trocar de ferramenta, só alteramos o Provider. Nenhum componente da aplicação sabe que o ConfigCat existe.

ConfigCat (serviço externo)
    ↓ polling a cada N segundos
ConfigCatReactProvider (engine — busca, cache, polling)
    ↓
ConfigCatSync (sincroniza user + busca flags boolean e string + escuta mudanças)
    ↓ armazena no useState
FeatureFlagsContext.Provider (Context próprio do projeto)
    ↓ expõe via useContext
Componentes (consomem com getFlag ou getStringFlag, não sabem que ConfigCat existe)

Dois tipos de flag, contratos distintos:

  • Boolean — getFlag(key) → { isEnabled, isLoading } — liga/desliga features, protege rotas, kill switch
  • String — getStringFlag(key) → { value, isLoading } — A/B testing, banners sazonais, temas, conteúdo dinâmico

Na segunda parte, mostro a implementação completa: constantes tipadas, detecção de ambiente, o Provider com sincronização de usuário, consumo nos componentes e como mockar tudo nos testes com Jest.

Escrito por Guilherme Marucchi — LinkedIn

Carregando publicação patrocinada...