Módulo 1: Por qué versionar tus workflows

8. Proyecto: audita y exporta un workflow

Siguiente →

Descripción

Al terminar esta lección vas a tener tu primer entregable real de la guía: un workflow exportado como JSON, leído campo por campo, acompañado de una nota de riesgos de portabilidad que documenta cada punto que se rompería al mover ese workflow a otra instancia. No vas a aprender un concepto nuevo; vas a poner las manos sobre todo lo que aprendiste en las siete lecciones anteriores y a producir un artefacto que sirve de base para el resto de la guía.

Esto importa porque es la diferencia entre haber leído sobre versionado y haber empezado a hacerlo. Las siete lecciones te dieron el porqué (1, 2), el problema (3, 4, 5), el modelo (6) y la economía (7). Nada de eso se fija hasta que exportas un workflow de verdad, lo abres, y con tu propio dedo señalas "aquí está el ID de credencial que se va a romper". Y la nota de riesgos que vas a escribir no es un ejercicio de práctica que se tira: es la primera piedra del artefacto de portafolio de la lección 2, y el documento sobre el que los Módulos 3 y 4 construyen las soluciones.

Conexión con el módulo: este proyecto ensambla las siete lecciones. El Download es de la lección 3; leer el JSON con criterio es la lección 4; identificar qué se rompe es la lección 5; entender por qué documentarlo importa es la lección 6 (el repo como fuente de verdad necesita que el porqué esté escrito); y saber que todo esto se hace gratis es la lección 7. Si algo de lo que sigue no te resulta familiar, ese es el número de lección al que conviene volver. Y mirando hacia adelante: el JSON que exportes aquí es lo que vas a versionar con Git en el Módulo 2, y la nota de riesgos es lo que vas a resolver, punto por punto, en los Módulos 3 y 4.

Lo que vas a entregar

Dos archivos, que juntos son tu primer entregable de dueño del sistema:

  1. El JSON exportado de un workflow real —order-triage de Cumbre si lo tienes armado, o cualquier workflow tuyo que use al menos una credencial; idealmente uno con un webhook y una llamada a una API externa, para que los cuatro puntos frágiles aparezcan—.

  2. La nota de riesgos de portabilidad: un documento corto, en texto plano o Markdown, que para el workflow elegido liste cada campo que se rompería al importarlo en otra instancia, clasificado por punto frágil, con qué haría falta para que no se rompa. Es la aplicación directa de la lección 5 a tu workflow concreto.

entregable-modulo-1/
  ├── order-triage.json          ← el workflow exportado (lección 3)
  └── PORTABILITY-RISKS.md        ← la nota de riesgos (lección 5)

Sobre el tiempo: exportar y leer el JSON son unos veinte minutos; escribir la nota de riesgos con cuidado, otros veinte. Es un proyecto corto a propósito: su valor no está en la extensión, sino en que hagas de verdad el gesto de auditar un workflow antes de moverlo, que es el gesto que te faltaba.

Una nota sobre los nombres de archivo: van en inglés, como toda la convención del ecosistema. order-triage.json, PORTABILITY-RISKS.md, entregable-modulo-1/ —bueno, ese último tiene "modulo" porque es tu carpeta local de trabajo, ponle el nombre que quieras; los que importan, los que van a vivir en el repo, van en inglés—.

Vale la pena que veas este entregable con la mirada de la lección 2: es la primera versión, humilde pero real, del artefacto de portafolio. Un evaluador que abriera esta carpeta ya vería un gesto que el constructor no hace —auditar un workflow antes de moverlo— y una capacidad que la mayoría no tiene: anticipar por escrito qué se rompe. No es el repositorio completo todavía; es su primera piedra. Y como cada módulo agrega una pieza sobre la anterior, empezar bien aquí —con un workflow que de verdad te importe y una nota específica— te ahorra rehacer el trabajo más adelante.

Fase 0 — Elige y prepara el workflow

Necesitas un workflow para auditar. Tienes tres caminos, en orden de preferencia.

Camino A — order-triage de Cumbre. Si vienes siguiendo la guía y armaste (o vas a armar) el workflow del caso de estudio —recibe pedidos por webhook, consulta el CRM por HTTP, clasifica con un nodo AI Agent—, ese es el ideal, porque tiene los cuatro puntos frágiles: dos credenciales (CRM y proveedor de IA), un webhook, y valores que cambian por entorno. Si aún no lo tienes armado, puedes construir una versión mínima: un nodo Webhook, un nodo HTTP Request a cualquier API que requiera una credencial, y un nodo AI Agent con la credencial de un proveedor de modelos. No tiene que hacer nada útil todavía; solo tiene que existir y tener esas piezas.

Camino B — un workflow tuyo real. Si ya tienes workflows en tu instancia, elige el que más te importe que sea portable: idealmente uno con webhook y al menos una credencial. Es incluso mejor que el caso de estudio, porque el análisis se vuelve sobre algo que de verdad te interesa proteger.

Camino C — un workflow mínimo de práctica. Si no tienes ni lo uno ni lo otro, arma en cinco minutos un workflow con un Manual Trigger, un HTTP Request con cualquier credencial de autenticación (aunque sea a una API pública que pida una llave), y guárdalo. Con una sola credencial ya puedes practicar el punto frágil más importante.

Paso 0.1. Abre el workflow elegido en el editor de n8n. Asegúrate de guardarlo antes de exportar —recuerda de la lección 3 que el export saca lo guardado, no lo último que tocaste sin guardar—.

Qué esperar: el workflow abierto, guardado, con al menos un nodo que use credenciales. Si tu workflow no usa ninguna credencial, el punto frágil 1 —el más importante— no va a aparecer, así que vale la pena agregar aunque sea un nodo con autenticación para que el ejercicio tenga sustancia.

Fase 1 — Exporta el workflow

Paso 1.1. Con el workflow abierto y guardado, abre el menú de tres puntos (⋯) arriba a la derecha y elige Download. (Verifica la etiqueta exacta en tu versión; si el menú está en otro lugar o la opción se llama distinto, búscala: es la que baja el workflow como archivo .json.)

Qué esperar: tu navegador baja un archivo con extensión .json. El nombre por defecto suele ser el nombre del workflow. Guárdalo en la carpeta de trabajo de tu entregable y, si quieres, renómbralo a order-triage.json (o el nombre en inglés que corresponda a tu workflow).

Paso 1.2 (opcional pero recomendado). Abre también el workflow con el atajo de copiar: selecciona todos los nodos (Ctrl+A) y copia (Ctrl+C). Pega el resultado en un editor de texto y compáralo con el archivo que bajaste. Qué esperar: el contenido es esencialmente el mismo JSON. Este paso no es para el entregable; es para que confirmes con tus propios ojos, una vez más, que las dos formas de exportar (lección 3) producen lo mismo.

Micro-verificación: abre el archivo .json en un editor de texto (cualquiera sirve: el editor de código que uses, o hasta el bloc de notas). Si ves un bloque grande de texto que empieza con { y contiene las palabras nodes y connections, exportaste bien. Si el archivo está vacío o no se ve como JSON, algo falló en la descarga; vuelve a intentar el Download.

Fase 2 — Lee el JSON con los ojos de la lección 4

Ahora la parte que separa auditar de solo mirar. Vas a recorrer el archivo con la estructura de la lección 4 en la mano, localizando cada parte. No tienes que entender cada carácter; tienes que poder señalar dónde está cada cosa.

Paso 2.1 — Las secciones de nivel superior. En tu archivo, localiza y anota en qué zona del archivo están: name (el nombre del workflow), nodes (la lista de nodos, empieza con [), connections (el objeto que menciona nombres de nodos), settings, active, y si existen, pinData, meta, versionId, tags.

Qué esperar: vas a encontrar nodes y connections como las secciones más grandes, y las demás más cortas. Si tu versión de n8n nombra algún campo distinto de como lo describe la lección 4, anótalo: era medio punto de la lección 4 que confirmaras que los nombres exactos pueden variar por versión.

Paso 2.2 — Un nodo por dentro. Elige el nodo más interesante de tu workflow —el que usa credenciales— y localiza, dentro de su objeto: name, type, typeVersion, parameters, position, id, y credentials (si lo tiene).

Paso 2.3 — El campo credentials. Este es el que más importa. Si tu nodo usa credenciales, localiza su sección credentials y anota exactamente qué ves: el tipo de credencial, el id (un número o cadena corta) y el name (el nombre legible). Qué esperar: vas a ver el id y el name, pero no el secreto en sí —ni la contraseña, ni la llave de API—. Confirmar eso con tus propios ojos es cerrar la idea central de la lección 4: el JSON guarda una referencia, no el secreto.

Paso 2.4 — Clasifica cinco campos. Toma cinco campos cualquiera de tu archivo y clasifícalos como estables o volátiles según la lección 4. Por ejemplo: parameters (estable), position (volátil), name de nodo (estable), id de nodo (volátil), versionId (volátil). Qué esperar: deberías poder justificar cada clasificación en una frase —"position es volátil porque cambia con solo mover el nodo, sin cambiar el comportamiento"—.

Fase 3 — Caza los puntos frágiles con la lección 5

Con el archivo ya mapeado, ahora aplicas la lista de la lección 5: recorres los cuatro puntos frágiles y anotas cuáles aparecen en tu workflow y dónde.

Paso 3.1 — Punto frágil 1: IDs de credencial. Busca en el archivo todas las secciones credentials. Por cada una, anota: el tipo, el id y el name. Cada una de estas es un punto que se rompería al importar en otra instancia, porque ese id es por instancia. Qué esperar: si tu workflow tiene dos credenciales (como order-triage, con el CRM y el AI Agent), anotas dos. Si tiene una, anotas una. Si tiene cero, tu workflow no tiene este riesgo —pero entonces vale la pena que agregues un nodo con credencial para que el ejercicio tenga el punto más importante—.

Paso 3.2 — Punto frágil 2: IDs de nodo. Localiza los id de los nodos (esas cadenas largas tipo código de barras). Anota que existen y que podrían regenerarse al importar. Recuerda de la lección 5 que esto no suele romper el flujo —las conexiones usan nombres—, pero ensucia el historial. Qué esperar: tantos id como nodos tenga tu workflow.

Paso 3.3 — Punto frágil 3: webhooks. Busca si algún nodo es de tipo webhook (por ejemplo n8n-nodes-base.webhook). Si lo hay, localiza su path y su webhookId, y anota que la URL del webhook cambiaría al mover el workflow, rompiendo a cualquier sistema externo que lo llame. Qué esperar: si tu workflow empieza con un webhook, este es uno de los riesgos más importantes de anotar, porque es el único que rompe cosas fuera de n8n y no da ninguna señal dentro. Si usas un Manual Trigger en su lugar (camino C), anótalo: no tienes este riesgo, y eso también es información.

Paso 3.4 — Punto frágil 4: valores y variables de entorno. Recorre los parameters de tus nodos buscando valores fijos que deberían cambiar por entorno: URLs de servicios (¿apunta a producción?), identificadores de cuenta, umbrales, cualquier cosa escrita a mano que en dev debería ser distinta que en prod. Anota cada uno. Qué esperar: al menos una URL o un valor que, si importaras el workflow en un entorno de prueba, seguiría apuntando a lo real. Este es el punto silencioso: no se rompe visiblemente, pero puede hacer que una "prueba" toque datos de verdad.

Ejemplo trabajado: una auditoría completa de order-triage

Antes de que escribas tu nota, veamos una pasada de auditoría completa sobre el esqueleto de order-triage de la lección 4, para que tengas un modelo que imitar. Voy a leer el archivo en voz alta, como lo harías tú, anotando lo que importa a medida que aparece.

Empiezo por arriba. "name": "order-triage" —bien, es el workflow que quiero—. Entro a nodes y veo tres objetos. El primero es el webhook.

Nodo "Order received (Webhook)". Su type es n8n-nodes-base.webhook. Alarma de punto frágil 3: hay un webhook. Anoto: path es "order-triage", tiene un webhookId. La URL de este webhook va a cambiar al mover el workflow, y la tienda de Cumbre le manda los pedidos aquí. Esto es lo que rompe fuera de n8n sin avisar. Lo apunto con estrella, porque es el que nadie recuerda.

El segundo nodo es la llamada al CRM.

Nodo "Get customer from CRM". type n8n-nodes-base.httpRequest. Miro sus parameters: la url es https://crm.example.com/api/customers/..., escrita a mano. Punto frágil 4: este valor apunta al mismo CRM sin importar el entorno; si importo esto en dev, va a llamar al CRM real. Lo anoto. Y miro su credentials: tipo httpHeaderAuth, id "27", name "Cumbre CRM - Header Auth". Punto frágil 1: ese id "27" es por instancia. Lo anoto como riesgo de credencial número uno.

El tercer nodo es el agente.

Nodo "Classify order (AI Agent)". type @n8n/n8n-nodes-langchain.agent. Su credentials: tipo openAiApi, id "14", name "Cumbre OpenAI - Dev". Punto frágil 1 otra vez: segunda credencial que se rompe. Y noto el sufijo "Dev" en el nombre —pista de que en prod esta debería ser otra credencial, no la de dev—. Lo anoto: al promover a producción, hay que asegurarse de usar la credencial de producción, no arrastrar la de dev.

Reviso los id de los tres nodos —11111111-..., 22222222-..., 33333333-...—. Punto frágil 2: pueden regenerarse al importar; no rompen el flujo porque connections usa nombres, pero ensucian el diff. Lo anoto como riesgo menor, para normalizar en el Módulo 3.

Cierro con connections —las flechas van del webhook al CRM y del CRM al agente, todo por nombre, así que sobreviven a la mudanza— y con settings, active: false, etc.

Qué esperar de esta pasada: al terminar tengo, en un papel, seis anotaciones —un webhook, dos credenciales, tres IDs de nodo, una URL fija—, cada una con su nombre y ubicación exactos. Eso es exactamente lo que la nota de riesgos va a formalizar. Fíjate en el método: leo el archivo de arriba hacia abajo, y por cada nodo me pregunto los cuatro puntos frágiles en orden. No busco al azar; recorro con una lista. Esa es la diferencia entre auditar y mirar.

Fase 4 — Escribe la nota de riesgos de portabilidad

Ahora conviertes tus anotaciones en el documento entregable. La nota de riesgos tiene una estructura simple y un propósito claro: que cualquier persona —incluido tú en tres meses— pueda leer, antes de mover este workflow, exactamente qué tiene que revisar para que no se rompa en silencio.

Paso 4.1. Crea un archivo PORTABILITY-RISKS.md con esta estructura. Escribe la prosa en español y los identificadores (nombres de nodo, de credencial, campos) en inglés, como en todo el repo:

# Portability risks — order-triage

Qué revisar ANTES de importar este workflow en otra instancia.
Cada punto es algo que se rompe en silencio si no se controla.

## 1. Credenciales (rompe al ejecutar)
- Nodo "Get customer from CRM": credencial `httpHeaderAuth`, id 27,
  name "Cumbre CRM - Header Auth".
  → Recrear en la instancia destino y reasignar. Usar la del entorno correcto.
- Nodo "Classify order (AI Agent)": credencial `openAiApi`, id 14,
  name "Cumbre OpenAI - Dev".
  → Recrear y reasignar. Ojo: en prod debe ser la credencial de prod, no la de dev.

## 2. IDs de nodo (ensucia el historial)
- Los tres nodos tienen id que puede regenerarse al importar.
  → No rompe el flujo (las conexiones usan nombres), pero normalizar
    para diffs limpios (Módulo 3).

## 3. Webhook (rompe FUERA de n8n, sin aviso)
- Nodo "Order received (Webhook)": path "order-triage".
  → La URL cambia con el dominio de la instancia destino.
    Actualizar el sistema externo (la tienda de Cumbre) para que llame
    a la URL nueva. NADIE avisa si se olvida.

## 4. Valores de entorno (rompe silencioso / peligroso)
- Nodo "Get customer from CRM": url "https://crm.example.com/..."
  escrita a mano.
  → Apunta al mismo CRM sin importar el entorno. En dev/staging
    debería apuntar al CRM de prueba. Sacar el valor a config por entorno (Módulo 4).

## Verificación después de importar
1. Abrir cada nodo con credenciales, confirmar que no está en rojo.
2. Reasignar credenciales del entorno correcto.
3. Anotar la URL nueva del webhook y re-cablear el sistema externo.
4. Revisar valores fijos que deban cambiar por entorno.
5. Prueba end-to-end con datos de prueba, no solo ejecución manual.

Adapta el contenido a tu workflow: si tiene una sola credencial, tu sección 1 tiene un punto; si no tiene webhook, tu sección 3 dice "no aplica: usa Manual Trigger" —lo cual es información valiosa, no un hueco—.

Paso 4.2. Relee tu nota preguntándote: "si le doy este documento a alguien que nunca vio el workflow, ¿sabría qué revisar antes de moverlo?". Si la respuesta es sí, la nota cumple su función. Si algún punto es vago —"revisar las credenciales" sin decir cuáles ni dónde—, precísalo. La diferencia entre una nota útil y una inútil es la especificidad: nombres concretos, ubicaciones concretas, acciones concretas.

Qué esperar: un documento de una o dos pantallas, escaneable, que un compañero puede leer en dos minutos y usar como lista de verificación. No es un ensayo; es una lista de riesgos con su acción. Ese formato —conciso, accionable, con el porqué implícito en la acción— es el que vas a usar para el runbook completo del Módulo 6.

Fase 5 — Verifica el entregable (y, si puedes, compruébalo)

Paso 5.1 — Lista de verificación del entregable. Confirma que tienes:

  • El archivo .json exportado, que abre y se ve como JSON válido.
  • Localizaste en él las secciones principales (nodes, connections, credentials si aplica).
  • La nota PORTABILITY-RISKS.md con los cuatro puntos frágiles, cada uno con nombres y ubicaciones concretas, y su acción.
  • Una sección de verificación post-importación en la nota.

Paso 5.2 — La comprobación real (opcional, muy recomendada). Si tienes forma de levantar una segunda instancia de n8n —otra en tu máquina, una limpia en Docker—, haz la prueba que cierra el módulo: importa tu workflow ahí y observa qué se rompe. Qué esperar: vas a ver los nodos con credenciales marcados en rojo (punto 1), vas a notar que el webhook tiene otra URL (punto 3), y vas a confirmar con tus propios ojos que tu nota de riesgos predijo exactamente lo que pasó. No hay mejor forma de fijar la lección 5 que ver tu predicción cumplirse. Si no puedes levantar una segunda instancia ahora, no te preocupes: en el Módulo 4 vas a montar entornos de verdad, y ahí sobra ocasión de comprobarlo.

Paso 5.3 — Guárdalo bien. Este entregable no se tira. El JSON es lo que vas a versionar con Git en el Módulo 2, y la nota de riesgos es lo que vas a resolver, punto por punto, en los Módulos 3 y 4. Ponlo en un lugar que no vayas a perder —idealmente, la carpeta desde la que vas a inicializar tu repositorio cumbre-automations en la próxima unidad—.

Errores comunes

Auditar el JSON "de memoria" sin abrir el archivo (práctico). Qué pasa: alguien escribe la nota de riesgos basándose en lo que recuerda del workflow, sin abrir el JSON exportado, y se pierde cosas —una segunda credencial que olvidó, un valor fijo enterrado en un nodo—. Por qué pasa: parece más rápido, y uno cree conocer su propio workflow. Cómo detectarlo: si tu nota no cita id ni ubicaciones concretas, probablemente no abriste el archivo. Cómo corregirlo: la auditoría se hace sobre el archivo, no sobre la memoria. El JSON siempre tiene más de lo que recuerdas —n8n mete IDs, metadatos, valores por defecto que nunca viste en el editor—. Abrir el archivo es el punto entero del ejercicio.

Escribir una nota de riesgos vaga (práctico). Qué pasa: la nota dice cosas como "revisar credenciales" y "checar el webhook", sin nombres ni ubicaciones ni acciones. Cuando alguien la usa dentro de tres meses, no le sirve: no sabe cuáles credenciales ni qué hacer. Por qué pasa: escribir específico cuesta más y en el momento uno tiene todo fresco en la cabeza, así que la vaguedad no se nota. Cómo detectarlo: si un punto de tu nota no dice el nombre concreto de lo que se rompe y la acción concreta para arreglarlo, es vago. Cómo corregirlo: cada punto lleva nombre (qué nodo, qué credencial), ubicación (dónde en el JSON) y acción (qué hacer). La especificidad es lo que convierte una nota en una herramienta; la vaguedad la convierte en decoración.

Tratar el proyecto como descartable (conceptual). Qué pasa: alguien hace el ejercicio "para cumplir", con un workflow de juguete que no le importa, y tira el resultado. Se pierde que este es el primer ladrillo del artefacto de portafolio y la base de los módulos siguientes. Por qué pasa: es el proyecto del módulo 1, se siente introductorio. Cómo detectarlo: si elegiste un workflow que no te importa y no piensas guardarlo, lo estás tratando como descartable. Cómo corregirlo: elige un workflow que de verdad quieras llevar hasta el final de la guía —order-triage o uno tuyo real— porque este JSON y esta nota van a crecer contigo módulo a módulo hasta ser el entregable final. Empezar con algo real te ahorra rehacerlo después.

Olvidar guardar el workflow antes de exportar (práctico). Qué pasa: alguien toca el workflow en el editor, exporta sin guardar, y el JSON no incluye el último cambio, porque el export saca lo guardado (lección 3). Después la nota de riesgos analiza un estado que no es el actual. Por qué pasa: el editor no siempre deja obvio si hay cambios sin guardar. Cómo detectarlo: si el JSON no tiene algo que juras haber cambiado, no guardaste. Cómo corregirlo: guarda siempre antes de exportar. Es el primer paso de la fase 1 por una razón; conviértelo en reflejo, porque este mismo tropiezo te va a acechar cada vez que exportes en el resto de la guía.

Ejercicios

Estos ejercicios extienden el proyecto: no repiten lo que ya hiciste, lo profundizan.

Ejercicio 1 — Predice y comprueba. Antes de importar tu workflow en una segunda instancia (si puedes), escribe una predicción de tres líneas: qué exactamente esperas que se vea roto al abrirlo del otro lado. Después impórtalo y compara tu predicción con lo que pasó.

Ver solución

Una predicción típica para order-triage: "Los dos nodos con credenciales (CRM y AI Agent) van a aparecer en rojo o sin credencial seleccionada. El webhook va a tener una URL distinta. El flujo de nodos va a estar completo y las conexiones intactas, porque usan nombres."

Lo que casi siempre confirma la comprobación: exactamente eso. Las credenciales se marcan (n8n te las señala), el webhook cambia de URL (nada te lo señala), y las conexiones sobreviven. Si algo te sorprende —un comportamiento que no predijiste—, ese es el hallazgo más valioso del ejercicio: es un punto frágil que tu modelo mental todavía no capturaba, y ahora sí.

Por qué funciona: predecir antes de comprobar es lo que convierte una observación pasiva en aprendizaje activo. Cuando tu predicción se cumple, la lección 5 pasa de "algo que leíste" a "algo que sabes". Cuando falla, encontraste tu punto ciego, que es aún más útil.

Ejercicio 2 — Anonimiza para compartir. Imagina que vas a subir el JSON de tu workflow a un foro público para pedir ayuda. Revisa el archivo y anota qué tendrías que quitar o cambiar antes de compartirlo, según la advertencia de seguridad de las lecciones 3 y 4.

Ver solución

Lo que hay que revisar antes de compartir un JSON públicamente:

  • Los name de las credenciales. Los IDs no son secretos, pero un nombre como "Cumbre CRM - Producción - API Key Principal" revela información de tu infraestructura. Anonimízalos a algo genérico.
  • Cabeceras de autenticación en nodos HTTP. Si algún nodo HTTP Request se creó importando un cURL, puede llevar un token o una llave real dentro de parameters (por ejemplo en un header Authorization). Eso es un secreto de verdad: quítalo.
  • URLs internas. Direcciones de servicios internos (https://crm.interno.cumbre.local/...) revelan tu arquitectura. Considera reemplazarlas por example.com.
  • pinData. Si fijaste datos de prueba, pueden contener información real que capturaste en una ejecución. Revísalo.

Por qué funciona: este ejercicio te entrena el reflejo de seguridad que vas a necesitar toda la guía. Compartir un JSON —en un foro, con un cliente, en un repo público— sin revisarlo es una de las formas más comunes de filtrar información sin querer. Y de paso, refuerza la idea de la lección 4: el JSON guarda referencias (seguras) pero también puede arrastrar secretos reales en lugares específicos (headers, pinData) que hay que vigilar.

Ejercicio 3 — Escribe el "por qué versiono esto". En tres o cuatro frases, escribe la justificación de por qué este workflow específico merece estar versionado, dirigida a alguien que te preguntara "¿para qué tanto lío con un solo workflow?". Usa lo que sabes de las lecciones 1 a 3.

Ver solución

Una justificación posible para order-triage:

"Este workflow procesa los pedidos reales de la empresa: si se rompe, dejan de entrar pedidos, que es dinero. Versionarlo me da tres cosas que hoy no tengo: si un cambio lo rompe, vuelvo a la versión de ayer en un minuto en vez de adivinar; si otra persona lo toca, no nos pisamos en silencio; y cuando yo no esté, queda escrito por qué está armado así, incluyendo qué se rompe si alguien lo mueve —que es justo lo que documenté en la nota de riesgos—. No es 'tanto lío por un workflow': es que este workflow es un sistema del que depende la operación, y los sistemas de los que se depende se versionan."

Por qué funciona: la justificación conecta el valor abstracto (historial, rollback, colaboración) con el costo concreto de que este workflow falle (dejan de entrar pedidos). Esa conexión —del beneficio general al riesgo específico— es la que convence a un jefe escéptico y la que te convence a ti mismo cuando el trabajo de versionar se sienta tedioso. Si pudiste escribirla, cerraste el argumento del módulo: sabes no solo cómo empezar a versionar, sino por qué vale la pena.

Resumen y siguiente paso

En este proyecto produjiste tu primer entregable de dueño del sistema: un workflow exportado a JSON y una nota de riesgos de portabilidad que documenta, con nombres y ubicaciones concretas, cada campo que se rompería al mover ese workflow a otra instancia. Ensamblaste las siete lecciones del módulo: exportaste con el Download de la lección 3, leíste el JSON con la estructura de la lección 4 —localizando nodes, connections, y sobre todo el campo credentials que guarda una referencia y no el secreto—, cazaste los cuatro puntos frágiles con la lista de la lección 5, y escribiste la nota con la disciplina de documentación que el modelo de la lección 6 exige. Y lo hiciste enteramente en Community, gratis, como dijo la lección 7. Si pudiste, comprobaste tu predicción importando el workflow en una segunda instancia y viste tus riesgos cumplirse con tus propios ojos.

Antes de cerrar el módulo, confirma que puedes: exportar un workflow y abrir su JSON; localizar sus secciones principales y su campo credentials; y escribir, para un workflow dado, una nota de riesgos específica y accionable. Si las tres están, dominas la capacidad de salida del módulo: explicar por qué el export/import no versiona, leer la estructura del JSON, e identificar qué se rompe en un re-import ingenuo.

Lo que sigue es dejar de auditar y empezar a versionar. Tienes el JSON exportado y sabes exactamente qué lo hace frágil; el Módulo 2 te enseña Git desde cero —para alguien que nunca lo tocó— para convertir ese archivo en un workflow bajo control de versiones de verdad: con historial, con capacidad de leer cada cambio como un diff, con ramas para trabajar sin miedo, con respaldo en GitHub y con la capacidad de volver a una versión que funcionaba. El archivo que exportaste hoy es la semilla del repositorio cumbre-automations que vas a construir en la próxima unidad. Guárdalo bien; la próxima vez que lo veas, va a ser el primer commit de tu historia.

Recursos

← Anterior7. Source control: Community vs Enterprise, con honestidadSiguiente →1. Introducción: Git aplicado a workflows