🚀 Deploy: salir de tu laptop

Si tu automatización deja de funcionar cuando cierras la laptop, todavía no es una automatización: es un script que tú mismo ejecutas.

Es la prueba más rápida para saber si algo ya está listo para convertirse en una rutina de verdad o si todavía depende de ti.

Ejecución local, dependencia de presencia, "ejecutar por sí solo".

La nube es una computadora de otra empresa, conectada todo el tiempo y alquilada según el uso: tu automatización se ejecuta allí, no en tu habitación.

Entender este cambio de «dónde se ejecuta» es la base para que todo lo demás de la ruta tenga sentido.

Servidor remoto, disponibilidad 24/7, costo por uso.

Las tareas puntuales que tú mismo inicias ("organiza esta carpeta ahora") no necesitan ningún deploy.

Publicar todo en la nube sin necesidad es trabajo y costo adicionales en vano.

Tarea puntual vs. rutina recurrente.

Claude Code escribe el código, git lo lleva al repositorio (GitHub) y una plataforma de ejecución obtiene ese código y lo ejecuta en la nube.

Es el mapa completo que el módulo 4.2 detallará paso a paso.

Repositorio, plataforma de ejecución, pipeline.

El agente escribe el código; tu habilidad en esta ruta es leer el resultado y el log, no escribir TypeScript.

Te quita el miedo a «tengo que convertirme en programador» para poder publicar automatizaciones de verdad.

Lectura de logs, revisión, delegación de escritura de código.

Pipeline → desarrollo/producción → secretos → reintentos → ejercicio práctico de build → observabilidad.

Ver el camino completo evita perderse en medio de un tema nuevo y técnico.

Progresión de la ruta, dependencia entre módulos.

Pides la tarea en portugués y el agente escribe la «receta» en TypeScript, un lenguaje de programación que usan estas plataformas de ejecución.

Saber que esta etapa existe (y que no tienes que escribirla tú) quita el miedo a «no sé programar».

TypeScript, task (tarea en código), escritura asistida.

git envía el código al repositorio: una caja fuerte en línea (GitHub) que guarda todas las versiones de tu proyecto.

Es esta etapa la que observa la plataforma de ejecución: cuando llega algo nuevo, reacciona.

git, repositorio, push (el comando para enviar).

Una plataforma de ejecución (usamos Trigger.dev en este curso) obtiene ese código del repositorio y lo ejecuta en sus propios servidores, sin depender de tu computadora.

Es la etapa en la que la automatización de verdad «cobra vida propia».

Plataforma de ejecución, deploy, entorno en la nube.

Después de ejecutarse, la plataforma registra todo en un log que puedes consultar en el panel, sin necesidad de revisar el código.

Es la habilidad que reemplaza «saber programar»: saber leer esta respuesta.

Log, panel, resultado de ejecución.

En cada etapa, tú pides, revisas y apruebas; el agente se encarga del trabajo pesado de escribir código.

Define exactamente dónde pones tu atención y dónde puedes confiar en el proceso.

Revisión, aprobación, delegación supervisada.

Escribe → envía → ejecuta → registra. Un ciclo corto que se repite con cada cambio que apruebas.

Fijar este ciclo es lo que te permite sentirte cómodo al publicar cualquier automatización de aquí en adelante.

Ciclo de deploy, repetibilidad.

Una copia de la automatización que se ejecuta por separado, donde los errores no afectan a nadie en la práctica.

Es donde pruebas los cambios antes de ponerlos en práctica de verdad.

Entorno de prueba (dev/staging), copia aislada.

El entorno que funciona de verdad, interactuando con datos reales y enviando cosas reales (correos electrónicos, hojas de cálculo, mensajes).

Los errores aquí tienen consecuencias reales; de ahí la importancia de nunca probar directamente en él.

Entorno de producción, datos reales, acción real.

El mismo código se ejecuta en ambos entornos; lo que cambia son las configuraciones y los secretos que se usan en cada uno.

No necesitas duplicar el trabajo: solo apuntar al entorno correcto antes de publicar.

El mismo código, configuración por entorno.

Solo pasa a producción después de ejecutarse sin errores en la prueba varias veces, con datos similares a los reales.

Evita la sorpresa de descubrir un bug cuando ya hay datos reales afectados.

Criterio de promoción, prueba repetida.

El modo de plan (visto en el módulo 0.5) le pide al agente que muestre lo que hará antes de actuar — aquí, un bug en producción no solo se ve mal, también cuesta datos duplicados.

Vincular este requisito específico con los cambios en producción es el hábito que separa las sesiones seguras de las arriesgadas.

Modo de planificación, revisión antes de actuar, costo de equivocarse en producción.

Probó en el entorno de prueba, revisó el plan y verificó los secretos del entorno correcto; solo entonces promueve.

Una lista de verificación breve evita olvidar el paso que más duele olvidar.

Lista de verificación de promoción.

Cualquier información que dé acceso a algo —clave de API, contraseña, token— y que no pueda filtrarse a nadie.

La automatización en la nube siempre usa secretos para comunicarse con otros servicios — protegerlos es obligatorio.

Secreto, clave de API, token de acceso.

El archivo .env guarda tus secretos localmente y queda fuera de lo que se envía al repositorio.

Los repositorios pueden hacerse públicos por accidente — un secreto filtrado allí es prácticamente irreversible.

Archivo .env, .gitignore (lista de lo que nunca se sube).

Las claves se escriben directamente en el panel de la plataforma de ejecución, en un campo protegido, nunca dentro del código.

Es la única forma de que la automatización acceda al secreto sin que este pase por el repositorio.

Registro manual en el campo protegido del panel.

El secreto de pruebas y el secreto de producción se registran por separado: cada entorno tiene su propia clave.

Así, una prueba disparatada nunca afecta la cuenta ni el servicio real de producción.

Secreto por entorno, aislamiento de credenciales.

Rotar es generar una clave nueva y desactivar la anterior: el remedio para un secreto expuesto.

Saber cuál es el siguiente paso evita que el susto se convierta en un problema mayor.

Rotación de clave, revocación.

.env fuera del repositorio, claves configuradas en los dos entornos, nada de secretos en capturas de pantalla ni mensajes.

Una lista de verificación breve se convierte en un hábito y evita el error más costoso de esta ruta.

Lista de verificación de seguridad de secretos.

La conexión se cae, un servicio externo tarda, el servidor se reinicia: las fallas pasajeras son normales en la nube.

Aceptar que habrá fallos cambia cómo diseñas la automatización desde el principio.

Falla transitoria, inestabilidad de red.

Un reintento (retry) es cuando la plataforma vuelve a intentar por sí sola una etapa que falló, sin que tengas que reiniciar todo.

Es el mecanismo que permite que la automatización supere fallas pasajeras sin que tengas que intervenir.

Retry, intento automático.

Si toda la automatización es un solo bloque, un fallo a mitad del proceso obliga a repetir todo desde el principio, incluso lo que ya había salido bien.

Dividirlo en etapas pequeñas hace que solo haya que repetir la etapa que falló.

División por etapas, granularidad de las tareas.

Separar la etapa que busca un dato de la etapa que lo guarda evita que un reintento guarde lo mismo dos veces.

Es el diseño que evita el problema más común de una automatización mal planificada: los registros duplicados.

Separación entre buscar y guardar, prevención de duplicados.

Una cola guarda las tareas pendientes en orden y procesa una a la vez, como una fila en el banco, pero de trabajo.

Las colas evitan la sobrecarga cuando llegan muchas tareas a la vez.

Cola, procesamiento en orden.

Tareas pequeñas + reintento automático + buscar por separado de guardar.

Es el resumen que puedes pedirle a Claude Code que aplique cada vez que diseñes una automatización nueva.

Resiliencia, principios de diseño.

La primera publicación debe ser pequeña, algo como enviar un resumen diario por correo electrónico.

Empezar con algo sencillo reduce la cantidad de cosas que pueden salir mal en el primer deploy.

Alcance pequeño, primer deploy.

Un prompt claro que describa qué debe hacer la automatización, cuándo debe ejecutarse y a qué necesita acceder.

Cuanto más claro sea el pedido, menos idas y vueltas habrá hasta que el código quede bien.

Prompt de tarea, programación.

Ejecutar la task en el entorno de prueba, con un secreto de prueba, y revisar el log.

Es la etapa que evita llevar un error directamente al mundo real.

Prueba en dev, verificación del log.

Repetir el registro del secreto, ahora en el entorno de producción, con la clave real del servicio.

Sin esto, la automatización publicada se ejecuta en producción, pero falla por falta de credenciales.

Secreto de producción, panel de configuración.

El comando de deploy sube el código que ya se probó al entorno de producción de la plataforma.

Es el momento en que la automatización empieza a existir de verdad, fuera de tu computadora.

Deploy, publicación en producción.

Después del deploy, confirma en el panel que la automatización esté programada y espera a que ocurra la primera ejecución automática.

Verla ejecutarse sola, sin que toques nada, es la prueba de que toda la secuencia funcionó.

Confirmación de la programación, primera ejecución automática.

Un panel (dashboard) es la página web de la plataforma donde ves todas las ejecuciones de tu automatización.

Es el único lugar donde puedes «ver» lo que está pasando en la nube.

Panel, dashboard, lista de ejecuciones.

El log es la lista, en orden, de todo lo que fue haciendo la automatización — como un diario de operaciones.

Leer logs es la habilidad que sustituye a «saber programar» en todo este recorrido.

Log, evento registrado.

Las fallas suelen aparecer resaltadas en rojo en el registro; es el primer lugar que debes revisar cuando algo sale mal.

Evita leer el registro entero línea por línea cuando el problema ya está señalado.

Error destacado, punto de falla.

Copiar el fragmento del log con el error y pegarlo en una conversación con el agente para pedirle que lo explique y lo corrija.

No necesitas entender el error por tu cuenta: necesitas saber dónde encontrarlo y llevárselo al agente adecuado.

Diagnóstico asistido, corrección guiada.

Muchas plataformas te avisan por correo electrónico cuando falla una ejecución, sin que tengas que entrar al panel a cada rato.

Es lo que transforma la observabilidad de «tarea manual» en «hábito automático».

Alerta, notificación de error.

Pasaste de «solo funciona en mi laptop» a «se ejecuta solo, con el secreto protegido y una forma de comprobar el estado de la automatización».

Es la base que sostiene las siguientes rutas, que dan por hecho que tu automatización ya puede vivir en la nube.

Deploy, observabilidad, próxima ruta.