Feature flags (também chamados de feature toggles ou toggles) são uma técnica poderosa no desenvolvimento de software que permite ligar ou desligar funcionalidades sem alterar o código ou fazer um novo deploy. Em vez de lançar uma funcionalidade diretamente para todos os usuários, você pode controlar sua visibilidade em tempo de execução, por meio de configurações. Isso desacopla o deploy (a disponibilização do código no ambiente) da release (a exposição da funcionalidade aos usuários), oferecendo uma flexibilidade imensa para equipes de DevOps.

Nesta aula, exploraremos como as feature flags funcionam, seus principais casos de uso e os cuidados necessários para evitar problemas. Você aprenderá a implementar toggles de forma simples, usando variáveis de ambiente ou serviços dedicados, e como integrá-los em seu fluxo de CI/CD para melhorar a segurança e a velocidade das entregas.

Desacoplando deploy de release

No modelo tradicional de desenvolvimento, quando você termina uma funcionalidade, faz o deploy e ela imediatamente fica disponível para todos. Isso pode ser arriscado: se houver um bug ou problema de performance, é preciso reverter o deploy, o que pode ser demorado e impactar a disponibilidade. Com feature flags, você pode fazer o deploy do código com a funcionalidade desligada (default off) e depois ativá-la gradualmente, ou mesmo desativá-la instantaneamente sem precisar de um novo deploy.

Isso separa o momento em que o código é colocado em produção (deploy) do momento em que a funcionalidade é liberada para os usuários (release). Isso é especialmente útil em arquiteturas de microserviços, onde diferentes serviços podem ter ciclos de deploy independentes. Por exemplo, você pode fazer o deploy de um novo serviço com a funcionalidade desabilitada, e depois ativar o toggle quando o serviço estiver estável e os testes passarem.

# Exemplo de variável de ambiente para controlar uma feature flag
# No arquivo de configuração do serviço
FEATURE_NEW_CHECKOUT=true

# No código, a verificação pode ser feita assim (em Python, por exemplo):
# if os.environ.get("FEATURE_NEW_CHECKOUT") == "true":
#     # nova lógica
# else:
#     # lógica antiga

Com essa abordagem, você pode reverter uma funcionalidade problemática simplesmente mudando a variável de ambiente e reiniciando o processo, sem precisar reverter o commit ou fazer rollback do deploy. Isso reduz o tempo de recuperação (MTTR) e aumenta a confiança da equipe em fazer deploys frequentes.

Toggles

Os toggles são a implementação concreta das feature flags. Eles podem ser tão simples quanto uma variável booleana em um arquivo de configuração, ou tão complexos quanto um sistema centralizado com painel de controle, segmentação por usuário e histórico de mudanças. Existem basicamente dois tipos de toggles: toggles de release (que controlam a liberação de funcionalidades) e toggles de experimento (para testes A/B).

Em termos de implementação, você pode usar:

  • Variáveis de ambiente: simples, mas requer reinicialização do serviço para aplicar mudanças.
  • Arquivos de configuração: semelhante, mas pode ser lido dinamicamente.
  • Serviços de feature flag: como LaunchDarkly, Split ou ConfigCat, que oferecem gerenciamento centralizado, mudanças em tempo real, segmentação por usuário e auditoria.

Um exemplo de implementação simples em bash para verificar uma flag:

#!/bin/bash
if [ "${FEATURE_XYZ:-false}" = "true" ]; then
    echo "Feature XYZ está ativa"
else
    echo "Feature XYZ está inativa"
fi

A escolha da abordagem depende do tamanho do projeto e da necessidade de dinamismo. Em projetos pequenos, variáveis de ambiente são suficientes; em empresas com muitos microsserviços, um serviço dedicado é mais adequado.

Casos de uso

As feature flags têm vários casos de uso práticos:

  • Lançamento incremental: Liberar uma funcionalidade para uma pequena porcentagem de usuários antes de liberar para todos. Isso permite monitorar métricas e detectar problemas em um ambiente controlado.
  • Testes A/B: Mostrar versões diferentes de uma funcionalidade para grupos de usuários e comparar o comportamento.
  • Deploy de funcionalidades incompletas: Integrar código no branch principal mesmo que a funcionalidade ainda não esteja pronta, mas desabilitada por padrão, evitando branches de longa duração.
  • Kill switch: Desabilitar rapidamente uma funcionalidade que está causando problemas, sem reverter o deploy.
  • Personalização por segmento: Ativar funcionalidades apenas para usuários premium, por exemplo.

Em DevOps, o uso mais comum é o lançamento incremental e o kill switch. Por exemplo, você pode fazer o deploy de uma nova versão do backend com uma feature flag que ativa um novo algoritmo de recomendação. Inicialmente, você ativa para 10% dos usuários. Se as métricas de erro e latência estiverem boas, aumenta para 50% e depois para 100%. Se houver problemas, desativa imediatamente.

# Exemplo de script para ativar uma flag gradualmente (simulação)
# Em um sistema real, você usaria um serviço de feature flag

for percentual in 10 50 100; do
    echo "Ativando feature para $percentual% dos usuários"
    # Chamada ao serviço de feature flag para definir o percentual
    # feature_flag_service.set_percentage("nova_busca", $percentual)
    sleep 3600  # espera 1 hora para observar métricas
done

Outro caso de uso é o canary release, onde você envia o tráfego gradualmente para a nova versão, mas isso é diferente de feature flag, pois envolve a infraestrutura. Feature flags complementam estratégias como blue-green e canary.

Cuidados

Embora feature flags sejam poderosas, elas introduzem complexidade e riscos que precisam ser gerenciados:

  • Dívida técnica: Toggles antigos que não são removidos podem acumular código morto e confusão. É essencial ter um processo para limpar flags após a funcionalidade estar estável.
  • Segurança: Se uma flag controla acesso a dados sensíveis, certifique-se de que a configuração não possa ser alterada por usuários não autorizados. Use serviços com controle de acesso.
  • Testes: Você precisa testar o código com a flag ativada e desativada, o que aumenta a matriz de testes. Automatize testes para ambos os estados.
  • Observabilidade: É importante monitorar o estado das flags e ter logs para saber qual flag está ativa em cada serviço, especialmente em incidentes.
  • Performance: Avaliações de flags em tempo real podem adicionar latência se forem feitas muitas chamadas a um serviço externo. Use cache ou SDKs otimizados.

Uma boa prática é adotar uma convenção de nomenclatura (ex.: prefixo FEATURE_) e documentar o propósito de cada flag. Além disso, sempre defina um prazo para remover a flag após o lançamento completo.

# Exemplo de script para listar flags em um arquivo de configuração
# Suponha um arquivo config.txt com linhas do tipo FEATURE_X=true

grep "^FEATURE_" config.txt | while IFS='=' read -r key value; do
    echo "$key está $([ "$value" = "true" ] && echo "ativa" || echo "inativa")"
done

Em resumo, feature flags são uma ferramenta essencial no DevOps moderno, mas exigem disciplina para evitar problemas de manutenção e segurança.

Boas práticas

  • Mantenha o número de flags pequeno e remova-as assim que possível.
  • Use um serviço de feature flag com painel e auditoria para projetos grandes.
  • Integre a verificação de flags em seus pipelines de CI/CD para testes em ambos estados.
  • Documente cada flag: motivo, responsável, data de expiração.
  • Monitore o uso das flags em produção para detectar anomalias.

Exercícios

  1. Explique a diferença entre deploy e release no contexto de feature flags.
  2. Escreva um script bash que verifica se a variável de ambiente FEATURE_PAGAMENTO está definida como "true" e imprime uma mensagem correspondente.
  3. Cite três casos de uso de feature flags e explique como cada um beneficia o fluxo de DevOps.
  4. Quais são os principais cuidados ao usar feature flags? Dê dois exemplos de problemas que podem surgir.
  5. Como você removeria uma feature flag que não é mais necessária? Descreva o processo passo a passo.

✓ Resposta: Deploy é o processo de colocar o código em um ambiente (como produção), enquanto release é quando a funcionalidade é disponibilizada para os usuários finais. Com feature flags, você pode fazer o deploy de um código com a funcionalidade desabilitada e depois ativá-la (release) sem precisar de um novo deploy, permitindo controle e reversão rápida.

✓ Resposta: 
#!/bin/bash
if [ "${FEATURE_PAGAMENTO:-false}" = "true" ]; then
    echo "Pagamento habilitado"
else
    echo "Pagamento desabilitado"
fi

✓ Resposta: Três casos de uso: 1) Lançamento incremental: liberar para um percentual de usuários para reduzir risco. 2) Kill switch: desligar rapidamente uma funcionalidade com problema. 3) Testes A/B: comparar versões para tomar decisões baseadas em dados. Benefícios: mais segurança, deploy contínuo e feedback mais rápido.

✓ Resposta: Cuidados: 1) Acúmulo de dívida técnica por toggles antigos; 2) Risco de segurança se a configuração for acessível a pessoas não autorizadas. Exemplos: código morto que confunde desenvolvedores, e um atacante que altera a flag para acessar funcionalidades restritas.

✓ Resposta: Processo: 1) Identificar a flag e sua funcionalidade; 2) Garantir que a funcionalidade está estável e completa; 3) Remover a flag do código, mantendo apenas o comportamento ativo; 4) Atualizar a configuração para remover a variável; 5) Testar o código sem a flag; 6) Fazer deploy da nova versão; 7) Limpar referências em documentação e monitoramento.

Referências