Rollback que funciona: desfazer deploy sem perder dado

Todo time acha que tem rollback. Poucos já usaram sob pressão, e menos ainda usaram depois de uma migração de banco de dados. A conversa costuma terminar assim: "é só voltar a versão anterior" — e então alguém lembra que a versão anterior não funciona com o esquema que acabou de ser aplicado.

Rollback de código é trivial: a imagem antiga está no registry, sobe em minutos. Rollback de estado é o problema real, e ele precisa ser projetado antes do deploy, não descoberto durante o incidente.

O ponto sem volta

Toda mudança tem um momento a partir do qual voltar deixa de ser gratuito. Identificá-lo antecipadamente é a parte mais valiosa do planejamento:

A conclusão que orienta tudo: evite migração destrutiva no mesmo deploy que o código que depende dela. É a regra que preserva o rollback.

Expandir e contrair

É o padrão que torna rollback real. Toda mudança de esquema vira três deploys separados no tempo:

1. Expandir. Adicione o novo sem remover o antigo. Coluna nova, tabela nova, campo novo na mensagem. O código antigo continua funcionando porque nada que ele usa foi tocado.

2. Migrar o uso. O código novo passa a escrever nos dois — antigo e novo — e a ler do novo, com o antigo como reserva. Aqui há um deploy de código, reversível, porque o esquema comporta as duas versões.

3. Contrair. Semanas depois, quando não há mais código antigo em lugar nenhum e não há mais motivo para voltar, remova o que ficou obsoleto.

Renomear uma coluna, que parece uma operação de um minuto, vira: adicionar a nova, escrever nas duas, migrar os dados existentes, passar a ler da nova, e só então remover a antiga. É mais trabalho — e é a diferença entre uma mudança reversível e uma aposta.

A pergunta que vale fazer em toda revisão de pull request com migração: "se precisarmos voltar duas horas depois de aplicar isso, o que acontece?". Se a resposta não for imediata e tranquila, a migração precisa ser dividida.

O que fazer quando a migração é inevitavelmente destrutiva

Às vezes não dá para dividir. Nesse caso:

1. Backup imediatamente antes, verificado, com a restauração já cronometrada em ensaio.
2. Janela de manutenção declarada, porque o rollback vai custar indisponibilidade.
3. Script de reversão escrito e testado em cópia do banco de produção, com volume realista.
4. Critério de abortar definido antes e uma pessoa nomeada para decidir.
5. Comunicação preparada para o caso de precisar voltar.

O passo 3 é o que quase ninguém faz. Script de rollback nunca executado é um documento, não uma ferramenta.

Feature flags: o rollback mais rápido que existe

A forma mais eficiente de reverter não envolve deploy nenhum.

Com a funcionalidade nova atrás de uma chave, o deploy entrega código que está presente mas inativo. Você liga para 1% dos usuários, observa, aumenta. Se der problema, desliga — em segundos, sem pipeline, sem redeploy, sem tocar em infraestrutura.

Isso desacopla duas coisas que costumam ser confundidas: entregar código e liberar funcionalidade. Entregar passa a ser rotineiro e de baixo risco; liberar passa a ser uma decisão de produto, reversível.

A disciplina que mantém o benefício: flags têm dono e prazo de validade. Base com duzentas flags esquecidas é um emaranhado de caminhos de código que ninguém consegue testar — e vira um problema maior que o que resolvia. Remova a flag quando a funcionalidade estiver estável.

O caso especial: mensagens e filas

Mudança de formato de mensagem é onde rollback quebra de forma mais sutil, porque o efeito é assíncrono.

A versão nova publica mensagens em formato novo. Você reverte o código. Os consumidores voltam à versão antiga — e encontram na fila mensagens no formato novo, que não sabem processar. Elas falham, vão para a fila de descarte, e o dano só aparece depois.

O que evita:

• Consumidores toleram campo desconhecido e são atualizados antes dos produtores.
• Mudança de formato também segue expandir e contrair: adiciona campo novo, mantém o antigo, remove depois.
• Fila de descarte monitorada, com alerta. É frequentemente o primeiro sinal de que algo deu errado.
• Versionamento explícito da mensagem, para o consumidor saber o que recebeu.

O caso especial: cache

Se a versão nova mudou o formato do que é guardado em cache e você volta, a versão antiga lê dados que não entende.

A solução é barata: inclua a versão na chave do cache. Versões diferentes usam espaços diferentes, e o rollback simplesmente volta a usar as chaves antigas. O custo é um período de cache frio, que é infinitamente melhor que erro de desserialização em produção.

Rollback automático

Para serviços com bom monitoramento, a decisão pode ser do pipeline. O que precisa existir:

• Critérios objetivos, escritos antes: taxa de erro, latência em percentil alto, métrica de negócio.
• Janela de observação definida — tempo suficiente para o sinal aparecer, curto o bastante para limitar o dano.
• Comparação com a linha de base, não com um valor absoluto.
• Ação automática ao ultrapassar o limite.
• Notificação clara de que o rollback aconteceu e por quê.

Rollback automático só é seguro quando o rollback é seguro. Se houve migração destrutiva, automatizar a reversão pode causar mais dano que o problema original. A regra: automatize onde o rollback é de código puro; exija decisão humana onde há estado envolvido.

Ensaie

A lista de rollbacks que existiam no papel e falharam na prática é longa. Os motivos são sempre os mesmos e sempre banais: a imagem antiga tinha sido removida do registry pela política de limpeza; a configuração mudou e a versão antiga não lê o formato novo; o segredo foi rotacionado; ninguém sabia o comando.

O ensaio que resolve, em homologação, uma vez por trimestre:

1. Deploy da versão nova.
2. Rollback para a anterior.
3. Cronometre.
4. Valide que o sistema funciona de verdade, não só que subiu.
5. Documente os comandos exatos.
6. Corrija o que faltou.

Faça isso também depois de mudanças na política de retenção do registry — é a causa mais idiota e mais comum de rollback impossível.

O checklist antes de cada deploy

1. Esta mudança tem migração de banco? É aditiva?
2. A versão anterior funciona com o esquema depois desta migração?
3. Qual é o ponto sem volta?
4. A imagem anterior ainda está no registry?
5. A configuração da versão anterior ainda é válida?
6. Mudou formato de mensagem? Os consumidores toleram?
7. Mudou formato de cache? A chave tem versão?
8. Existe feature flag para desligar sem deploy?
9. Qual o critério objetivo para reverter?
10. Quem decide?
11. Alguém já executou este rollback alguma vez?

Onze perguntas, dois minutos, e elas separam o deploy tranquilo do deploy que vira noite em claro.

Erros comuns

• Migração destrutiva no mesmo deploy que o código que a usa.
• Renomear coluna diretamente em vez de expandir e contrair.
• Script de rollback escrito e nunca testado.
• Imagem anterior removida do registry pela política de limpeza.
• Configuração incompatível com a versão anterior.
• Formato novo de mensagem sem consumidores preparados.
• Cache sem versão na chave.
• Feature flags sem dono nem prazo, acumulando caminhos de código.
• Rollback automático em mudança com estado.
• Critério de reversão decidido durante o incidente.
• Ninguém nomeado para decidir.
• Nunca ter ensaiado.

Onde a Solvefy/Cloud entra

Rollback confiável é desenho, não ferramenta. Implantamos com o seu time o padrão expandir e contrair nas migrações, versionamento de mensagem e de cache, feature flags com governança, critérios objetivos de reversão no pipeline com rollback automático onde é seguro, e o ensaio trimestral cronometrado que garante que o caminho de volta continua existindo. Também revisamos a política de retenção do registry — a causa mais evitável de rollback impossível.

Quando foi a última vez que alguém do seu time reverteu um deploy de verdade? Diagnóstico gratuito, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.