# Checklist producao codigo: 15 passos antes do deploy

> O Checklist de Produção de Código reúne 15 passos essenciais antes do deploy, organizados em categorias de código, banco, segurança, infraestrutura e testes. O checklist deve ser utilizado antes de cada release para evitar retrocessos e garantir a qualidade da entrega.

*Bombou na Web · Tecnologia · 16 de julho de 2026 · Otávio Bensaúde*

Este checklist de producao de codigo reune 15 passos essenciais antes do deploy, organizados por categoria: codigo, banco, seguranca, infra e testes. Use antes de cada release para evitar retrocessos.

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.

---

Fonte (canonical): https://www.bombounaweb.com.br/tecnologia/checklist-producao-codigo-15-passos-antes-do-deploy/