Deploy Checklist Verificação: 15 Passos Antes de Publicar

Fazer deploy é o momento em que o código encontra o usuário real. Sem uma rotina de verificação, cada release vira uma aposta: será que a migração de banco vai quebrar? A variável de ambiente secreta foi configurada? O health check vai responder? Este checklist organiza os 15 pontos críticos que você deve conferir antes de apertar o botão de publicar. Use-o como guia, não como burocracia, cada item existe porque alguém já queimou a mão com ele.

Código e Versionamento

1. Revisão de código (peer review) concluída. Toda alteração deve passar por pelo menos um par de olhos. Não é desconfiança: é a chance de pegar lógica duvidosa, nomes confusos ou aquele console.log esquecido antes de ir para produção.

2. Branch de destino correta. Parece óbvio, mas o número de deploys que foram para a branch errada é maior do que se admite. Confirme se o merge vai para main, master ou a branch de release definida no fluxo.

3. Commits associados a uma tarefa ou issue. Cada alteração deve ter rastreabilidade. Se algo quebrar, você quer saber qual ticket gerou a mudança e por quê.

Testes e Qualidade

4. Testes automatizados passando no pipeline. Unitários, integração e, se aplicável, fim a fim. Não vale só bater no verde: veja se a cobertura cobre o caminho crítico da funcionalidade nova.

5. Testes manuais no ambiente de staging. Automatização não pega tudo. Um smoke test rápido na UI ou na API de staging pode revelar problemas de layout, latência ou dados inconsistentes que o pipeline não capturou.

6. Verificação de performance básica. Se a feature nova adiciona uma consulta pesada ou um processamento extra, rode um teste de carga leve. Um endpoint que responde em 2s em staging pode virar 10s em produção com concorrência.

Infraestrutura e Configuração

7. Variáveis de ambiente e secrets configurados no ambiente de produção. Cheque se a chave de API, a string de conexão e os tokens estão no lugar certo. Um erro comum: esquecer de adicionar a variável nova e a aplicação cair com undefined.

8. Migrações de banco de dados testadas e reversíveis. Rode a migração em staging primeiro. E tenha um script de rollback da migração pronto, não confie que "só dar deploy de novo" resolve. Toda migração deve ter down.

9. Dependências externas (APIs, filas, CDN) acessíveis. Confirme se os endpoints de terceiros estão no ar e com as credenciais corretas. Uma API que mudou de versão sem aviso pode derrubar sua aplicação.

Deploy e Rollback

10. Plano de rollback documentado e testado. Saiba exatamente qual comando ou botão reverte a versão anterior. Teste o rollback em staging. Se o processo manual leva mais de 5 minutos, automatize.

11. Estratégia de deploy definida (blue-green, canary, rolling). Para aplicações críticas, evite deploy direto em todas as instâncias. Uma liberação gradual permite detectar problemas com um subconjunto de usuários antes do impacto total.

12. Health checks configurados e respondendo. O orquestrador (Kubernetes, ECS, etc.) usa health checks para saber se a aplicação está viva. Se o endpoint de saúde retornar 200 sem verificar a conexão com o banco, ele não está fazendo seu trabalho.

Pós-Deploy e Monitoramento

13. Logs e métricas sendo coletados. Após o deploy, confira se os logs da nova versão estão aparecendo no agregador (Datadog, New Relic, ELK). Sem logs, você está cego.

14. Alertas configurados para os principais indicadores. Erro 5xx, latência alta, taxa de requisições zerada. Defina limites que disparem notificação antes de o usuário reclamar.

15. Notificação à equipe sobre o deploy concluído. Um aviso no canal do Slack ou no e-mail da equipe evita que outro desenvolvedor tente fazer deploy em cima sem saber. Também cria um registro histórico.

O Erro Mais Comum

O erro mais frequente em deploys não é técnico, é a pressa. Aquele "só mais um hotfix" que pula o checklist, ou a migração feita diretamente em produção porque "é só uma coluna nova". A pressa transforma um incidente evitável em uma madrugada de rollback. Se o checklist parece longo demais para uma mudança pequena, pergunte: o custo de verificar é maior que o custo de quebrar produção? Na maioria das vezes, não é.

FAQ

O que fazer se o deploy quebrar em produção?

Ative o rollback imediatamente para a versão anterior estável. Depois, analise os logs para entender a causa raiz. Não tente corrigir em produção, corrija em staging, teste e faça um novo deploy.

Quantas pessoas devem revisar o código antes do deploy?

No mínimo uma, de preferência alguém que não participou da implementação. Para mudanças críticas (migração de banco, alteração de segurança), duas revisões são recomendadas.

Devo testar em staging idêntico à produção?

O ideal é sim. Se o orçamento não permite, pelo menos os dados de teste e as configurações de infra (versão do banco, sistema operacional) devem espelhar produção. Diferenças escondem bugs.

Como garantir que as variáveis de ambiente estão corretas?

Use um script de validação no pipeline que compara as variáveis declaradas no código com as configuradas no ambiente. Ferramentas como dotenv ou Vault ajudam a centralizar.

Qual a diferença entre blue-green e canary deploy?

Blue-green mantém dois ambientes completos; você troca o roteador de um para o outro. Canary libera a nova versão para uma fração dos usuários gradualmente. Ambos reduzem risco, mas canary permite observação mais granular.

Preciso de checklist mesmo para deploys pequenos?

Sim. O checklist não precisa ser seguido à risca toda vez, mas os itens críticos (variáveis de ambiente, migração, rollback) devem ser verificados sempre. Automatize o que puder para que a verificação seja rápida.