Feature Toggle — fundamentos, tipos de interruptores e aplicação
Feature Toggle é um mecanismo em tempo de execução para ativar e desativar funcionalidades da aplicação, permitindo que desenvolvedores gerenciem a disponibilidade de recursos sem alterar código ou reimplantar. Diferente da compilação condicional (ifdef), o toggle funciona em nível de runtime e pode ser alterado dinamicamente. De acordo com Martin Fowler (2024), os feature toggles são um elemento-chave do trunk-based development e da entrega contínua. Feature toggle dá às equipes flexibilidade no gerenciamento de lançamentos e experimentos.
Principais pontos
- Feature Toggle — um interruptor dinâmico que controla o comportamento da aplicação através de configuração
- Tipos principais: business toggles, release toggles, experiment toggles e infrastructure toggles
- Feature Toggle vs Flag — toggle geralmente se refere a interruptores binários simples, flag — a plataformas completas
- Integração CI/CD permite verificar e testar automaticamente os toggles em cada etapa do pipeline
- Problema principal — acúmulo de stale toggles, que precisam ser auditados e removidos regularmente
O que é um Feature Toggle
Feature Toggle é uma técnica onde o código de uma nova funcionalidade é envolvido em uma construção condicional que verifica o valor de um parâmetro de configuração. Se o parâmetro for verdadeiro — a nova funcionalidade está ativa, se for falso — o código antigo é executado. A principal diferença de um feature flag é que um toggle é um interruptor binário operando no princípio liga/desliga, sem regras complexas de segmentação ou distribuição de tráfego.
Definição e princípio de funcionamento
Um feature toggle é implementado como uma simples construção if em torno de uma nova funcionalidade. O valor do toggle é armazenado na configuração da aplicação — variáveis de ambiente, um arquivo JSON ou um banco de dados. Quando a aplicação é iniciada, ela carrega a configuração e a utiliza para tomar decisões sobre a visibilidade das funcionalidades. No caso mais simples, alterar o valor de um toggle requer reiniciar a aplicação, mas em sistemas de produção os toggles geralmente suportam recarga a quente através de um servidor de configuração externo ou API.
Exemplo de toggle simples
Vamos ver uma implementação de feature toggle em JavaScript (Node.js). O toggle é armazenado em um arquivo JSON de configuração e carregado quando o servidor inicia. O middleware verifica o valor do toggle antes de rotear a requisição para o manipulador novo ou antigo. Esta implementação permite adicionar novas funcionalidades ao ramo principal do código sem quebrar a versão atual da API.
js
const config = require("./config.json");
const toggles = {
get(name) {
return config.features[name] ?? false;
},
isEnabled(name, context) {
const toggle = config.features[name];
if (!toggle) return false;
if (toggle.enabled === true) return true;
if (toggle.percentage && context.userId) {
return hashCode(context.userId) % 100 < toggle.percentage;
}
return false;
}
};
const app = express();
app.use("/api/checkout", (req, res, next) => {
if (toggles.isEnabled("new_checkout", req)) {
return newCheckoutHandler(req, res);
}
return legacyCheckoutHandler(req, res);
});Tipos de Feature Toggles
Pete Hodgson da ThoughtWorks identifica três tipos principais de feature toggles, classificando-os por tempo de vida e propósito. Identificar corretamente o tipo de toggle ajuda a escolher o mecanismo de armazenamento e o processo de gerenciamento adequados. Vamos ver cada tipo no contexto do desenvolvimento móvel.
Business e Release Toggles
Os Business toggles são os interruptores de maior duração. Eles gerenciam regras de negócio disponíveis apenas para certas categorias de usuários (funcionalidades premium, particularidades regionais). Esses toggles podem viver por anos e geralmente têm lógica mais complexa do que liga/desliga binário. Os Release toggles são interruptores temporários para ocultar funcionalidades incompletas. Seu ciclo de vida varia de alguns dias a algumas semanas. Uma vez que a funcionalidade é concluída, o release toggle é removido do código. Esses toggles são a base do trunk-based development, permitindo que desenvolvedores commitem no ramo principal sem esperar que toda a funcionalidade seja concluída.
Experiment e Infrastructure Toggles
Os Experiment toggles são usados para testes A/B e rollout gradual. Diferente dos release toggles, os experiment toggles suportam distribuição percentual de usuários e integração com sistemas de análise. Eles podem viver mais que os release toggles (até vários meses), mas também devem ser removidos após a conclusão do experimento. Os Infrastructure toggles são interruptores para gerenciar mudanças de infraestrutura: migração de banco de dados, troca de provedor de API, alteração de algoritmos de cache. Esses toggles exigem atenção especial aos testes, pois sua ativação afeta a estabilidade de todo o serviço.
| Tipo de toggle | Duração | Público | Exemplo |
|---|---|---|---|
| Business | Meses-anos | Por papéis/regiões | Funcionalidades premium |
| Release | Dias-semanas | Desenvolvedores/QA | Tela incompleta |
| Experiment | Semanas-meses | % de usuários | Teste A/B de interface |
| Infrastructure | Dias-semanas | Interno | Migração de BD |
Feature Toggle vs Feature Flag
Embora os termos “feature toggle” e “feature flag” sejam frequentemente usados como intercambiáveis, existem diferenças conceituais entre eles. Compreender essas diferenças ajuda a escolher a ferramenta certa para uma tarefa específica e evitar confusão na equipe. Vamos ver as principais diferenças e casos de uso de cada abordagem.
Diferenças na abordagem
Feature toggle é principalmente um mecanismo técnico: um interruptor binário embutido no código da aplicação. O toggle é gerenciado através de configuração e não requer infraestrutura externa. Feature flag é um conceito mais amplo que inclui uma plataforma de gerenciamento: interface de usuário para configuração, SDK para integração, monitoramento de uso, análise e auditoria. Flags suportam regras complexas de segmentação (por região, versão, dispositivo), experimentos A/B e remoção automática. Pode-se dizer que o feature flag é a evolução do feature toggle: as equipes começam com interruptores de configuração simples e migram para uma plataforma especializada à medida que crescem.
Quando um toggle é suficiente
Para equipes pequenas e projetos com um serviço único ou monólito, toggles de configuração simples são perfeitamente suficientes. Se você tem 5–10 desenvolvedores e 1–2 toggles ativos por vez, uma plataforma externa seria excessiva. As plataformas de feature flags (LaunchDarkly, Unleash) tornam-se necessárias quando o número de flags ativos excede 20–30, a equipe tem 20+ desenvolvedores, ou é necessário controle de acesso detalhado para diferentes segmentos de usuários. Para aplicações móveis, onde as atualizações do cliente levam dias, as plataformas de feature flags oferecem uma vantagem adicional — a capacidade de alterar o comportamento da aplicação sem publicar uma nova versão.
Ferramentas de gerenciamento
A escolha de uma ferramenta de gerenciamento de feature toggles depende do tamanho da equipe, da pilha tecnológica e dos requisitos de segurança. Vamos ver opções desde arquivos de configuração simples até plataformas de gerenciamento empresarial, incluindo alternativas de código aberto.
Integração com CI/CD
Os feature toggles devem ser cidadãos de primeira classe do pipeline CI/CD. Na etapa de compilação, o pipeline verifica se todos os release toggles programados para remoção na sprint atual foram realmente removidos do código. Na etapa de teste, testes matriciais são executados com diferentes combinações de toggles. Na etapa de implantação, o sistema sincroniza automaticamente a configuração dos toggles com o ambiente de produção. A integração com PagerDuty ou Opsgenie permite criar alertas quando stale toggles são detectados ou quando o número permitido de toggles ativos é excedido.
Soluções populares
Para cenários simples, um arquivo JSON de configuração no Git com revisão de código nas alterações é suficiente. Uma opção mais avançada é Togglz (Java) ou Gofeature (Go) — bibliotecas que adicionam uma interface de usuário mínima para gerenciamento de toggles. Para sistemas de produção, recomenda-se Unleash (código aberto) com SDK para todas as linguagens e suporte a estratégias de ativação, ou Flagsmith com teste A/B integrado. LaunchDarkly continua sendo o padrão para projetos empresariais com altos requisitos de auditoria e conformidade. Para aplicações móveis, todas as soluções fornecem SDK nativos com cache e modo offline.
Dívida técnica e remoção
Os feature toggles são uma faca de dois gumes. Sem disciplina de gerenciamento, eles se transformam em dívida técnica que retarda o desenvolvimento e aumenta a complexidade do código. De acordo com um estudo da CodeScene (2024), 35–50% das bases de código contêm stale toggles — interruptores que permanecem no código após a conclusão do rollout. Vamos ver estratégias para prevenir e eliminar essa dívida.
Remoção de toggles
O processo de remoção de um feature toggle consiste em quatro etapas. Primeiro: garantir que o toggle esteja ativado para 100% do público ou desativado para 0% (dependendo de qual ramo de código deve permanecer). Segundo: remover todas as verificações condicionais do toggle do código, deixando apenas o ramo que deve ser o comportamento de produção. Terceiro: remover a definição do toggle do sistema de armazenamento (configuração, banco de dados ou plataforma). Quarto: executar testes para confirmar que a remoção não quebrou a funcionalidade. Cada toggle deve ter um proprietário e uma data de remoção planejada, registrados quando o interruptor é criado.
Automação de auditoria
A auditoria manual de toggles é ineficiente em escalas acima de 50 interruptores. A automação é construída em três princípios: verificação em CI (stale toggles bloqueiam o merge), monitoramento (um painel mostrando a idade e o status de cada toggle), alertas (notificar o proprietário se um toggle não mudou em N dias). Ferramentas de análise estática de código (SonarQube, plugin ESLint) podem detectar toggles que estão sempre ativados ou sempre desativados no código — um sinal claro de stale toggle. A verificação final é a revisão de código, onde o revisor deve verificar se o novo toggle é realmente necessário e se o ramo de código antigo será removido.
go
package toggles
type Toggle struct {
Name string
Enabled bool
Owner string
CreatedAt time.Time
TTL time.Duration
}
type ToggleManager struct {
store map[string]*Toggle
}
func NewToggleManager() *ToggleManager {
return &ToggleManager{store: make(map[string]*Toggle)}
}
func (m *ToggleManager) IsEnabled(name string) bool {
t, ok := m.store[name]
if !ok {
return false
}
return t.Enabled
}
func (m *ToggleManager) GetStaleToggles() []string {
var stale []string
for name, t := range m.store {
if t.Enabled && time.Since(t.CreatedAt) > t.TTL {
stale = append(stale, name)
}
}
return stale
}Perguntas frequentes
Como um feature toggle difere de um feature flag?
Os termos são frequentemente usados de forma intercambiável, mas tecnicamente feature toggle é um interruptor binário no código (uma condição if que verifica um valor de configuração). Feature flag é um conceito mais amplo que inclui uma plataforma de gerenciamento com interface de usuário, SDK, análise e regras complexas de segmentação. Um toggle não requer infraestrutura externa; um flag geralmente requer.
Com que frequência os toggles antigos devem ser removidos?
Os release toggles devem ser removidos dentro de 1–2 semanas após a conclusão do rollout. Experiment toggles — imediatamente após a conclusão do teste A/B. Business toggles exigem auditoria regular (trimestral). Recomenda-se configurar uma verificação em CI que bloqueie o merge se um PR adicionar um novo toggle sem uma tarefa de remoção no rastreador de tarefas.
Pode-se usar toggles para aplicações móveis?
Sim, os feature toggles são ativamente usados no desenvolvimento móvel. A ferramenta principal é o Firebase Remote Config, que permite gerenciar dinamicamente os interruptores sem publicar uma nova versão da aplicação. Alternativas: SDK do LaunchDarkly para iOS/Android, SDK do Unleash, um servidor de toggle personalizado com API REST. É importante implementar cache de valores para o modo offline.
Como testar código com feature toggles?
O método principal é o teste matricial: executar todos os testes com o toggle ativado e desativado. Para N toggles, o teste matricial completo requer 2^n execuções, portanto, na prática, combinações críticas são selecionadas. Testes unitários devem simular o valor do toggle. Testes de integração verificam cenários específicos. Uma etapa é adicionada ao CI que executa testes com uma combinação aleatória de toggles para detectar interações inesperadas.
Quais são os riscos dos feature toggles?
Principais riscos: 1) stale toggles — o código com ambos os ramos (ativado/desativado) torna-se complexo e difícil de manter; 2) complexidade combinatória de teste — cada toggle dobra o número de estados; 3) código morto — o ramo antigo permanece no código após o toggle ser permanentemente ativado; 4) segurança — interruptores que controlam acesso criam vulnerabilidades quando mal configurados. Todos os riscos são gerenciáveis com disciplina e automação.
Resumo
- Feature Toggle — um interruptor binário de funcionalidade controlado através da configuração da aplicação
- Tipos principais: business (meses-anos), release (dias-semanas), experiment (semanas-meses), infrastructure (dias-semanas)
- Feature Toggle vs Flag — toggle é mais simples (condição if + configuração), flag inclui uma plataforma de gerenciamento completa
- Integração CI/CD é obrigatória: verificação de stale toggles, testes matriciais, sincronização de configuração
- Stale toggles — o principal risco: 35–50% das bases de código contêm interruptores não utilizados
- Remoção de toggle requer um processo: confirmar estado, remover código, remover configuração, executar testes
- Automação de auditoria através de CI, painéis e análise estática de código previne o acúmulo de dívida técnica
Vamos desenvolver um aplicativo móvel chave na mão
A IT Sectr cria aplicativos para iOS e Android para startups e empresas desde 2017. Nós vamos aconselhá-lo e propor a melhor solução.
Leia também