Uma feature flag separa a publicação do código da ativação do comportamento. Em uma automação, isso permite enviar uma nova sincronização de faturas ou regra de conciliação desativada, validar com um grupo controlado e ampliar o uso acompanhando os resultados. A flag não substitui testes nem rollback: ela adiciona caminhos em runtime, risco de configuração e um controle operacional que precisa ter responsável.
| Finalidade | Duração típica | Controle a definir |
|---|---|---|
| Ocultar recurso incompleto | Curta, até a liberação | Aprovação e data de limpeza |
| Kill switch operacional | Pode durar mais | Quem desativa, alerta e condição de retorno |
| Experimento ou coorte | Até haver evidência suficiente | Atribuição estável e métrica de sucesso |
| Permissão ou entitlement | Política de acesso duradoura | Fonte oficial de autorização, não apenas UI |
Não reutilize uma flag booleana para finalidades diferentes. Dê nome ao comportamento, registre dono e prazo de revisão e determine claramente o que significa “desligada”. Em uma automação de risco, o padrão deve manter o comportamento antigo ou parar com segurança; nunca ignorar autorização, validação ou auditoria.
Comece por organização, conta de integração ou entidade de teste antes de escolher registros individuais. Uma atribuição determinística evita que retries coloquem o mesmo cliente em caminhos alternados. Evite enviar e-mails ou outros dados pessoais no contexto da avaliação quando um identificador opaco estável basta. Confira também como o provedor trata esse contexto e sua telemetria.
Em jobs em lote, decida se a avaliação ocorre por tarefa, lote de cliente ou item. Uma mudança no meio da execução pode dividir uma operação lógica entre dois comportamentos. Registre a variante avaliada junto ao ID de correlação para investigar depois.
Se a configuração remota ficar indisponível, o job continua pelo caminho antigo, pausa ou falha fechado? A resposta depende do efeito e do risco. Uma configuração em cache pode ser útil com prazo de desatualização limitado, mas não presuma que um kill switch remoto funciona durante uma partição de rede sem testar.
Acompanhe avaliação, variante, versão do código e resultados sem registrar dados pessoais de direcionamento. Compare erros, duplicidades, divergências de conciliação, latência e chamados entre grupos. Defina limiar de rollback e um meio visível para a operação desligar o recurso. Um interruptor de emergência não deveria depender de novo deploy.
Teste a configuração de produção esperada, o fallback e a flag alterada isoladamente. Não é necessário testar toda combinação de flags históricas, mas cubra interações no mesmo fluxo. Apague flags temporárias após a liberação: controles obsoletos criam ramificações ocultas e multiplicam estados de teste. Mantenha poucos kill switches duradouros, documentados e revisados.
Feature flags tornam uma liberação reversível quando público, padrão seguro, métricas e controle operacional são projetados juntos. Aumente a exposição aos poucos, meça invariantes, defina o que ocorre se o provedor cair e atribua um responsável a cada flag. Sem plano de remoção, ela vira mistério de produção.