Gerenciamento de Feature Flags

Feature flags desacoplam deployment de release. Implante código quando estiver pronto, libere funcionalidades quando tiver confiança. Isso permite lançamentos mais seguros, rollbacks mais fáceis e melhor teste. Este guia cobre abordagens práticas para gerenciamento de feature flags.

Tipos de Flags

Implementação Básica

Feature Flags Simples

BÁSICOS DE FEATURE FLAG
══════════════════════

IMPLEMENTAÇÃO SIMPLES:
─────────────────────────────────────
Verificação básica de flag:

// Configuração
const FLAGS = {
  newCheckout: true,
  darkMode: false,
  betaFeatures: true,
};

// Uso
if (FLAGS.newCheckout) {
  return <NewCheckoutFlow />;
} else {
  return <OldCheckoutFlow />;
}

CONFIGURAÇÃO EXTERNA:
─────────────────────────────────────
Flags do servidor:

// Buscar flags na inicialização
const flags = await fetchFlags(userId);

// Uso
if (flags.isEnabled('newCheckout')) {
  return <NewCheckoutFlow />;
}

// Benefícios:
// - Alterar sem deploy
// - Flags específicos de usuário
// - Rollouts por porcentagem
// - Analytics integrado

PROVEDORES DE SERVIÇO DE FLAGS:
─────────────────────────────────────
Serviços populares:
├── LaunchDarkly
├── Split.io
├── ConfigCat
├── Unleash (open source)
├── Flagsmith (open source)
└── Escolha baseado nas necessidades

Estratégias de Rollout

Lançamento Gradual

ESTRATÉGIAS DE ROLLOUT
══════════════════════

ROLLOUT POR PORCENTAGEM:
─────────────────────────────────────
Aumento gradual:

Dia 1: 1% dos usuários
├── Monitorar erros
├── Verificar performance
├── Observar métricas
└── Raio de explosão pequeno

Dia 2: 10% dos usuários
├── Mais tráfego
├── Mais confiança
├── Ainda controlado
└── Rollback fácil

Dia 3: 50% dos usuários
├── Metade do tráfego
├── Validação significativa
├── Quase lá
└── Pronto para completo?

Dia 4: 100% dos usuários
├── Rollout completo
├── Funcionalidade ativa
├── Flag pode ser removida
└── Pronto!

ROLLOUT DIRECIONADO:
─────────────────────────────────────
Usuários específicos primeiro:
├── Funcionários internos primeiro
├── Depois usuários beta
├── Depois porcentagem de todos
├── Depois release completo
└── Construção gradual de confiança

// Regras de direcionamento
flag.targets = [
  { type: 'email', contains: '@company.com' }, // Staff
  { type: 'segment', equals: 'beta_users' },   // Beta
  { type: 'percentage', value: 10 },           // 10%
];

RELEASE CANARY:
─────────────────────────────────────
├── Combinar com deployment canary
├── Flag habilita em instâncias canary
├── Rede de segurança dupla
├── Muito controlado
└── Segurança máxima

Ciclo de Vida da Flag

Criação até Remoção

CICLO DE VIDA DE FEATURE FLAG
════════════════════════════

CRIAÇÃO:
─────────────────────────────────────
Ao criar flag:
├── Nome: descritivo, consistente
├── Proprietário: quem é responsável
├── Propósito: por que esta flag existe
├── Expiração: quando deve ser removida
├── Rastreamento: link para tarefa/issue
└── Documentar a flag

Exemplo:
{
  name: "new_checkout_v2",
  owner: "sarah@company.com",
  purpose: "Rollout gradual do redesign do checkout",
  created: "2024-01-15",
  expectedRemoval: "2024-02-15",
  jiraTicket: "PROJ-456"
}

USO ATIVO:
─────────────────────────────────────
Enquanto flag está ativa:
├── Monitorar uso
├── Rastrear no gerenciamento de projeto
├── Atualizar status conforme progresso do rollout
├── Documentar decisões
└── Gerenciamento ativo

REMOÇÃO:
─────────────────────────────────────
Quando funcionalidade estiver estável:
1. Flag em 100% por 2+ semanas
2. Nenhum problema observado
3. Remover código da flag
4. Implantar limpeza de código
5. Deletar flag do serviço
6. Fechar tarefa de rastreamento

DÍVIDA DE LIMPEZA:
─────────────────────────────────────
Agendar auditorias regulares:
├── Quais flags estão ativas?
├── Alguma passou da remoção esperada?
├── Alguma flag órfã?
├── Remover flags obsoletas
├── Prevenir acúmulo
└── Auditoria mensal ou trimestral

Higiene de Flags

Evitando Dívida de Flags

HIGIENE DE FLAGS
════════════════

SINTOMAS DE DÍVIDA DE FLAGS:
─────────────────────────────────────
Sinais de alerta:
├── Muitas flags ativas
├── Ninguém sabe o que as flags fazem
├── Flags nunca removidas
├── Combinações complexas de flags
├── Flags de anos atrás
├── Ninguém é dono das flags
└── Dívida técnica

PREVENÇÃO:
─────────────────────────────────────
Boas práticas:
├── Datas de expiração na criação
├── Proprietário para cada flag
├── Tarefa para remover flag
├── Auditorias regulares
├── Limitar flags totais
├── Cultura de limpeza
└── Flags são temporárias

LIMITES DE FLAGS:
─────────────────────────────────────
Diretrizes:
├── Máx 10-20 flags de release ativas
├── Mais para flags ops/permissão
├── Se muitas, parar de adicionar
├── Limpar antes de criar novas
└── Qualidade sobre quantidade

PROCESSO DE AUDITORIA:
─────────────────────────────────────
Mensalmente:
├── Listar todas flags ativas
├── Verificar cada uma: ainda necessária?
├── Criar tarefas de remoção
├── Remover flags expiradas
├── Atualizar documentação
└── Manutenção regular

Teste

Estratégias de Teste com Flags

TESTE COM FLAGS
═══════════════

TESTAR AMBOS OS CAMINHOS:
─────────────────────────────────────
Quando flag existe:
├── Testar com flag LIGADA
├── Testar com flag DESLIGADA
├── Ambos os caminhos funcionam
├── Testes CI para ambos
└── Sem surpresas

describe('Checkout', () => {
  it('funciona com novo checkout (flag ligada)', () => {
    setFlag('newCheckout', true);
    // testar novo caminho
  });
  
  it('funciona com checkout antigo (flag desligada)', () => {
    setFlag('newCheckout', false);
    // testar caminho antigo
  });
});

FLAGS DE AMBIENTE:
─────────────────────────────────────
Diferentes por ambiente:
├── Dev: Todas flags ligadas (testar novo)
├── Staging: Espelho da produção
├── Produção: Rollout controlado
└── Config específica do ambiente

TESTE EM PRODUÇÃO:
─────────────────────────────────────
Flag permite teste seguro:
├── Habilitar para usuários internos
├── Testar em produção
├── Dados reais, condições reais
├── Flag protege usuários
├── Construir confiança
└── Depois fazer rollout

Integração com Projeto

Rastreando Flags no GitScrum

RASTREAMENTO DE FLAGS NO GITSCRUM
═════════════════════════════════

FLAG COMO TAREFA:
─────────────────────────────────────
Criar tarefa para flag:
├── "Remover flag new_checkout_v2"
├── Data limite: 2 semanas após rollout completo
├── Atribuído: Proprietário da flag
├── Label: "flag-cleanup"
├── Rastrear no backlog
└── Não vai esquecer

STATUS DA FLAG:
─────────────────────────────────────
Rastrear status do rollout:
├── Na tarefa: porcentagem atual
├── Na tarefa: algum problema
├── Atualizar conforme progresso do rollout
├── Visibilidade dos stakeholders
└── Progresso rastreado

DOCUMENTAÇÃO DA FLAG:
─────────────────────────────────────
No NoteVault:
├── Lista de flags ativas
├── Propósitos das flags
├── Status do rollout
├── Cronograma de limpeza
├── Referência única
└── Visibilidade do time

NOTAS DE RELEASE:
─────────────────────────────────────
Quando flag totalmente lançada:
├── Funcionalidade agora nas notas de release
├── Vinculada à tarefa original da funcionalidade
├── Tarefa de limpeza da flag criada
└── Rastreamento completo

Melhores Práticas

Para Feature Flags

1. Proprietário de cada flag — Alguém responsável
2. Datas de expiração — Flags são temporárias
3. Auditorias regulares — Remover flags obsoletas
4. Testar ambos os caminhos — Flag ligada e desligada
5. Rastrear na ferramenta de projeto — Visibilidade

Anti-Padrões

ERROS DE GERENCIAMENTO DE FLAGS:
✗ Flags sem proprietários
✗ Flags nunca removidas
✗ Muitas flags ativas
✗ Sem datas de expiração
✗ Combinações complexas de flags
✗ Flags como funcionalidades permanentes
✗ Sem documentação
✗ Sem teste de ambos os caminhos

Soluções Relacionadas

• Como lidar com feature flags no fluxo de desenvolvimento
• Estratégias de automação de deployment
• Como usar GitScrum para desenvolvimento com feature flags