O que é feature flag? Guia prático e direto para devs solo

O que é feature flag? Um if cuja resposta fica fora do seu código. Você envia o novo caminho de código desligado e, depois, liga a funcionalidade mudando um valor num arquivo de configuração, numa linha do banco de dados ou num serviço de flags, sem novo deploy. Esse truque separa subir código de liberar uma funcionalidade, e é por isso que uma flag é o rollback mais barato que você vai ter.

Aprendi a segunda metade dessa frase da pior forma. Minha primeira flag era um booleano numa variável de ambiente, ligado numa sexta à noite, e eu esqueci que ela existia por onze meses. Nada quebrou. Esse é exatamente o problema, e chegamos a ele daqui a pouco.

Como uma feature flag se parece no código?

Bem menor do que as páginas dos fornecedores sugerem. Tirando os painéis, uma flag é uma consulta seguida de um desvio:

const flags = { newCheckout: false };

if (flags.newCheckout) {
  return renderNewCheckout(user);
}
return renderOldCheckout(user);

Todo o resto é uma pergunta sobre de onde vem flags e quem pode mudá-lo. Uma constante no arquivo é uma flag que você muda fazendo deploy, o que anula o objetivo. Uma variável de ambiente muda ao reiniciar. Uma linha no banco muda em segundos. Um serviço hospedado também muda em segundos e ainda oferece segmentação por usuário, interface e log de auditoria.

O que pega na prática: o código é trivial, o ciclo de vida não é. Dois caminhos em produção significam dois comportamentos para testar, dois caminhos para depurar às 2 da manhã, e um deles destinado a apodrecer.

Quais são os quatro tipos de feature flag, e qual você precisa primeiro?

A taxonomia de Martin Fowler continua sendo a forma mais limpa de separá-las, e o eixo útil é quanto tempo cada tipo deve viver.

Flags de release escondem trabalho inacabado ou arriscado. São transitórias: uma ou duas semanas, depois você apaga. É a primeira que você precisa.

Flags de operação são chaves de desligamento de emergência. Você envolve uma funcionalidade pesada ou frágil (um widget de recomendação, uma chamada a um serviço externo) para conseguir desligá-la sob carga, sem deploy. A maioria dura pouco, algumas ficam para sempre, e tudo bem.

Flags de experimento dividem os usuários em grupos para testes A/B. Duram o tempo necessário para chegar a um resultado estatisticamente relevante, de horas a semanas, e só fazem sentido com tráfego real.

Flags de permissão liberam funcionalidades por plano ou conta: o plano Pro, o grupo beta. Podem durar anos, e nesse ponto já não são bem flags. São direitos de acesso, e merecem um modelo de dados próprio.

Se você é dev solo com 40 usuários, precisa de flags de release e talvez de uma chave de operação. Flags de experimento com 40 usuários geram ruído, não dados. Deixe para depois, até conseguir nomear a métrica e o tamanho da amostra.

Que problema as flags resolvem que branches e deploys não resolvem?

Três coisas, e só três merecem atenção.

Subir trabalho inacabado com segurança. Branches de longa duração atrapalham porque fazer merge delas vira uma pequena guerra. Uma flag permite fazer merge na main todo dia com o código novo desligado. É a base do trunk-based development, em que todo mundo commita numa branch só e as flags carregam as partes inacabadas.

Liberação gradual. Ligue para você, depois para 1% dos usuários, depois 10%, depois para todos. Fowler descreve escolher um grupo canário de cerca de 1% pegando o ID do usuário em módulo 100. Se algo der errado, o raio de impacto são algumas pessoas, e não a sua base inteira.

Desfazer rápido. Reverter um deploy significa build, pipeline e um pouco de coragem. Virar uma flag é uma edição. Num dia ruim, a diferença são minutos de dor contra uma hora.

Nada disso exige um fornecedor no primeiro dia. Tudo isso exige disciplina.

Você precisa do LaunchDarkly, ou um arquivo JSON basta?

Um arquivo JSON ou uma tabela no banco basta até que uma destas coisas aconteça: alguém que não é desenvolvedor precisa ligar flags, você precisa de rollouts percentuais ou segmentação por usuário, precisa de um histórico de quem mudou o quê, ou mais de um serviço lê as mesmas flags.

A escada aproximada que eu subiria, nesta ordem:

1. Constantes e variáveis de ambiente. Custo zero. Serve para a primeira flag de release de um projeto paralelo.

2. Uma tabela flags ou um JSON lido em tempo de execução. Dez linhas de código, troca instantânea, sem fornecedor. Isso leva um projeto solo surpreendentemente longe.

3. Um serviço de flags open source ou hospedado. Quando você quer regras de segmentação, rollouts graduais e uma interface que outra pessoa consiga usar.

4. Uma plataforma corporativa. Quando compliance, aprovações e dezenas de engenheiros entram em cena.

Ferramentas hospedadas cobrem os passos 3 e 4. O LaunchDarkly é o nome estabelecido, com os recursos mais profundos de segmentação e governança, e um preço que reflete isso.

O Statsig junta flags com experimentação e análise de produto, o que faz sentido se a intenção é medir o que a flag fez, e não apenas alternar.

Dispense os dois se sua equipe é só você. Uma tabela de três colunas vence um painel que você abre duas vezes por trimestre. Escolha um serviço só quando a versão manual tiver custado algo específico, como uma edição de configuração de produção às 2 da manhã da qual você se arrependeu.

Um seguro que vale conhecer: o OpenFeature é um projeto incubado na CNCF que define uma API neutra de fornecedor para avaliar flags, com SDKs para Node.js, Python, Go, Java, .NET e clientes web, entre outros. Você programa contra a interface padrão e troca o provedor por baixo. Se desconfia que vai ultrapassar sua primeira configuração, passar pelo OpenFeature transforma essa mudança numa alteração de configuração.

Como adicionar sua primeira flag sem bagunçar tudo?

Comece com uma única flag de release e algumas regras básicas. Esta é a versão que eu queria ter seguido.

Dê o nome da funcionalidade, não do mecanismo. novo-fluxo-checkout diz o que quebra se estiver errada. flag_47 não diz nada daqui a seis meses.

Padronize o desligado, e faça o desligado significar o comportamento antigo. A convenção de que "desligado é legado, ligado é novo" permite raciocinar sobre o sistema sob pressão. Quebre isso e cada flag vira um quebra-cabeça.

Avalie em um só lugar. Fowler chama a correção de inversão de toggle: em vez de espalhar if (flags.x) por vinte arquivos, decida uma vez, perto da borda do sistema, e passe o resultado adiante. Um ponto de decisão significa um lugar para mudar e um lugar para testar.

Escreva o ticket de remoção no momento em que criar a flag. Coloque-o no backlog com uma data. Fowler também sugere datas de expiração para toggles de vida curta, e até testes que falham quando uma flag passa da data. Flag sem ticket de remoção é um empréstimo sem plano de pagamento.

Registre cada avaliação que importa. Quando um usuário relata um bug, você quer saber de que lado da flag ele estava. Se não consegue responder isso, a flag é um passivo.

Testar é onde as pessoas exageram. Você não precisa testar toda combinação de flags, porque a maioria não interage com as outras. Teste a configuração que espera em produção, teste o fallback com a flag nova desligada e, opcionalmente, rode uma passagem com tudo ligado para pegar desvios.

Qual é o custo real das feature flags que ninguém menciona?

Cada flag duplica um caminho de código. Dez flags independentes são, em teoria, 1.024 combinações. Você nunca vai testar todas, mas ainda pode cair numa que ninguém previu em produção.

O custo mais doloroso são as flags mortas. O rollout termina, todo mundo já está no comportamento novo, a flag fica em 100%, e o ramo antigo continua no repositório como código que ninguém tem coragem de apagar. Seis meses depois, ninguém lembra se desligá-la é seguro.

A versão famosa disso é a Knight Capital, em agosto de 2012. Uma flag antiga, que já tinha ativado uma função de negociação aposentada, foi reaproveitada para código novo. Um de oito servidores perdeu o deploy e continuou rodando o código antigo. Em cerca de 45 minutos a empresa perdeu aproximadamente $440 milhões, segundo o próprio relatório trimestral, e relatos posteriores colocam a perda mais perto de $460 milhões. É uma empresa de negociação com dinheiro real e engenheiros de verdade, então não vou afirmar que o seu projeto paralelo está mais seguro. A lição escala para baixo sem problema: nunca reaproveite o nome de uma flag, e apague flags mortas antes que virem arqueologia.

A visão de Fowler é a que eu mantenho: trate flags como inventário com custo de manutenção. Alguns times limitam o número de flags vivas e exigem remover uma antes de adicionar outra. Para um dev solo, um teto de cinco já basta.

Quando é melhor não usar feature flags?

Com mais frequência do que os fornecedores admitem.

Dispense quando a funcionalidade é pequena, a mudança é fácil de reverter no git e seu deploy leva dois minutos. Uma flag adiciona um desvio, uma fonte de configuração e algo para esquecer. Se reverter é mais rápido do que virar uma flag, a flag é teatro.

Dispense quando você ainda não tem usuários. Liberar gradualmente para zero pessoas é só um atraso. Suba, olhe os logs, corrija.

Dispense em migrações de banco que nenhum toggle consegue desfazer. Uma flag pode esconder uma coluna nova na interface, mas não consegue trazer de volta uma tabela apagada. Mudanças de schema precisam de um plano próprio de expandir e contrair, com flag ou sem.

Vale a pena quando a mudança toca pagamento ou autenticação, quando você quer fazer merge diário de trabalho inacabado, ou quando uma dependência externa pode falhar e você quer uma chave de desligamento.

O que monitorar depois que a flag estiver ligada?

Uma flag controla a exposição, e a exposição só ajuda se você conseguir ver o que acontece depois. Ligar uma funcionalidade para 10% dos usuários sem olhar a taxa de erro e a latência é cara ou coroa com passos extras.

Antes do primeiro rollout, garanta que consegue responder três perguntas em menos de um minuto: os erros subiram no grupo com a flag, a latência piorou, e algo a jusante mudou? Monitoramento de uptime e busca em logs cobrem a maior parte disso para um produto pequeno. Uma ferramenta como o Better Stack reúne monitores, páginas de status e logs num só lugar, com plano gratuito.

A regra que eu sigo hoje: uma flag só vale o alarme que está ligado a ela. Sem alarme, você está ligando coisas no escuro.

O que faríamos de fato nesta semana?

Escolha uma coisa inacabada que você tem medo de fazer merge. Coloque-a atrás de um booleano lido de uma tabela ou de um JSON, com padrão desligado, e faça merge na main hoje. Escreva o ticket de remoção antes de fechar o editor, com uma data daqui a duas semanas.

Depois ligue só para você e use por um dia. Se aguentar, amplie. Se não, desligue, e você não perdeu nada além de um minuto.

Qual flag do seu código está em 100% há mais de um mês? Essa é a sua primeira exclusão.