🚉 O pipeline em 4 estações

Pensa numa esteira de produção com quatro postos de trabalho. Em cada um, alguém (ou alguma coisa) faz uma parte do trabalho e passa adiante. Ninguém no posto 3 precisa saber fazer o trabalho do posto 1 — só precisa saber receber o que chegou e continuar. É exatamente assim que uma automação sai do "só funciona no meu computador" e vira algo que roda sozinho, 24 horas por dia.

Novo aqui? Pipeline é esse nome chique pra "esteira": uma sequência de etapas automáticas, uma alimentando a próxima, do jeito que você pediu pão numa padaria e a massa passa por sova, fermentação e forno sem você tocar em nada no meio.

Legenda: repare que você só entra em cena no começo (pedir a tarefa) e no fim (ler o resultado) — as duas estações do meio, git e Trigger.dev, funcionam sem você precisar apertar nenhum botão extra.

Tudo começa com você descrevendo, em português, o que quer que aconteça sozinho — "todo dia às 8h, busca a cotação do dólar e me manda por e-mail". O Claude Code traduz esse pedido para TypeScript. Novo aqui? TypeScript é uma linguagem de programação — um jeito de escrever instruções que o computador entende, parecido com uma receita de cozinha bem detalhada, mas em código. Você não escreve essa receita. O agente escreve. Sua parte é descrever o prato que quer, provar o resultado, e pedir ajustes se precisar.

Isso muda completamente o que você precisa aprender. Programadores profissionais passam anos estudando sintaxe de linguagens como TypeScript. Você não vai fazer isso — e não precisa. O que você vai desenvolver é a habilidade de descrever bem o que quer e de reconhecer se o resultado final (o comportamento da automação, não o código por trás) está certo.

Novo aqui? git é um programa que guarda um histórico de todas as versões do seu código, como se cada alteração fosse salva numa foto separada — dá pra voltar no tempo se algo quebrar. Quando o Claude Code termina de escrever a automação, ele usa o git para "empacotar" essa versão e enviar para um lugar central: o repositório. Repositório é essa pasta guardada na nuvem que centraliza o código e o histórico dele — no nosso caso, hospedado no GitHub, o serviço mais usado do mundo para isso.

Por que essa estação existe? Porque o seu computador não é o lugar onde a automação vai morar. O GitHub funciona como um armário compartilhado: o código sai do seu laptop, entra nesse armário, e fica disponível para qualquer serviço autorizado — no nosso caso, o Trigger.dev — vir buscar.

Novo aqui? Trigger.dev é a plataforma de execução que usamos neste curso: um serviço na nuvem que "escuta" o repositório, percebe quando chegou código novo, pega esse código e roda ele num computador que nunca é desligado — não é o seu laptop, é um servidor da empresa Trigger.dev, ligado 24 horas por dia. É essa troca de endereço (do seu laptop para um servidor sempre ligado) que faz a automação virar de fato "automática".

Vale a pena ver o passo a passo dessa estação em detalhe, porque é a parte mais "mágica" do pipeline — e entender a sequência tira o mistério.

Novo aqui? Log é a lista de eventos que a automação foi registrando enquanto rodava — tipo um diário de bordo. "Comecei", "busquei o dado X", "consegui", "enviei o e-mail", "terminei" — ou, se algo deu errado, a linha exata onde travou e por quê. O Trigger.dev mostra esse log num painel (também chamado de dashboard) na internet — uma tela com a lista de todas as vezes que sua automação rodou, com um sinal verde (deu certo) ou vermelho (deu problema) do lado de cada execução.

Isso é o coração deste módulo: você não precisa entender o TypeScript por trás da automação para saber se ela funcionou. Você abre o painel, olha o log em português (ou em inglês simples, tipo "task completed"), e confere: rodou na hora certa? Fez o que devia? Se algo deu errado, o log geralmente já te diz onde — e no módulo 4.7 (Observabilidade) você vai aprender a ler esses sinais com calma, incluindo os casos mais confusos.

Novo aqui? task é como o Trigger.dev chama cada automação individual — uma unidade de trabalho com um nome, um gatilho (quando ela roda) e um código por trás. Chegou a hora de ver o pipeline inteiro em ação com o exemplo mais simples possível: uma task que não faz nada arriscado, só prova que a esteira funciona de ponta a ponta.

Objetivo: pedir ao Claude Code para criar uma task de teste do Trigger.dev que busca a hora atual e imprime uma mensagem no log — sem enviar e-mail, sem mexer em nenhum dado real. É o "alô, mundo" do deploy: se essa task aparecer com sucesso no painel, as quatro estações do pipeline estão funcionando.

Cria uma task simples do Trigger.dev pra mim, só pra eu testar o pipeline
de deploy. Ela deve:

1. Se chamar "teste-pipeline"
2. Não precisar de nenhum gatilho automático por enquanto — só rodar quando
   eu disparar manualmente pelo painel do Trigger.dev
3. Buscar a hora atual e imprimir no log uma mensagem tipo:
   "Task rodou às . Pipeline funcionando!"
4. Não mexer em nenhum arquivo, e-mail ou dado real — é só um teste

Depois de escrever o código, me explica em português o que você fez,
faz o commit e o push pro repositório, e me diz exatamente onde no painel
do Trigger.dev eu vou ver essa task pra poder disparar ela manualmente
e conferir o log.

(Se precisar de alguma chave de API pra configurar o projeto do
Trigger.dev, não escreve ela no código — me avisa que eu cadastro
separadamente. Minha chave de teste é SUA_CHAVE_AQUI, só como referência,
não deve aparecer em nenhum arquivo.)

Como verificar: depois que o agente terminar, abra o painel (dashboard) do Trigger.dev no navegador. Procure a task "teste-pipeline" na lista — ela deve aparecer registrada, mesmo sem ter rodado ainda. Dispare ela manualmente (normalmente um botão "Run" ou "Test") e acompanhe o log em tempo real: se aparecer a linha com a hora e a mensagem "Pipeline funcionando!" e o status ficar verde, as quatro estações passaram no teste. Se aparecer vermelho, copie a mensagem de erro do log e cole de volta pro Claude Code — ele lê o próprio log tão bem quanto você vai aprender a ler.