# Rollback Deploy: Guia Prático Sem Downtime em 6 Passos

> Rollback Deploy é um processo de reversão de versão de software sem interromper a disponibilidade do serviço. O guia prático apresenta seis passos objetivos para executar rollback com zero downtime, utilizando estratégias como blue-green, canary e restore de banco. A abordagem permite que times de engenharia retornem a versão anterior de forma segura, minimizando riscos operacionais e mantendo a estabilidade do sistema durante a reversão.

*Pingobox · Apps e Software · 27 de agosto de 2026 · Lavínia Castro*

Reverter um deploy não precisa derrubar o sistema. Este guia mostra estratégias de rollback sem downtime, com passos práticos para blue-green, canary e restore de banco. Ideal para times que querem voltar a versão anterior sem sustos.

Quando um deploy sai do controle, a primeira reação costuma ser restaurar o backup e rezar. Mas existe um caminho mais elegante: reverter a versão sem tirar o sistema do ar. Este guia mostra como fazer rollback de deploy sem downtime, com técnicas que times de plataforma usam na prática. Você vai precisar de acesso ao pipeline de CI/CD, permissão para alterar configurações de roteamento e, idealmente, um ambiente com réplicas da aplicação. O resultado esperado é voltar a versão anterior em minutos, com usuários percebendo no máximo uma lentidão breve.

## Passo 1: Escolha a estratégia de rollback antes do deploy

A decisão mais importante não acontece na hora do incidente. Ela vem antes, quando você define como o deploy será estruturado. As duas abordagens mais comuns para rollback sem downtime são blue-green e canary.

No blue-green, você mantém dois ambientes idênticos: o azul (versão atual) e o verde (nova versão). Quando o deploy vai para o verde, o roteador de tráfego aponta para ele. Se algo der errado, o roteador volta para o azul. O rollback é um flip de configuração, não um redeploy.

No canary, a nova versão recebe uma porcentagem pequena do tráfego, tipo 5% ou 10%. Se as métricas de erro não disparam, o tráfego aumenta gradualmente. Para reverter, basta zerar a porcentagem e direcionar tudo para a versão estável. A escolha entre uma e outra depende do seu risco: blue-green é mais simples, canary é mais granular.

**Erro comum:** tentar implementar a estratégia depois que o deploy já foi feito. Sem o ambiente preparado, o rollback vira um redeploy na hora errada.

## Passo 2: Garanta que a versão anterior esteja acessível

Parece óbvio, mas muita gente descobre que o artefato da versão anterior foi sobrescrito ou apagado. Antes de qualquer deploy, confirme que a imagem Docker, o pacote ou o binário da versão atual está armazenado em um registro imutável. Use tags que não mudam, como o hash do commit ou a data do build, em vez de tags móveis como "latest".

Se o seu pipeline usa versionamento semântico, mantenha as últimas versões disponíveis no registro por pelo menos 30 dias. Isso cobre a janela típica de detecção de problemas pós-deploy.

**Dica:** automatize um script que lista as últimas versões disponíveis e marca qual é a "candidata a rollback". Isso evita decisão manual sob pressão.

## Passo 3: Prepare o banco de dados para reverter sem perder dados

O maior risco de um rollback não é a aplicação, é o banco. Se a nova versão roda migrações que alteram o schema, voltar o código sem reverter o banco pode quebrar tudo. Duas abordagens ajudam:

- Migrações reversíveis: cada migration tem um método "down" que desfaz a alteração. Teste esse caminho em staging antes de precisar dele.
- Expandir e contrair: primeiro adicione a nova coluna sem remover a antiga (expand), depois faça o deploy do código que usa a nova, e só então remova a antiga (contract). O rollback fica mais fácil porque o banco suporta as duas versões ao mesmo tempo.

**Erro comum:** rodar migração destrutiva (DROP TABLE, DELETE) sem um plano de restore. Nesse caso, o rollback de aplicação não resolve nada.

## Passo 4: Automatize o processo de reversão no pipeline

Rollback manual é lento e propenso a erro. Configure o pipeline para ter um job de rollback que: aponta o roteador para a versão anterior, reverte as migrações se necessário e dispara alertas para o time. Ferramentas como Argo Rollouts, Jenkins ou GitLab CI têm suporte nativo ou plugins para isso.

O job deve ser disparado por um comando simples, tipo rollback --version v1.2.3, e registrar tudo em log. Isso reduz o tempo de reversão de horas para minutos.

**Dica:** inclua um health check automático após o rollback. Se a versão anterior também estiver com problema, o sistema avisa antes de você considerar o incidente encerrado.

## Passo 5: Monitore as métricas durante e após o rollback

Durante o rollback, acompanhe taxa de erro HTTP, latência e uso de CPU. Se a versão anterior estava saudável antes do deploy, ela deve voltar a esses níveis. Use dashboards com alertas para detectar qualquer desvio nos primeiros 10 minutos.

Um ponto que muitos esquecem: o rollback pode expor um bug que já existia na versão anterior, mas estava mascarado pela nova versão. Isso não é falha do processo, mas é bom saber antes de declarar vitória.

**Erro comum:** encerrar o monitoramento logo após o rollback. Problemas de dados podem levar horas para aparecer.

## Passo 6: Documente o que aconteceu e ajuste o processo

Depois do rollback, registre a causa raiz do problema, o tempo de reversão e o que funcionou. Isso vira insumo para melhorar o pipeline e evitar o mesmo incidente. Se o rollback foi necessário porque a versão nova tinha um bug, crie um teste de regressão no CI para pegar isso antes do deploy.

**Dica:** mantenha um runbook com os passos exatos de rollback para cada serviço. Quando o alarme tocar, ninguém precisa pensar.

## Checklist rápido: seu rollback sem downtime está pronto se

- Você escolheu blue-green ou canary antes do deploy.
- A versão anterior está armazenada com tag imutável.
- As migrações de banco são reversíveis ou usam expand-contract.
- Existe um job de rollback automatizado com health check.
- Você monitora métricas por pelo menos 30 minutos após a reversão.
- O runbook está atualizado e acessível ao time.

## FAQ: rollback de deploy sem downtime

### O que é rollback de deploy?

Rollback de deploy é o processo de reverter uma aplicação para uma versão anterior depois que um deploy novo causa problemas. O objetivo é restaurar a estabilidade rapidamente, e quando feito com estratégias como blue-green, não há interrupção do serviço para o usuário.

### Qual a diferença entre blue-green e canary para rollback?

Blue-green mantém dois ambientes completos e alterna o tráfego entre eles, tornando o rollback um simples flip. Canary envia uma fração do tráfego para a nova versão e permite reverter zerando essa fração. Blue-green é mais simples; canary é mais seguro para mudanças arriscadas.

### Como fazer rollback de banco de dados sem downtime?

Use migrações reversíveis ou a estratégia expand-contract, onde o schema suporta duas versões simultaneamente. Isso permite reverter a aplicação sem perder dados. Para migrações destrutivas, o restore de backup é necessário, mas causa indisponibilidade.

### Quanto tempo leva um rollback sem downtime?

Com automação, um rollback blue-green ou canary leva de 1 a 5 minutos, dependendo do tempo de health check. Sem automação, pode levar horas, porque envolve decisões manuais e possíveis erros de configuração.

### Preciso de ferramentas específicas para rollback sem downtime?

Ferramentas como Argo Rollouts, Spinnaker ou até scripts em CI/CD resolvem. O essencial é ter roteamento de tráfego configurável e um pipeline que suporte a troca de versão. Muitos times usam Kubernetes com ingress controllers para isso.

### O que fazer se o rollback também der errado?

Se a versão anterior também apresentar problemas, o próximo passo é restaurar de um backup completo ou investigar se o problema é de infraestrutura, não de código. Mantenha um plano de disaster recovery para esse cenário, com backups testados regularmente.

---

Fonte (canonical): https://www.pingobox.com.br/apps-e-software/rollback-deploy-guia-pratico-sem-downtime-em-6-passos/