Feature flags no deploy: LaunchDarkly ou Unleash integrados

1. Introdução às Feature Flags no Contexto DevOps

Feature flags (ou toggles) são mecanismos que permitem ativar ou desativar funcionalidades em tempo de execução sem necessidade de novo deploy. No contexto DevOps, elas transformam a entrega contínua ao separar o momento da implantação do momento da liberação do código.

Existem três categorias principais de flags:
- Flags de release: controlam quando uma funcionalidade é exposta aos usuários
- Flags de experimentação: permitem testes A/B e segmentação de tráfego
- Flags operacionais: gerenciam comportamento do sistema em produção (ex: desligar cache em caso de degradação)

Os benefícios diretos no ciclo DevOps incluem rollback instantâneo (basta desabilitar a flag), deploys sem downtime (código novo já está no ar, mas oculto) e testes em produção com usuários reais segmentados.

2. Arquitetura de Feature Flags em Kubernetes

Em clusters Kubernetes, há dois padrões principais de integração:

Sidecar vs. Agente Externo: O padrão sidecar executa um proxy de flags (como o Relay Proxy do LaunchDarkly) no mesmo pod da aplicação, reduzindo latência e tráfego externo. Já o agente externo usa SDKs client-side que se conectam diretamente ao serviço de flags.

Para aplicações stateless, flags podem ser expostas via ConfigMaps e Secrets para valores estáticos, mas isso perde a capacidade de toggle em tempo real. A abordagem recomendada é usar SDKs com cache local e fallback:

# ConfigMap para fallback de flags
apiVersion: v1
kind: ConfigMap
metadata:
  name: feature-flags-fallback
data:
  flags.json: |
    {
      "nova-busca": false,
      "checkout-v2": true,
      "modo-manutencao": false
    }

Estratégias de resiliência incluem cache TTL (30-60 segundos), fallback para valores default e circuit breaker para evitar cascata de falhas caso o serviço de flags fique indisponível.

3. LaunchDarkly: Integração e Práticas no Cluster

O SDK LaunchDarkly em containers Docker requer variáveis de ambiente para a chave SDK e health checks que validam a conexão. O Relay Proxy (sidecar) reduz latência ao manter conexão persistente com o serviço cloud.

# Deployment com LaunchDarkly Relay Proxy sidecar
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-com-flags
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: app
        image: minha-app:latest
        env:
        - name: LD_SDK_KEY
          valueFrom:
            secretKeyRef:
              name: launchdarkly-secrets
              key: sdk-key
        - name: LD_RELAY_HOST
          value: "localhost:8030"
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
      - name: relay-proxy
        image: launchdarkly/relay-proxy:latest
        env:
        - name: LD_RELAY_KEY
          valueFrom:
            secretKeyRef:
              name: launchdarkly-secrets
              key: relay-key
        ports:
        - containerPort: 8030

O Relay Proxy como DaemonSet (um por nó) também é viável para clusters grandes, compartilhando cache entre pods do mesmo nó.

4. Unleash: Self-Hosted e Controle Total

Unleash permite deploy on-premises com controle total sobre dados e compliance. A arquitetura típica inclui StatefulSet para o servidor Unleash + PostgreSQL.

# Helm values.yaml para Unleash
unleash:
  replicaCount: 2
  image:
    repository: unleashorg/unleash-server
    tag: latest
  persistence:
    enabled: true
    size: 10Gi
  postgresql:
    enabled: true
    postgresqlPassword: "senha-segura"
    persistence:
      size: 20Gi
  probes:
    readiness:
      initialDelaySeconds: 30
      periodSeconds: 10
    liveness:
      initialDelaySeconds: 60
      periodSeconds: 15
  rbac:
    create: true
    serviceAccountName: unleash-sa

Para autorização, configure RBAC com tokens de API para cada ambiente (dev, staging, production) e use NetworkPolicies para restringir acesso ao banco de dados.

5. Pipeline CI/CD com Feature Flags (GitLab CI / GitHub Actions)

Automatizar a criação e atualização de flags no pipeline garante consistência entre ambientes. A estratégia de rollout gradual: flag desabilitada no staging, habilitada parcialmente em produção.

# Script de toggle via API (Unleash)
#!/bin/bash
FLAG_NAME="nova-busca"
ENVIRONMENT="production"
API_TOKEN="${UNLEASH_API_TOKEN}"
UNLEASH_URL="https://unleash.exemplo.com/api"

# Habilitar flag para 10% dos usuários
curl -X PATCH "${UNLEASH_URL}/admin/projects/default/features/${FLAG_NAME}/environments/${ENVIRONMENT}/strategies" \
  -H "Authorization: ${API_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "strategies": [{
      "name": "flexibleRollout",
      "parameters": {
        "groupId": "nova-busca",
        "rollout": "10",
        "stickiness": "userId"
      }
    }]
  }'

No GitHub Actions, esse script pode ser executado após deploy bem-sucedido, com validação de métricas antes de aumentar o rollout para 50% e 100%.

6. Canary + Feature Flags: Sinergia para Deploys Seguros

Canary releases combinadas com feature flags permitem segmentação por usuário, região ou qualquer contexto. Com Istio, é possível rotear tráfego baseado em flags:

# VirtualService com roteamento condicional
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: app-flags
spec:
  hosts:
  - app.exemplo.com
  http:
  - match:
    - headers:
        x-feature-flag:
          exact: "nova-busca"
    route:
    - destination:
        host: app-canary
        port:
          number: 8080
  - route:
    - destination:
        host: app-stable
        port:
          number: 8080

Métricas de Prometheus (taxa de erro, latência) alimentam Grafana dashboards que podem acionar toggles automáticos via webhook: se erro > 1%, desabilitar flag automaticamente.

7. Segurança e Rotação de Chaves de Acesso

SDK keys e tokens de API são segredos críticos. O External Secrets Operator sincroniza automaticamente com AWS Secrets Manager ou Vault:

# ExternalSecret para LaunchDarkly
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: launchdarkly-secrets
spec:
  refreshInterval: "1h"
  secretStoreRef:
    name: aws-secrets-manager
    kind: SecretStore
  target:
    name: launchdarkly-secrets
  data:
  - secretKey: sdk-key
    remoteRef:
      key: prod/launchdarkly/sdk-key
  - secretKey: relay-key
    remoteRef:
      key: prod/launchdarkly/relay-key

Para renovação automática, configure o Relay Proxy para recarregar credenciais sem reinicializar pods (via SIGHUP ou endpoint /reload). Isso garante rotação segura sem downtime.

8. Comparativo e Boas Práticas Finais

LaunchDarkly é ideal para equipes que precisam de experimentação avançada (A/B tests, targeting por atributos), multi-nuvem e suporte SaaS gerenciado. Unleash é superior para cenários on-premises, compliance rigoroso (LGPD, HIPAA) e controle total de custos (sem taxa por volume de flags).

Checklist de boas práticas:
- [ ] Cleanup trimestral de flags antigas (remover código morto)
- [ ] Testes de toggle em ambientes não-produção
- [ ] Monitoramento de impacto (métricas antes/depois de ativar flag)
- [ ] Documentação de cada flag (responsável, data de expiração)
- [ ] Uso de OpenFeature como padrão aberto de abstração

Tendências: OpenFeature (CNCF) está se consolidando como padrão para abstrair provedores de flags, permitindo migrar entre LaunchDarkly e Unleash sem alterar código. Progressive Delivery combina feature flags com canary, blue-green e análise de métricas para deploys verdadeiramente seguros.

Referências