Teste de realidade da produção
A IA mudou a aplicação. A atualização mudou os seus planos.
Trate como regressão, não como convite para mais dez prompts. Recupere primeiro; melhore depois.
01
O que aconteceu?
Atualizações geradas podem tocar ficheiros distantes, dependências, esquema e configuração. O diff é a fonte de verdade.
02
Porque é que isto acontece
- A edição incluiu alterações fora do pedido.
- Frontend, backend e base de dados ficaram dessincronizados.
- Uma migração só de ida tornou o rollback inseguro.
03
O que pode verificar
- Identifique a última versão boa e a primeira má.
- Compare código, lockfile, configuração e migrações.
- Antes do rollback, confirme se dados de produção mudaram.
NÃO TÉCNICO
Agora importam mais estas duas coisas do que o código.
Não precisa de ler a atualização para ajudar. Precisa de descrever o que mudou do seu ponto de vista.
- Pare de pedir mais correções sobre a atualização — isso só torna a linha do tempo mais difícil de desembaraçar.
- Escreva exatamente o que funcionava antes e o que deixou de funcionar depois da atualização.
- Verifique se alguém usou a aplicação, introduziu dados ou fez uma compra desde que a atualização foi publicada — isso afeta se um rollback é seguro.
- Preserve a versão anterior que funcionava, em vez de confiar na memória de como costumava ser.
Com essa linha do tempo, o Shipvise ou um programador pode isolar a alteração e decidir se um rollback, uma correção, ou ambos, é o caminho seguro de volta.
04
Como testar a correção em segurança
Faça a correção num branch separado, valide-a num staging próximo de produção e publique exatamente a versão aprovada. Mantenha disponível o último artefacto estável e um rollback testado.
05
Quando precisa de um programador
Chame um programador sénior quando estiverem em causa dados, autenticação, permissões, pagamentos ou infraestrutura, ou quando a causa não for explicável. O Shipvise junta staging, verificações automáticas, revisão por IA ou sénior, deploy controlado, hosting e rollback.
FAQ
Perguntas que as pessoas realmente fazem
Faço rollback já?
Com impacto relevante e rollback seguro conhecido, geralmente sim; verifique primeiro dados e efeitos externos.
Posso confiar no resumo da IA?
Use-o como orientação. O diff, os comandos e o commit publicado são a prova.
Como evito isto da próxima vez?
Use ramos pequenos, verificações automáticas, staging, diffs revistos, aprovação explícita e um rollback testado para cada lançamento em produção.
Posso voltar a uma versão anterior se não usar Git?
Verifique se a sua ferramenta de IA tem histórico de versões ou checkpoints, ou uma exportação ou deploy anterior que possa restaurar. Sem isso, peça à IA para mostrar exatamente o que alterou na atualização, e reverta essas alterações específicas em vez de adivinhar.
E se a atualização também alterou a base de dados, não só o código?
Nesse caso, um simples rollback do código não chega — reverter a versão da aplicação pode deixá-la dessincronizada dos dados. Verifique se a atualização correu alguma migração ou alterou a estrutura dos dados antes de reverter, e confirme que nada importante foi já escrito com a nova estrutura.
Devo pedir à IA para corrigir a sua própria atualização, ou recomeçar do zero?
Peça primeiro que explique o que alterou e porquê. Se a correção for pequena e conseguir verificá-la face ao problema original, uma reparação está bem; se a explicação não fizer sentido ou a alteração tocou em muitos ficheiros, voltar à última versão funcional costuma ser mais rápido e seguro.