Módulo 6: Promoción, rollback y entrega documentada

7. Chequeos de CI y el artefacto de portafolio

Siguiente →

Descripción

Al terminar esta lección vas a poder poner un chequeo de CI en GitHub Actions que valida el JSON de tus workflows en cada commit, automáticamente y a costo cero: un inspector que revisa que cada workflow esté bien formado y normalizado sin que nadie tenga que acordarse. Vas a entender qué es la integración continua, la anatomía de un archivo de GitHub Actions pieza por pieza, y cómo el chequeo se conecta con la normalización del Módulo 3. Y vas a armar el artefacto de portafolio —el repositorio con su workflow versionado, más la evidencia visual— que las ofertas piden como filtro de contratación, con la guía de cómo defenderlo en una entrevista.

Esto importa por dos razones que se juntan. La primera es de calidad: hasta ahora, la revisión del JSON dependía de que tú te acordaras de mirarlo (lección 3). Un chequeo de CI convierte "acordarse de revisar" en "el sistema revisa solo, siempre", que es la única forma de que la disciplina sobreviva a las prisas y a los meses. La segunda es de carrera: el mercado no pide un workflow que funcione —eso lo asume—, pide un artefacto que demuestre que sabes entregar como profesional. Un repositorio con CI verde en cada commit es exactamente esa prueba: le dice a quien te evalúa "esta persona no solo construye, valida y opera". Es la diferencia entre contar que sabes y mostrarlo.

Conexión con el módulo: la lección 3 te enseñó a revisar el diff a mano; esta automatiza una parte de esa revisión —la validación del JSON— para que ocurra sola en cada commit. Es el mismo espíritu del script export.sh del Módulo 3 (convertir un paso manual en uno automático), ahora del lado de la verificación. Y prepara el terreno para la lección 8: el chequeo de CI y el artefacto de portafolio que armas aquí son dos piezas del entregable final. Esta es la penúltima parada; después viene el proyecto que junta todo y cierra la guía.

Qué es la integración continua (CI)

Empecemos por el nombre, porque suena más grande de lo que necesitas que sea.

CI son las siglas de continuous integration, integración continua. En su forma más simple —la que te sirve aquí—, CI es la práctica de que, cada vez que subes un cambio al repositorio, un sistema automático corre una serie de verificaciones sobre ese cambio, sin que tú hagas nada. Si las verificaciones pasan, el cambio queda marcado como bueno; si alguna falla, el sistema te avisa de inmediato. La palabra "continua" es literal: la verificación ocurre continuamente, en cada cambio, no una vez al mes cuando alguien se acuerda.

Piénsalo como el detector de humo de tu casa. No tienes que acordarte de revisar si hay humo cada noche: el detector está ahí, siempre encendido, y si aparece humo, suena solo. Su valor no está en que detecte mejor que tú —tú también olerías el humo—, sino en que no depende de que te acuerdes. Vigila mientras duermes, mientras estás distraído, mientras tienes prisa. Un chequeo de CI es ese detector para tu repositorio: verifica cada commit, sin cansarse, sin olvidarse, aunque tú estés pensando en otra cosa.

Aquí está la conexión con lo que ya sabes. En la lección 3 aprendiste a revisar el JSON de un workflow a mano: leer el diff, buscar sorpresas, confirmar que está normalizado. Eso funciona cuando te acuerdas y tienes tiempo. Pero un martes ocupado, con tres cosas urgentes, es fácil commitear sin revisar bien. El chequeo de CI atrapa lo que a ti se te pasa: valida el JSON en cada commit, sin excepción. No reemplaza tu revisión —el juicio de negocio sigue siendo tuyo—; la respalda con una red que no se distrae.

Qué es GitHub Actions

La herramienta con la que vas a hacer CI, gratis, se llama GitHub Actions.

GitHub Actions es el sistema de automatización integrado en GitHub que corre tareas en respuesta a eventos de tu repositorio: cuando haces push, cuando abres un pull request, en un horario fijo, o cuando lo disparas a mano. Cada tarea corre en una computadora temporal que GitHub te presta —un runner—, hace su trabajo, reporta si pasó o falló, y desaparece. No tienes que administrar ningún servidor: GitHub pone la máquina, tú pones las instrucciones.

Y es gratis para lo que necesitas. Los repositorios públicos tienen GitHub Actions sin costo, y los privados traen una cuota mensual gratuita más que suficiente para validar el JSON de unos workflows en cada commit. Como todo en esta guía, el camino por defecto no cuesta nada.

Un detalle de vocabulario que confunde, y conviene aclarar de una vez: en GitHub Actions, a cada archivo de automatización se le llama, también, un "workflow". Es una colisión de nombres desafortunada, porque en n8n "workflow" es otra cosa. Para no perdernos, en esta lección voy a decir "workflow de CI" cuando hable del archivo de GitHub Actions, y "workflow de n8n" —o simplemente order-triage— cuando hable de lo que construyes en n8n. Dos "workflows" distintos: uno automatiza tu repositorio, el otro automatiza el negocio de Cumbre.

Anatomía de un workflow de CI

Un workflow de CI de GitHub Actions es un archivo de texto en formato YAML, que vive en una carpeta especial de tu repositorio: .github/workflows/. YAML es un formato para escribir configuración de forma legible, con la estructura marcada por la sangría —parecido a cómo Python usa la sangría—. GitHub lee cualquier archivo .yml de esa carpeta y lo trata como un workflow de CI.

Antes de escribir el nuestro, veamos las piezas de las que está hecho cualquier workflow de CI, porque son pocas y se repiten en todos. Toma este esqueleto:

name: validate-workflows

on:
  push:
    paths:
      - 'workflows/**.json'
  pull_request:
    paths:
      - 'workflows/**.json'

jobs:
  validate-json:
    runs-on: ubuntu-latest
    steps:
      - name: Check out the repository
        uses: actions/checkout@v4
      - name: Validate the JSON
        run: echo "aquí van las verificaciones"

Desármalo pieza por pieza, porque una vez que reconoces la estructura, todos los workflows de CI se leen igual:

  • name — el nombre del workflow de CI, como aparecerá en la pestaña "Actions" de tu repositorio en GitHub. Aquí, validate-workflows. Es puramente para que lo identifiques.
  • on — el disparador: qué eventos hacen que este workflow corra. Aquí decimos "corre en cada push y en cada pull_request, pero solo cuando cambian archivos que calzan con workflows/**.json". Ese filtro de paths es una cortesía: no tiene sentido validar el JSON de los workflows si el commit solo tocó el README. El ** significa "en cualquier subcarpeta".
  • jobs — la lista de trabajos a ejecutar. Un workflow de CI puede tener varios; el nuestro tiene uno, llamado validate-json.
  • runs-on — en qué tipo de máquina corre el trabajo. ubuntu-latest es una máquina Linux estándar que GitHub provee, con herramientas comunes ya instaladas —incluido jq, que vamos a usar—.
  • steps — los pasos del trabajo, en orden. Cada paso o usa una acción preexistente (uses) o corre un comando de shell (run).
  • uses: actions/checkout@v4 — el primer paso casi siempre es este: "trae el contenido de mi repositorio a la máquina temporal". Sin esto, el runner está vacío y no tiene tus archivos que validar. actions/checkout es una acción oficial de GitHub; el @v4 fija la versión.
  • run: — corre un comando de shell en la máquina. Aquí es donde pones tus verificaciones de verdad. Fíjate en algo tranquilizador: este run es shell normal, el mismo de tu terminal. No aplica ninguna restricción del nodo Code de n8n —esto corre en una máquina Linux de GitHub, fuera de n8n por completo—, así que tienes jq, bash, y todo lo que necesites, igual que en el export.sh del Módulo 3.

Con estas piezas ya puedes leer cualquier workflow de CI. Ahora escribamos el que valida tus workflows de n8n.

El workflow de CI que valida tu JSON

Este es el corazón de la lección: un workflow de CI que, en cada commit que toque tus workflows de n8n, verifica dos cosas —que el JSON es parseable (está bien formado) y que está normalizado (sin campos volátiles, con las claves ordenadas), como lo dejó el export.sh del Módulo 3—. Va en .github/workflows/validate-workflows.yml:

name: validate-workflows

# Corre en cada push y pull request que toque el JSON de los workflows.
on:
  push:
    paths:
      - 'workflows/**.json'
  pull_request:
    paths:
      - 'workflows/**.json'

jobs:
  validate-json:
    runs-on: ubuntu-latest
    steps:
      # 1. Trae el repositorio a la máquina temporal.
      - name: Check out the repository
        uses: actions/checkout@v4

      # 2. Verifica que cada workflow es JSON parseable (bien formado).
      - name: Every workflow must be parseable JSON
        run: |
          for f in workflows/*.json; do
            echo "Checking $f is valid JSON"
            jq empty "$f"
          done

      # 3. Verifica que cada workflow está normalizado, como lo deja export.sh.
      - name: Every workflow must be normalized
        run: |
          for f in workflows/*.json; do
            normalized=$(jq -S 'del(.pinData, .versionId, .active, .triggerCount, .meta.instanceId)' "$f")
            if [ "$normalized" != "$(cat "$f")" ]; then
              echo "::error file=$f::$f no está normalizado. Corre ./scripts/export.sh y commitea otra vez."
              exit 1
            fi
          done

Léelo por bloques, porque cada uno tiene un propósito claro:

El disparador (on). Corre en cada push y pull_request, filtrado a los cambios de workflows/**.json. Así, cada vez que promueves un cambio de order-triage al repositorio —o cuando abres un pull request para revisarlo, como en la lección 3—, el chequeo corre solo. La revisión automática y la manual se combinan: tú lees el diff, GitHub valida el JSON, y las dos deben pasar antes de integrar.

El primer paso: checkout. Trae tus archivos a la máquina de GitHub. Obligatorio; sin él no hay nada que validar.

El segundo paso: JSON parseable. El bucle recorre cada workflows/*.json y corre jq empty "$f". Aquí jq empty es un truco preciso: intenta parsear el archivo y no produce ninguna salida si el JSON está bien formado, pero falla con error si el JSON está roto —una llave sin cerrar, una coma de más—. Y recuerda del export.sh: en un script (y en CI vale igual), un comando que falla detiene todo. Así, si algún workflow tiene JSON inválido, este paso falla y el chequeo se pone en rojo. Es la verificación mínima: "esto al menos es JSON de verdad".

El tercer paso: JSON normalizado. Este es más fino y conecta directo con el Módulo 3. Para cada workflow, calcula cómo se vería normalizado —quitando los mismos campos volátiles que el export.sh (pinData, versionId, active, triggerCount, meta.instanceId) y ordenando las claves con jq -S— y lo compara con lo que hay commiteado. Si no coinciden, significa que alguien commiteó un JSON sin normalizar (probablemente lo bajó del editor a mano en vez de usar el script), y el paso falla con un mensaje que dice exactamente cómo arreglarlo: Corre ./scripts/export.sh y commitea otra vez. El ::error file=...:: es la forma de GitHub Actions de marcar el error apuntando al archivo culpable, para que en el pull request se vea justo dónde está el problema.

Qué esperar cuando esto está puesto: cada vez que commiteas o abres un pull request que toca un workflow, en GitHub aparece una marca —una palomita verde si todo pasó, una equis roja si algo falló—. Si intentas commitear un order-triage.json roto o sin normalizar, el chequeo se pone rojo y te lo dice antes de que ese JSON malo llegue a prod. Es el detector de humo funcionando: tú ni te enteras la mayoría de las veces, porque casi siempre está verde, y justo por eso vale, porque el día que se pone rojo te salvó de un problema que no viste.

Por qué esto vale tanto por tan poco

Detente en la economía de lo que acabas de montar. Son unas veinte líneas de YAML, se escriben una vez, y a partir de ahí cada commit, para siempre, queda validado sin que nadie haga nada. Compara eso con la alternativa: confiar en que cada persona del equipo, en cada commit, se acuerde de correr las verificaciones a mano. La primera es una garantía; la segunda es una esperanza. Y la garantía costó veinte líneas y cero pesos.

Hay una razón más profunda por la que esto importa en un equipo: el chequeo de CI hace la calidad independiente de la disciplina de cada persona. No importa si el que commiteó hoy es cuidadoso o distraído, experto o nuevo: el JSON malo no pasa, porque el detector no depende de él. Eso es lo que convierte una buena práctica personal en una garantía de equipo. Y es, no por casualidad, exactamente lo que un empleador quiere ver: no que tú seas cuidadoso, sino que hayas construido un sistema que no depende de que nadie lo sea.

Cerrar la puerta: el CI como requisito para integrar

Hay un paso más que convierte el chequeo de "un aviso" en "una barrera de verdad", y conecta el CI con el pull request de la lección 3. GitHub permite marcar un chequeo de CI como obligatorio para integrar (required status check): con eso activado, un pull request cuyo chequeo esté en rojo no se puede fusionar a la rama principal. No es que aparezca una equis y la gente decida ignorarla; es que el botón de fusionar se bloquea hasta que el chequeo pase.

Esto —parte de lo que GitHub llama branch protection, protección de rama— cierra el círculo entre las dos redes del módulo. La revisión humana de la lección 3 aprueba el juicio; el CI obligatorio garantiza la forma. Un cambio solo llega a la rama principal —y de ahí a la promoción— si un humano aprobó el diff y el CI está en verde. Ninguna de las dos redes sola alcanza; juntas y obligatorias, nada roto ni sin revisar pasa a producción.

La analogía: es la diferencia entre un detector de humo que solo suena y uno conectado al sistema que, además de sonar, cierra la válvula del gas. El primero avisa y confía en que alguien reaccione; el segundo actúa. Marcar el CI como obligatorio es conectar tu detector a la válvula: el JSON malo no solo dispara la alarma, sino que queda físicamente impedido de avanzar. Para un proyecto personal quizás no lo necesites; para un equipo, es lo que hace que la garantía sea real y no una sugerencia.

El artefacto de portafolio

Ahora la segunda mitad de la lección, la que conecta todo tu trabajo con tu carrera.

Un artefacto de portafolio es algo concreto que puedes mostrar y que demuestra una capacidad, en vez de solo afirmarla. No es un currículum que dice "sé versionar workflows"; es un repositorio que alguien puede abrir y verificar que sabes. La diferencia es enorme en una entrevista: cualquiera puede decir que sabe entregar automatizaciones profesionales; muy pocos pueden abrir un repositorio real y señalar la evidencia.

El mercado lo pide así de directo. Recuerda la frase que atraviesa toda la guía —"as version-controlled, documented JSON"— y añádele la actitud con la que muchas ofertas la acompañan: "no prototype = no conversation" —sin un prototipo, no hay conversación—. No es crueldad; es un filtro de eficiencia. Quien contrata sabe que un artefacto real separa a quien hizo de quien leyó sobre, y prefiere empezar la conversación por ahí. Tu artefacto de portafolio es tu entrada a esa conversación.

¿Qué compone el artefacto? Dos cosas que se refuerzan:

  • El repositorio versionado —cumbre-automations—: el workflow order-triage exportado, normalizado, documentado, con las credenciales fuera, los entornos por Docker Compose, el runbook, y —ahora— el chequeo de CI con su marca verde. Es la sustancia.
  • La evidencia visual —una captura del workflow order-triage abierto en el editor de n8n, mostrando su Webhook, su nodo AI Agent y su nodo HTTP Request conectados—. Es la prueba de que el JSON versionado corresponde a un workflow real que funciona. La captura muestra que funciona; el repo muestra que sabes entregarlo. Juntos cuentan la historia completa: "construyo esto, y lo entrego como un profesional".

La captura importa más de lo que parece. Un repositorio de JSON, por sí solo, es abstracto para muchos evaluadores; una imagen del workflow armado lo vuelve tangible en un vistazo. Pon la captura en el README de raíz, arriba, como portada: lo primero que ve quien abre tu repo es el workflow real, y debajo, la prueba de que sabes versionarlo, probarlo y operarlo.

Cómo defenderlo en una entrevista

El artefacto no habla solo; tú lo defiendes. Y la buena noticia es que las preguntas que te harían son las mismas que este módulo —y toda la guía— respondió. Prepara estas defensas, porque son las que separan a quien muestra un repo de quien lo entiende:

  • "¿Cómo llevas un cambio a producción?" — Abres el runbook de promoción y explicas el flujo de la lección 2: sacar del repo, revisar el diff, importar inactivo, verificar credenciales, activar a mano. No describes teoría; señalas tu propio procedimiento escrito.
  • "¿Y si el cambio rompe producción?" — Abres el runbook de rollback de la lección 5 y explicas las dos mitades —repo e instancia— y que lo ensayaste en staging. Muy pocos candidatos tienen un rollback ensayado que mostrar.
  • "¿Cómo sabes que el JSON entregado está bien?" — Muestras la pestaña "Actions" con el chequeo de CI en verde y explicas que cada commit se valida solo, así la calidad no depende de que alguien se acuerde. Señalas el detector de humo funcionando.
  • "Si usas IA para construir, ¿cómo te aseguras de que no rompa nada?" — Explicas el lazo seguro de la lección 4: la IA construye en dev vía MCP, Git registra, tú revisas el diff, y solo lo aprobado se promueve. Demuestras que sabes usar la IA sin perder el control.
  • "¿Podría otro tomar esto sin ti?" — Abres el README de handoff y muestras que alguien podría arrancar el sistema solo con la documentación. La prueba del desconocido, en vivo.

Fíjate en el patrón, que ya viste en el proyecto del Módulo 3 y aquí se completa: cada pregunta que un buen entrevistador haría, esta guía la convirtió en una decisión de diseño que puedes señalar con el dedo en tu propio repositorio. No estás describiendo lo que sabes; estás mostrando evidencia de lo que hiciste. Esa es la diferencia entre "sé usar n8n" y "soy dueño de un sistema de automatización" —y es, palabra por palabra, lo que las mejores ofertas piden—.

Errores comunes

Confundir el "workflow" de GitHub Actions con el workflow de n8n (conceptual). Qué pasa: alguien lee "workflow" en la documentación de GitHub Actions y cree que está configurando su order-triage, o al revés. Se confunde sobre qué archivo edita y dónde. Por qué pasa: la colisión de nombres es real y desafortunada; los dos se llaman "workflow". Cómo detectarlo: si no tienes claro si estás tocando el .yml de CI o el .json de n8n, tienes la confusión. Cómo corregirlo: el workflow de CI es el .yml en .github/workflows/, automatiza tu repositorio, y lo lee GitHub. El workflow de n8n es el .json en workflows/, automatiza el negocio de Cumbre, y lo corre n8n. Son dos cosas distintas que casualmente comparten nombre; tenlo presente y no se mezclan.

Creer que el chequeo de CI reemplaza la revisión humana (conceptual). Qué pasa: alguien pone el workflow de CI y concluye que ya no necesita leer los diffs, porque "el sistema valida solo". Después promueve un cambio con JSON perfecto pero con una lógica desastrosa para el negocio —el umbral en 100—, que el CI aprobó porque el JSON era válido. Por qué pasa: el CI en verde da una sensación de "todo bien" que se confunde con "está revisado". Cómo detectarlo: si dejaste de leer diffs porque tienes CI, delegaste en la máquina un juicio que es humano. Cómo corregirlo: el CI valida que el JSON esté bien formado y normalizado; no juzga si el cambio es buena idea. Ese juicio de negocio sigue siendo tuyo, con la revisión de diff de la lección 3. El CI y la revisión humana son dos redes distintas: una atrapa el JSON roto, la otra atrapa la mala decisión. Las dos hacen falta.

Poner el archivo de CI en el lugar equivocado (práctico). Qué pasa: alguien crea el validate-workflows.yml en la raíz del repo, o en workflows/, y GitHub Actions nunca lo corre. Se frustra porque "el CI no funciona". Por qué pasa: GitHub solo busca workflows de CI en una carpeta específica, y es fácil no saberlo. Cómo detectarlo: si tu chequeo no aparece nunca en la pestaña "Actions", revisa dónde pusiste el archivo. Cómo corregirlo: el archivo tiene que estar en .github/workflows/ —esa ruta exacta, con el punto inicial—. GitHub lee solo de ahí. Es un requisito estricto de la plataforma, no una convención opcional.

Mostrar un repo sin evidencia visual del workflow (práctico, de portafolio). Qué pasa: alguien comparte su repositorio de JSON versionado en una entrevista, y el evaluador —que quizás no lee JSON con fluidez— no logra "ver" el workflow y pierde interés. El trabajo estaba, pero no se comunicó. Por qué pasa: para quien lo hizo, el JSON es el workflow; para quien lo evalúa desde afuera, es texto abstracto. Cómo detectarlo: si tu repo no tiene una captura del workflow armado, le falta la mitad que lo hace tangible. Cómo corregirlo: pon una captura del order-triage abierto en el editor —con sus nodos conectados— arriba en el README de raíz. La imagen muestra que funciona; el repo muestra que sabes entregarlo. Juntos cuentan la historia; por separado, cada uno se queda a medias.

Ejercicios

Ejercicio 1 — Lee el workflow de CI. Sin correrlo, lee el validate-workflows.yml de esta lección y responde: (a) ¿qué eventos hacen que corra, y por qué se filtra por paths? (b) ¿qué hace exactamente jq empty "$f" y por qué sirve para validar? (c) ¿qué detecta el tercer paso que el segundo no, y con qué mensaje ayuda al que se equivocó?

Ver solución

(a) Corre en cada push y cada pull_request, pero solo cuando el cambio toca archivos que calzan con workflows/**.json. El filtro por paths evita correr la validación cuando el commit solo tocó, por ejemplo, el README: no tiene sentido validar el JSON de los workflows si ningún workflow cambió. Es una cortesía que ahorra ejecuciones inútiles.

(b) jq empty "$f" intenta parsear el archivo como JSON y no produce ninguna salida si está bien formado, pero falla con error si el JSON está roto (una llave sin cerrar, una coma de más). Como en CI un comando que falla detiene el paso y pone el chequeo en rojo, jq empty sirve como prueba mínima de "esto al menos es JSON válido".

(c) El tercer paso detecta que el JSON, aunque sea válido, no está normalizado: compara el archivo commiteado con cómo se vería tras quitar los campos volátiles y ordenar las claves (lo que hace el export.sh). Si no coinciden, significa que alguien commiteó un JSON sin pasar por el script —probablemente bajado del editor a mano—, y falla con el mensaje Corre ./scripts/export.sh y commitea otra vez, que le dice exactamente cómo arreglarlo.

Por qué funciona: si pudiste responder las tres, ya puedes leer un workflow de CI, que es el 80% de saber escribirlos. Y ves cómo el chequeo automatiza justo las dos verificaciones que en el Módulo 3 hacías a mano —JSON válido y normalizado—, ahora en cada commit sin que nadie se acuerde.

Ejercicio 2 — Distingue las dos redes. Para cada problema, di si lo atraparía el chequeo de CI, la revisión humana de diff (lección 3), o ninguno de los dos: (a) un order-triage.json con una llave sin cerrar; (b) un cambio que baja el umbral de revisión manual a 100, colapsando al equipo de Cumbre; (c) un JSON válido pero sin normalizar, bajado del editor a mano; (d) un secreto del CRM pegado en claro dentro del JSON.

Ver solución

(a) CI. Una llave sin cerrar hace el JSON no parseable; jq empty falla y el chequeo se pone rojo. Es exactamente lo que el segundo paso atrapa.

(b) Revisión humana. El JSON es válido y estaría normalizado, así que el CI lo aprueba sin problema —para la máquina, un umbral de 100 es tan legítimo como uno de 5000—. Solo un humano que conoce el negocio de Cumbre sabe que 100 es absurdo. Es el juicio de negocio de la lección 3.

(c) CI. El tercer paso compara con la forma normalizada y falla si no coincide, pidiendo correr export.sh. La revisión humana también podría notarlo, pero el CI lo garantiza en cada commit.

(d) Los dos, idealmente. La revisión humana de diff lo atraparía (buscas sk-, Bearer, claves largas). Un chequeo de CI podría extenderse para buscar patrones de secretos también —una mejora razonable—, pero el validate-workflows.yml de esta lección, tal como está, no lo hace: valida forma y normalización, no busca secretos. La primera red real contra secretos sigue siendo el .gitignore del Módulo 3 y la revisión de diff.

Por qué funciona: el ejercicio deja clara la división de trabajo. El CI atrapa problemas mecánicos (JSON roto, sin normalizar) de forma automática e infalible; la revisión humana atrapa problemas de juicio (mala decisión de negocio, secreto colado) que requieren entender el contexto. Confundir las dos —creer que el CI verde significa "revisado"— es el error de la lección. Las dos redes son distintas y las dos hacen falta.

Ejercicio 3 — Prepara una defensa de entrevista. Un entrevistador abre tu cumbre-automations y pregunta: "Veo que usas IA para construir algunos workflows. ¿Cómo te aseguras de que la IA no meta algo malo en producción?" Escribe la respuesta que darías en cuatro o cinco frases, señalando piezas concretas de tu repositorio.

Ver solución

Una respuesta posible:

"La IA nunca toca producción; construye solo en mi entorno dev, que está aislado por Docker Compose y, de hecho, tiene el módulo MCP deshabilitado en prod con N8N_DISABLED_MODULES=mcp, así que ni siquiera es posible conectarla ahí. Cuando la IA propone un cambio en dev, yo lo exporto y lo commiteo, y entonces reviso el diff —no lo que la IA dice que hizo, sino lo que efectivamente cambió— con un pull request, aquí en el repo. Además, este chequeo de CI en verde valida el JSON en cada commit, y este runbook de rollback me deja volver atrás en minutos si algo se cuela. O sea: la IA acelera la construcción, pero el diff que reviso yo y el flujo de promoción son los que deciden qué llega a prod. La IA propone; yo apruebo."

Por qué funciona: la respuesta convierte una pregunta abstracta en un recorrido por evidencia concreta del repo —el candado de MCP por entorno, el pull request con el diff, el CI verde, el runbook—. No describe buenas intenciones; señala mecanismos que el entrevistador puede verificar abriendo el repositorio. Esa es la diferencia entre defender un artefacto y solo hablar de uno.

Resumen y siguiente paso

En esta lección automatizaste la verificación y armaste tu carta de presentación profesional. Entendiste que CI es correr verificaciones automáticas en cada commit —el detector de humo que no depende de que te acuerdes— y que GitHub Actions es la herramienta gratuita que lo hace, con sus workflows de CI en .github/workflows/. Aprendiste la anatomía de un workflow de CI pieza por pieza —name, on, jobs, runs-on, steps, uses, run— y escribiste validate-workflows.yml, que en cada commit verifica que tus workflows de n8n sean JSON parseable (con jq empty) y estén normalizados (comparando con la forma que deja el export.sh del Módulo 3), poniendo el chequeo en rojo con un mensaje útil si algo falla. Viste por qué eso vale tanto por tan poco: hace la calidad independiente de la disciplina de cada persona, que es justo lo que un empleador quiere ver. Y armaste el artefacto de portafolio —el repositorio versionado más la evidencia visual del workflow— que las ofertas piden como filtro ("no prototype = no conversation"), con las defensas de entrevista preparadas: cada pregunta de un buen entrevistador es una decisión de diseño que puedes señalar con el dedo en tu repo.

Antes de avanzar deberías poder: explicar qué es CI y por qué su valor está en no depender de que te acuerdes; leer un workflow de CI y decir qué hace cada pieza; distinguir qué atrapa el CI de qué atrapa la revisión humana; y nombrar qué compone el artefacto de portafolio y cómo lo defenderías.

La lección 8 es el proyecto final, y cierra la guía. Vas a integrar todo —los seis módulos— en el entregable completo y defendible: el repositorio cumbre-automations con el JSON normalizado y documentado, los tres entornos por Docker Compose, la pasada de sandbox ejecutada, el runbook de promoción y rollback, y el chequeo de CI que acabas de montar. Se entrega exactamente como lo pide el mercado: "as version-controlled, documented JSON". Es el ensayo general completo, la prueba de que cruzaste de constructor de workflows a dueño del sistema de automatización, y el artefacto que vas a defender en la entrevista que te espera.

Recursos

← Anterior6. Git nativo (Enterprise) vs el flujo CLI: la decisiónSiguiente →8. Proyecto final: entrega versionada y documentada