Deploy do Trigger.dev e as pegadinhas
Fecha o Módulo 4 com a parte que mais nos custou tempo na prática: colocar Trigger.dev em produção. São pegadinhas chatas de descobrir e óbvias depois de conhecidas. Documentar isso é Lealdade a Dados aplicada ao nosso próprio histórico de erros.
Pegadinha 1 — Schedules só sincronizam no deploy
A mais importante: mudou o cron? Precisa fazer deploy. Alterar o agendamento no código e não deployar significa que o agendamento antigo continua valendo. Você jura que mudou pra 6h, mas roda às 8h porque o deploy não aconteceu. Toda mudança de schedule = deploy.
Pegadinha 2 — Pinar a CLI na versão do SDK
Rodar o deploy com uma versão da CLI diferente da versão do SDK gera erro confuso, difícil de diagnosticar. A regra: pinar a CLI à versão do SDK — npx trigger.dev@<versão> deploy. Não use a CLI global "qualquer versão".
Pegadinha 3 — Timezone no cron
Já apareceu no #25, mas merece repetição porque é fácil esquecer: cron sem fuso roda no fuso do servidor. Declare o agendamento como objeto { pattern, timezone } pra rodar no horário do Brasil. Senão, "o job das 6h" chega na madrugada.
Pegadinha 4 — Worktree sem node_modules
Detalhe do nosso fluxo: worktrees criados em .superset/worktrees vêm sem node_modules. Antes de buildar ou deployar a partir de um, rode pnpm install. Esquecer disso gera "erro de dependência" que não é erro de código.
O checklist de deploy de job
Antes de dizer "o job está no ar":
- Fez deploy depois de mexer no schedule? (senão, schedule velho)
- CLI pinada na versão do SDK?
- Cron com timezone correto?
- Job é idempotente (sobrevive a retry/redeploy)?
- Disparou manual e olhou o log pelo menos uma vez?
Vibe coding e a documentação das pegadinhas
A IA acelera escrever o job, mas não conhece as nossas pegadinhas operacionais — a menos que a gente conte. Por isso elas viram este post e entram no contexto do time. Conhecimento de operação documentado é o que evita o time inteiro tropeçar na mesma pedra.
Fechando a automação
Você viu o porquê (#24), o primeiro job (#25), resiliência e observabilidade (#26), IA em background (#27) e agora o deploy sem dor. Com automação no lugar, o próximo módulo entra no canal que mais fala com o cliente: o WhatsApp.
⚠️ Armadilha #28: mexer no schedule, testar local, ver funcionar e achar que está no ar. Sem deploy, produção segue com o agendamento antigo. "Funcionou na minha máquina" vale menos ainda pra job agendado.
Fim do Módulo 4 — Trigger.dev. Próximo: Módulo 5 (#29) — Mensageria com Evolution API.