Módulo 3: Exportar, normalizar y estructurar el repositorio

8. Proyecto: de instancia a repositorio documentado

Siguiente →

Descripción

Al terminar esta lección vas a haber producido, de punta a punta, el entregable central del módulo: convertir la instancia de n8n de Cumbre —con sus cuatro workflows y sus credenciales— en el repositorio cumbre-automations, normalizado, documentado, con exportación automatizada por script, credenciales fuera del repo y un .gitignore correcto. El resultado es un repositorio que pasaría la revisión de otro desarrollador: exactamente lo que las ofertas describen cuando piden "version-controlled, documented JSON".

Esto importa porque es la prueba de que las siete lecciones anteriores encajan. Hasta ahora practicaste cada pieza por separado: exportar, separar secretos, normalizar, estructurar, documentar, automatizar. El proyecto las junta en el orden correcto y te muestra que el todo es más que la suma —un repositorio profesional no es "hacer las siete cosas", es hacerlas en la secuencia que evita los accidentes—. Y te deja un artefacto real: no un ejercicio que se descarta, sino un repositorio que puedes enseñar en una entrevista y defender.

Conexión con el módulo: esta lección no introduce conceptos nuevos; integra todos los del módulo. Cada fase del proyecto es una lección anterior puesta en su lugar dentro del flujo completo. Presta atención al orden de las fases, porque ahí está la enseñanza que ninguna lección suelta podía dar: por qué el .gitignore va antes que la exportación, por qué la documentación va después de la estructura, por qué la verificación de seguridad va antes del commit. Al terminar, cierras la primera de las tres fases visuales de la guía —"versionar workflows con Git"— y quedas listo para el Módulo 4, donde ese repositorio limpio se convierte en la fuente de tres entornos aislados.

Un proyecto es un ensayo del trabajo real

Antes de las manos a la obra, una palabra sobre qué es este proyecto y qué no.

No es un ejercicio de juguete. Es un ensayo del trabajo real, en el sentido teatral: la representación completa, en orden, de lo que harías el primer día en un puesto que pide entregar automatizaciones versionadas. Cuando una empresa te contrate para "ordenar los workflows de n8n y dejarlos versionados y documentados", vas a hacer, casi paso por paso, lo que haces aquí con Cumbre. Por eso vale la pena hacerlo con seriedad, como si el CRM fuera de verdad y la llave que proteges valiera dinero de verdad —porque en el trabajo real, lo será—.

Piénsalo como el ensayo general de una obra antes del estreno. En el ensayo general se corre la función entera, con vestuario y luces, sin público. No se aprende una escena nueva; se pone a prueba que todas las escenas que ya ensayaste por separado fluyen juntas sin tropiezos. Este proyecto es tu ensayo general: la función es "instancia a repositorio documentado", y las escenas son las siete lecciones. Si alguna escena se traba, ahí descubres qué no habías entendido del todo —y mejor descubrirlo en el ensayo que en el estreno—.

Hay una recompensa oculta en hacerlo en orden y con seriedad: al terminar, no vas a "saber sobre" versionar workflows, vas a tenerlo hecho. La distancia entre esas dos cosas es enorme en una entrevista. Cualquiera puede decir que entiende .gitignore; muy pocos pueden abrir un repositorio real, señalar la línea que protege los secretos y explicar por qué está donde está. Este proyecto te pone del segundo lado.

Una nota sobre el punto de partida. El proyecto asume que ya tienes, del Módulo 2, un repositorio cumbre-automations inicializado con Git (con git init ya hecho), y una instancia de n8n con los workflows de Cumbre. Si estás siguiendo la guía con tu propia instancia, usa tus workflows reales; la forma es idéntica. Si no tienes instancia a mano, lee el proyecto completo de todos modos: la secuencia y su lógica se entienden igual, y las corres cuando tengas el entorno.

Ejemplo trabajado: el proyecto completo, fase por fase

Vamos a construir cumbre-automations en ocho fases. Cada fase abre con dónde estás y cierra con qué esperar, para que en todo momento sepas si vas bien.

Fase 0 — Dónde estás: la instancia y el repo vacío

Punto de partida: una instancia de n8n con los cuatro workflows de Cumbre —order-triage, inventory-sync, weekly-report, support-autoresponder— y sus credenciales, más una carpeta cumbre-automations con Git inicializado y, por ahora, prácticamente vacía. Párate en ella:

cd cumbre-automations

Qué esperar: git status te muestra un repositorio sin nada relevante todavía (quizás un README mínimo del Módulo 2). Es el lienzo en blanco. A partir de aquí construimos.

Todos los comandos que siguen suponen el escenario Docker de la guía (docker exec -u node "$CONTAINER" ...). Si tu n8n está instalado con npm en tu máquina, ya sabes de la lección 2 cómo adaptarlos: quitas el prefijo docker exec ... y corres n8n export:workflow directo, sin necesidad de docker cp. La lógica del proyecto es idéntica en los dos escenarios; solo cambia cómo llamas a la CLI.

Fase 1 — Blindar los secretos, ANTES que nada

Dónde estás: repo vacío, a punto de empezar a meter archivos. Esta es la fase que va primero, y el orden no es negociable. Antes de exportar un solo workflow —y muchísimo antes de tocar una credencial—, pones la red de seguridad, para que ningún secreto pueda colarse ni por accidente.

Crea el .gitignore en la raíz, con el contenido de la lección 3:

# --- Secretos: nunca al repositorio ---
.env
.env.*
!.env.example
credentials/*.json
*.credentials.json
credentials-backup.json
*-decrypted.json
.n8n/

# --- Ruido del sistema y temporales ---
node_modules/
.DS_Store
.export-raw/

(Fíjate en dos ajustes respecto de la lección 3: credentials/*.json ignora cualquier .json dentro de credentials/ pero deja pasar su README.md; y agregamos .export-raw/, la carpeta temporal que usa el export.sh de la lección 7.)

Y el .gitattributes de la lección 4, para los finales de línea:

*.json text eol=lf

Qué esperar: dos archivos nuevos en la raíz, .gitignore y .gitattributes. Todavía no hay secretos que proteger, y esa es exactamente la idea: la red se pone antes de que haya nada que se pueda caer. Poner el .gitignore primero es la decisión que hace segura toda la fase de exportación que viene.

Fase 2 — Estructurar el esqueleto

Dónde estás: los secretos ya están blindados. Ahora le das forma al repo, con el layout de la lección 5.

mkdir -p workflows credentials docs scripts
touch docs/.gitkeep

Crea el .env.example en la raíz, con los nombres de las variables secretas y sin valores:

# .env.example — copia a .env y rellena con TUS valores. .env NO se sube (ver .gitignore).
CRM_API_KEY=
LLM_API_KEY=
STORE_API_KEY=
DB_CONNECTION_STRING=
SMTP_PASSWORD=

Y el inventario de credenciales en credentials/README.md, sin valores:

# Credenciales requeridas

Los valores reales NO viven en este repo. Aquí solo se documenta qué hace falta.

| Workflow | Credencial | Tipo | Para qué |
|---|---|---|---|
| order-triage | Cumbre CRM key | Header Auth | Leer datos del cliente en el CRM |
| order-triage | Cumbre LLM key | (modelo de lenguaje) | Clasificar el pedido con el AI Agent |
| inventory-sync | Store API | Header Auth | Leer stock de la tienda en línea |
| weekly-report | Reporting DB | Postgres | Leer las ventas de la semana |
| weekly-report | Ops mailbox | SMTP | Enviar el reporte |
| support-autoresponder | Support mailbox | IMAP/SMTP | Leer y responder correos |
| support-autoresponder | Cumbre LLM key | (modelo de lenguaje) | Redactar la respuesta |

Qué esperar: cuatro carpetas (workflows/, credentials/, docs/, scripts/), el .env.example y el credentials/README.md. El esqueleto está en pie, aún sin contenido en workflows/. git status debe mostrar estos archivos nuevos y no debe mostrar ningún .env real (no lo creaste, pero de existir, estaría ignorado).

Fase 3 — El script de exportación

Dónde estás: esqueleto listo, sin workflows todavía. Antes de exportar a mano, pones la máquina que lo hace por ti: el export.sh de la lección 7. Créalo en scripts/export.sh con el contenido completo de esa lección —incluyendo la verificación de dependencias— y hazlo ejecutable:

chmod +x scripts/export.sh

Qué esperar: scripts/export.sh existe y es ejecutable. Aún no lo corriste; solo está listo. Ponerlo antes de la primera exportación significa que hasta tu primera exportación es reproducible: nunca haces el proceso "a mano una vez y con script después", lo haces con script desde el principio.

Fase 4 — Exportar y normalizar de una pasada

Dónde estás: el script listo, workflows/ vacío. Ahora corres el script y ves la magia del módulo entero condensada en un comando. Desde la raíz del repo:

./scripts/export.sh

Qué esperar: la terminal imprime los cuatro pasos, y al final workflows/ tiene los cuatro archivos con nombres legibles y ya normalizados: order-triage.json, inventory-sync.json, weekly-report.json, support-autoresponder.json. Ábrelos: sin pinData, sin versionId, sin meta.instanceId, con las claves ordenadas. Un vistazo a order-triage.json te confirma que su bloque credentials tiene solo referencias (id y name), no valores. Los secretos siguen afuera; la lógica está adentro, limpia.

Este es el momento donde el módulo "hace clic": lo que en la lección 1 eran cinco carencias del botón del editor, ahora es un comando que produce material reproducible, sin secretos y con diffs limpios.

Fase 5 — Documentar para el handoff

Dónde estás: los workflows exportados y limpios, pero todavía sin explicar. Ahora la lección 6: un README por workflow en docs/, más el README de raíz.

Crea docs/order-triage.md con la plantilla completa de la lección 6 —propósito, disparador, dependencias, credenciales requeridas, variables, contrato de entrada, diagrama Mermaid y notas/supuestos—. Repite, más breve, para los otros tres workflows: cada uno merece al menos propósito, disparador, dependencias, credenciales y un diagrama. No tienen que ser largos; tienen que ser suficientes (recuerda la prueba del desconocido).

Agrega el README.md de raíz con las cinco respuestas de la lección 5: qué es, qué hay adentro, cómo ponerlo a correr, cómo mantenerlo, dónde están los secretos.

Y, opcionalmente pero recomendado, abre cada workflow en el editor de n8n y agrégale una sticky note de cabecera con su propósito y un puntero a su doc. Al re-exportar, esas notas viajan en el JSON.

Qué esperar: docs/ con un .md por workflow, un README.md en la raíz que orienta, y credentials/README.md de la fase 2. Un desconocido que abra el repo ahora puede entender qué hace cada workflow y cómo arrancarlo. El .gitkeep de docs/ ya sobra —bórralo, la carpeta tiene contenido real—.

Fase 6 — Verificación de seguridad, antes de tocar la historia

Dónde estás: todo el contenido está en su lugar. Antes de commitear —nunca después— haces la revisión de seguridad. Es el último control antes de que algo entre a la historia permanente de Git.

git status

Revisa la lista con ojo de auditor. Deben aparecer: workflows/, docs/, credentials/README.md, scripts/export.sh, .env.example, .gitignore, .gitattributes, el README.md. No deben aparecer, bajo ninguna circunstancia: ningún .env con valores, ninguna exportación de credenciales (*-decrypted.json, credentials-backup.json), la carpeta .n8n/, ni la temporal .export-raw/.

Como doble chequeo, busca activamente cualquier cosa con forma de secreto en lo que vas a commitear:

git diff --cached

(Si aún no hiciste git add, primero míralo con git diff.) Lee buscando sk-, Bearer , password, llaves largas. Si encuentras un secreto, detente: sácalo, y si ya llegó a estar en un archivo que se exportó, considera rotar esa credencial. Mejor un minuto de paranoia ahora que un incidente después.

Qué esperar: la lista de git status contiene solo archivos que deben viajar, y ningún secreto. Si algo no cuadra, el problema casi siempre es un patrón faltante en el .gitignore (fase 1) —corrígelo antes de seguir—.

Fase 7 — Commitear el entregable

Dónde estás: verificación pasada, cero secretos a la vista. Ahora sí, tú —no yo, no el script— decides qué entra a la historia. Agregas los archivos que revisaste y commiteas con un mensaje claro:

git add .
git commit -m "Repositorio inicial: workflows exportados, normalizados y documentados"

(Y si el repo tiene un remoto en GitHub del Módulo 2, git push lo respalda y lo hace compartible.)

Qué esperar: un commit que captura el repositorio completo. git log lo muestra; git show --stat HEAD lista qué archivos entraron —revísalo una vez más para confirmar que no se coló nada indebido—. Con esto, cumbre-automations es un entregable real.

Fase opcional — Respaldar las credenciales, fuera del repo

Dónde estás: el repo commiteado, con los secretos correctamente afuera. Pero "afuera del repo" no puede significar "sin respaldo": las credenciales de Cumbre también necesitan una copia de seguridad, solo que en otro lado. Cierra el ciclo de la lección 3 con un respaldo cifrado que vive lejos del repositorio.

docker exec -u node "$CONTAINER" n8n export:credentials --all --output=/tmp/creds-backup.json
docker cp "$CONTAINER":/tmp/creds-backup.json ~/secure-backups/cumbre-creds-backup.json

Fíjate en dos decisiones deliberadas: es sin --decrypted (sale cifrado, no en texto plano), y el destino es ~/secure-backups/, una carpeta fuera del árbol de cumbre-automations, no dentro. Ese respaldo cifrado, para restaurarse, necesita la misma N8N_ENCRYPTION_KEY que lo cifró, así que guarda también esa llave en tu gestor de contraseñas —separada del respaldo, como la combinación y la caja fuerte de la lección 3—.

Qué esperar: un archivo de respaldo cifrado en un lugar seguro, y cero rastro de él en el repositorio. git status dentro de cumbre-automations no debe mostrar nada nuevo: el respaldo vive en otro universo. Con esto, tus credenciales están respaldadas y fuera del repo, que es justo el equilibrio que la lección 3 perseguía.

Cómo se revisa: la rúbrica del otro desarrollador

El estándar del proyecto no es "hice las ocho fases"; es "otro desarrollador aprobaría este repo". Vale la pena verlo con sus ojos, porque esa es la revisión que importa. Esta es la lista con la que un revisor competente juzgaría cumbre-automations, agrupada por lo que cada lección aportó:

Seguridad (lección 3) — lo que se revisa primero y con más severidad:

  • No hay ningún valor de credencial en el repo, ni cifrado ni en claro.
  • El .gitignore cubre .env, exportaciones de credenciales y .n8n/.
  • .env.example tiene los nombres de las variables pero ningún valor.
  • La historia de Git (no solo el estado actual) está limpia de secretos.

Exportación y limpieza (lecciones 2 y 4):

  • Los workflows están exportados por CLI, no descargados a mano.
  • El JSON está normalizado: sin pinData, versionId, meta.instanceId; claves ordenadas.
  • Un guardado sin cambios de lógica produciría un diff vacío tras normalizar.

Estructura (lección 5):

  • Layout claro: workflows/, credentials/, docs/, scripts/, archivos de config en la raíz.
  • Nombres de archivo legibles en kebab-case, no ids.
  • La organización del repo refleja la de la instancia.

Documentación (lección 6):

  • Un README por workflow con propósito, disparador, dependencias, credenciales y diagrama.
  • Un README de raíz que permite arrancar sin preguntarle al autor.
  • La prueba del desconocido pasa: alguien podría poner un workflow a correr solo con la doc.

Reproducibilidad (lección 7):

  • Existe un export.sh (o equivalente) que reproduce el estado del repo de un comando.
  • El script está documentado en el README como la forma de mantener el repo.

Si tu cumbre-automations marca todas estas casillas, no es un ejercicio: es un artefacto de portafolio. La casilla que más gente falla es la cuarta de seguridad —"la historia está limpia"—, porque revisan el estado actual y olvidan que un secreto commiteado y borrado sigue en la historia. Revísala con cuidado.

Defender el repo en una entrevista

Este repositorio no es solo un ejercicio terminado: es un artefacto de portafolio, algo concreto que puedes mostrar y defender cuando alguien te pregunte "¿sabes entregar automatizaciones como un profesional?". Vale la pena pensar de antemano cómo lo presentarías, porque las preguntas que te harían son las mismas que este módulo respondió.

Si un entrevistador abre tu cumbre-automations y te pregunta, tú deberías poder contestar sin dudar:

  • "¿Cómo garantizas que no se filtre una credencial?" — Muestras el .gitignore puesto desde el primer commit, explicas que ni las credenciales cifradas van al repo (la mitad del candado, la historia permanente), y que la referencia en el JSON es un puntero, no un secreto. Esa respuesta sola te separa de la mayoría de los candidatos.
  • "¿Por qué tus diffs son tan limpios?" — Explicas la normalización: los campos volátiles que quitas y el orden estable de claves, y demuestras que un guardado sin cambios de lógica produce un diff vacío. Es una respuesta que muy poca gente puede dar, y revela que entiendes qué hay dentro del JSON.
  • "¿Cómo mantienes esto al día?" — Enseñas el export.sh y explicas que un comando reproduce el estado del repo, y por qué la reproducibilidad es la que hace posible automatizar.
  • "¿Podría otro tomar esto sin ti?" — Aplicas la prueba del desconocido en vivo: abres un README de workflow y muestras que alguien podría arrancarlo solo con eso.

Fíjate en el patrón: cada pregunta que un buen entrevistador haría, este módulo la convirtió en una decisión de diseño que puedes señalar con el dedo en tu propio repo. No estás describiendo teoría; estás mostrando evidencia. Esa es la diferencia entre decir "sé usar n8n" y demostrar "soy dueño de un sistema de automatización" —y es, palabra por palabra, lo que las mejores ofertas piden—.

Guarda este repo. Púlelo. Cuando termines la guía completa —con los entornos del Módulo 4, las pruebas del Módulo 5 y la promoción del Módulo 6—, va a ser el proyecto que muestres, y cada módulo le agrega una capa que responde otra pregunta de entrevista.

Errores comunes

Exportar antes de poner el .gitignore (práctico, y el error de orden más grave). Qué pasa: alguien, con el entusiasmo de empezar, corre export.sh o exporta credenciales antes de crear el .gitignore, y en la primera exportación se genera un archivo que, sin la red puesta, un git add . captura. Por qué pasa: parece natural "primero traigo el contenido, después lo organizo". Con los secretos, ese orden es peligroso. Cómo detectarlo: si tu primer commit incluye algo que debía estar ignorado, invertiste el orden. Cómo corregirlo: el .gitignore es siempre la fase 1, antes de generar cualquier archivo. La secuencia del proyecto está diseñada precisamente para que la red exista antes que aquello que podría caerse.

Commitear sin la fase de verificación (práctico). Qué pasa: alguien salta de "terminé de documentar" directo a git add . && git commit, sin el git status y git diff de auditoría, y se lleva un secreto o un temporal a la historia. Por qué pasa: la verificación se siente como un paso opcional cuando tienes prisa. Cómo detectarlo: si commiteas sin haber mirado explícitamente qué estás commiteando, te falta la verificación. Cómo corregirlo: la fase 6 no es opcional; es el control de calidad antes de tocar la historia. Mira siempre qué entra antes de que entre. Es más barato revisar que reparar.

Documentar los cuatro workflows con la misma profundidad que el JSON, sin agregar valor (conceptual). Qué pasa: alguien, para "documentar completo", describe nodo por nodo cada workflow, repitiendo lo que el JSON ya dice, y no escribe los propósitos ni los supuestos. Por qué pasa: describir el cómo es fácil; pensar el por qué cuesta. Cómo detectarlo: si tu documentación se puede reconstruir mirando el canvas, no agrega nada. Cómo corregirlo: concéntrate en lo que el JSON no dice —propósito, supuestos, qué vigilar— y deja el cómo para el diagrama. La prueba del desconocido es tu juez: donde esa persona se atora, falta doc; donde se aburre, sobra.

Duplicar los workflows por entorno "para adelantar el Módulo 4" (conceptual). Qué pasa: alguien, sabiendo que vienen tres entornos, crea workflows-dev/, workflows-staging/ y workflows-prod/ con copias del mismo order-triage.json. Por qué pasa: confunde "tres entornos" con "tres copias de la lógica". Cómo detectarlo: si el mismo workflow está tres veces en tu repo, es esto. Cómo corregirlo: la lógica se versiona una vez; lo que cambia por entorno es la configuración, no el workflow, y eso lo maneja el Módulo 4 con una carpeta aparte. Un workflow, muchos entornos. Duplicar la lógica es garantizar que un día arregles un bug en una copia y lo dejes en las otras dos.

Ejercicios

Ejercicio 1 — Autoevalúa con la rúbrica. Toma tu cumbre-automations terminado (o el que construiste siguiendo el proyecto) y recórrelo con la rúbrica del otro desarrollador, casilla por casilla. Anota cuáles marcas con confianza y cuáles no. Para cada casilla que no puedas marcar, escribe en una frase qué falta.

Ver solución

No hay una respuesta única; el resultado es tu diagnóstico. Lo que la mayoría descubre es que las casillas de seguridad y estructura se marcan fácil, y que las que quedan flojas son dos: la de la historia limpia (porque se revisa el estado y no la historia) y la de la prueba del desconocido (porque uno documenta desde el conocimiento que ya tiene en la cabeza).

Si una casilla no la puedes marcar, ahí está exactamente tu siguiente tarea, y es pequeña y concreta: no "mejora el repo" en abstracto, sino "agrega el propósito al README de weekly-report" o "confirma con git log que no hay secretos en la historia". La rúbrica convierte "¿está bien mi repo?" en una lista de acciones puntuales.

Por qué funciona: aprender a revisarte con los ojos de otro es la habilidad que este módulo entero persigue. La rúbrica es el andamio para hacerlo antes de que te revise alguien de verdad —en una entrevista, en un pull request—. Cada casilla que arreglas tú es un comentario que no te van a hacer ellos.

Ejercicio 2 — Justifica el orden de las fases. Sin volver a mirar el proyecto, explica en una o dos frases por qué cada uno de estos órdenes es el correcto: (a) el .gitignore (fase 1) antes de exportar (fase 4); (b) la estructura (fase 2) antes de documentar (fase 5); (c) la verificación de seguridad (fase 6) antes del commit (fase 7).

Ver solución

(a) El .gitignore va antes de exportar porque la exportación puede generar archivos con secretos (sobre todo si tocas credenciales), y el .gitignore solo protege el futuro, no el pasado: puesto después, no saca de la historia lo que ya se coló. La red se pone antes de que haya algo que se pueda caer.

(b) La estructura va antes de la documentación porque la documentación vive dentro de la estructura —los READMEs van en docs/, que tiene que existir primero— y porque documentar tiene sentido cuando ya sabes dónde vive cada cosa. Primero el esqueleto, después la carne.

(c) La verificación va antes del commit porque el commit es lo que hace permanente el contenido en la historia de Git. Verificar después de commitear es revisar cuando ya es tarde: un secreto commiteado ya está en la historia aunque lo borres. El control de calidad va antes de la línea que no se puede deshacer, no después.

Por qué funciona: el orden de las fases no es cronológico por casualidad; es causal. Cada fase habilita o protege a la siguiente. Entender por qué ese orden —y no otro— es lo que te deja improvisar con criterio cuando un proyecto real no calce exacto con el de Cumbre. La secuencia es la enseñanza; las fases sueltas son solo tareas.

Ejercicio 3 — Simula un cambio y su ciclo completo. Imagina que mañana cambias en el editor el umbral de order-triage de 1500 a 2000. Escribe la secuencia exacta de pasos que seguirías para que ese cambio llegue al repositorio de forma limpia, desde que guardas en el editor hasta el commit.

Ver solución

La secuencia: (1) guardas el cambio en el editor de n8n; (2) desde la raíz del repo, corres ./scripts/export.sh, que re-exporta y normaliza los cuatro workflows; (3) corres git diff para revisar el cambio —y aquí está la recompensa de la normalización: el diff muestra solo la línea del umbral, 1500 → 2000, y nada más—; (4) si el cambio de lógica afecta la documentación (aquí, la variable PRIORITY_THRESHOLD en docs/order-triage.md), la actualizas en el mismo ciclo; (5) git status para confirmar que no se coló nada indebido; (6) git add y git commit -m "order-triage: subir el umbral de envío urgente a 2000".

Lo elegante es que este ciclo —editar, correr el script, revisar el diff limpio, actualizar la doc, verificar, commitear— es el mismo para cualquier cambio, chico o grande. Es el hábito que el módulo entero construyó, condensado en seis pasos que se vuelven automáticos.

Por qué funciona: un proyecto no termina cuando lo entregas; empieza a vivir. Este ejercicio te mueve del "monté el repo una vez" al "mantengo el repo cada vez que algo cambia", que es donde ocurre el trabajo real. Un repositorio profesional no es el que nació ordenado, sino el que sigue ordenado después de cincuenta cambios, y eso solo se logra con un ciclo repetible como este.

Resumen y siguiente paso

En esta lección integraste todo el módulo en un entregable real. Convertiste la instancia de Cumbre en el repositorio cumbre-automations, en ocho fases cuyo orden es la enseñanza: primero blindaste los secretos con el .gitignore (porque protege el futuro, no el pasado), después estructuraste el esqueleto, montaste el export.sh, exportaste y normalizaste de una pasada, documentaste para el handoff, verificaste la seguridad con ojo de auditor —antes de tocar la historia— y recién entonces commiteaste, decidiendo tú qué entra. Y viste el proyecto con los ojos de quien lo revisa, mediante una rúbrica que agrupa por seguridad, exportación, estructura, documentación y reproducibilidad, con la advertencia de que la casilla más olvidada es la de la historia limpia, no solo el estado.

Con esto cierras el Módulo 3 y la primera fase de la guía: "versionar workflows con Git". Ya sabes construir workflows (guías previas), versionarlos con Git (Módulos 1 y 2) y —ahora— exportarlos, limpiarlos, estructurarlos, documentarlos y automatizar todo eso en un repositorio que otro desarrollador puede tomar. Cruzaste de "constructor de workflows" a alguien que entrega un sistema.

El Módulo 4 abre la segunda fase. Hasta aquí, cumbre-automations es un repositorio; a partir del Módulo 4 se convierte en la fuente de verdad de tres entornos aislados —dev, staging y prod—, cada uno una instancia de n8n separada, levantada con Docker Compose, con su propia N8N_ENCRYPTION_KEY y sus propias credenciales de prueba o de producción. Vas a ver por qué un entorno de verdad no es "otra pestaña del navegador", cómo se aísla uno de otro, y cómo la separación entre "lógica común" y "configuración por entorno" que ya empezaste a diseñar aquí se vuelve la columna vertebral de un despliegue profesional. El repositorio que acabas de entregar es exactamente lo que el Módulo 4 necesita para empezar.

Recursos

← Anterior7. Automatizar la exportación con un scriptSiguiente →1. Introducción: qué es un entorno de verdad