🚉 El pipeline en 4 estaciones

Piensa en una línea de producción con cuatro puestos de trabajo. En cada uno, alguien (o algo) hace una parte del trabajo y la pasa al siguiente. Nadie en el puesto 3 necesita saber hacer el trabajo del puesto 1 — solo necesita saber recibir lo que llegó y continuar. Así es exactamente como una automatización pasa de «solo funciona en mi computadora» a funcionar sola, las 24 horas del día.

¿Eres nuevo aquí? Pipeline es el nombre elegante para «cinta transportadora»: una secuencia de etapas automáticas, donde cada una alimenta a la siguiente, como cuando pides pan en una panadería y la masa pasa por el amasado, la fermentación y el horno sin que tengas que tocar nada en el medio.

Leyenda: fíjate en que tú solo apareces al principio (pedir la tarea) y al final (leer el resultado): las dos estaciones intermedias, git y Trigger.dev, funcionan sin que tengas que presionar ningún botón adicional.

Todo empieza cuando describes, en portugués, lo que quieres que ocurra automáticamente: «todos los días a las 8, busca la cotización del dólar y envíamela por correo electrónico». Claude Code traduce esa solicitud a TypeScript. ¿Eres nuevo aquí? TypeScript es un lenguaje de programación: una forma de escribir instrucciones que la computadora entiende, parecido a una receta de cocina muy detallada, pero en código. Tú no escribes esta receta. La escribe el agente. Tu parte es describir el plato que quieres, probar el resultado y pedir ajustes si hace falta.

Esto cambia por completo lo que necesitas aprender. Los programadores profesionales pasan años estudiando la sintaxis de lenguajes como TypeScript. Tú no harás eso, y no hace falta. Lo que desarrollarás es la habilidad de describir bien lo que quieres y reconocer si el resultado final (el comportamiento de la automatización, no el código que hay detrás) es correcto.

¿Eres nuevo aquí? git es un programa que guarda un historial de todas las versiones de tu código, como si cada cambio se guardara en una foto separada; puedes volver atrás en el tiempo si algo se rompe. Cuando Claude Code termina de escribir la automatización, usa git para «empaquetar» esa versión y enviarla a un lugar central: el repositorio. Repositorio es esa carpeta guardada en la nube que centraliza el código y su historial; en nuestro caso, alojado en GitHub, el servicio más usado del mundo para esto.

¿Por qué existe esta estación? Porque tu computadora no es el lugar donde vivirá la automatización. GitHub funciona como un armario compartido: el código sale de tu laptop, entra en ese armario y queda disponible para que cualquier servicio autorizado —en nuestro caso, Trigger.dev— lo busque.

¿Eres nuevo aquí? Trigger.dev é a plataforma de ejecución que usamos en este curso: un servicio en la nube que «escucha» el repositorio, detecta cuándo llega código nuevo, lo toma y lo ejecuta en una computadora que nunca se apaga — no es tu laptop, sino un servidor de la empresa Trigger.dev, encendido las 24 horas del día. Ese cambio de dirección (de tu laptop a un servidor siempre encendido) es lo que hace que la automatización sea realmente «automática».

Vale la pena ver en detalle el paso a paso de esta estación, porque es la parte más "mágica" del pipeline — y entender la secuencia despeja el misterio.

¿Eres nuevo aquí? Log es la lista de eventos que la automatización fue registrando mientras se ejecutaba, como un diario de navegación. «Empecé», «busqué el dato X», «lo conseguí», «envié el correo electrónico», «terminé» o, si algo salió mal, la línea exacta donde se detuvo y por qué. Trigger.dev muestra ese log en un panel (también llamado dashboard) en internet: una pantalla con la lista de todas las veces que se ejecutó tu automatización, con una señal verde (salió bien) o roja (hubo un problema) junto a cada ejecución.

Este es el corazón de este módulo: no necesitas entender el TypeScript detrás de la automatización para saber si funcionó. Abres el panel, miras el registro en portugués (o en inglés sencillo, como "task completed") y verificas: ¿se ejecutó a la hora correcta? ¿Hizo lo que debía? Si algo salió mal, el registro generalmente ya te indica dónde; en el módulo 4.7 (Observabilidad) aprenderás a leer esas señales con calma, incluidos los casos más confusos.

¿Eres nuevo aquí? task es como Trigger.dev llama a cada automatización individual: una unidad de trabajo con un nombre, un disparador (cuándo se ejecuta) y un código detrás. Llegó el momento de ver todo el pipeline en acción con el ejemplo más sencillo posible: una task que no hace nada arriesgado, solo demuestra que el flujo funciona de principio a fin.

Objetivo: pedirle a Claude Code que cree una task de prueba de Trigger.dev que consulte la hora actual e imprima un mensaje en el log — sin enviar correos ni tocar ningún dato real. Es el «hola, mundo» del deploy: si esa task aparece correctamente en el panel, las cuatro estaciones del pipeline están 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.)

Cómo verificar: después de que el agente termine, abre el panel (dashboard) de Trigger.dev en el navegador. Busca la task "teste-pipeline" en la lista: debería aparecer registrada, aunque todavía no se haya ejecutado. Dispárala manualmente (normalmente con un botón "Run" o "Test") y sigue el log en tiempo real: si aparece la línea con la hora y el mensaje "Pipeline funcionando!" y el estado queda en verde, las cuatro estaciones pasaron la prueba. Si aparece en rojo, copia el mensaje de error del log y pégaselo a Claude Code: lee su propio log tan bien como tú aprenderás a leerlo.