Rollback no desenvolvimento: o que é, métodos e como funciona

O que é rollback no desenvolvimento

Rollback é uma operação que retorna o sistema a um estado estável anterior. No contexto do desenvolvimento, isso pode significar desfazer um commit no Git, reverter uma transação no banco de dados ou retornar a uma versão anterior de um aplicativo no servidor. O termo vem do inglês “rollback” e está firmemente estabelecido no vocabulário dos desenvolvedores de todas as plataformas.

A necessidade de um rollback surge quando uma nova alteração quebra a funcionalidade, causa erros ou falha nas verificações de qualidade. Em um processo de desenvolvimento bem organizado, o rollback não é um sinal de falha, mas um procedimento padrão incorporado ao fluxo de trabalho. Quanto mais rápida uma equipe puder reverter uma alteração problemática, menor será o impacto do bug nos usuários.

Diferentes ferramentas oferecem diferentes mecanismos de rollback: o Git oferece uma escolha entre revert seguro e reset destrutivo, os bancos de dados suportam rollback transacional, e os sistemas CI/CD podem alternar o tráfego entre versões. A escolha da abordagem depende do contexto e dos requisitos de preservação do histórico de alterações.

Git revert vs git reset: qual a diferença

Git revert é um método seguro de rollback que cria um novo commit desfazendo as alterações anteriores. O histórico permanece linear e todos os commits antigos são preservados. Esta é a única escolha correta para reverter em um branch compartilhado no qual vários desenvolvedores trabalham. Git revert não exclui o histórico — ele adiciona o fato do rollback como uma nova alteração.

Git reset move o ponteiro do branch atual para um commit específico, descartando todas as alterações subsequentes. Dependendo da flag — soft, mixed ou hard — o reset lida com o diretório de trabalho e o índice de forma diferente. O modo hard remove completamente as alterações do histórico, tornando-o perigoso para branches compartilhados e adequado apenas para trabalho local.

Quando usar revert

Revert é usado em branches compartilhados: main, develop, release. Ele preserva o histórico e permite que outros desenvolvedores entendam que uma alteração foi desfeita. Após o revert, você pode fazer git pull com segurança — o sistema não produzirá conflitos relacionados ao histórico reescrito. No trabalho em equipe, revert é o padrão por omissão.

# Desfazer o último commit criando um novo commit
git revert HEAD

# Desfazer um commit específico por hash
git revert a1b2c3d

Quando usar reset

Reset é apropriado em um branch local onde você ainda não publicou alterações. Se você estava experimentando e quer limpar completamente o histórico — reset hard fará isso. Em um branch local, você pode usar reset mixed para desfazer commits mas manter as alterações no diretório de trabalho para recommitar.

# Desfazer o último commit, manter alterações no diretório de trabalho
git reset HEAD~1

# Desfazer completamente — as alterações são removidas permanentemente
git reset --hard HEAD~2

Rollback em bancos de dados: transações e ACID

Rollback de transação é uma operação que desfaz todas as alterações feitas dentro da transação atual e retorna o banco de dados ao estado no início da transação. Isso garante a atomicidade — um dos quatro princípios ACID (Atomicity, Consistency, Isolation, Durability). Se ocorrer um erro em qualquer estágio da transação, um rollback é executado e os dados retornam ao seu estado original.

O mecanismo de rollback é implementado através do log de escrita antecipada (Write-Ahead Log, WAL). Antes de modificar uma página de dados, o SGBD escreve os valores antigos e novos no log. Durante o rollback, o sistema lê o log e restaura os valores originais para todas as páginas modificadas. Isso garante que mesmo em caso de falha de energia, a transação possa ser corretamente desfeita.

BEGIN TRANSACTION;

UPDATE accounts
SET balance = balance - 100
WHERE id = 1;

-- Rollback on error
ROLLBACK;

Savepoint: rollback parcial

Em transações longas, é conveniente usar savepoints — pontos de salvamento intermediários para os quais você pode reverter sem concluir toda a transação. Isso permite lidar com erros dentro de uma operação complexa sem perder o progresso em outras partes. Os savepoints são suportados pela maioria dos SGBDs relacionais: PostgreSQL, MySQL, Oracle.

SAVEPOINT sp1;

UPDATE orders SET status = 'cancelled'
WHERE id = 42;

ROLLBACK TO sp1;

Rollback em implantação: estratégias e ferramentas

Rollback de implantação é retornar um aplicativo em execução a uma versão anterior após uma implantação mal-sucedida. Esta é uma capacidade crítica para ambientes de produção: o tempo de recuperação (MTTR) afeta diretamente o SLA e a experiência do usuário. As plataformas modernas oferecem várias estratégias de rollback dependendo da arquitetura e dos requisitos de disponibilidade.

Blue-green deployment

Blue-green é uma estratégia onde dois ambientes idênticos funcionam simultaneamente: blue (versão atual) e green (nova versão). O tráfego muda para green após uma implantação bem-sucedida. Se a nova versão funcionar incorretamente, o comutador de tráfego retorna para blue. O rollback é realizado instantaneamente, sem reimplantação — basta alterar o roteamento.

Canary release com rollback automático

Canary deployment direciona uma pequena parte do tráfego para a nova versão e monitora métricas: taxa de erros, tempo de resposta, percentual de solicitações bem-sucedidas. Se as métricas piorarem, o sistema reverte automaticamente o canary e direciona todo o tráfego para a versão estável. Kubernetes e malhas de serviço (Istio, Linkerd) suportam essa estratégia nativamente.

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 10
  strategy:
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

Exemplos práticos de rollback no desenvolvimento

Vamos examinar três cenários típicos em que um desenvolvedor precisa reverter alterações. Cada cenário requer sua própria abordagem — desde um simples comando no terminal até um procedimento de várias etapas envolvendo CI/CD.

Cenário 1: commit acidental no main

Você acidentalmente enviou um commit com um bug para o main. Sua tarefa é reverter as alterações sem perder o histórico para a equipe. Use git revert para criar um commit de reversão e depois git push. Todos os membros da equipe verão o rollback e poderão continuar trabalhando sem conflitos. Este é o método mais seguro e transparente.

git checkout main
git pull origin main
git revert HEAD
git push origin main

Cenário 2: migração de banco de dados falha

Uma migração de banco de dados falhou e alguns dados estão corrompidos. Use rollback transacional no script de migração e restaure a partir do backup para alterações já aplicadas. Em um sistema bem projetado, cada migração é envolvida em uma transação — em caso de erro, o SGBD realiza automaticamente um rollback.

Cenário 3: implantação com bug crítico

Após implantar uma nova versão, você descobre que a autorização não está funcionando. Se você usa blue-green, o rollback é alternar o roteador de volta. Se for atualização contínua — o comando kubectl rollout undo retornará a versão anterior. Idealmente, o processo de rollback deve ser automatizado e não levar mais de um minuto.