1. Introducción: cerrar el ciclo de entrega

Descripción

Al terminar esta lección vas a poder describir el ciclo completo de entrega de un workflow —editar, exportar, commitear, probar, promover y, si hace falta, revertir— visto de punta a punta, como una sola cadena y no como pasos sueltos. Vas a tener el mapa de las ocho lecciones de este módulo, que es el que cierra la guía. Y vas a conocer el criterio que separa una demo que funciona en tu pantalla de un despliegue que una empresa puede operar sin ti: el criterio que este módulo entero existe para instalarte.

Esto importa porque hasta aquí construiste todas las piezas, pero todavía no las conectaste en el gesto que las vuelve un sistema entregable. Ya tienes el repositorio versionado (Módulos 2 y 3), los tres entornos aislados corriendo en Docker (Módulo 4) y una pasada de prueba en sandbox que corriste a costo cero (Módulo 5). Tienes las partes. Lo que falta es lo que un dueño del sistema hace con ellas todos los días: llevar un cambio probado de un entorno al siguiente sin romper producción, revisar cada cambio antes de que llegue, poder volver atrás cuando algo falla, y entregar todo el paquete de forma que otra persona lo pueda tomar. Ese es el trabajo de este módulo, y es exactamente el que las ofertas mejor pagadas describen cuando piden workflows "as version-controlled, documented JSON".

Conexión con el módulo: esta lección es el mapa del cierre. Aquí ves el ciclo completo en una sola imagen y conoces el entregable final que vas a construir a lo largo de las ocho lecciones. La lección 2 te enseña a promover —mover un workflow de staging a prod con la CLI—; la 3, a revisar cada cambio como un diff antes de promoverlo, incluidos los cambios que hizo una IA; la 4, a dejar que una IA construya workflows contra un entorno no-prod usando el servidor MCP de n8n, nunca directo en producción; la 5, a revertir con un runbook cuando algo se rompe; la 6, a decidir entre el Git nativo de Enterprise y el flujo CLI de esta guía; la 7, a poner un chequeo de CI que valida el JSON en cada commit y a armar el artefacto de portafolio. La lección 8 es el proyecto final: el entregable completo y defendible, que cierra el módulo y la guía.

El ciclo de vida de un workflow, visto entero

Vamos a mirar el trabajo de este módulo desde arriba, porque cuando ves la cadena completa, cada eslabón cobra sentido.

Piensa en cómo llega un plato nuevo a la carta de un restaurante grande, uno de esos que tienen varias cocinas. No lo inventan directo en la cocina que sirve a los comensales. El proceso es más cuidadoso, y por buenas razones.

Primero, el chef prueba la idea en la cocina de pruebas: un espacio aparte, con ingredientes de práctica, donde puede equivocarse sin que nadie se lleve un plato malo. Cuando la receta le convence, la escribe en el recetario del restaurante, con la fecha y el motivo del cambio. Después la pasa a la cocina de ensayo, que imita las condiciones de la cocina real —el mismo horno, el mismo ritmo— para ver si aguanta la presión. Solo cuando pasó las dos cocinas, y alguien con criterio revisó la receta escrita y la aprobó, la receta llega a la cocina principal, la que le cocina a los clientes que pagan. Y si esa noche algo sale mal —la receta nueva no funcionó como en el ensayo—, el jefe de cocina no improvisa: saca la receta anterior del recetario, la que sí funcionaba, y vuelve a ella en minutos. El recetario guardó la versión buena; nunca la perdió.

Ese recorrido —cocina de pruebas, recetario, cocina de ensayo, cocina principal, y una salida de emergencia hacia atrás— es, casi punto por punto, el ciclo de vida de un workflow profesional. Cámbiale los nombres:

• La cocina de pruebas es tu entorno dev: donde construyes y rompes sin miedo.
• El recetario es tu repositorio cumbre-automations: donde vive cada versión con su fecha, su autor y su motivo.
• La cocina de ensayo es staging: donde pruebas el cambio en condiciones parecidas a las reales.
• La cocina principal es prod: donde corren los pedidos de verdad de Cumbre.
• La salida de emergencia es el rollback: volver a la última versión buena que el recetario guardó.

Los tres primeros módulos de esta guía te dieron el recetario. El Módulo 4 te dio las cocinas. El Módulo 5 te enseñó a probar en la cocina de pruebas y en la de ensayo. Este módulo te enseña el paso que junta todo: cómo una receta viaja de una cocina a la siguiente de forma controlada, cómo se revisa antes de servir, y cómo se deshace si sale mal. Ese viaje tiene un nombre técnico, y es la palabra que gobierna este módulo: promoción.

El pipeline completo

Pongamos la cadena en una sola imagen, porque la vas a tener en la cabeza los seis módulos condensados aquí. Este es el ciclo que un cambio recorre, de la idea a producción y, si hace falta, de vuelta:

  editar        exportar       commit        probar        promover       revertir
    │              │             │             │              │              │
  en dev    →   con la CLI  →  a Git    →   en sandbox  →  a staging   →  al último
 (o con IA        a JSON       (recetario)   y en staging   y a prod        JSON bueno
  vía MCP)        normalizado                 (Módulo 5)     (este módulo)   (este módulo)
    │              │             │             │              │              │
 Módulo 4     Módulos 2-3    Módulos 2-3    Módulo 5      Módulo 6        Módulo 6

Léelo de izquierda a derecha como el camino feliz —un cambio que nace en dev, se versiona, se prueba y llega a prod— y de derecha a izquierda como la red de seguridad —cuando algo falla en prod, vuelves al último JSON bueno del recetario—. Las primeras cuatro columnas ya las sabes hacer. Las dos últimas, promover y revertir, son el corazón de este módulo.

Fíjate en un detalle de la primera columna: dice "editar en dev, o con IA vía MCP". Esa es una novedad de este módulo que quizás no esperabas. n8n 2.0 permite que un asistente de IA —Claude, ChatGPT, Cursor— construya y edite workflows dentro de tu instancia, a través de una tecnología que se llama MCP. Es potente y es peligroso a la vez, y por eso las lecciones 3 y 4 le dedican atención entera: la IA puede construir, pero nunca directo en producción. Construye en dev, Git registra el cambio, un humano lo revisa, y solo entonces se promueve. Los entornos aislados que montaste en el Módulo 4 son, justamente, la red que hace seguro dejar que una IA toque tus workflows.

Ejemplo trabajado: un cambio de order-triage, de la idea a producción

Sigamos un cambio concreto por todo el pipeline, para que la cadena deje de ser abstracta. No vamos a correr comandos —eso es de las lecciones que siguen—; vamos a ver el recorrido, para que cuando aprendas cada eslabón por separado sepas dónde encaja.

El cambio: el equipo de Cumbre decide que los pedidos de más de 5000 pesos ya no se aprueben solos, sino que vayan a revisión manual. Una regla de negocio nueva, pequeña, que toca order-triage. Veamos su viaje.

Nace en dev (editar). Alguien —una persona en el editor, o una IA vía MCP apuntada a dev— agrega el umbral y el paso de revisión manual en el entorno de desarrollo. Aquí se prueba a mano, se rompe, se ajusta. Nada de esto toca producción: dev usa datos sintéticos y credenciales de prueba, así que equivocarse no cuesta nada. Qué esperar: el workflow modificado corre en dev y hace lo nuevo.

Se versiona (exportar y commit). El cambio se exporta con la CLI a un JSON normalizado y se commitea en cumbre-automations con una nota clara: "send orders over 5000 to manual review". Ahora el cambio existe en el recetario, con su fecha y su motivo. Qué esperar: un commit nuevo en el historial; el git diff muestra solo las líneas del umbral y el nodo de revisión, nada más.

Se prueba (en sandbox y en staging). El cambio se promueve a staging y se corre la pasada de prueba del Módulo 5: datos sintéticos, dry run, aserciones. Se confirma que los pedidos de más de 5000 caen en revisión manual y los demás siguen su curso. Qué esperar: la pasada queda verde; el cambio se ganó el paso a producción.

Se revisa (el diff, antes de promover). Antes de tocar prod, un humano lee el diff una última vez: ¿hace lo que dice?, ¿cambió algo inesperado?, ¿se coló un secreto? El diff es aburrido en el buen sentido —solo el umbral—, así que se aprueba. Qué esperar: un pull request aprobado, con registro de quién y cuándo.

Se promueve (a prod). El JSON revisado se importa en la instancia de prod, llega inactivo, se verifica que las credenciales reales resuelven, y se activa a mano, mirando. Qué esperar: order-triage empieza a procesar los pedidos reales de Cumbre con la regla nueva.

Y si algo falla (revertir). Supón que, ya en prod, aparece un efecto que staging no reprodujo. El runbook de rollback vuelve al último JSON bueno del repo y lo re-importa en minutos. Qué esperar: prod corriendo de nuevo la versión que funcionaba, mientras el cambio problemático espera en dev para depurarse con calma.

Fíjate en lo que este recorrido tiene y una demo no: en cada eslabón hubo una red —una prueba, una revisión, una salida de emergencia—. El cambio no saltó de la cabeza de alguien a producción; recorrió una cadena de confianza donde cada paso se ganó el siguiente. Ese recorrido completo es lo que este módulo te enseña a ejecutar, eslabón por eslabón.

Qué separa una demo de un despliegue

Antes de entrar en la técnica, vale la pena nombrar el criterio que este módulo persigue, porque es el que un entrevistador usa para saber de qué lado de la línea estás.

Una demo es un workflow que funciona cuando tú lo corres, en tu máquina, mirándolo. Es una habilidad real —construir algo que funciona no es poco—, pero es frágil de una forma específica: depende de ti, del momento, y de que nada cambie. Si te preguntan "¿y cómo llevas esto a producción?", la demo no tiene respuesta.

Un despliegue es el mismo workflow, pero envuelto en las garantías que lo hacen operable por otros y recuperable cuando falla. La diferencia no está en lo que el workflow hace; está en todo lo que lo rodea. Un despliegue responde, sin dudar, cinco preguntas que la demo deja en el aire:

1. ¿Cómo llega un cambio a producción? No "lo edito en prod", sino "lo pruebo en dev, lo verifico en staging, y lo promuevo a prod con un procedimiento repetible". Eso es la lección 2.
2. ¿Quién revisó este cambio antes de que llegara? No "yo lo miré", sino "hay un diff que alguien aprobó, y queda registro de quién y cuándo". Eso es la lección 3.
3. Si una IA tocó el workflow, ¿cómo sabes que no rompió nada? No "confío en la IA", sino "la IA solo toca dev, y su cambio pasa por el mismo diff y la misma revisión humana que cualquier otro". Eso es la lección 4.
4. Si el cambio rompe producción, ¿en cuánto tiempo vuelves atrás? No "intento acordarme de qué toqué", sino "sigo el runbook: vuelvo al último JSON bueno del repo y lo re-importo, en minutos, con pasos que otra persona también podría seguir". Eso es la lección 5.
5. ¿Cómo garantizas que el JSON entregado está bien formado? No "lo revisé a ojo", sino "un chequeo automático valida el JSON en cada commit, sin que nadie tenga que acordarse". Eso es la lección 7.

Cada una de esas preguntas es una lección de este módulo. Y cada respuesta es una decisión de diseño que vas a poder señalar con el dedo en tu propio repositorio al terminar. Ese es el punto: al final de este módulo no vas a decir que sabes entregar como un profesional; vas a tener el artefacto que lo demuestra.

El entregable final que vas a construir

Este módulo cierra la guía, así que conviene ver desde ya hacia dónde apunta todo. El proyecto de la lección 8 no es un ejercicio nuevo: es la integración de los seis módulos en un solo entregable, empaquetado exactamente como el mercado lo pide. Cuando termines, vas a tener un repositorio de GitHub —cumbre-automations— que contiene:

• El workflow order-triage exportado por CLI, normalizado para diffs limpios y documentado con un README de handoff, con las credenciales fuera del repo (Módulos 2 y 3).
• Tres entornos aislados por Docker Compose —dev, staging, prod—, cada uno con su propia N8N_ENCRYPTION_KEY y sus credenciales de prueba o de producción (Módulo 4).
• Una pasada de prueba en sandbox ejecutada a costo cero: datos sintéticos, llaves sandbox, dry run, replay de ejecución y aserciones con el nodo Evaluation usando modelos locales (Módulo 5).
• Un runbook de promoción y rollback: los pasos numerados para llevar un cambio a producción y para revertirlo bajo presión (lecciones 2 y 5 de este módulo).
• Un chequeo de CI en GitHub Actions que valida el JSON del workflow en cada commit, a costo cero (lección 7).

Ese paquete es el artefacto de portafolio. Es defendible en una entrevista, funciona como prueba de que no solo construyes workflows sino que los versionas, pruebas, promueves y operas, y se produce entero sin pagar una suscripción —la única cuenta que abres es la de GitHub, que es gratis para un repositorio como este—. Todo el camino por defecto de esta guía es self-hosted Community a costo cero, y este módulo no es la excepción.

Guárdate esa lista, porque la lección 8 la construye fase por fase. Todo lo que aprendes en las lecciones 2 a 7 es una pieza de ese entregable.

El artefacto crece contigo, lección a lección

Vale la pena ver el entregable no como algo que aparece de golpe en la lección 8, sino como algo que has estado construyendo desde el Módulo 1 sin darte cuenta. Cada módulo le agregó una capa, y este módulo le agrega la última —la de operación—, que es justamente la que responde las preguntas de entrevista más difíciles.

Piénsalo como una casa que se construye por etapas. Los Módulos 2 y 3 pusieron los cimientos y las paredes: el repositorio versionado y documentado. El Módulo 4 instaló las habitaciones separadas: los tres entornos aislados. El Módulo 5 probó que la plomería no gotea: la pasada de sandbox. Y este módulo pone lo que hace la casa habitable por otros: las instrucciones de cómo operarla (el runbook de promoción), qué hacer en una emergencia (el runbook de rollback), y la alarma que vigila sola (el chequeo de CI). Una casa sin esa última capa se ve terminada, pero nadie más que su constructor sabe vivir en ella. Con la capa de operación, cualquiera puede tomarla.

Esto tiene una consecuencia práctica para cómo lees el módulo: no estás empezando un proyecto nuevo, estás terminando el que vienes armando toda la guía. Cada lección de aquí en adelante no es una técnica suelta; es una pieza que encaja en un entregable que ya existe a medias. Cuando en la lección 5 escribas el runbook de rollback, no lo escribes en el vacío: lo escribes para tu cumbre-automations, el mismo que documentaste en el Módulo 3 y desplegaste en el Módulo 4. Esa continuidad es deliberada, y es lo que hace que el proyecto final se sienta como un cierre natural y no como un examen sorpresa.

Dónde estás parado ahora

Vale la pena situarte con precisión, porque este módulo asume un punto de partida concreto y construir sobre él es lo que lo hace posible.

A estas alturas de la guía, tú ya tienes —o estás siguiendo el caso de Cumbre como si tuvieras—:

Lo que ya tienes	De qué módulo viene	Por qué lo necesitas aquí
El repositorio cumbre-automations versionado	Módulos 2 y 3	Es la fuente de verdad desde donde promueves y a donde vuelves al revertir
El workflow order-triage normalizado y documentado	Módulo 3	Es lo que vas a promover, revisar y, si hace falta, revertir
Tres entornos dev/staging/prod aislados por Docker	Módulo 4	Son las "cocinas" entre las que promueves; sin ellos no hay a dónde promover
Credenciales por entorno (prueba vs producción)	Módulo 4	Al promover, hay que mapear las credenciales del entorno de destino
Una pasada de prueba en sandbox ejecutada	Módulo 5	Es lo que valida un cambio antes de que lo promuevas a prod

Si te falta alguna de esas piezas porque saltaste un módulo, este es el momento de volver a completarla, porque este módulo la usa como cimiento. Si vienes siguiendo la guía en orden, ya tienes todo lo que necesitas: solo falta el gesto de entrega que las conecta.

Fíjate en la columna del medio de la tabla: cada pieza viene de un módulo distinto, y ninguna es opcional para lo que sigue. Promover (lección 2) no tiene sentido sin dos entornos entre los cuales mover el workflow —por eso necesitas los tres entornos del Módulo 4—. Revertir (lección 5) no es posible sin un repositorio con historial al cual volver —por eso necesitas el versionado de los Módulos 2 y 3—. Y promover con honestidad exige haber probado antes —por eso necesitas la pasada de sandbox del Módulo 5—. El módulo que empiezas no agrega cimientos nuevos; construye el último piso sobre los que ya levantaste. Esa dependencia es la razón por la que este es el módulo 6 y no el 2: solo tiene sentido cuando todo lo demás ya está en su lugar.

Una nota honesta, como en toda la guía: si no tienes una instancia a mano para correr los comandos, lee las lecciones de todos modos. La secuencia y su lógica se entienden igual, y las corres cuando tengas el entorno montado. Lo que se transfiere —el orden de los pasos, el criterio de cada decisión— vale más que teclear los comandos una vez.

El mapa de este módulo

Este es el recorrido de las ocho lecciones, con lo que resuelve cada una:

Lección	Qué resuelve
2	Promover con la CLI: import:workflow e import:credentials para subir order-triage de staging a prod, mapear las credenciales del destino y decidir si el workflow llega activo o inactivo
3	Revisar el cambio como un diff antes de promoverlo: el pull request como punto de control obligatorio, y cómo revisar lo que una IA modificó dentro de tu instancia
4	Construir con IA contra un entorno no-prod: el servidor MCP de n8n, el lazo seguro (la IA propone en dev, Git registra, el humano aprueba, se promueve), y por qué los entornos aislados son la red
5	Revertir con un runbook: volver al último JSON bueno del repo y re-importarlo, y escribir el procedimiento numerado que otra persona pueda seguir bajo presión
6	Decidir entre el Git nativo de Enterprise y el flujo CLI de esta guía, con una matriz por tamaño de equipo, presupuesto y cumplimiento
7	Automatizar la revisión con un chequeo de CI en GitHub Actions que valida el JSON en cada commit, y armar el artefacto de portafolio defendible
8	Integrar todo: el proyecto final, el entregable completo "as version-controlled, documented JSON", que cierra el módulo y la guía

Fíjate en el orden, porque cuenta una historia. Primero el movimiento hacia adelante —promover (2)—. Después el control de calidad de ese movimiento —revisar (3) y el caso especial de la IA (4)—. Luego la red de seguridad —revertir (5)—. En seguida la decisión económica —gratis o de pago (6)— y la automatización de la revisión —CI (7)—. Y al final, todo junto en un entregable (8). Es el arco completo de "constructor de workflows" a "dueño del sistema", cerrándose.

Una última cosa antes de empezar, sobre el ritmo. Este módulo cierra la guía, así que la tentación es correrlo para "terminar ya". Resiste esa prisa. Cada lección instala una pieza de operación que vas a usar en tu trabajo real —promover sin romper, revertir bajo presión, revisar lo que hace una IA—, y esas piezas se aprenden mejor despacio, con las manos en el teclado si tienes una instancia, o siguiendo el razonamiento con cuidado si no la tienes. No hay premio por llegar rápido al final; el premio es tener el entregable hecho y entendido. Ve al ritmo que te deje poder hacer cada cosa, no solo reconocerla.

Errores comunes

Creer que "promover" es simplemente volver a exportar e importar (conceptual). Qué pasa: alguien lee que promover se hace con import:workflow y concluye que es solo correr un comando, sin cuidado especial. Después importa un workflow en prod y se rompe, porque las credenciales del destino no estaban mapeadas o porque llegó activo cuando debía llegar inactivo. Por qué pasa: el comando es simple, pero lo que lo rodea —revisar antes, mapear credenciales, decidir el estado de activación, tener el rollback listo— es lo que hace segura la promoción. Cómo detectarlo: si tu plan para llevar un cambio a prod es "lo importo y ya", te falta todo lo que envuelve al comando. Cómo corregirlo: entiende que la promoción es un procedimiento, no un comando. Las lecciones 2 a 5 son, en conjunto, ese procedimiento: promover, revisar, y tener cómo volver atrás.

Dejar que una IA construya workflows directo en producción (conceptual y de seguridad). Qué pasa: alguien descubre que puede pedirle a Claude o a Cursor que construya un workflow dentro de su instancia vía MCP, se entusiasma, y lo apunta a su instancia de prod. La IA construye, valida y ejecuta —a veces sobre datos reales— sin que un humano haya revisado el resultado. Por qué pasa: la comodidad es enorme y la tentación de saltarse los pasos, también; el lazo de la IA se corrige a sí mismo y da la falsa sensación de que no necesita supervisión. Cómo detectarlo: si tu asistente de IA está conectado a la instancia donde corren los pedidos reales de Cumbre, tienes el problema. Cómo corregirlo: la IA construye en dev, nunca en prod; su cambio pasa por Git y por una revisión humana antes de promoverse. Es la lección 4 entera, y el principio es innegociable: la IA propone, el humano aprueba, y solo entonces el cambio llega a producción.

Pensar que el rollback se improvisa en el momento del incidente (conceptual). Qué pasa: alguien confía en que, si algo se rompe en prod, ya se le ocurrirá cómo volver atrás cuando pase. Y cuando pasa —a las tres de la mañana, con quejas entrando—, no recuerda qué commit era el bueno, ni el comando exacto para re-importar, y pierde una hora bajo presión haciendo lo que ensayado tomaría dos minutos. Por qué pasa: el rollback se siente como algo hipotético hasta que deja de serlo, y nadie ensaya la salida de emergencia mientras todo funciona. Cómo detectarlo: si no tienes escrito, en algún lado, "para revertir order-triage hago exactamente estos pasos", no tienes rollback, tienes una esperanza. Cómo corregirlo: escribe el runbook antes de necesitarlo y ensáyalo una vez con calma. Es la lección 5, y su lema resume el módulo: se ensaya el rollback antes del incidente, no durante.

Ejercicios

Ejercicio 1 — Dibuja tu propio pipeline. Sin volver a mirar el diagrama de esta lección, dibuja de memoria el ciclo de vida de un cambio de workflow, de la idea a producción y de vuelta. Marca en cada eslabón qué módulo de la guía te enseñó esa pieza. Después compara con el diagrama de la sección "El ciclo de vida de un workflow, visto entero" y anota qué eslabón se te escapó.

Ver solución

El pipeline es: editar (en dev, o con IA vía MCP — Módulo 4) → exportar (con la CLI, a JSON normalizado — Módulos 2 y 3) → commit (al repositorio — Módulos 2 y 3) → probar (en sandbox y en staging — Módulo 5) → promover (a staging y a prod — Módulo 6) → y, si hace falta, revertir (al último JSON bueno — Módulo 6).

Lo que la mayoría dibuja bien es la parte del medio —exportar, commitear, probar— porque son los módulos que acaban de hacer. Lo que más se escapa son los dos extremos: que la edición puede venir de una IA (el gancho de la lección 4) y que el rollback es un eslabón de primera clase, no un accidente (la lección 5).

Por qué funciona: tener el pipeline completo en la cabeza es lo que te deja ubicar cualquier técnica del módulo en su lugar. Cuando en la lección 2 aprendas import:workflow, no vas a verlo como "otro comando", sino como el eslabón "promover" del ciclo que ya dibujaste. El mapa hace que cada pieza tenga un dónde.

Ejercicio 2 — Demo o despliegue. Para cada situación, di si describe una demo o un despliegue, y qué le falta a la demo para volverse despliegue: (a) "Construí el workflow, lo corrí, funcionó, y le mandé el link al cliente." (b) "El workflow está en prod, hay un runbook para revertirlo, y cada cambio pasó por staging y por una revisión de diff." (c) "Le pedí a Cursor que armara el workflow en mi instancia y ya está corriendo con datos reales."

Ver solución

(a) Demo. Funciona cuando el autor lo corre, pero no responde cómo llega un cambio a producción, quién lo revisa, ni cómo se revierte. Para volverse despliegue le falta el ciclo entero de este módulo: entornos, promoción controlada, revisión de diff y rollback.

(b) Despliegue. Responde las preguntas que la demo deja en el aire: cómo llega el cambio (por staging), quién lo revisó (el diff aprobado) y cómo se revierte (el runbook). Es exactamente lo que este módulo construye.

(c) Demo peligrosa. Es peor que la (a), porque no solo le falta el ciclo, sino que rompe el principio de la lección 4: una IA construyendo directo en producción, sobre datos reales, sin revisión humana. Para volverse despliegue tendría que apuntar la IA a dev, pasar el cambio por un diff revisado, y promoverlo a prod recién después.

Por qué funciona: el criterio "demo contra despliegue" es el mismo que usa un entrevistador, aunque no lo diga con esas palabras. Cuando pregunta "¿cómo manejas los despliegues?", está midiendo si tu trabajo termina en la demo o si sabes envolverla en las garantías del despliegue. Este ejercicio te entrena a oír esa pregunta detrás de sus muchas formas.

Ejercicio 3 — Inventaria tu punto de partida. Recorre la tabla de la sección "Dónde estás parado ahora" y, para el caso de Cumbre (o para tu propio proyecto si lo tienes), marca cuáles de las cinco piezas ya tienes listas y cuáles no. Para cada pieza que falte, escribe en una frase a qué módulo tendrías que volver.

Ver solución

No hay una respuesta única; el resultado es tu diagnóstico. Si vienes siguiendo la guía en orden, deberías poder marcar las cinco: repositorio versionado, workflow normalizado y documentado, tres entornos aislados, credenciales por entorno y una pasada de prueba en sandbox.

Si alguna te falta, la tabla te dice exactamente a dónde volver: el repositorio y el workflow normalizado son Módulos 2 y 3; los entornos y las credenciales por entorno son el Módulo 4; la pasada de prueba es el Módulo 5. Este módulo construye sobre esas cinco piezas, así que un hueco aquí se va a sentir en las lecciones que siguen.

Por qué funciona: un dueño del sistema empieza cualquier trabajo verificando su punto de partida, no asumiéndolo. Este inventario es ese hábito en pequeño. Y te ahorra la frustración de intentar promover un workflow (lección 2) cuando en realidad te falta el segundo entorno a donde promoverlo (Módulo 4).

Resumen y siguiente paso

En esta lección viste el ciclo de vida completo de un workflow —editar, exportar, commit, probar, promover, revertir— como una sola cadena, con la imagen de las cocinas de un restaurante: la de pruebas (dev), el recetario (cumbre-automations), la de ensayo (staging), la principal (prod) y la salida de emergencia (el rollback). Entendiste que este módulo cierra la guía enseñando el gesto que junta todas las piezas que ya tienes: la promoción controlada entre entornos, la revisión de cada cambio como diff (incluidos los que hace una IA), la construcción con IA contra entornos no-prod vía MCP, el rollback con runbook, la decisión entre Git nativo y flujo CLI, y el chequeo de CI que valida el JSON en cada commit. Viste el criterio que separa una demo de un despliegue —cinco preguntas que el despliegue responde y la demo deja en el aire— y conociste el entregable final que vas a construir: el artefacto de portafolio completo, a costo cero.

Antes de avanzar a la lección 2 deberías poder: dibujar el pipeline completo de memoria y ubicar cada módulo en su eslabón; explicar en una frase qué separa una demo de un despliegue; y decir qué cinco piezas ya tienes de los módulos anteriores y por qué este módulo las necesita.

Lo que sigue es empezar a mover. La lección 2 entra de lleno en la promoción: vas a tomar order-triage, ya probado en sandbox, y llevarlo de staging a prod con la CLI de n8n. Vas a conocer import:workflow e import:credentials, el problema de mapear las credenciales del entorno de destino, la decisión de si el workflow llega activo o inactivo, y —lo más importante— qué revisar antes de promover para no romper los pedidos reales de Cumbre. Es el primer eslabón de los dos que faltan, y el que convierte tu repositorio en algo que de verdad llega a producción.

Recursos

• Source control and environments — n8n Docs — la sección oficial sobre control de versiones y entornos; el marco donde vive todo lo que este módulo hace a mano en Community.
• Use the command line — n8n Docs — la referencia de la CLI, incluidos import:workflow e import:credentials que la lección 2 usa para promover.
• Set up and use the n8n MCP server — n8n Docs — el servidor MCP a nivel de instancia que permite a una IA construir workflows; base de las lecciones 3 y 4. Verifica el estado y la ubicación exacta en tu versión.
• GitHub Actions documentation — GitHub Docs — la plataforma de CI gratuita que la lección 7 usa para validar el JSON en cada commit.
• Release notes 2.x — n8n Docs — el historial de la versión 2 de n8n; útil para confirmar qué versión usas frente a lo que dice este módulo, sobre todo para las features de MCP, que evolucionan rápido.