🍳 La cocina de pruebas y la cocina del restaurante abierto
Imagina un restaurante con dos cocinas. Una permanece cerrada al público: allí el chef prueba un plato nuevo, se pasa con la sal, lo tira y vuelve a intentarlo, sin apuro y sin nadie esperando el plato en la mesa. La otra cocina está abierta, con clientes sentados que esperan su comida. Nadie en su sano juicio prueba una receta nueva en la cocina que está atendiendo a clientes de verdad.
¿Eres nuevo aquí? Producción es el nombre que se le da al entorno que está realmente «en línea»: la automatización funcionando de verdad, modificando datos reales, enviando correos reales y ejecutando acciones que nadie puede deshacer con un «ctrl+Z». Es la cocina abierta.
¿Eres nuevo aquí? Staging (también llamado entorno de dev, de «desarrollo») es la cocina cerrada: una copia de la automatización que se ejecuta por separado, con datos ficticios o de prueba, donde puedes romperlo todo sin que ningún cliente real sufra las consecuencias.
💡 Concepto principal
La misma automatización se ejecuta en dos lugares diferentes. En uno es seguro equivocarse; en el otro, no.
- •Staging/dev: cocina cerrada, puedes equivocarte cuanto quieras.
- •Producción: cocina abierta, cliente sentado esperando el plato correcto.
⚠️ Por qué un bug en producción no es solo algo feo
Si un sitio tiene un pequeño error visual, lo corriges y nadie se da cuenta. La automatización es diferente: actúa. Un error en una automatización que se ejecuta en producción puede enviar el mismo correo dos veces a cientos de clientes reales, registrar el mismo pedido duplicado en tu sistema o generar un cobro que no debería existir. No puedes «deshacer» un correo que ya llegó a la bandeja de entrada de alguien.
Por eso la regla es simple y no tiene excepciones: todo cambio de código pasa primero por el entorno de staging/dev, se ejecuta allí, se revisa y solo después —con aprobación— pasa a producción. Probar directamente en producción es como si el chef probara la nueva receta sirviéndosela directamente al cliente de la mesa 4.
✗ Probar en producción
- ✗Un error de lógica envía correos duplicados a clientes reales
- ✗Una prueba mal hecha guarda registros duplicados en la base de datos real
- ✗No se puede «deshacer» una acción que ya se ejecutó en el mundo real
✓ Probar en staging
- ✓Ocurre el error, ves el log, lo corriges y vuelves a probar
- ✓Ningún cliente real se dio cuenta de que algo se rompió
- ✓Solo pasa a producción lo que ya se verificó que funciona
⚠️ Atención
Un bug en producción no es vergonzoso: le pasa a cualquier equipo. El problema es no tener un staging para detectar ese bug antes de que llegue al cliente. Esa es la red de seguridad que construye este módulo.
🔍 Los dos entornos por dentro
En la práctica, «dos entornos» no significa dos computadoras físicas diferentes. Es la misma plataforma de ejecución en la nube (Trigger.dev del módulo 4.2) ejecutando el mismo código dos veces, cada una con una variable de entorno diferente que indique cuál es cuál: una especie de credencial que dice "esto es staging" o "esto es producción".
Leyenda: el mismo código sale del repositorio y alimenta los dos entornos. Lo que cambia es la variable de entorno que indica «estoy en desarrollo» o «estoy en producción», y los datos que cada uno puede ver.
🔍 Por dentro
- Variable de entorno: una información guardada fuera del código (como una nota pegada en el panel) que le indica al programa «estás ejecutándote en dev» o «en producción», sin tener que reescribir nada.
- Clave de API separada por entorno: dev usa una clave de prueba; producción usa la clave real. Profundizamos en esto en el módulo 4.4 (Secretos).
✓ Variable correcta por entorno
- ✓Dev lee
AMBIENTE=devy usa datos de prueba - ✓Producción lee
AMBIENTE=producaoy usa datos reales
✗ Valor fijo en el código (hardcoded)
- ✗El código siempre apunta a producción, incluso cuando solo quieres hacer pruebas
- ✗Probar se vuelve sinónimo de arriesgar datos reales, porque no puedes «elegir» el entorno
🔁 El flujo de un cambio, del código a producción
Cuando el agente (Claude Code) cambia algo en tu automatización, ese código no pasa directamente a producción. Pasa por una cadena con etapas; cada etapa es una oportunidad de detectar errores antes de que lleguen al cliente.
El código cambia
El agente escribe o ajusta el TypeScript de la automatización (recuerda el módulo 4.2: tú lees y apruebas, no escribes a mano).
Probado en dev
La automatización se ejecuta apuntando al entorno de staging, con datos de prueba. Observas el log y compruebas si el resultado es el esperado.
Aprobado
Tú —la persona, no el agente— decides si el comportamiento es correcto y das luz verde para seguir adelante.
Promovido a producción
Solo ahora el mismo código pasa a ejecutarse apuntando a producción, modificando datos reales de verdad.
💡 Concepto principal
Observa que "probado" y "aprobado" son dos pasos separados: pasar la prueba no significa que ya se haya promocionado. La promoción siempre es una decisión explícita tuya.
🛠️ Construir: ejecutar la automatización apuntada a dev
¿Eres nuevo aquí? CLI es la sigla de «interfaz de línea de comandos»: el programa que ejecutas desde la terminal al escribir un comando, en lugar de hacer clic en botones de una pantalla. Trigger.dev tiene su propia CLI para ejecutar tus tareas.
Objetivo de esta tarea: pedirle al agente que ejecute la automatización ya apuntada explícitamente al entorno de desarrollo, sin dejarlo nunca «en automático». Pide algo como: "ejecuta la tarea de la automatización de notificaciones apuntando al entorno de desarrollo, no a producción". El comando que hay detrás normalmente se ve así:
AMBIENTE=dev npx trigger.dev@latest dev --env=staging \
--api-key=<isto voce troca>SUA_CHAVE_AQUI</isto voce troca>La variable AMBIENTE=dev y la flag --env=staging garantizan que la automatización solo vea el entorno de prueba. Nunca pegues una clave de API real en un prompt o en un archivo compartido; usa siempre un placeholder como SUA_CHAVE_AQUI hasta el momento de configurarla de verdad (el módulo 4.4 explica dónde se guarda realmente esa clave).
🔍 Cómo verificar
- 1. En el panel de Trigger.dev, comprueba que la ejecución aparece en la lista bajo el entorno "Development"/"Staging", no bajo "Production".
- 2. Abre el log (la lista de eventos registrados durante la ejecución, que se profundiza en el módulo 4.7) y confirma que los datos usados son los de prueba, no los reales.
- 3. Si la automatización envía algo (correo electrónico, mensaje), comprueba que haya llegado a una bandeja de prueba — nunca a un cliente real.
🧭 Consolidar: el modo plan vale más aquí que en cualquier ruta anterior
Conociste el modo plan allá en el módulo 0.5: el agente muestra lo que pretende hacer antes de actuar, y tú lo apruebas o lo ajustas. En ningún módulo anterior esto había sido tan importante como aquí, porque ahora «hacer» puede significar modificar producción, con datos de clientes reales y sin botón para deshacer.
La regla práctica para fijarlo: siempre que le pidas al agente que lleve un cambio a producción, oblígalo a usar primero el modo plan. Deja que te muestre exactamente qué va a cambiar y en qué entorno; solo después de leerlo, dile «adelante».
🎯 Concepto principal
- •Staging existe para que puedas equivocarte sin costo: úsalo siempre antes de tocar producción.
- •Modo de planificación antes de cualquier paso a producción, sin excepciones.
Verificación rápida (opcional): ¿por qué una automatización prueba primero en staging antes de pasar a producción?