O que é Feature Flag (Feature Toggle)?

Não há um único criador reconhecido para feature flags. A técnica se desenvolveu na prática de entrega contínua de software. Pete Hodgson sistematizou seus usos e riscos no artigo Feature Toggles (aka Feature Flags), publicado no site de Martin Fowler em partes a partir de 2016 e atualizado em 2017. O texto distingue flags de lançamento, experimento, operação e permissão.

A prática também se associa ao desenvolvimento baseado em trunk, no qual alterações pequenas são integradas cedo. Uma flag pode manter inativo um comportamento ainda não liberado enquanto o código segue integrado. Isso não dispensa projeto cuidadoso, testes nem decisão sobre quando remover a chave.

Pense em um interruptor com regras de acesso. O código novo já pode estar no ambiente, mas a aplicação escolhe que caminho executar conforme a configuração da flag e o contexto da requisição. A decisão pode ser simples, ligada ou desligada para todos, ou considerar um grupo de usuários. Alterar a regra de exposição não precisa exigir outro deploy, desde que a configuração possa mudar em tempo de execução. Essa capacidade depende da implementação escolhida; uma flag gravada em arquivo empacotado no software pode exigir novo deploy para ser alterada.

Deploy e lançamento. Deploy coloca uma versão do software em um ambiente. Lançamento expõe um comportamento a quem o usa. Uma feature flag permite que esses momentos sejam diferentes. A equipe pode integrar uma alteração pequena, verificá-la em produção ainda oculta e liberar apenas quando produto e operação estiverem preparados. O código inativo continua precisando de cuidado: pode ocupar recursos, alterar dados ou introduzir falhas mesmo quando a interface está desligada.

Tipos de decisão. Uma flag de lançamento protege uma mudança ainda não exposta. Uma de experimento distribui variações entre grupos para comparar resultados; para isso, cada pessoa precisa permanecer no grupo atribuído enquanto o teste durar. Uma flag operacional permite reduzir ou desligar um comportamento diante de falhas ou carga. Uma de permissão seleciona quem tem acesso a uma capacidade. Os tipos têm duração e responsáveis diferentes. Uma regra de permissão duradoura não deve ser tratada como pendência temporária de limpeza.

Ponto de decisão e configuração. O ponto de decisão no código deve ficar claro e a regra que escolhe o valor deve ser gerenciável. Uma equipe precisa saber quem pode mudar a flag, em qual ambiente, para qual público e com qual registro. Se qualquer pessoa a ativa sem revisão, a exposição pode fugir do planejamento. Se ninguém sabe qual valor está em vigor, depurar problemas fica mais difícil. Defina também um valor seguro quando a fonte de configuração não estiver disponível. Seguro depende do caso: desligar uma recomendação pode ser aceitável; desligar uma proteção de segurança, não.

Liberação gradual. Em vez de expor uma função a todos de uma vez, o time pode começar por pessoas internas, avançar a um pequeno grupo e ampliar depois de observar erros e efeito no produto. Porcentagens de usuários são uma opção, mas requerem distribuição estável. Sortear a cada requisição pode fazer a mesma pessoa alternar entre experiências e quebrar fluxos. A CI/CD ajuda a colocar código verificável no ambiente; a flag governa a exposição.

Testes e observação. Os caminhos com flag ligada e desligada precisam ser testados. Também é necessário verificar se a transição preserva dados e sessões em andamento. Em produção, acompanhe falhas, latência e o resultado que motivou a mudança. Uma flag não transforma automaticamente um lançamento em experimento confiável. Para teste A/B, é preciso definir hipótese, grupos e medição coerentes.

Ciclo de vida. Registre propósito, responsável, data ou condição de revisão e plano de remoção. Depois que todos usam o novo comportamento e a equipe descarta o antigo, retire a flag e o código morto. Flags temporárias esquecidas multiplicam combinações de estados, elevam o custo dos testes e escondem decisões obsoletas. Algumas flags, como controles permanentes de acesso, podem durar mais: ainda assim merecem documentação e revisão periódica.

Feature flags combinam bem com trunk-based development, pois permitem integrar código em partes sem necessariamente expor uma função incompleta. Mas não devem servir para deixar trabalho sem qualidade na linha principal. A Definition of Done continua a exigir o padrão acordado para um incremento; ocultar na interface não torna código defeituoso pronto.

Imagine um time hipotético que muda o cálculo de frete em um checkout. Antes, a alteração fica numa branch durante 12 dias. Na véspera do lançamento, aparecem conflitos de integração e a equipe precisa escolher entre adiar a mudança inteira ou expô-la a todos. Os números são ilustrativos.

O time passa a integrar pequenas partes da nova lógica na linha principal, protegidas por uma flag de lançamento. Primeiro, todos continuam no cálculo antigo. Testes cobrem ambos os caminhos e verificam pedidos em andamento. Depois, pessoas internas usam o novo cálculo. O time observa divergências de preço e corrige um caso de endereço antes de ampliar o acesso.

Em seguida, a regra atende um grupo estável equivalente a 5% dos usuários elegíveis. Se a taxa de erro subir, a equipe consegue desligar a exposição sem reverter todo o deploy, desde que o caminho antigo continue funcional e os dados sejam compatíveis. Após verificar comportamento e resultado de negócio, amplia para todos. Quando o caminho antigo já não é necessário, remove a flag, a configuração e os testes que existem apenas para essa bifurcação.

A melhoria não é uma garantia de lançamento sem falhas. Se a nova rotina escrever dados que o caminho antigo não consegue ler, desligar a flag talvez não recupere o serviço. O plano de retorno precisa considerar migração de dados, efeitos externos e transações iniciadas. A flag é uma ferramenta de controle, não substituto de uma estratégia de implantação segura.

Curso K21 recomendado