Publicar código e liberar uma funcionalidade para todos os usuários não precisam ser o mesmo acontecimento. Separar essas decisões permite testar uma mudança com um grupo controlado, observar o comportamento e interromper a exposição quando houver problema.
Feature flags são controles que alteram comportamentos da aplicação sem exigir um novo deploy para cada decisão de liberação. Elas ajudam a administrar risco, mas também criam estados adicionais que precisam de teste, segurança e prazo de remoção.
O que uma flag pode controlar
Uma flag pode habilitar uma tela, trocar um fluxo ou selecionar uma implementação. A documentação do OpenFeature apresenta uma API aberta e independente de fornecedor para feature flagging. O mecanismo não define sozinho a política de liberação nem substitui autorização de usuário.
Uma funcionalidade escondida por flag ainda precisa de proteção no servidor. Se o endpoint continua aceitando chamadas de qualquer pessoa, ocultar o botão não restringe acesso. Liberação de produto e direito de executar uma operação são controles diferentes.
Planeje uma liberação em etapas
Em um exemplo hipotético, um sistema lança uma nova aprovação de despesas. Primeiro, a equipe interna usa dados de teste. Depois, um grupo autorizado acompanha operações reais selecionadas. A expansão ocorre somente quando os critérios de erro, tempo e resultado estiverem dentro do esperado.
O grupo deve ser identificado de forma estável. Uma pessoa não deveria alternar entre o fluxo antigo e o novo aleatoriamente a cada clique, especialmente durante uma mesma operação. Defina também se a seleção acontece por usuário, empresa, sessão ou outro contexto adequado.
| Etapa | Objetivo | Condição para avançar |
|---|---|---|
| Ambiente de validação | Conferir comportamento e integrações | Casos de aceite concluídos |
| Uso interno | Encontrar problemas de experiência | Sem bloqueios críticos conhecidos |
| Grupo controlado | Observar condições reais | Métricas e suporte estáveis |
| Ampliação | Aumentar exposição gradualmente | Capacidade e resultados confirmados |
| Consolidação | Remover o caminho temporário | Dependências antigas encerradas |
Desligar a flag não desfaz os efeitos
Se a nova versão alterou dados, enviou mensagens ou criou cobranças, ocultar a funcionalidade não reverte o passado. O plano de recuperação precisa considerar o que já aconteceu e como o fluxo antigo interpreta os registros novos.
Essa é uma razão para combinar flags com mudanças de banco compatíveis. Uma tela nova pode depender de uma estrutura adicional; retirar a tela não deve quebrar o restante da aplicação. O desenho precisa permitir convivência durante a transição ou assumir uma janela controlada quando isso não for possível.
Também teste a ausência do serviço de configuração. A aplicação deve ter um comportamento padrão definido. Para uma capacidade de risco, liberar tudo por falha pode ser inadequado. Para uma função essencial, bloquear tudo pode interromper a operação. A decisão pertence ao contexto do produto.
Meça o que a mudança pretende melhorar
Uma liberação gradual não é automaticamente um experimento estatístico. Para comparar versões, defina hipótese, população, período e indicadores. Diferenças no perfil dos grupos podem explicar resultados aparentes, especialmente com pouco volume.
Além da métrica principal, acompanhe sinais de proteção. Um formulário pode aumentar envios e piorar a qualidade das solicitações; um fluxo pode reduzir cliques e aumentar erros de autorização. A equipe precisa avaliar o resultado de negócio e os efeitos colaterais.
Não interrompa ou declare vitória com base em poucas ocorrências convenientes. Quando o objetivo for reduzir risco operacional, a observação pode ser qualitativa e técnica; quando for estimar ganho de conversão, o desenho de análise precisa ser apropriado ao volume disponível.
Evite o acúmulo de flags esquecidas
Cada flag adiciona combinações possíveis. Com o tempo, fica difícil saber quais caminhos ainda são usados e quais deveriam ser removidos. Registre proprietário, finalidade, data de revisão e condição de encerramento.
Separe flags temporárias de liberação, controles operacionais e permissões permanentes. Usar a mesma ferramenta para tudo pode esconder regras importantes. O time deve entender se está desligando um lançamento, aplicando um limite operacional ou alterando acesso de um cliente.
Checklist de um lançamento controlado
- Hipótese e critério de sucesso definidos.
- Grupo de liberação estável e autorizado.
- Validação no servidor preservada.
- Estados ligado, desligado e indisponível testados.
- Compatibilidade de dados avaliada.
- Plano para efeitos já executados.
- Responsável e prazo de remoção registrados.
Perguntas frequentes
Flag substitui rollback?
Não. Ela pode reduzir exposição rapidamente, mas não desfaz alterações de dados nem corrige todos os tipos de falha. Recuperação continua necessária.
Posso usar flag para cobrar por plano?
É possível compor a experiência, mas a autorização e a regra comercial devem ser verificadas no servidor. Não confie apenas no estado do navegador.
Toda funcionalidade precisa de uma flag?
Não. O benefício deve superar o custo de manter estados adicionais. Uma alteração pequena e facilmente reversível pode não justificar essa camada.
Referência e aplicação
Veja a introdução do OpenFeature para o conceito e a interface padronizada. O roteiro de liberação é uma proposta editorial, não uma promessa de risco zero.
Para evoluir um produto com previsibilidade, conheça o desenvolvimento da A2CR e organize a validação com o guia de homologação.
