Feature flags: ative e desative funcionalidade sem novo deploy

Já falei aqui sobre CI/CD e sobre deploy automático, mas tem uma pergunta que aparece logo depois de resolver isso: e se a funcionalidade que acabou de ir pro ar quebrar alguma coisa? Fazer rollback de um deploy inteiro pra desligar uma única funcionalidade é um martelo grande demais pra esse problema. Feature flag é a ferramenta certa pra esse tamanho de situação.

O que é uma feature flag

Uma feature flag é, na essência, um if controlado de fora do código. Em vez de uma funcionalidade estar sempre ligada ou sempre desligada dependendo do que foi commitado, ela fica atrás de uma condição que pode ser trocada em tempo real, sem precisar de novo deploy:

if (featureFlags.novoCheckout) {
  return <NovoCheckout />;
}
 
return <CheckoutAntigo />;

O valor de featureFlags.novoCheckout não vem fixo no código, vem de algum lugar configurável, um serviço externo, um banco de dados, um arquivo de configuração. Mudar esse valor de false pra true liga a funcionalidade pra todo mundo, na hora, sem passar por build, sem passar por pipeline de deploy.

O problema real que isso resolve

O motivo mais comum de usar feature flag é separar duas coisas que, sem ela, ficam grudadas: o momento em que o código vai pro ar, e o momento em que a funcionalidade fica visível pro usuário. Sem flag, essas duas coisas acontecem juntas, no mesmo deploy.

Isso cria uma pressão desnecessária: o código de uma funcionalidade grande, levando semanas pra ficar pronta, precisa ficar numa branch separada até estar 100% completa, senão vai pro ar incompleta. Com feature flag, o código pode ir pra main e pra produção em pedaços menores, integrado com o resto do sistema o tempo todo, só que desligado, atrás da flag, até estar pronto de verdade pra aparecer.

Rollback instantâneo

Esse é o ganho mais direto. Se uma funcionalidade nova vai pro ar e alguma coisa dá errado, desligar a flag reverte o comportamento na hora, sem precisar reverter um deploy inteiro (que pode levar junto outras correções que já foram pro ar depois). É a diferença entre apertar um interruptor e ter que desfazer uma pilha de commits.

Lançamento gradual

Feature flag não precisa ser só ligado ou desligado pra todo mundo. Uma implementação mais completa permite ligar a flag só pra uma porcentagem dos usuários:

function flagAtiva(usuarioId, porcentagem) {
  const hash = hashSimples(usuarioId);
  return hash % 100 < porcentagem;
}
 
if (flagAtiva(usuario.id, 10)) {
  return <NovoCheckout />;
}

Isso libera a funcionalidade pra 10% dos usuários primeiro. Se não aparecer nenhum erro novo nos logs, nem reclamação, você sobe pra 50%, depois 100%, com controle da exposição em cada etapa, em vez de expor todo mundo de uma vez e torcer.

Teste A/B como efeito colateral

Como a decisão de mostrar ou não uma funcionalidade já está isolada num único lugar, fica fácil usar essa mesma estrutura pra comparar duas versões de algo, mostrando cada versão pra um grupo diferente de usuário e medindo qual converte mais. A infraestrutura é a mesma da flag, só muda o que você faz com o resultado depois.

Uma implementação simples, sem ferramenta paga

Não precisa contratar um serviço especializado (tipo LaunchDarkly) pra começar. Uma tabela simples no banco já resolve o básico:

CREATE TABLE feature_flags (
  nome TEXT PRIMARY KEY,
  ativa BOOLEAN DEFAULT FALSE
);

async function flagAtiva(nome) {
  const flag = await db.query(
    "SELECT ativa FROM feature_flags WHERE nome = $1",
    [nome]
  );
  return flag?.ativa ?? false;
}

Com uma tela administrativa simples (ou até direto no banco) pra ligar e desligar cada linha, você já tem o essencial: mudar comportamento em produção sem deploy. Ferramenta especializada entra em cena quando o time cresce e precisa de coisa mais sofisticada, tipo segmentação por atributo de usuário, histórico de quem mudou o quê, ou integração com métricas automáticas.

O cuidado que ninguém fala: flag esquecida

O risco real de feature flag não é técnico, é organizacional: flag que devia durar duas semanas e fica esquecida no código por dois anos, empilhando if que ninguém mais lembra o motivo de existir. Toda flag deveria ter um destino claro desde o início, virar permanente (removendo o if e deixando só o código novo) ou ser removida, nunca ficar pendurada indefinidamente só porque "funciona assim mesmo".

Fechando

Feature flag separa o deploy do lançamento, e essa separação é o que permite rollback instantâneo, lançamento gradual e teste controlado, sem depender de reverter código a cada problema. Não precisa de ferramenta cara pra começar, uma tabela e um if já resolvem o básico. O que precisa de disciplina é não deixar a flag virar dívida técnica esquecida depois que ela já cumpriu o papel dela.