🚀 Deploy: sair do seu laptop

Se sua automação para de funcionar quando você fecha o laptop, ela ainda não é automação — é um script que você mesmo aciona.

É o teste mais rápido pra saber se algo já está pronto pra virar rotina de verdade ou ainda depende de você.

Execução local, dependência de presença, "rodar sozinho".

Nuvem é um computador de outra empresa, ligado o tempo todo, alugado por uso — sua automação roda lá, não no seu quarto.

Entender essa troca de "onde roda" é a base pra todo o resto da trilha fazer sentido.

Servidor remoto, disponibilidade 24/7, custo por uso.

Tarefas pontuais que você mesmo dispara ("organiza essa pasta agora") não precisam de deploy nenhum.

Publicar tudo na nuvem sem necessidade é trabalho extra e custo extra à toa.

Tarefa pontual vs. rotina recorrente.

O Claude Code escreve o código, o git leva pro repositório (GitHub), e uma plataforma de execução puxa e roda esse código na nuvem.

É o mapa completo que o módulo 4.2 vai detalhar passo a passo.

Repositório, plataforma de execução, pipeline.

O agente escreve o código; sua habilidade nesta trilha é ler o resultado e o log — não escrever TypeScript.

Tira o medo de "preciso virar programador" pra conseguir publicar automação de verdade.

Leitura de log, revisão, delegação de escrita de código.

Pipeline → dev/produção → segredos → retentativas → build prático → observabilidade.

Ver o caminho inteiro evita se perder no meio de um assunto novo e técnico.

Progressão da trilha, dependência entre módulos.

Você pede a tarefa em português, o agente escreve a "receita" em TypeScript — uma linguagem de programação usada por essas plataformas de execução.

Saber que essa etapa existe (e que não é você que escreve) tira o medo de "não sei programar".

TypeScript, task (tarefa em código), escrita assistida.

O git envia o código pro repositório — um cofre online (GitHub) que guarda todas as versões do seu projeto.

É essa etapa que a plataforma de execução observa: quando algo novo chega ali, ela reage.

git, repositório, push (o comando que envia).

Uma plataforma de execução (usamos o Trigger.dev neste curso) puxa esse código do repositório e o executa em servidores próprios, sem depender do seu computador.

É a estação onde a automação de fato "ganha vida própria".

Plataforma de execução, deploy, ambiente na nuvem.

Depois de rodar, a plataforma registra tudo num log que você acompanha pelo painel — sem precisar olhar o código.

É a habilidade que substitui "saber programar": saber ler esse retorno.

Log, painel, retorno de execução.

Em cada estação você pede, revisa e aprova — o trabalho pesado de escrever código fica com o agente.

Define exatamente onde entra sua atenção e onde você pode confiar no processo.

Revisão, aprovação, delegação supervisionada.

Escreve → envia → roda → registra. Um ciclo curto que se repete a cada mudança que você aprova.

Fixar esse ciclo é o que te deixa confortável pra publicar qualquer automação daqui pra frente.

Ciclo de deploy, repetibilidade.

Uma cópia da automação rodando separada, onde erros não afetam ninguém de verdade.

É onde você testa mudanças antes de deixá-las valer pra sério.

Ambiente de teste (dev/staging), cópia isolada.

O ambiente que roda de verdade, mexendo com dados reais e enviando coisas reais (e-mails, planilhas, mensagens).

Erros aqui têm consequência real — daí a importância de nunca testar direto nele.

Ambiente de produção, dado real, ação real.

O mesmo código roda nos dois ambientes; o que muda são as configurações e os segredos usados em cada um.

Você não precisa duplicar trabalho — só apontar pro ambiente certo antes de publicar.

Mesmo código, configuração por ambiente.

Só sobe pra produção depois de rodar sem erro no teste, algumas vezes, com dado parecido com o real.

Evita o susto de descobrir um bug já com dado real afetado.

Critério de promoção, teste repetido.

O modo plano (visto no módulo 0.5) pede pro agente mostrar o que vai fazer antes de agir — aqui, um bug em produção não é só feio, custa dado duplicado.

Ligar essa exigência específica pra mudanças em produção é o hábito que separa sessões seguras de sessões arriscadas.

Modo plano, revisão antes de agir, custo de erro em produção.

Testou no ambiente de teste, revisou o plano, conferiu os segredos do ambiente certo — só então promove.

Um checklist curto evita esquecer o passo que mais dói esquecer.

Checklist de promoção.

Qualquer informação que dá acesso a algo — chave de API, senha, token — e que não pode vazar pra ninguém.

Automação na nuvem sempre usa segredos pra falar com outros serviços — proteger isso é obrigatório.

Segredo, chave de API, token de acesso.

O arquivo .env guarda seus segredos localmente e fica de fora do que é enviado pro repositório.

Repositórios podem virar públicos por engano — um segredo vazado ali é praticamente irreversível.

Arquivo .env, .gitignore (lista do que nunca sobe).

As chaves são digitadas direto no painel da plataforma de execução, num campo protegido — nunca dentro do código.

É o único jeito de a automação acessar o segredo sem ele nunca passar pelo repositório.

Cadastro manual, campo protegido do painel.

O segredo de teste e o segredo de produção são cadastrados separadamente — cada ambiente com sua própria chave.

Assim um teste maluco nunca mexe com a conta ou o serviço real de produção.

Segredo por ambiente, isolamento de credenciais.

Rotacionar é gerar uma chave nova e desativar a antiga — o remédio pra um segredo exposto.

Saber o passo seguinte evita que o susto vire um problema maior.

Rotação de chave, revogação.

.env fora do repositório, chaves cadastradas nos dois ambientes, nada de segredo em print ou mensagem.

Um checklist curto vira hábito e evita o erro mais caro dessa trilha.

Checklist de segurança de segredos.

Conexão cai, serviço externo demora, servidor reinicia — falhas passageiras são normais na nuvem.

Aceitar que falha vai acontecer muda como você projeta a automação desde o início.

Falha transitória, instabilidade de rede.

Retentativa (retry) é a plataforma tentando de novo sozinha uma etapa que falhou, sem você precisar reiniciar tudo.

É o mecanismo que faz a automação sobreviver a falhas passageiras sem intervenção sua.

Retry, tentativa automática.

Se a automação inteira é um bloco só, uma falha no meio obriga a refazer tudo de novo — inclusive o que já tinha dado certo.

Quebrar em etapas pequenas faz com que só a etapa que falhou precise repetir.

Divisão em etapas, granularidade de tarefa.

Separar a etapa que busca um dado da etapa que grava esse dado evita que uma retentativa grave a mesma coisa duas vezes.

É o desenho que impede o problema mais comum de automação mal planejada: registro duplicado.

Separação buscar/gravar, prevenção de duplicidade.

Uma fila guarda tarefas pendentes em ordem, processando uma de cada vez — como uma fila de banco, mas de trabalho.

Filas evitam sobrecarga quando muitas tarefas chegam de uma vez.

Fila, processamento em ordem.

Tarefas pequenas + retentativa automática + buscar separado de gravar.

É o resumo que você pode pedir pro Claude Code aplicar sempre que desenhar uma automação nova.

Resiliência, princípios de desenho.

A primeira publicação deve ser pequena — algo como enviar um resumo diário por e-mail.

Começar simples reduz o número de coisas que podem dar errado no primeiro deploy.

Escopo pequeno, primeiro deploy.

Um prompt claro descrevendo o que a automação deve fazer, quando rodar, e o que ela precisa acessar.

Quanto mais claro o pedido, menos idas e vindas até o código ficar certo.

Prompt de task, agendamento.

Rodar a task no ambiente de teste, com um segredo de teste, e conferir o log.

É a etapa que evita levar um erro direto pro mundo real.

Teste em dev, verificação de log.

Repetir o cadastro do segredo, agora no ambiente de produção, com a chave real do serviço.

Sem isso, a automação publicada roda em produção mas falha por falta de credencial.

Segredo de produção, painel de configuração.

O comando de deploy sobe o código já testado pro ambiente de produção da plataforma.

É o momento em que a automação passa a existir de verdade, fora do seu computador.

Deploy, publicação em produção.

Depois do deploy, confirme no painel que a automação está agendada e espere a primeira execução automática acontecer.

Ver rodar sozinha, sem você tocar em nada, é a prova de que a trilha inteira funcionou.

Confirmação de agendamento, primeira execução automática.

Um painel (dashboard) é a página web da plataforma onde você vê todas as execuções da sua automação.

É o único lugar onde você "enxerga" o que está acontecendo na nuvem.

Painel, dashboard, lista de execuções.

O log é a lista, em ordem, de tudo que a automação foi fazendo — como um diário de bordo.

Ler log é a habilidade que substitui "saber programar" nesta trilha inteira.

Log, evento registrado.

Falhas costumam aparecer destacadas em vermelho no log — é o primeiro lugar a olhar quando algo deu errado.

Evita ler o log inteiro linha por linha quando o problema já está sinalizado.

Erro destacado, ponto de falha.

Copiar o trecho de log com erro e colar numa conversa com o agente pedindo pra explicar e corrigir.

Você não precisa entender o erro sozinho — precisa saber onde encontrá-lo e levar pro agente certo.

Diagnóstico assistido, correção guiada.

Muitas plataformas avisam por e-mail quando uma execução falha, sem você precisar entrar no painel toda hora.

É o que transforma observabilidade de "tarefa manual" em "hábito automático".

Alerta, notificação de falha.

Você saiu do "só funciona no meu laptop" pra "roda sozinho, com segredo protegido e um jeito de checar a saúde da automação".

É a base que sustenta as próximas trilhas, que assumem que sua automação já pode viver na nuvem.

Deploy, observabilidade, próxima trilha.