Lançar para 100% dos usuários e torcer é coisa do passado. Veja como feature flags permitem rollout gradual, rollback em segundos e experimentos no código, e como não se afogar nelas.
Índice do artigo
- O que é uma feature flag
- Os 4 tipos de flag e por que separá-los
- Rollout gradual: o passo a passo
- Kill switch: o botão de emergência
- Feature flag x teste A/B
- Medindo o impacto do lançamento
- Governança: o ciclo de vida de uma flag
- Os erros que mais aparecem
- Perguntas frequentes
O que é uma feature flag
Uma feature flag (ou feature toggle) é uma condição no código que decide, em tempo de execução, se uma funcionalidade está ligada para um usuário. A decisão fica numa plataforma (como VWO FME ou ABsmartly), e não no código: mudar quem vê o quê não exige novo deploy.
Em uma frase: feature flag separa o deploy (o código chegou em produção) do lançamento (o usuário passou a ver).
Os 4 tipos de flag e por que separá-los
- Release flag: esconde uma funcionalidade em construção ou libera aos poucos. Vida curta: some quando o lançamento termina.
- Experiment flag: divide usuários entre variantes para medir impacto. Vida curta: some quando o teste é decidido.
- Ops flag (kill switch): desliga algo pesado ou arriscado em caso de problema (uma integração, um recurso de alto custo). Vida longa, por definição.
- Permission flag: libera funcionalidades por plano, cliente ou perfil. Vida longa, mas é regra de negócio, e às vezes deveria morar em outro lugar.
Separar os tipos importa porque o prazo de remoção é diferente. Uma release flag de seis meses é dívida técnica; um kill switch de seis meses é normal.
Rollout gradual: o passo a passo
- Interno: ligue para o time (por atributo de usuário ou lista de IDs).
- Canário: 1% a 5% da base, monitorando erros, latência e métricas-chave.
- Ampliação: 25%, 50%, 100%, com critérios claros para avançar ou recuar.
- Remoção: com 100% estável, remova a flag e o código antigo.
Para que o mesmo usuário não entre e saia da funcionalidade entre sessões, a decisão precisa ser baseada num identificador estável (User ID).
Kill switch: o botão de emergência
Toda funcionalidade que depende de terceiro, consome muito recurso ou mexe em fluxo de pagamento merece um kill switch. Quando algo dá errado às 23h de sexta, desligar pela plataforma é questão de segundos; reverter um deploy pode levar muito mais.
Documente quem pode acionar, em que situação e como comunicar.
Feature flag x teste A/B
Toda experiment flag é um teste A/B, mas nem toda flag é experimento. A diferença está na intenção e na medição:
- Release flag: o objetivo é lançar com segurança; a pergunta é "quebrou algo?".
- Experiment flag: o objetivo é descobrir qual versão é melhor; a pergunta é "qual converte mais?", e exige grupo de controle, métrica principal, tamanho de amostra e checagem de qualidade (como SRM,Sample Ratio Mismatch.
Plataformas como VWO FME e ABsmartly fazem as duas coisas com o mesmo SDK. No ABsmartly, por exemplo, a exposição é registrada na chamada de treatment; no VWO FME, os eventos só são contabilizados quando ligados a experimentos ativos.
Medindo o impacto do lançamento
Mesmo sem teste formal, meça o lançamento:
- envie a informação de flag e variante para o analytics (os SDKs do VWO FME têm um callback de integração para isso; o ABsmartly permite publicar exposições via publisher customizado);
- compare métricas de quem tem a funcionalidade ligada com quem não tem durante o rollout;
- acompanhe erros e performance por grupo.
Governança: o ciclo de vida de uma flag
- Nome padronizado: tipo + funcionalidade (release_novo_checkout, exp_frete_gratis_limite).
- Dono: quem criou responde pela remoção.
- Data de expiração: definida na criação para release e experiment flags.
- Revisão periódica: listar flags antigas e decidir remover ou transformar em permanente.
- Alertas de limpeza: o ABsmartly, por exemplo, sinaliza "Code Cleanup Needed" quando um experimento já decidido continua recebendo chamadas de exposição.
- Automação: as REST APIs de flags (como as do VWO FME) permitem integrar a criação e a revisão de flags ao pipeline de desenvolvimento.
Os erros que mais aparecem
- Flags sem dono e sem data de expiração.
- Código antigo mantido depois que a flag chegou a 100%.
- Decisão de flag baseada em ID instável.
- Flags aninhadas (uma dentro da outra), criando combinações impossíveis de testar.
- Rollout sem métricas definidas para avançar ou recuar.
Perguntas frequentes
O que é feature flag?
Uma condição no código que liga ou desliga uma funcionalidade por usuário, controlada por uma plataforma, sem novo deploy.
Qual a diferença entre feature flag e teste A/B?
A flag controla quem vê a funcionalidade; o teste A/B usa essa divisão com grupo de controle e estatística para medir impacto.
O que é kill switch?
Uma flag de operação usada para desligar rapidamente uma funcionalidade em caso de problema.
O que é rollout gradual?
Liberar uma funcionalidade para porcentagens crescentes da base, monitorando métricas em cada etapa.
Feature flag gera dívida técnica?
Sim, quando flags temporárias não são removidas. Dono e data de expiração resolvem.
Quais ferramentas oferecem feature flags?
Entre outras, VWO FME e ABsmartly, que combinam flags e experimentação no mesmo SDK.