Nesta aula, vamos explorar as principais estratégias de deploy utilizadas em ambientes DevOps. O deploy é uma das fases mais críticas do ciclo de vida do software, pois é o momento em que as alterações são disponibilizadas para os usuários. Escolher a estratégia correta pode minimizar riscos, reduzir downtime e permitir rollbacks rápidos. Vamos detalhar quatro abordagens populares: Rolling, Blue-green, Canary e Feature flags.

Cada estratégia possui características específicas que se adequam a diferentes cenários, como aplicações críticas, ambientes de alta disponibilidade ou necessidade de testes controlados. Ao final, você será capaz de avaliar qual estratégia aplicar em cada contexto.

Rolling

O deploy Rolling (ou rolling update) consiste em substituir gradualmente as instâncias da aplicação antiga pela nova versão, uma a uma ou em grupos. Durante o processo, algumas instâncias ainda executam a versão antiga enquanto outras já estão na nova, garantindo que o serviço permaneça disponível. Essa estratégia é comum em sistemas que rodam em clusters, como Kubernetes, onde os pods são atualizados progressivamente.

Vantagens: não requer capacidade extra (como em blue-green), permite rollback parcial e reduz o downtime. Desvantagens: pode causar inconsistências temporárias entre versões e o rollback pode ser lento se muitas instâncias já foram atualizadas.

Exemplo prático com Kubernetes:

kubectl set image deployment/meu-app meu-app=meu-app:v2 --record
kubectl rollout status deployment/meu-app

Nesse exemplo, o comando kubectl set image inicia um rolling update, atualizando os pods gradualmente. O status pode ser monitorado com kubectl rollout status.

Blue-green

A estratégia Blue-green mantém dois ambientes idênticos: o ambiente azul (blue) e o ambiente verde (green). Em um dado momento, apenas um deles está recebendo tráfego de produção. Para realizar o deploy, você implanta a nova versão no ambiente inativo e, após testar, redireciona o tráfego para ele. Isso permite um switch instantâneo e um rollback imediato se algo der errado.

Vantagens: zero downtime, rollback rápido (basta redirecionar o tráfego de volta), e testes completos no ambiente de staging antes de ir para produção. Desvantagens: requer o dobro da capacidade de infraestrutura, e o gerenciamento de estado compartilhado (como bancos de dados) pode ser complexo.

Exemplo com balanceador de carga (NGINX):

# Supondo que azul está ativo:
server {
    location / {
        proxy_pass http://blue_upstream;
    }
}

# Após deploy no verde, troque para:
server {
    location / {
        proxy_pass http://green_upstream;
    }
}
# Recarregue o NGINX:
sudo nginx -s reload

Esse script altera o upstream do NGINX de blue para green e recarrega a configuração, efetuando o switch.

Canary

O deploy Canary expõe a nova versão para uma pequena parcela dos usuários (por exemplo, 5%) antes de liberar para todos. O objetivo é monitorar métricas (erros, latência, etc.) e, se tudo estiver estável, aumentar gradualmente a porcentagem até 100%. Caso contrário, o tráfego é redirecionado para a versão antiga.

Vantagens: permite testar em produção com baixo risco, coleta feedback real e reduz o impacto de problemas. Desvantagens: complexidade de roteamento e monitoramento, e pode exigir suporte a feature flags ou balanceamento de carga avançado.

Exemplo com Istio (service mesh):

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: meu-app
spec:
  hosts:
  - meu-app
  http:
  - route:
    - destination:
        host: meu-app
        subset: v1
      weight: 95
    - destination:
        host: meu-app
        subset: v2
      weight: 5

Esse manifesto do Istio define que 95% do tráfego vai para a versão v1 e 5% para a v2 (canary).

Feature flags

Feature flags (ou toggles) são chaves no código que permitem ativar ou desativar funcionalidades sem fazer novo deploy. Elas são gerenciadas por um sistema de configuração remota (como LaunchDarkly, ConfigCat ou até variáveis de ambiente). Isso possibilita liberar recursos gradualmente, fazer testes A/B, ou desativar funcionalidades problemáticas instantaneamente.

Vantagens: controle granular, rollback instantâneo (apenas desligar a flag), e permite deploy contínuo com funcionalidades escondidas. Desvantagens: complexidade no código (precisa gerenciar flags), poluição do código se não forem removidas após estabilização, e necessidade de um sistema de gerenciamento.

Exemplo em Python (usando variável de ambiente):

import os

NOVA_FUNCIONALIDADE = os.getenv('NOVA_FUNCIONALIDADE', 'false') == 'true'

def main():
    if NOVA_FUNCIONALIDADE:
        print("Nova funcionalidade ativa")
    else:
        print("Funcionalidade antiga")

if __name__ == '__main__':
    main()

Nesse exemplo, a flag é controlada pela variável de ambiente NOVA_FUNCIONALIDADE. Em produção, basta alterar a variável para ativar/desativar sem redeploy.

Boas práticas e observações finais

A escolha da estratégia de deploy depende do seu contexto: orçamento, criticidade, maturidade da equipe e infraestrutura. Rolling é simples e econômico; blue-green oferece zero downtime com custo maior; canary é ideal para validação gradual; feature flags dão flexibilidade máxima. Muitas equipes combinam estratégias, como usar feature flags dentro de um canary. Sempre monitore métricas e tenha planos de rollback.

Referências

Exercícios

  1. Qual estratégia de deploy é mais indicada para uma aplicação que não pode ter downtime e possui recursos de infraestrutura limitados? Justifique.

    ✓ Resposta: A estratégia Rolling é a mais indicada, pois permite atualização gradual sem necessidade de capacidade extra, mantendo o serviço disponível durante o processo. Blue-green exigiria o dobro de recursos, o que pode ser inviável com recursos limitados.
  2. Descreva como você implementaria um deploy Canary usando Kubernetes e Istio.

    ✓ Resposta: Primeiro, crie dois deployments (v1 e v2) e dois services. Depois, defina um VirtualService do Istio com pesos: 95% para v1 e 5% para v2. Monitore métricas (erros, latência) e, se estável, aumente gradualmente o peso de v2 até 100%. Se houver problemas, reverta o peso para 0%.
  3. Quais são as principais desvantagens da estratégia Blue-green?

    ✓ Resposta: As principais desvantagens são: necessidade do dobro de infraestrutura (custo maior), complexidade no gerenciamento de estado compartilhado (bancos de dados, caches) e possível inconsistência se o switch não for atômico.
  4. Explique como Feature flags podem ser usadas para realizar um deploy Canary.

    ✓ Resposta: Com Feature flags, você pode implantar a nova versão com a flag desativada para todos. Em seguida, ative a flag para um pequeno grupo de usuários (canary). Monitore o comportamento e, se tudo estiver bem, aumente gradualmente a porcentagem de usuários com a flag ativa até 100%. Se houver problemas, desative a flag instantaneamente.
  5. Em um deploy Rolling, o que pode acontecer se uma migração de banco de dados for incompatível entre versões?

    ✓ Resposta: Pode ocorrer inconsistência, pois instâncias antigas e novas acessam o mesmo banco. Se a migração adicionar colunas ou alterar esquemas de forma não retroativa, a versão antiga pode falhar. Para evitar, as migrações devem ser compatíveis com ambas as versões (backward compatibility) ou usar feature flags para controlar o acesso a novas funcionalidades.