Estratégias de deploy são abordagens para atualizar aplicações em produção com o mínimo de risco e tempo de inatividade. Em DevOps, a escolha da estratégia correta impacta diretamente a confiabilidade, a velocidade de entrega e a experiência do usuário. Nesta aula, exploraremos quatro estratégias fundamentais: rolling, blue-green, canary e feature flags, detalhando como implementá-las e quando cada uma é mais adequada.

Antes de mergulharmos, é importante entender que nenhuma estratégia é universalmente superior; a escolha depende do contexto, da criticidade do sistema e da maturidade da equipe. Vamos analisar cada uma com exemplos práticos em ambientes Kubernetes e scripts de automação.

Rolling

Rolling update é a estratégia padrão em muitos orquestradores, como Kubernetes. Ela substitui gradualmente as instâncias da versão antiga pela nova, mantendo a aplicação disponível durante todo o processo. Por exemplo, em um deployment com 10 réplicas, você pode atualizar 2 por vez, garantindo que sempre haja pelo menos 8 instâncias saudáveis.

A principal vantagem é a simplicidade e o baixo custo de infraestrutura, pois não requer ambientes paralelos completos. No entanto, o rollback pode ser lento se muitos pods já foram atualizados, e problemas podem afetar gradualmente os usuários sem um isolamento claro.

# Exemplo de rolling update no Kubernetes
kubectl set image deployment/meu-app meu-app=minha-imagem:v2 --record
kubectl rollout status deployment/meu-app

Para controlar a velocidade, você pode configurar o maxSurge e maxUnavailable no deployment YAML. Um rolling update bem parametrizado permite detectar falhas cedo, mas exige monitoramento contínuo.

Blue-green

Blue-green mantém dois ambientes idênticos (blue e green). Apenas um está ativo (recebendo tráfego). Ao lançar uma nova versão, você implanta no ambiente inativo, realiza testes e, quando tudo estiver ok, redireciona todo o tráfego para ele. O ambiente anterior fica como reserva para rollback imediato.

Essa abordagem elimina o tempo de inatividade e facilita o rollback instantâneo. Porém, requer o dobro de recursos de infraestrutura e pode ser cara. É ideal para aplicações críticas onde o tempo de inatividade é inaceitável.

# Exemplo com balanceador de carga (HAProxy)
# Suponha que blue esteja ativo e green receba a nova versão
# Após validação, troque o backend ativo
# Comando fictício para alterar configuração do balanceador
# (na prática, use scripts ou ferramentas como Terraform)
echo "backend blue active" > /etc/haproxy/haproxy.cfg
systemctl reload haproxy

Um detalhe importante: certifique-se de que o banco de dados seja compatível com ambas as versões, ou utilize migrações reversíveis. Ferramentas como Spinnaker ou Argo Rollouts automatizam esse processo.

Canary

Canary releases expõem a nova versão para uma pequena parcela de usuários (por exemplo, 5%) enquanto os demais continuam na versão estável. Aos poucos, aumenta-se a porcentagem até 100%, monitorando métricas de erro e desempenho. Se algo der errado, o tráfego é redirecionado de volta para a versão antiga.

Essa estratégia minimiza o impacto de falhas, permitindo testar em produção com riscos controlados. Exige, porém, um sistema de roteamento dinâmico e monitoramento robusto. É excelente para validação de funcionalidades e testes A/B.

# Exemplo com Istio (service mesh) para canary
# Definição de VirtualService com pesos
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: meu-app
spec:
  hosts:
  - meu-app
  http:
  - route:
    - destination:
        host: meu-app
        subset: stable
      weight: 95
    - destination:
        host: meu-app
        subset: canary
      weight: 5

Ferramentas como Flagger automatizam a análise de métricas e a progressão do canary. Lembre-se de que a amostra de usuários deve ser representativa e o monitoramento deve capturar sinais de degradação rapidamente.

Feature flags

Feature flags (ou toggles) permitem ativar/desativar funcionalidades em tempo real sem implantar novo código. Você pode lançar uma feature desabilitada por padrão e, após testes, habilitá-la para usuários específicos ou gradualmente. Isso separa o deploy da ativação de funcionalidades.

Essa estratégia reduz drasticamente o risco de lançamentos, pois você pode desligar instantaneamente uma feature problemática sem rollback. No entanto, aumenta a complexidade do código e requer uma ferramenta de gerenciamento de flags (como LaunchDarkly, Unleash ou ConfigCat).

# Exemplo de uso de feature flag (pseudo-código)
# No código da aplicação:
if feature_flag.is_enabled("nova-funcionalidade"):
    # executa novo fluxo
else:
    # fluxo antigo

Boas práticas incluem: remover flags antigas após a funcionalidade estar estável, usar flags de curta duração e auditar quem pode alterá-las. Feature flags também permitem testes A/B e rollout progressivo sem necessidade de múltiplos ambientes.

Boas práticas e observações finais

Independentemente da estratégia, sempre tenha um plano de rollback claro e automatizado. Monitore métricas de negócio e técnicas (latência, taxa de erro, throughput). Combine estratégias: por exemplo, use canary com feature flags para controle granular. Documente o processo e treine a equipe para responder rapidamente a incidentes.

Lembre-se: a estratégia de deploy deve evoluir com o produto. Comece com rolling se o orçamento for limitado, migre para blue-green quando a criticidade aumentar, e adicione canary e feature flags para maior segurança e flexibilidade.

Referências

Exercícios

  1. Explique a diferença fundamental entre rolling update e blue-green deployment em termos de utilização de recursos e rollback.

    ✓ Resposta: Rolling update utiliza apenas um ambiente e substitui instâncias gradualmente, consumindo recursos equivalentes ao número de réplicas. O rollback é lento, pois precisa reverter cada instância. Blue-green mantém dois ambientes completos, dobrando o consumo de recursos, mas permite rollback instantâneo ao trocar o tráfego de volta para o ambiente anterior.

  2. Descreva um cenário onde canary release é mais adequada que blue-green e justifique.

    ✓ Resposta: Canary é mais adequada quando se deseja testar uma nova versão com um subconjunto de usuários reais para validar comportamento em produção antes de um lançamento completo. Por exemplo, um site de comércio eletrônico que quer testar um novo algoritmo de recomendação com 5% dos usuários para medir impacto em conversão. Blue-green não permite esse teste gradual; exporia todos os usuários à mudança de uma vez.

  3. Como as feature flags podem complementar uma estratégia de canary? Dê um exemplo.

    ✓ Resposta: Feature flags permitem ativar/desativar funcionalidades independentemente do deploy. Em um canary, você pode implantar a nova versão com a flag desabilitada para todos, depois habilitá-la gradualmente para os usuários do canary, e então para todos. Exemplo: deploy de uma nova interface de checkout com flag 'novo-checkout' desabilitada; no canary, ativa para 5% dos usuários; se bem-sucedido, aumenta para 100%.

  4. Escreva um comando kubectl para realizar um rolling update de um deployment chamado 'api' com a imagem 'api:v2', registrando a atualização no histórico.

    ✓ Resposta: 
    kubectl set image deployment/api api=api:v2 --record

  5. Cite duas desvantagens do blue-green deployment e como mitigá-las.

    ✓ Resposta: 1) Custo elevado de infraestrutura (dobro de recursos). Mitigação: usar ambientes compartilhados ou escalar sob demanda. 2) Problemas de compatibilidade de banco de dados (schema pode não ser compatível entre versões). Mitigação: garantir que as migrações sejam reversíveis ou usar flags de compatibilidade.