Feature Flags: Como Separar Deploy de Release e Entregar Sem Medo
Feature flags desacoplam colocar código em produção de ativá-lo para o usuário. Entenda os tipos de flag, rollout progressivo, kill switch e como não afundar em dívida técnica de flags.
Neste artigo
Existe uma diferença que muda a forma como um time entrega software, e que a maioria descobre tarde demais: deploy e release não são a mesma coisa. Deploy é colocar o código em produção. Release é torná-lo visível e ativo para o usuário. Quando esses dois eventos acontecem juntos — o código sobe e no mesmo instante está no ar para todo mundo — cada deploy é uma aposta de tudo ou nada. É aí que entram as feature flags.
Uma feature flag (ou feature toggle) é um interruptor no código que decide, em tempo de execução, se um trecho de funcionalidade está ativo ou não, sem exigir um novo deploy para mudar. Com ela, você faz o deploy do código desligado, e depois liga a funcionalidade quando quiser, para quem quiser — e desliga na mesma velocidade se algo der errado. Vamos entender os tipos de flag, os padrões de uso e as armadilhas que fazem times bem-intencionados afundarem em dívida técnica.
O conceito central: o interruptor em runtime#
No código, uma flag é uma condição:
``python if flags.is_enabled("novo_checkout", user=usuario): return renderizar_novo_checkout(usuario) return renderizar_checkout_antigo(usuario) ``
O que muda tudo é de onde vem o valor de is_enabled. Ele não é uma constante compilada; é buscado em runtime de um serviço de configuração de flags. Isso significa que você pode alterar o comportamento da aplicação — para todos, para 10% dos usuários, para um cliente específico — sem tocar no código e sem reimplantar. O mesmo artefato em produção passa a se comportar de forma diferente porque a configuração da flag mudou.
Essa separação entre deploy e release é o que destrava várias práticas modernas: integração contínua de verdade (você mescla código incompleto, protegido por flag), rollout progressivo, testes A/B, e a capacidade de desligar uma funcionalidade problemática em segundos.
Os tipos de flag (e por que a distinção importa)#
Nem toda flag é igual. Uma classificação clássica separa quatro tipos por longevidade e dinamismo, e confundi-los é a origem de boa parte da bagunça.
Release toggles#
São flags temporárias que escondem funcionalidade em desenvolvimento. Permitem mesclar código incompleto na branch principal sem expô-lo. Vivem dias ou semanas — o suficiente para a funcionalidade ficar pronta e ser ativada. Devem ser removidas assim que a feature está 100% no ar. São a fonte número um de dívida quando esquecidas.
Experiment toggles#
Dividem usuários em grupos para testes A/B. Um grupo vê a variante A, outro a B, e você mede qual converte melhor. São dinâmicas por usuário e vivem o tempo do experimento. A decisão de qual variante cada usuário vê precisa ser consistente (o mesmo usuário sempre cai no mesmo grupo) para o experimento ter validade.
Ops toggles#
Controlam aspectos operacionais em produção: ligar/desligar uma funcionalidade pesada sob carga, ativar um caminho de degradação graciosa. O kill switch é o exemplo mais importante — um interruptor para desativar rapidamente algo que está causando problema. Alguns ops toggles são de vida longa, permanecendo como válvulas de controle permanentes.
Permission toggles#
Controlam quais funcionalidades cada usuário ou plano vê — recursos premium, acesso antecipado para beta testers. São de vida longa por natureza, porque fazem parte da lógica de produto, não de entrega. Aqui a "flag" na prática se confunde com autorização e deve seguir as regras de authz (decisão no servidor, nunca confiável no cliente).
A confusão perigosa é tratar um release toggle como se fosse permanente (e nunca removê-lo) ou um permission toggle como temporário. Nomeie e documente o tipo de cada flag desde o nascimento.
Rollout progressivo: ligando aos poucos#
O maior ganho operacional das flags é poder ativar uma funcionalidade gradualmente, observando o impacto antes de expor todo mundo. Em vez de um big-bang, você abre a torneira devagar:
``text Dia 1: novo_checkout = 1% dos usuários -> observa erros, latência Dia 2: novo_checkout = 10% -> métricas saudáveis, segue Dia 3: novo_checkout = 50% Dia 4: novo_checkout = 100% ``
Se, em qualquer etapa, as métricas degradarem — taxa de erro sobe, conversão cai, latência dispara — você volta a flag para o percentual anterior instantaneamente. Isso é um rollback sem deploy: o código problemático continua em produção, mas desligado. Compare com o rollback tradicional, que exige reimplantar a versão anterior e leva minutos ou mais.
O direcionamento pode ir além do percentual: ativar primeiro para usuários internos (dogfooding), depois para um beta, depois por região, por plano, por qualquer atributo. A flag vira um bisturi para controlar exatamente quem é exposto ao novo.
O kill switch: sua rede de segurança#
Toda funcionalidade nova de risco deveria nascer atrás de um kill switch — uma flag cujo único propósito é desligar aquilo rápido. Quando um alerta dispara às três da manhã por causa da feature que subiu ontem, a diferença entre "desligo a flag em dez segundos" e "preciso preparar, revisar e implantar um rollback" é a diferença entre um soluço e um incidente.
``python # Caminho protegido por kill switch com degradação graciosa. if flags.is_enabled("recomendacoes_ml"): try: return servico_ml.recomendar(usuario) except Exception as e: logger.error("recomendacao_ml_falhou", trace_id=trace_id, erro=str(e)) return recomendacoes_padrao() # degrada, não quebra return recomendacoes_padrao() ``
Repare que o kill switch e a degradação graciosa andam juntos: quando a funcionalidade está desligada (ou falha), o sistema cai num comportamento padrão seguro, em vez de quebrar. É a mesma filosofia da independência de serviços — a ausência de um componente degrada a experiência, não derruba o sistema.
A dívida técnica das flags#
Aqui está o lado sombrio. Cada flag adiciona um if no código, e cada if dobra os caminhos possíveis. Um punhado de flags convive bem; dezenas de flags esquecidas transformam o código em um labirinto onde ninguém sabe mais quais combinações são realmente testadas ou usadas. Flags acumuladas são dívida técnica que rende juros compostos.
Os problemas concretos:
- Explosão combinatória: N flags criam até 2^N combinações de estado. Testar
todas é impossível; na prática, você testa só as que imagina, e as outras viram bugs latentes.
- Código morto disfarçado: uma flag que já está em 100% há meses ainda tem o
ramo else com o código antigo, que ninguém remove e que confunde quem lê.
- Flags zumbi: ninguém lembra para que servem, ninguém tem coragem de
removê-las, e elas ficam ali para sempre.
A disciplina que evita isso:
- Toda release toggle nasce com data de validade e um responsável. Se passou
do prazo, vira tarefa de remoção prioritária.
- Remover a flag faz parte de terminar a feature. A funcionalidade só está
"pronta" quando está em 100%, estável, e a flag foi removida junto com o código do caminho antigo.
- Inventário de flags visível. Um painel que lista todas as flags ativas, seu
tipo, idade e estado. Flags velhas demais aparecem em vermelho.
- Limpeza periódica. Reserve tempo de manutenção para caçar e remover flags
mortas, como quem tira o lixo.
Distinguir o tipo ajuda aqui: release toggles têm de morrer; permission e alguns ops toggles são permanentes por design. O problema é quase sempre release toggle que virou permanente por inércia.
Flags e testes: a combinação que precisa ser testada#
Um risco pouco discutido é que feature flags multiplicam os estados que o sistema pode assumir, e isso tem consequência direta para os testes. Se uma funcionalidade está atrás de uma flag, tanto o caminho com a flag ligada quanto o desligado precisam funcionar — e ambos precisam de cobertura. Testar só o estado que está em produção hoje deixa o outro caminho como um campo minado: no dia em que você liga a flag, descobre que aquele ramo nunca foi exercitado.
A prática saudável é testar os dois estados relevantes de cada flag ativa, e resistir à tentação de deixar flags acumularem justamente porque cada uma dobra o espaço de teste. Quando uma release toggle chega a 100% e é removida, o número de combinações diminui e o sistema volta a ser testável de forma exaustiva. É mais um argumento para a disciplina de remoção: flags não são só dívida de leitura de código, são dívida de testabilidade.
Onde as flags são avaliadas, e a questão da confiança#
Uma decisão de arquitetura importante: a avaliação da flag acontece no servidor ou no cliente? Para qualquer coisa que envolva segurança ou autorização (os permission toggles), a resposta é categórica: no servidor. Uma flag que esconde um botão de admin no frontend é só experiência de usuário — se a rota do servidor não reverifica a permissão, um usuário mal-intencionado chama a API direto e contorna o botão escondido. Flag de UI não é controle de acesso.
Para flags de release e experimento sem implicação de segurança, avaliar no cliente é aceitável e às vezes preferível (evita uma ida ao servidor). Mas o valor que decide precisa vir de uma fonte confiável e ser resolvido de forma consistente por usuário.
Começando com o pé direito#
Feature flags são uma dessas ferramentas que resolvem problemas reais e criam outros se usadas sem disciplina. Um caminho pragmático para adotá-las bem:
- Comece com um mecanismo simples de flags — pode ser configuração em runtime
antes de um serviço dedicado — e proteja a próxima funcionalidade de risco atrás de uma.
- Pratique o rollout progressivo já na primeira: 1%, 10%, 50%, 100%, observando
métricas em cada degrau.
- Trate o kill switch como item obrigatório de qualquer feature que possa quebrar
produção.
- Nomeie, documente e datar cada flag desde o commit que a cria.
- Faça da remoção parte da definição de pronto.
O objetivo final não é ter muitas flags — é entregar com segurança. A flag é o meio pelo qual você separa a coragem de implantar da prudência de expor, ligando o novo devagar e podendo voltar atrás num piscar de olhos. Usada com disciplina, ela transforma o deploy de um evento tenso em um não-evento, e é isso que permite a um time entregar muitas vezes ao dia sem prender a respiração a cada push.
