Rollback de deploy: como planejar a volta atrás sem pânico

1. Por que rollback é parte essencial da estratégia de deploy

O mito do deploy perfeito persiste em muitas equipes de desenvolvimento. A crença de que "dessa vez vai dar certo" ignora uma verdade fundamental: sistemas complexos falham. Estatísticas da indústria mostram que aproximadamente 40% dos deploys em produção apresentam algum problema que exige ação corretiva. Aceitar essa realidade não é pessimismo — é maturidade técnica.

Rollback, hotfix e revert de commit são conceitos frequentemente confundidos, mas distintos:

  • Rollback: reversão completa de um deploy para uma versão anterior estável
  • Hotfix: correção emergencial aplicada diretamente em produção
  • Revert de commit: desfazer alterações específicas no controle de versão

Um rollback mal planejado causa mais danos que o problema original. Downtime prolongado, dados inconsistentes entre bancos e caches, e o estresse da equipe tentando resolver às pressas são consequências evitáveis com planejamento.

2. Estratégias de deploy que facilitam o rollback

Blue-green deployment

Esta estratégia mantém dois ambientes idênticos (blue e green). O tráfego é direcionado para um deles enquanto o outro recebe a nova versão. A reversão é instantânea: basta redirecionar o tráfego de volta.

# Exemplo de configuração de blue-green com balanceador NGINX
upstream app_blue {
    server 10.0.1.10:8080;
}

upstream app_green {
    server 10.0.2.10:8080;
}

server {
    listen 80;

    # Durante deploy normal, tráfego vai para blue
    location / {
        proxy_pass http://app_blue;
    }

    # Em caso de rollback, trocar para green
    # location / {
    #     proxy_pass http://app_green;
    # }
}

Canary deployment

Libera a nova versão para um subconjunto de usuários (ex: 5% do tráfego). Se métricas indicarem problemas, o tráfego é redirecionado para a versão estável.

# Script de canary com Kubernetes
kubectl set image deployment/app app=app:v2 --record
kubectl scale deployment/app-v2 --replicas=2
kubectl scale deployment/app-v1 --replicas=18

# Se problemas surgirem, rollback imediato
kubectl rollout undo deployment/app

Feature flags

Permitem desligar funcionalidades específicas sem reverter o deploy inteiro. Ideal para lançamentos graduais.

// Exemplo de feature flag em Node.js
const featureFlags = {
    novoCheckout: false, // Desligado durante rollback parcial
    relatorioV2: true
};

app.get('/checkout', (req, res) => {
    if (featureFlags.novoCheckout) {
        return handleNovoCheckout(req, res);
    }
    return handleCheckoutLegado(req, res);
});

3. Pré-requisitos técnicos para um rollback seguro

Versionamento de artefatos

Use tags imutáveis para imagens de contêiner e artefatos de build. Evite tags como latest — elas tornam impossível saber qual versão estava em produção.

# Boas práticas de versionamento
# Imagens Docker
docker build -t app:v1.2.3 .
docker tag app:v1.2.3 registry.example.com/app:v1.2.3

# Artefatos Java/Maven
mvn deploy -Dversion=1.2.3
# Armazenar em repositório com versão fixa

Migrações de banco de dados reversíveis

Toda migração deve ter um script forward (aplicar) e backward (reverter). Sem isso, rollback de aplicação sem rollback de banco gera inconsistência.

-- Migração forward: adicionar coluna
ALTER TABLE usuarios ADD COLUMN telefone VARCHAR(20);

-- Migração backward: remover coluna
ALTER TABLE usuarios DROP COLUMN telefone;

Snapshots de estado

Antes do deploy, capture snapshots de:
- Cache Redis/Memcached
- Filas de mensagens (RabbitMQ, SQS)
- Sessões de usuário ativas

# Snapshot de cache Redis antes do deploy
redis-cli SAVE
cp /var/lib/redis/dump.rdb /backups/pre-deploy-2025-01-15.rdb

# Snapshot de fila SQS (AWS)
aws sqs purge-queue --queue-url https://sqs.region.amazonaws.com/...
# Alternativa: drenar fila para arquivo

4. O plano de rollback: documentação e automação

Runbook de rollback

Documente passos claros, responsáveis e tempos estimados. Exemplo:

RUNBOOK: Rollback de deploy - Sistema de Pagamentos
===================================================
Versão: 1.2
Última atualização: 15/01/2025

GATILHOS PARA ROLLBACK:
- Erro 5xx > 5% por mais de 2 minutos
- Latência média > 2 segundos
- Alertas de integridade de dados

PASSOS:
1. NOTIFICAR equipe no canal #incidentes (2 min)
2. PARAR tráfego no balanceador (1 min)
3. RESTAURAR versão anterior via CI/CD (3 min)
4. EXECUTAR migração reversa de banco (5 min)
5. RESTAURAR cache do snapshot pré-deploy (2 min)
6. VALIDAR saúde do sistema (3 min)
7. RETOMAR tráfego gradualmente (5 min)

RESPONSÁVEIS:
- Decisão de rollback: Tech Lead
- Execução técnica: DevOps Engineer
- Comunicação: Product Manager

Scripts automatizados de reversão

Integre o rollback ao pipeline de CI/CD para execução com um clique.

# Script de rollback via GitHub Actions
name: Rollback Production

on:
  workflow_dispatch:
    inputs:
      version:
        description: 'Versão para reverter'
        required: true

jobs:
  rollback:
    runs-on: ubuntu-latest
    steps:
      - name: Restore version
        run: |
          docker pull registry.example.com/app:${{ github.event.inputs.version }}
          docker tag registry.example.com/app:${{ github.event.inputs.version }} app:production

      - name: Deploy stable version
        run: |
          kubectl set image deployment/app app=app:${{ github.event.inputs.version }}

      - name: Run database rollback
        run: |
          ./scripts/db_rollback.sh ${{ github.event.inputs.version }}

Testes periódicos

Agende testes de rollback em staging mensalmente. Documente resultados e ajuste o runbook.

# Teste agendado de rollback (cron job)
0 2 * * 0 /scripts/test-rollback.sh

# Script de teste
#!/bin/bash
echo "Iniciando teste de rollback em staging..."
kubectl set image deployment/app-staging app=app:broken-version
sleep 30
# Simular falha
curl -f http://staging.example.com/health || {
    echo "Falha detectada. Executando rollback..."
    kubectl rollout undo deployment/app-staging
    echo "Rollback concluído em $(date)"
}

5. Executando o rollback sem pânico

Gatilhos para decisão

Monitore métricas em tempo real. Decida pelo rollback quando:

ALERTAS CRÍTICOS:
- Taxa de erro HTTP: > 5% por 2 minutos consecutivos
- Latência p95: > 3 segundos
- Queda de conversão: > 10% comparado à média
- Alertas de integridade de dados disparados

Comunicação imediata

Notifique equipe e stakeholders sem demora:

MENSAGEM PADRÃO DE INCIDENTE:
🚨 Rollback em andamento para sistema [NOME]
Versão problemática: v1.2.3
Início: 14:32 UTC
Motivo: Taxa de erro 5xx em 12%
Responsável: @joao.devops
Previsão de conclusão: 14:45 UTC
Canal de acompanhamento: #incidentes

Passo a passo da reversão

Execute sem hesitação:

  1. Parar tráfego: redirecione todo tráfego para versão estável ou desative balanceador
  2. Restaurar versão anterior: execute script de rollback automatizado
  3. Reverter migrações de banco: aplique scripts backward
  4. Restaurar estado: carregue snapshots de cache e filas
  5. Validar saúde: execute testes de smoke e verifique métricas
  6. Retomar tráfego gradualmente: 10%, 25%, 50%, 100%

6. Pós-rollback: aprendendo com a falha

Análise de causa raiz (RCA)

Conduza a investigação sem blame culture. Foco no sistema, não nas pessoas.

TEMPLATE DE RCA:
================
Incidente: Rollback do deploy v1.2.3
Data: 15/01/2025
Impacto: 12 minutos de downtime parcial

CAUSA RAIZ:
- Migração de banco não testada com volume de dados real
- Ausência de validação de esquema antes do deploy

AÇÕES CORRETIVAS:
1. Adicionar validação de migração em staging com dados reais
2. Implementar pré-deploy checks automatizados
3. Atualizar runbook com checklist de verificação pré-deploy

RESPONSÁVEL: @maria.devops
PRAZO: 22/01/2025

Ajustes no pipeline de CI/CD

Implemente verificações automáticas para evitar recorrência:

# Adicionar ao pipeline pré-deploy
- name: Validate database migration
  run: |
    ./scripts/validate_migration.sh
    # Verifica se existe script backward para cada forward

- name: Load test with production data
  run: |
    ./scripts/load_test.sh --data-size=production

- name: Canary health check
  run: |
    ./scripts/canary_check.sh --duration=5m --error-threshold=2%

Melhoria contínua

Revise o runbook trimestralmente. Incorpore lições aprendidas de cada incidente. Automatize o que puder ser automatizado.

MELHORIAS IMPLEMENTADAS (Q1 2025):
✅ Rollback automatizado via CI/CD (redução de 15min para 3min)
✅ Testes de rollback semanais em staging
✅ Documentação de runbook revisada e aprovada pelo time
✅ Feature flags implementadas para releases críticas
✅ Monitoramento de métricas de negócio adicionado

Rollback não é sinal de fracasso — é evidência de que você tem um processo maduro. Quando o pânico cede lugar a um plano testado e documentado, sua equipe ganha confiança para deployar com mais frequência e segurança.

Referências