Colocar codigo em producao e um dos momentos mais criticos no ciclo de desenvolvimento. Um unico descuido pode derrubar o sistema, expor dados ou gerar retrabalho. Este checklist foi desenhado para ser usado minutos antes do deploy, independentemente da stack. Nao pule etapas: cada item existe porque alguem ja pagou o preco de ignora-lo.
1. Revisao de codigo por pares
Nunca deploye codigo que nao passou por code review. O segundo par enxerga erros de logica, esquecimentos de tratamento de erro e inconsistencias que o autor nao ve. Se o time e pequeno, use pair programming ou revisao assincrona com ferramentas como GitHub Pull Requests.
2. Testes automatizados passando
Antes do deploy, rode a suite completa de testes, unitarios, integracao e fim a fim. Nao confie apenas no "passou na minha maquina". Configure um pipeline de CI que bloqueie o merge se algum teste falhar. Testes de regressao sao os que mais salvam em producao.
3. Variaveis de ambiente e configuracoes
Verifique se todas as variaveis de ambiente necessarias estao definidas no ambiente de producao. Um erro comum e esquecer de configurar a URL do banco, chave de API ou nivel de log. Mantenha um arquivo .env.example atualizado e compare antes de cada release.
4. Backup do banco de dados
Antes de rodar migracoes ou scripts que alteram dados, faca um backup completo. Ferramentas como pg_dump (PostgreSQL) ou mysqldump (MySQL) permitem restaurar rapidamente. Programe backups automaticos diarios, mas o manual pre-deploy e a rede de seguranca extra.
5. Migracoes de banco testadas em staging
Rode as migracoes primeiro em um ambiente de staging identico ao de producao. Verifique se nao quebram dados existentes e se o rollback funciona. Migracoes destrutivas (como remover colunas) merecem atencao redobrada, considere fazer em duas etapas.
6. Dependencias e bibliotecas atualizadas sem breaking changes
Revise o arquivo de dependencias (package.json, requirements.txt, Gemfile) para garantir que nenhuma biblioteca foi atualizada para uma versao com mudancas quebradouras. Use lockfiles (package-lock.json, Gemfile.lock) para travar versoes e evitar surpresas.
7. Analise de seguranca de dependencias
Ferramentas como Snyk, Dependabot ou OWASP Dependency-Check varrem vulnerabilidades conhecidas nas bibliotecas do projeto. Nao deploye com alertas criticos abertos. Um pacote desatualizado pode ser a porta de entrada para um ataque.
8. Logs de debug e console.log desligados
Revise o codigo em busca de console.log, print, var_dump ou logs de debug que vazam informacao interna para o usuario final. Em producao, logs devem ter nivel INFO ou WARN, nunca DEBUG. Um log acidental pode expor dados sensiveis.
9. Tratamento de erros e fallbacks
Confira se todas as chamadas externas (API, banco, fila) tem tratamento de erro e fallback. Um sistema que falha silenciosamente e pior que um que exibe erro. Implemente circuit breakers e timeouts para evitar cascata de falhas.
10. Permissoes e autenticacao
Verifique se endpoints novos ou modificados estao protegidos pelo middleware de autenticacao e autorizacao corretos. Um erro comum e expor uma rota administrativa sem verificacao de papel (role). Teste com usuarios de diferentes niveis de acesso.
11. Headers de seguranca e HTTPS
Confirme que o servidor web (Nginx, Apache, CDN) envia headers como Content-Security-Policy, X-Frame-Options e Strict-Transport-Security. Toda comunicacao deve ser HTTPS. Use ferramentas como SecurityHeaders.com para auditar.
12. Monitoramento e alertas configurados
Antes do deploy, verifique se as metricas chave (latencia, taxa de erro, uso de CPU/memoria) estao sendo coletadas e se alertas estao ativos para thresholds aceitaveis. Sem monitoramento, voce descobre o problema quando o usuario reclama.
13. Plano de rollback testado
Nao basta ter um rollback, ele precisa funcionar. Teste o procedimento de reversao em staging: restore do banco, troca de versao do codigo, reativacao de versao anterior. Documente o passo a passo para que qualquer pessoa do time consiga executar em 5 minutos.
14. Feature flags para mudancas arriscadas
Se a feature e grande ou critica, entregue atras de uma feature flag. Assim, voce pode desliga-la sem um novo deploy. Ferramentas como LaunchDarkly ou flags simples no banco de configuracao permitem ativar/desativar em tempo real.
15. Comunicacao com o time
Avise o time sobre o deploy: horario, escopo, possiveis impactos e janela de rollback. Se o deploy envolve downtime, comunique com antecedencia. Um canal no Slack ou um calendario compartilhado evita surpresas.
O erro mais comum antes do deploy
O erro mais frequente e pular a verificacao de dependencias e logs de debug. Desenvolvedores confiam que "só mudou uma linha" e ignoram o checklist. Um console.log que expoe dados de usuario ou uma biblioteca com vulnerabilidade critica sao as causas mais comuns de incidentes pos-deploy. Nao confie na memoria: use o checklist.
FAQ, Checklist producao codigo
Qual a diferenca entre checklist de producao e checklist de codigo?
O checklist de producao foca no momento do deploy: variaveis, backup, seguranca, rollback. O checklist de codigo e usado durante o desenvolvimento: estilo, testes unitarios, cobertura. Ambos se complementam, mas o de producao e o ultimo filtro antes de ir ao ar.
Devo usar checklist manual ou automatizado?
O ideal e automatizar o maximo possivel no pipeline de CI/CD: testes, analise de seguranca, verificacao de variaveis. Porem, itens como backup manual e comunicacao com o time exigem acao humana. Use o checklist como documento de conferencia antes do clique final.
Quantos itens um checklist de producao deve ter?
Entre 10 e 20 itens, dependendo da complexidade do sistema. Muitos itens tornam o processo burocratico; poucos deixam lacunas. O importante e que cada item seja acionavel e verificavel em menos de 2 minutos.
Com que frequencia devo revisar o checklist?
Revise o checklist a cada 3 meses ou quando houver mudanca significativa na arquitetura (novo banco, novo provedor de nuvem, nova linguagem). O checklist deve evoluir com o sistema.
O que fazer se um item do checklist falhar?
Nao deploye ate resolver. Se a falha for em item nao critico (ex.: header de seguranca que pode ser configurado depois), documente e crie um ticket para correcao pos-deploy. Mas para itens como backup e variaveis de ambiente, pare o deploy.
Checklist serve para projetos pequenos?
Sim. Projetos pequenos tambem quebram em producao. Um checklist enxuto de 8 itens ja cobre o basico: backup, variaveis, logs, testes, rollback. O custo de seguir o checklist e muito menor que o custo de um incidente.