Checklist pré-lançamento: 17 itens para verificar antes do deploy

Checklist pré-lançamento: 17 itens para verificar antes do deploy

Um deploy sem checklist é uma aposta. O código funciona em staging, mas o ambiente de produção tem seus próprios humores: variáveis de ambiente ausentes, permissões de banco de dados incorretas, cache que insiste em servir versão velha. Este checklist reúne 17 itens verificáveis, agrupados em categorias, para transformar o pré-lançamento em um processo rastreável, não em um pulo no escuro.

Use este checklist antes de qualquer deploy, seja uma feature nova, um hotfix ou uma migração de infraestrutura. A ordem importa: comece pelo ambiente e dados, depois vá para segurança, performance e testes. Cada item inclui o porquê, para que você não apenas marque a caixa, mas entenda o risco que está mitigando.

Ambiente e infraestrutura

1. Variáveis de ambiente foram revisadas? Produção raramente usa as mesmas credenciais que staging. Um DATABASE_URL apontando para o banco de desenvolvimento pode vazar dados reais ou simplesmente quebrar a aplicação. Verifique cada variável contra um template mestre.

2. O arquivo `.env` ou secrets manager está atualizado? Chaves de API vencidas, tokens revogados ou certificados expirados são causas comuns de falha silenciosa. Confira a data de validade de cada segredo armazenado.

3. O banco de dados de produção tem backup recente? Antes de qualquer migração, o dump deve existir e ser restaurável. Backup sem teste de restauração não é backup, é esperança.

4. A migração de banco de dados é reversível? Nem toda migração pode ser desfeita com rollback. Colunas renomeadas ou dados transformados exigem script de reversão manual. Se não houver reversão, o deploy vira ponto de não retorno.

Segurança e acesso

5. Portas e firewalls estão configurados para produção? Servidores de produção não devem expor portas de administração (22, 3306, 5432) para a internet. Verifique se o security group ou network policy restringe o acesso ao mínimo necessário.

6. CORS e CSP estão configurados corretamente? Um Access-Control-Allow-Origin: * em produção expõe a API a qualquer origem. Da mesma forma, uma Content Security Policy frouxa permite injeção de scripts. Confira as políticas contra o domínio real.

7. Tokens e chaves de API não estão hardcoded? Código que funciona em staging com chave fixa pode vazar credenciais em produção. Use um scanner automático (como git-secrets ou truffleHog) antes de mergear.

Dados e integridade

8. Dados sensíveis estão mascarados em logs? CPF, e-mail e cartão de crédito não devem aparecer em logs de produção. Verifique se o logger filtra campos sensíveis, especialmente se a aplicação usa bibliotecas de terceiros que logam requisições inteiras.

9. A limpeza de dados de teste foi feita? Registros de staging com dados fictícios (e-mails como [email protected], senhas fracas) podem poluir o banco de produção. Scripts de seed não devem rodar em ambiente real.

Performance e escalabilidade

10. Assets estáticos foram minificados e cacheados? Arquivos CSS e JS sem compressão aumentam o tempo de carregamento. Verifique se o build gera versões com hash no nome (cache busting) e se o CDN está apontando para a versão correta.

11. Consultas lentas foram identificadas? Uma query que roda em 200ms em staging pode levar 2s em produção com volume real. Use o slow query log do banco ou ferramentas como New Relic para identificar gargalos antes do deploy.

12. O cache está aquecido ou limpo? Cache de produção com dados velhos pode servir informações inconsistentes. Decida se o deploy exige limpeza total de cache ou aquecimento gradual (por exemplo, pré-carregar endpoints mais acessados).

Testes e validação

13. Testes automatizados passaram no branch de release? Não basta que os testes passem no branch de feature. O merge pode introduzir conflitos sutis. Execute a suíte completa no branch de release, incluindo testes de integração que tocam banco e APIs externas.

14. Testes de fumaça (smoke tests) estão prontos para rodar pós-deploy? Um script simples que verifica se a home carrega, se o login funciona e se a rota crítica retorna 200. Automatize isso em um pipeline de CI/CD para detectar falhas nos primeiros 30 segundos após o deploy.

Rollback e monitoramento

15. O plano de rollback está documentado? Saber como voltar atrás é tão importante quanto saber como ir para frente. Documente o comando ou script que reverte o deploy, incluindo a restauração do banco se necessário.

16. Alertas de monitoramento estão configurados? Métricas de erro (5xx), latência (p95 > 1s) e taxa de requisições devem disparar alertas imediatos. Se o monitoramento não cobre a nova feature, crie um dashboard específico.

17. O responsável pelo deploy está de plantão? Parece óbvio, mas deplives feitos por quem está de saída ou sem comunicação com o time geram retrabalho. Confirme que alguém com acesso e conhecimento está disponível para responder a incidentes nas próximas horas.

O erro mais comum

O erro mais frequente em pré-lançamento não é esquecer um item técnico, é tratar o checklist como burocracia. Equipes que marcam caixas sem entender o risco associado acabam ignorando sinais reais: um log suspeito, uma query que demorou mais que o normal, uma variável de ambiente que parecia certa. Checklist funciona quando cada item é verificado com intenção, não com automatismo.

Perguntas frequentes sobre checklist pré-lançamento

Quantos itens um checklist pré-lançamento deve ter?

Não há número mágico. O ideal é ter itens suficientes para cobrir riscos recorrentes, mas não tantos que virem ruído. Entre 10 e 20 itens é um intervalo comum. Mais que isso, o time tende a pular etapas.

Devo automatizar o checklist pré-lançamento?

Sim, sempre que possível. Testes automatizados, validação de variáveis de ambiente e verificação de portas podem rodar em pipeline de CI/CD. Itens que exigem julgamento humano (como revisão de dados sensíveis em logs) devem ficar manuais.

Qual a diferença entre checklist pré-lançamento e checklist de deploy?

O pré-lançamento foca em verificar o estado do sistema antes do deploy. O checklist de deploy cobre o passo a passo da execução (sequência de comandos, rollback). Ambos se complementam.

Com que frequência devo revisar o checklist?

A cada mudança significativa de infraestrutura ou processo. Se o time adotou um novo banco, provedor de nuvem ou framework, itens antigos podem ficar obsoletos e novos riscos surgem.

O que fazer se um item do checklist falhar? Devo abortar o deploy?

Depende da gravidade. Itens de segurança (portas abertas, chaves vazadas) e dados (migração irreversível sem backup) justificam abortar. Já uma query lenta pode ser tratada com monitoramento pós-deploy e correção agendada.

Checklist pré-lançamento substitui testes de aceitação?

Não. O checklist é uma camada de verificação operacional. Testes de aceitação validam se a funcionalidade atende aos requisitos de negócio. Ambos são necessários e atuam em momentos diferentes do ciclo.