O que é um feature flag: guia prático para equipes

O que é um feature flag: guia prático para equipes de ops e analytics

Um feature flag é uma chave de ativação/desativação que você coloca no código para controlar qual funcionalidade os usuários veem, sem precisar reimplantar a aplicação. Sua equipe de engenharia envia o código para produção, e a flag decide se aquela feature fica visível ou não. Quando você ouve "estamos lançando atrás de uma flag" em uma reunião de sprint, agora você sabe exatamente o que significa: uma forma segura de lançar código novo sem risco.

Uma feature flag é um IF statement que sua equipe de engenharia usa em escala

No fundo, uma feature flag é um IF statement. Em Excel, você escreve =IF(A2="ON","Mostrar feature","Esconder feature"). No código de produção, é a mesma lógica: se a flag está verdadeira, execute este caminho de código; se não, pule e execute a alternativa.

A diferença é a escala e o contexto. Uma flag em uma aplicação de produção é avaliada milhões de vezes por segundo, em todas as sessões de usuário ativas, com lógica que pode direcionar usuários específicos, regiões geográficas, tipos de dispositivo ou até percentuais de usuários. Mas o conceito fundamental é idêntico ao que você já usa em uma planilha.

Os quatro tipos de feature flags que você vai encontrar

Release flags controlam se uma nova feature é visível aos usuários. São o tipo mais comum: você ativa a flag quando a feature está pronta para produção e todos podem vê-la.

Experiment flags alimentam os testes A/B. São flags temporárias que mostram versão A para uma parte dos usuários e versão B para outra, para você medir qual funciona melhor.

Ops flags são os kill switches de emergência. Quando algo dá errado em produção (um débito de crédito não está funcionando, ou uma integração com a API de pagamento caiu), ops desativa a flag em segundos, sem tocar em nada no código. Essa é a mais crítica.

Permission flags controlam quem tem acesso a quê. Você ativa uma feature para usuários premium, ou apenas para uma região específica, ou apenas para usuários que fizeram cadastro há menos de 30 dias.

Por que times de ops, analytics e produto dependem de flags

Quando uma métrica cai 40% de repente, a primeira pergunta é: qual flag foi ligada? Se você não entender feature flags, você fica perdido em conversas de debugging. As equipes que sabem ler o estado das flags conseguem diagnosticar problemas em minutos em vez de horas.

Ops precisa entender flags porque são a forma mais rápida de reverter problemas. Em vez de fazer um rollback (que pode levar 10 minutos e requer deploy), você apenas desativa a flag (segundos, sem deploy).

Analytics precisa saber o estado de todas as flags ativas para separar o ruído do sinal nas métricas. Se você vê um pico de erro na checkout, mas não sabe que a flag de "novo fluxo de pagamento" foi ativada 10 minutos antes, você vai ficar investigando a infraestrutura errado.

Produto usa flags para controlar o lançamento: ativa para 5% dos usuários, depois 25%, depois 100%. Se algo der errado nos 5%, reverte em segundos.

Como o estado de uma flag aparece nos seus relatórios

Toda flag deixa rastros na sua telemetria. Quando você envia um evento para seu analytics, deve incluir o ID ou o estado de cada flag relevante naquele momento. Assim você consegue depois fazer análises condicionais: "qual foi a taxa de conversão quando a flag X estava ON vs. quando estava OFF?"

Alguns times adicionam flags como dimensões automáticas: cada evento carrega um array de IDs de flags ativas. Outro carregam como props customizadas. A forma importa menos; o que importa é você conseguir depois fatiar seus números por flag.

Como construir um rastreador de flags em Excel ou Google Sheets

Se sua empresa ainda não tem uma plataforma de feature flags dedicada (como LaunchDarkly ou Unleash), um rastreador simples em Sheets é bem útil para ops documentar o estado das flags principais.

A estrutura é simples: uma coluna para o nome da flag, uma para o responsável, uma para a data de ativação, uma para o motivo (release, experiment, hotfix), uma para o status (ON/OFF), e uma coluna de observações.

Você pode criar uma fórmula IF que lê a coluna de status e exibe um símbolo: uma bola verde 🟢 para ON e uma vermelha 🔴 para OFF. É visual e os times conseguem ler rapidinho qual flag está onde.

A vantagem é ter um único lugar de verdade que todos conseguem consultar: não precisa de acesso à plataforma de flags, não precisa de login, é só abrir a planilha.

O padrão IF no centro da lógica de flags

O IF é o padrão mais básico. A forma geral é:

if (flagIsOn) {
  // execute novo código
} else {
  // execute código antigo / fallback
}

Em linguagens compiladas e interpretadas, a sintaxe muda, mas a lógica é a mesma. O que muda é como a flag decision é feita: geralmente através de um serviço externo (tipo LaunchDarkly) que você chama a cada request, ou através de um arquivo de configuração local que você puxa em intervalos regulares.

Quando o Sheets é o suficiente e quando não é

Um rastreador em planilha funciona bem para:

• Documentar flags do ponto de vista de negócio (qual feature, por quê, quem ativou)

• Times pequenos (até umas 10-15 flags ativas)

• Histórico de auditoría simples

Não funciona quando você precisa de:

• Controle de acesso granular (ativar para 5% de usuários, depois 10%, depois 100%)

• Decisões rápidas baseadas em atributos de usuário (país, plano de assinatura, ID de usuário)

• Rollback instantâneo sem deploy

• Integração com seu sistema de telemetria em tempo real

Nesse ponto, você vai precisar de uma plataforma real. A planilha fica para documentação e para ops comunicar com produto/eng sobre decisões de flags.

Três ferramentas que times de ops e analytics usam junto com flags

LaunchDarkly é a plataforma mais popular. Você define flags como booleanos, strings ou números, e pode criar regras complexas de quem vê o quê baseado em atributos de usuário. Integra nativamente com Amplitude, Mixpanel, DataDog. A desvantagem é o preço: começa em alguns milhares de dólares por ano.

Unleash é open-source e auto-hospedável. Se você tem a infraestrutura, é praticamente de graça. Interface web simples, suporta segmentação de usuários, histórico de auditoría. Menos sofisticado que LaunchDarkly, mas cobre 95% dos casos.

ConfigCat é outra alternativa SaaS mais barata que LaunchDarkly e com menos overhead operacional que Unleash. Bom meio termo. Muitos times menores começam aqui.

Erros comuns de flags que criam dor de cabeça em reporting

O erro número um é ativar uma flag e não documentar em nenhum lugar. Seis meses depois, você não sabe se uma feature está ativa para todos ou só para alguns. Regra de ouro: sempre que você ativa uma flag de release, anota a data e a dissemina pro time de analytics antes do lançamento.

Segundo erro: não incluir o ID da flag nos eventos de telemetria. Aí depois é impossível fazer análise causal. Você vê uma métrica cair e não consegue saber se foi porque a flag X foi ativada ou porque houve um bug natural no código antigo.

Terceiro erro: deixar flags mortas no código por meses ou anos. Uma flag que nasceu como A/B test em março e terminou em maio mas ninguém removeu do código fica lá acumulando técnica debt. O código fica mais complicado, e quando você precisa refatorar, essa lógica morta atrapalha.

Caso de uso: como ops diagnostica incidente com feature flags

Você é ops. 14:35: alguém reporta que checkout está falhando para alguns usuários. 14:36: você abre o painel de flags. Vê que a flag new_payment_flow foi ativada em 14:30 para 25% dos usuários. 14:37: você desativa. Problema resolvido.

Depois, produto e engineering fazem uma reunião para debugar por que o novo fluxo falhou. Mas ops já salvou a receita da empresa ao ter acesso rápido e fácil ao estado das flags.

Sem feature flags, esse mesmo incidente teria levado 30-45 minutos: você teria que rodar um rollback da deploy inteira, o que é mais arriscado e mais lento.

A matemática de feature flags em escala

Um aplicativo de produção típico tem entre 30 e 60 flags ativas simultaneamente. A maioria dorme (não afeta ninguém); algumas são globais (afetam 100% dos usuários); outras são experimentos temporários.

Quando você implementa bem, o tempo de resposta a um incidente cai de 45 minutos para menos de 2 minutos. É a diferença entre ops poder dormir à noite e ops estar com taquicardia.

FAQ: Dúvidas sobre feature flags

P: Feature flag é a mesma coisa que feature branch?

A: Não. Feature branch é uma cópia separada do código que você faz no seu versionamento (Git, SVN). Feature flag é um boolean no código já mergeado que ativa/desativa comportamento em produção. Você pode usar os dois juntos: feature branch durante desenvolvimento, feature flag no lançamento.

P: Preciso de uma plataforma como LaunchDarkly ou o IF simples no código é suficiente?

A: Depende de escala. 5-10 flags simples? IF no código funciona. 50+ flags, segmentação complexa, experimentos simultâneos? Você vai querer uma plataforma. A planilha fica para documentar.

P: Como eu incluo o estado da flag nos eventos do analytics?

A: Toda vez que você envia um evento, adicione um campo tipo active_flags: [flag1_id, flag2_id] ou flag_payment_v2: true. No seu Data Warehouse, você consegue depois fazer GROUP BY nessa dimensão e comparar métricas com vs. sem a flag.

P: Feature flags viram débito técnico?

A: Sim. Uma flag temporária (A/B test, hotfix) deve morrer 2-4 semanas depois que o experimento termina. Se fica 6 meses, custa. A melhor prática é adicionar uma data de expiração no código comentado: // Remove depois de 2026-10-15, e colocar um alarme no seu backlog.

P: Qual é a diferença entre uma ops flag e uma permission flag?

A: Ops flag é um kill switch de emergência, ativada/desativada raramente, com impacto imediato. Permission flag é mais permanente: controla sistematicamente quem tem acesso, baseado em plano de assinatura, país, ID de usuário. Uma é sobre "apagar incêndio rápido", a outra sobre "governança de feature".

P: Posso combinar múltiplas flags em uma decisão?

A: Sim. Você pode fazer lógica tipo if (flagA && flagB) { ... } ou if (flagA || flagB) { ... }. O problema é que conforme você combina mais flags, fica mais difícil debugar depois. Melhor é ter uma flag mãe que contém a lógica combinada.

P: Como sincronizo flags entre múltiplos serviços/aplicações?

A: Usar uma plataforma central (LaunchDarkly, Unleash, ConfigCat) que todos os serviços consultam. Cada serviço faz um GET request quando inicia (ou em intervalos regulares) para puxar o estado de todas as flags. Se a plataforma cai, você pode ter um fallback: arquivo de config local que você atualiza com deploy, ou cache local que respeita última versão conhecida.

Saber navegar o mundo de feature flags é uma skill que cruza engenharia, ops e analytics. Quanto mais cedo você entende a lógica (que no fundo é só um IF statement em escala), mais útil você é nas conversas de produção do seu time. E como bonus: você consegue debugar incidentes muito mais rápido.