Em ambientes DevOps, a capacidade de reverter rapidamente uma release problemática é tão importante quanto a velocidade de entrega. Rollback e recuperação são práticas essenciais para garantir a resiliência do sistema e minimizar o impacto de falhas em produção. Nesta aula, exploraremos estratégias de rollback, versionamento de releases, automação e testes, fornecendo um guia prático para implementar reversões seguras e eficientes.

O rollback pode ser parcial ou total, manual ou automático, e deve ser planejado antes mesmo do deploy. Abordaremos desde conceitos básicos até técnicas avançadas, com exemplos em bash e ferramentas como Kubernetes e Ansible.

Estratégias de rollback

Existem diversas estratégias para realizar rollback, cada uma com vantagens e desvantagens. As mais comuns incluem:

  • Rollback completo: reverte todo o sistema para a versão anterior. Simples, mas pode causar downtime e perda de dados.
  • Rollback parcial: reverte apenas componentes específicos (ex: um microsserviço). Mais granular, mas requer mapeamento de dependências.
  • Blue-green deployment: mantém duas versões (azul e verde). O rollback é feito alternando o tráfego para a versão anterior. Sem downtime, mas custo maior de infraestrutura.
  • Canary release: libera a nova versão gradualmente. O rollback é feito redirecionando todo o tráfego para a versão estável. Reduz risco, mas é mais complexo.
  • Feature flags: desabilita funcionalidades problemáticas sem reverter o deploy. Rápido e seguro, mas requer implementação de flags.

A escolha depende do contexto: aplicações críticas podem usar blue-green; sistemas com muitas dependências podem preferir rollback parcial. É importante documentar e testar cada estratégia.

# Exemplo de rollback completo com Docker Compose
# Suponha que a versão atual seja v2 e a anterior v1
docker-compose down
export TAG=v1
docker-compose up -d

Versionamento de releases

Versionamento semântico (semver) é fundamental para identificar rapidamente qual versão deve ser restaurada. O formato MAJOR.MINOR.PATCH (ex: 1.2.3) ajuda a entender o impacto da mudança. Além disso, é crucial armazenar artefatos de cada versão (imagens Docker, pacotes, binários) em um repositório confiável, como um registry de container ou um bucket S3.

Boas práticas incluem: taggear cada commit com a versão correspondente, manter um changelog atualizado e usar scripts para gerar automaticamente o número da versão. Em pipelines CI/CD, a versão pode ser injetada como variável de ambiente.

# Exemplo de versionamento com Git tags
git tag -a v1.0.0 -m "Release 1.0.0"
git push origin v1.0.0

# Gerar versão automaticamente (ex: usando date)
VERSION=$(date +%Y%m%d%H%M%S)
echo "Building version $VERSION"
docker build -t myapp:$VERSION .

Automatizando

Automatizar rollback reduz erros humanos e acelera a recuperação. Ferramentas como Ansible, Terraform, Kubernetes e scripts customizados podem orquestrar a reversão. O ideal é que o mesmo pipeline que faz o deploy também tenha um job de rollback, acionado manualmente ou automaticamente (ex: após falha em health checks).

No Kubernetes, por exemplo, é possível usar o comando kubectl rollout undo para reverter um deployment. Em ambientes com Ansible, playbooks podem ter tarefas condicionais que restauram versões anteriores. A automação deve incluir validações pós-rollback, como testes de smoke e monitoramento.

# Rollback automático no Kubernetes
kubectl rollout undo deployment/myapp --to-revision=2

# Script de rollback com Ansible (exemplo simplificado)
ansible-playbook -i inventory.ini rollback.yml -e "version=v1.2.0"

Testando rollback

Testar rollback é tão importante quanto testar deploy. Deve-se simular cenários de falha e verificar se o processo de reversão funciona corretamente, sem causar efeitos colaterais. Isso inclui testar a integridade dos dados, a consistência do banco de dados e o tempo de recuperação.

Práticas recomendadas: criar ambientes de staging idênticos à produção, usar ferramentas de chaos engineering (ex: Chaos Monkey) para induzir falhas, e documentar os procedimentos de rollback. O teste deve ser executado regularmente, não apenas após incidentes.

# Exemplo de script de teste de rollback
#!/bin/bash
echo "Simulando falha..."
kubectl set image deployment/myapp myapp=myapp:bad-version
sleep 10
if ! curl -f http://myapp/health; then
  echo "Health check falhou. Executando rollback..."
  kubectl rollout undo deployment/myapp
  echo "Rollback concluído."
else
  echo "Deploy bem-sucedido."
fi

Boas práticas e observações finais

Além das estratégias mencionadas, algumas práticas aumentam a eficácia do rollback: manter backups frequentes do banco de dados, versionar também a infraestrutura (Infrastructure as Code), e estabelecer SLAs para tempo de recuperação. Lembre-se: rollback não deve ser visto como falha, mas como parte do ciclo de vida do software. Invista em automação e testes contínuos para que a reversão seja tão confiável quanto o deploy.

Referências

Exercícios

  1. Explique a diferença entre rollback completo e parcial. Dê um exemplo de situação onde cada um seria mais adequado.

    ✓ Resposta: Rollback completo reverte todo o sistema para a versão anterior, adequado para falhas catastróficas que afetam todo o sistema (ex: erro em biblioteca compartilhada). Rollback parcial reverte apenas componentes específicos, ideal quando apenas um microsserviço apresenta problema (ex: falha no serviço de pagamento).
  2. Descreva como o versionamento semântico (semver) ajuda no processo de rollback.

    ✓ Resposta: O semver identifica claramente a versão anterior (ex: 1.2.3 -> 1.2.2) e indica o nível de mudança (major, minor, patch). Isso permite selecionar rapidamente a versão estável correta para rollback e entender o impacto das mudanças entre versões.
  3. Escreva um script bash que automatize o rollback de um deployment no Kubernetes para a revisão anterior (suponha que o deployment se chama "webapp").

    ✓ Resposta: 
    #!/bin/bash
kubectl rollout undo deployment/webapp
if [ $? -eq 0 ]; then
  echo "Rollback iniciado com sucesso."
else
  echo "Falha ao iniciar rollback."
  exit 1
fi
  4. Cite três ferramentas ou técnicas que podem ser usadas para testar rollback em um ambiente de staging.

    ✓ Resposta: 1. Chaos Monkey (Netflix) para induzir falhas. 2. Testes de smoke automatizados após rollback. 3. Ferramentas de IaC como Terraform para recriar ambientes e testar reversão.
  5. Em um cenário de blue-green deployment, como você implementaria um rollback automático se os health checks da nova versão falharem? Descreva os passos.

    ✓ Resposta: Passos: 1. Após deploy no ambiente verde, executar health checks. 2. Se falhar, alterar o balanceador de carga para direcionar tráfego apenas ao ambiente azul (versão anterior). 3. Enviar alerta e registrar o incidente. 4. Destruir ou marcar o ambiente verde como defeituoso para investigação.