Seu código novo está pronto, mas o medo de quebrar produção continua ali. Feature flag resolve isso: você envia o código desativado, liga depois, sem novo deploy. Este guia mostra o caminho direto, sem enrolação.
Feature flag em produção é uma técnica que permite ligar ou desligar uma funcionalidade em tempo de execução, sem reimplantar a aplicação. O resultado esperado aqui é um release seguro, com rollback instantâneo e exposição gradual a usuários reais.
Passo 1: Defina o escopo da flag
Antes de escrever código, responda: essa flag controla o quê? Uma tela nova, uma regra de negócio, uma integração externa? O escopo determina o tipo de flag. Flags de release são temporárias, somem após a adoção completa. Flags de operação, como desligar um recurso em caso de pico, ficam por mais tempo.
Erro comum: criar uma flag gigante que envolve dez arquivos e três serviços. Isso dificulta o monitoramento e o rollback. Prefira flags pequenas, com uma única responsabilidade.
Dica: escreva no ticket da flag o motivo da criação e a data prevista para remoção. Isso evita o acúmulo de código morto.
Passo 2: Escolha a ferramenta certa
Você tem duas rotas. A primeira é usar um serviço de terceiros, como LaunchDarkly, Split ou VWO. Eles oferecem interface visual, segmentação por usuário e monitoramento automático. A segunda é construir um sistema próprio, com um banco de dados e uma API simples.
A escolha depende do seu time. Se você precisa de segmentação complexa ou experimentação, um serviço pago economiza meses de desenvolvimento. Se a necessidade é só ligar e desligar, um sistema próprio com uma tabela no banco resolve.
Ressalva: ferramentas externas adicionam latência. Cada chamada remota para avaliar uma flag custa milissegundos. Para flags críticas no caminho de requisição, considere cache local ou SDK que sincroniza em background.
Passo 3: Codifique a flag com segurança
A implementação técnica segue um padrão simples. No início da função, você avalia a flag. Se estiver desativada, o fluxo antigo executa. Se ativada, o código novo roda.
if (featureFlag.isEnabled("nova-busca")) { return buscaNova(query); } else { return buscaAntiga(query); }
O erro clássico aqui é colocar a condicional no meio do código, depois de efeitos colaterais já terem acontecido. Avalie a flag no início, antes de qualquer chamada externa ou escrita no banco.
Outro erro comum: usar a flag para esconder código quebrado. A flag não é desculpa para subir código não testado. O código novo precisa passar nos mesmos testes que o código antigo.
Dica: defina um valor padrão para a flag no código, caso o serviço de configuração fique indisponível. Assim, se a ferramenta cair, o sistema assume um comportamento previsível.
Passo 4: Ative para um grupo pequeno primeiro
Nunca ligue a flag para 100% dos usuários de uma vez. Comece com um grupo interno, depois 5%, depois 20%, e vá subindo conforme os indicadores se mantêm estáveis.
A segmentação pode ser por ID de usuário, por IP, por navegador ou por qualquer atributo que sua ferramenta suporte. O objetivo é observar o comportamento real sem expor todos ao risco.
Erro comum: ativar a flag e não acompanhar nada. Defina métricas claras antes, como taxa de erro, latência e funil de conversão. Se algum indicador piorar, desative a flag imediatamente.
Dica: combine a flag com o monitoramento. Alerte quando a taxa de erro subir mais de 1% após a ativação. Isso permite reação em minutos, não em horas.
Passo 5: Monitore e tenha um plano de rollback
Depois de ativar a flag, o trabalho não acabou. Monitore os logs em busca de exceções novas e observe se o comportamento dos usuários mudou. Uma flag mal configurada pode causar aumento de chamadas ao banco ou lentidão em endpoints.
O rollback deve ser trivial: um clique para desativar. Se o rollback exigir novo deploy, você perdeu o benefício da flag. Teste o processo de desativação antes de precisar dele.
Ressalva: desativar a flag não desfaz efeitos colaterais já cometidos. Se o código novo gravou dados incorretos no banco, desligar a flag não corrige os registros. Para mitigar, use flags em etapas: primeiro escreva os dados, depois leia, depois exponha na interface.
Passo 6: Remova a flag quando a funcionalidade estiver estável
Uma flag que fica para sempre é dívida técnica. Ela adiciona complexidade ao código e confunde quem lê. Quando a funcionalidade estiver estável para todos os usuários, remova a flag e o código antigo.
O momento certo é quando a funcionalidade nova atingiu 100% de exposição e ficou estável por algumas semanas. Agende a remoção como uma tarefa normal do sprint.
Erro comum: manter flags de release ativas por meses, acumulando condicionais aninhadas que ninguém entende. Uma flag que não pode ser removida virou uma escolha de arquitetura, não um release.
Checklist final
Antes de considerar o trabalho completo, revise:
- A flag tem escopo definido e data de remoção?
- A ferramenta escolhida atende à necessidade de segmentação?
- O código avalia a flag no início, com valor padrão seguro?
- A ativação começa com um grupo pequeno?
- As métricas de monitoramento estão definidas?
- O rollback é um clique e foi testado?
- A remoção da flag está agendada?
FAQ
Feature flag e feature toggle são a mesma coisa?
Sim, são termos intercambiáveis. Feature flag é mais comum na comunidade, enquanto feature toggle aparece em textos técnicos mais antigos. A técnica é idêntica: controlar a ativação de código em produção sem novo deploy.
Qual a diferença entre feature flag e A/B testing?
Feature flag liga ou desliga uma funcionalidade para um grupo. A/B testing compara duas versões para medir qual performa melhor. Uma flag pode ser usada para A/B testing, mas nem todo A/B testing usa flag. Flags são mais simples.
Preciso de uma ferramenta paga para usar feature flag?
Não. Um sistema próprio com uma tabela no banco e uma API resolve o caso básico. Ferramentas pagas agregam valor quando você precisa de segmentação por usuário, experimentação ou monitoramento automático. Para equipes pequenas, o custo pode não se justificar.
Como evitar que feature flags causem dívida técnica?
Estabeleça um ciclo de vida: crie a flag com data de expiração, monitore a adoção e remova o código antigo quando a funcionalidade estiver estável. Revisões periódicas no código ajudam a identificar flags esquecidas.
O que fazer se uma flag ativada causar erro em produção?
Desative a flag imediatamente. O rollback deve ser instantâneo, sem novo deploy. Depois, investigue a causa no ambiente de desenvolvimento, corrija e reative gradualmente. Nunca deixe a flag ativa enquanto o erro persiste.