Deploy é uma mudança, não um botão

Quando um projeto sai da máquina local, ele entra em um sistema com usuários, dados, cache, DNS, certificados e dependências que não aparecem no editor. Tratar o deploy como uma mudança pequena ajuda a reduzir ansiedade e também evita o clássico "funciona aqui".

A ideia deste checklist não é criar burocracia. É deixar explícito o que precisa estar verdadeiro antes de apertar o botão.

Antes de publicar

  • Identifique a versão: registre o commit, a build ou o artefato que vai para produção. Se algo der errado, você precisa saber exatamente o que entrou.
  • Confira o ambiente: variáveis de produção, origem do banco, domínio, modo de cache e permissões devem estar separados do ambiente local. Nunca dependa de um .env esquecido no computador.
  • Faça uma verificação rápida de dados: uma migration destrutiva ou um seed rodando no lugar errado pode causar mais estrago que um bug visual.
  • Tenha um plano de volta: rollback pode ser um deploy anterior, uma troca de alias ou uma restauração de backup. O importante é que esteja descrito antes do incidente.

O que observar depois

A primeira página que abre não prova que o deploy deu certo. Eu costumo testar a rota inicial, uma rota dinâmica, um formulário, um arquivo estático e uma chamada de API. Também verifico o log do servidor e o status do banco.

Para cada sinal, pergunte: ele me diz que o usuário está conseguindo fazer a tarefa? Um gráfico bonito que não responde essa pergunta vira decoração.

Rollback sem vergonha

Rollback não é fracasso. É uma ferramenta de segurança. Se a mudança quebra o fluxo principal, volte para a versão estável, preserve o log do erro e só tente de novo depois de entender a causa. Isso é muito mais profissional do que insistir em um deploy quebrado por orgulho.

Um ritual que cabe na rotina

Antes: versão, variáveis, migration e backup. Durante: deploy observável e uma pessoa acompanhando. Depois: smoke test, logs e decisão de manter ou reverter. Em um projeto pequeno, esse ritual inteiro pode levar poucos minutos.

A discussão recente do Akita sobre fazer mais deploys com a mudança de premissa traz um ponto útil: ciclos curtos só são saudáveis quando existe feedback. O checklist é justamente o feedback mínimo que protege a velocidade.

Leitura relacionada: Parem de inventar desculpas e façam mais deploy — AkitaOnRails.