Checklist de testes antes de deploy em produção: 15 itens essenciais

Subir código para produção sem um checklist de testes antes do deploy é como pular a revisão antes de enviar um e-mail importante: a chance de algo sair errado é alta. Este guia reúne 15 itens práticos, organizados por categoria, para você verificar antes de cada release. Use-o como roteiro, não como burocracia.

Ambiente e infraestrutura

1. Ambiente de staging idêntico ao de produção, Testar em um ambiente que não replica o real é o erro mais comum. Confira variáveis de ambiente, versões de banco e configurações de rede. Uma diferença de porta ou de memória alocada pode gerar falhas silenciosas.

1. Backup do banco de produção recente, Antes de qualquer alteração, tenha um snapshot do banco atual. Em caso de rollback, você restaura os dados sem perda. Programe backups automáticos antes do deploy.

1. Acesso à infraestrutura de rollback, Verifique se o procedimento de reversão está documentado e acessível. Não adianta ter backup se ninguém sabe como aplicar. Teste o rollback em staging ao menos uma vez.

Código e testes automatizados

1. Testes unitários passando, Cada funcionalidade nova deve ter ao menos um teste unitário. Execute a suíte completa antes do deploy. Um teste quebrado é sinal de que algo pode falhar em produção.

1. Testes de integração com serviços externos, APIs de pagamento, envio de e-mail, autenticação: todos precisam responder como esperado. Use mocks apenas em unitários; nos de integração, chame o serviço real (ou um sandbox).

1. Testes de regressão nas funcionalidades críticas, O que já funcionava continua funcionando? Priorize fluxos de login, checkout e exibição de dados. Automatize esses testes para rodar a cada commit.

Dados e migrações

1. Scripts de migração testados em staging, Rode a migração em staging com um volume de dados similar ao de produção. Erros de schema ou de tipo de coluna aparecem primeiro lá.

1. Verificação de integridade dos dados pós-migração, Após aplicar a migração, confira se registros não foram corrompidos. Uma consulta simples de contagem já revela inconsistências.

1. Dados de teste removidos, Nada de CPF fake ou e-mail de teste no banco de produção. Scripts de limpeza devem rodar antes do deploy final.

Segurança e permissões

1. Chaves de API e senhas em variáveis de ambiente, Nenhuma credencial hardcoded no código. Use um cofre de segredos (como Vault ou AWS Secrets Manager) e confira se as permissões estão corretas.

1. Teste de autenticação e autorização, Um usuário comum não pode acessar rotas de admin. Teste com perfis diferentes em staging antes de subir.

Monitoramento e observabilidade

1. Logs estruturados e sem dados sensíveis, Logs devem conter info útil para debug, mas nunca senhas ou tokens. Configure níveis de log (info, warn, error) antes do deploy.

1. Alertas configurados para erros críticos, Se algo quebrar em produção, você precisa saber em minutos. Vincule os logs a uma ferramenta de monitoramento (Datadog, New Relic, Grafana) e defina thresholds.

O erro mais comum

O maior erro ao usar um checklist de testes antes do deploy é tratar a lista como tarefa burocrática, marcando itens sem realmente verificar. Um "ambiente testado" vira um clique sem sentido se ninguém validou as variáveis de ambiente. O checklist só funciona quando cada item é executado com atenção.

FAQ

Quantos itens um checklist de deploy deve ter?

Não há número mágico. O ideal é cobrir ambiente, código, dados, segurança e monitoramento. Entre 10 e 20 itens é um bom intervalo para a maioria dos projetos.

Posso pular itens em deploys emergenciais?

Emergências acontecem, mas pular verificações aumenta o risco de um problema maior. Priorize os itens de rollback e backup, eles salvam o deploy.

Devo automatizar todo o checklist?

Sim, sempre que possível. Testes automatizados e scripts de validação reduzem erro humano. Mas mantenha itens manuais para verificações subjetivas, como "dados de teste removidos".

O checklist substitui o code review?

Não. O checklist verifica aspectos operacionais; o code review avalia lógica e arquitetura. São complementares.

Com que frequência atualizar o checklist?

Revise a cada nova funcionalidade que introduza um risco diferente. Se um bug apareceu em produção e não estava no checklist, adicione o item.