A implantação ocorre quando o código chega à produção. Liberação é quando alguém pode realmente usá-lo. Confundir os dois é uma das maneiras mais rápidas de tornar cada implantação um momento um pouco tenso.
Os feature flag servem para colocar espaço entre esses dois momentos. Você pode implantar hoje, iniciar amanhã para a equipe interna, depois para um cliente piloto e depois para 10% dos usuários. Se algo der errado, desligue a bandeira. Você não precisa necessariamente reverter a versão inteira.
A bandeira não é apenas um if
Tecnicamente, geralmente é um if. Culturalmente é muito mais.
if (await flags.isEnabled('checkout.v2.enabled', context)) { return newCheckout(input); } return oldCheckout(input);
Esse pequeno if pode representar uma implementação gradual, um experimento, uma migração, uma licença empresarial ou um kill switch operacional. O problema é que se você não administrar bem, também pode virar uma dívida técnica que fica no código por dois anos.
Onde entra OpenFeature
OpenFeature é uma especificação aberta para avaliar feature flag com um API comum. A ideia é simples: o código da sua aplicação não deve depender diretamente do fornecedor ou do sistema interno que você usa para flags.
O aplicativo pergunta:
const enabled = await client.getBooleanValue('checkout.v2.enabled', false, { targetingKey: user.id, plan: user.plan, country: user.country, });
O provedor decide de onde vêm as regras: SaaS, arquivo, serviço interno, sinalizador, configuração do GitOps. Se um dia você alterar o back-end de sinalização de recursos, o aplicativo não precisará ser reescrito em todos os lugares.
Esta separação parece um detalhe arquitetônico, mas é sentida à medida que o projeto cresce.
Contexto é metade da batalha
Um sinalizador ligado ou desligado para todos é útil, mas limitado. A entrega progressiva vive no contexto:
- usuário interno ou externo;
- plano gratuito ou empresarial;
- aldeia;
- organização;
- versão do aplicativo;
- porcentagem estável de tráfego.
A chave importante é targetingKey: deve ser estável. Se mudar a cada solicitação, um usuário pode acabar uma vez na variante A e uma vez na variante B. Para um experimento é terrível, para um checkout pode ser desastroso.
Uma implementação sensata
Um fluxo que gosto é este:
- implantar com sinalizador desativado;
- ignição para desenvolvedores e controle de qualidade;
- ativação para um cliente ou inquilino piloto;
- Implementação de 5%;
- implantação em 25%;
- Implementação 100%;
- remoção de código e sinalizador antigos.
O ponto frequentemente esquecido é o último. Uma bandeira temporária deve ter uma data de falecimento. Se permanecer para sempre, todo refatorador futuro terá que perguntar: "mas esse branch ainda é útil?".
Kill switch: prepare-os primeiro
O kill switch é o sinalizador que salva você quando uma dependência externa começa a atrapalhar você, um trabalho consome muitos recursos ou uma nova lógica produz erros estranhos.
Um bom kill switch deve ser:
- fácil de encontrar;
- documentado no runbook;
- testado ocasionalmente;
- observável quando ativado;
- independente, tanto quanto possível, da parte que possa quebrar.
O pior é descobrir durante o acidente que a bandeira existe, mas ninguém sabe se ainda funciona.
Observabilidade ou entrega não progressiva
Ativar um recurso em 10% sem olhar as métricas é apenas otimismo com múltiplas etapas.
Cada implementação deve responder a perguntas simples:
- os erros aumentaram?
- a latência mudou?
- os usuários completam o fluxo?
- há mais tickets ou novas tentativas?
- uma variante afeta apenas um segmento?
OpenFeature suporta ganchos em torno da avaliação de sinalizadores. Eles são úteis para registrar erros, adicionar métricas ou vincular a classificação a trace.
Nomenclatura e propriedade
Os nomes são importantes. new_ui não diz nada. checkout.v2.enabled diz muito mais.
Para cada bandeira eu marcaria pelo menos:
- nome;
- descrição;
- proprietário;
- padrão seguro;
- razão pela qual existe;
- data ou condição da remoção.
Uma bandeira sem dono é quase sempre uma bandeira que ninguém irá eliminar.
Onde avaliá-los
Front-end, back-end ou edge? Depende.
Se o sinalizador for para layout, cópia ou integração, o frontend está bom. Se se tratar de permissões, cobrança, limites ou dados confidenciais, deve estar no backend. Se envolver roteamento ou experimentos de alto tráfego, a vantagem pode fazer sentido.
A regra simples: o frontend pode melhorar a experiência, mas não deve ser a única barreira de segurança.
Conclusão
Os feature flag bem feitos mudam a relação com a produção. Eles não eliminam o risco, mas o tornam menor e mais gerenciável. Você pode soltar em fatias, observar, parar, voltar, aprender.
OpenFeature adiciona uma base limpa: um API comum, provedores intercambiáveis e uma maneira mais organizada de expandir o sistema. Mas a disciplina continua sendo sua: padrões seguros, nomes claros, métricas, proprietários e limpeza.
A melhor bandeira é aquela que te ajuda a liberar com calma e depois desaparece quando não for mais necessária.