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

5. Rollback y runbook de operación

Siguiente →

Descripción

Al terminar esta lección vas a poder revertir un cambio que rompió producción: volver al último JSON bueno del repositorio y re-importarlo al entorno afectado, con Git y la CLI que ya dominas. Vas a saber la diferencia entre las dos formas de "volver atrás" en Git —git revert y volver a un commit anterior— y cuándo usar cada una. Y vas a escribir un runbook: un procedimiento numerado, con responsable y verificación, que otra persona —o tú mismo bajo presión— pueda seguir sin pensar, a las tres de la mañana, cuando algo se rompió.

Esto importa porque ningún sistema es seguro sin una salida de emergencia, y el momento de construirla es antes de necesitarla. Todo lo que hiciste hasta aquí —versionar, aislar entornos, probar, promover con cuidado— reduce la probabilidad de que algo se rompa, pero no la lleva a cero. Un cambio bien probado a veces falla en prod por algo que staging no reprodujo. Cuando eso pasa, la pregunta no es "¿cómo evito el error?" —ya es tarde—, sino "¿en cuánto tiempo vuelvo a la versión que funcionaba?". La diferencia entre dos minutos y dos horas de pedidos rotos es exactamente lo que esta lección te da: un plan escrito y ensayado, en vez de una improvisación bajo pánico.

Conexión con el módulo: las lecciones 2, 3 y 4 construyeron el camino hacia adelante —promover, revisar, construir con IA— y su control de calidad. Esta lección construye la red por el otro lado: qué haces cuando, a pesar de todo el cuidado, un cambio llega a prod y falla. Aquí cobra sentido, por fin, la frase que repetiste desde el Módulo 1: "el repositorio es la fuente de verdad". El rollback es el momento en que esa fuente de verdad te salva: vuelves a ella. Y el runbook que escribes aquí es una pieza directa del entregable final de la lección 8. Es la lección que convierte tu repositorio de "un lugar donde guardo versiones" en "mi seguro contra los desastres".

Qué es un rollback

Empecemos por la palabra, porque es el concepto central.

Un rollback —"revertir", "volver atrás"— es devolver un sistema a un estado anterior que sí funcionaba, después de que un cambio lo rompió. No es "arreglar el cambio malo"; es abandonarlo y regresar a la última versión buena conocida. La distinción importa: cuando prod está roto y entran pedidos que fallan, no es momento de depurar el bug con calma —eso viene después, en dev, sin presión—. Es momento de parar el sangrado volviendo a lo que funcionaba. El rollback es el torniquete, no la cirugía.

Piénsalo como la llanta de refacción del auto. Cuando se te poncha una llanta en la carretera, no te pones a reparar el neumático averiado en el acotamiento, con los coches pasando: pones la refacción, que sabes que funciona, y sigues tu camino. La reparación del neumático averiado la haces después, en el taller, con tranquilidad. El rollback es poner la refacción: la versión anterior, que ya sabías buena, vuelve a su lugar para que el sistema siga andando. Depurar el cambio que falló es el taller, y es un problema de dev, no de prod.

Aquí es donde tu repositorio paga todo el trabajo que le dedicaste. Porque el "estado anterior que funcionaba" no es un recuerdo ni una esperanza: es un commit concreto en cumbre-automations, con su fecha, su autor y su motivo. La refacción está en la cajuela, inflada y lista. Un rollback bien hecho es, literalmente, sacar esa versión del repositorio y volver a ponerla en el entorno afectado. Sin repositorio, no hay refacción; solo un neumático averiado y la carretera.

Las dos formas de volver atrás en Git

Git ofrece dos maneras de regresar a un estado anterior, y confundirlas causa problemas, así que vale la pena distinguirlas con cuidado. Las dos parten de que el commit bueno existe en tu historial —por eso versionaste—.

Forma 1: git revert — deshacer un cambio creando uno nuevo. git revert toma un commit específico y crea un commit nuevo que deshace exactamente lo que aquel hizo. Si el commit malo agregó tres líneas y quitó una, el revert quita esas tres y vuelve a agregar la una. Lo clave: no borra el commit malo del historial; lo neutraliza con un commit encima que lo cancela. Tu historia queda completa —se ve el cambio malo y su reversión—, que es exactamente lo que quieres en un repositorio compartido: nadie pierde el registro de lo que pasó.

git revert <hash-del-commit-malo>

Esto abre un commit nuevo con un mensaje como Revert "order-triage: bajar umbral a 100", que cancela ese cambio. La historia gana una entrada, no pierde ninguna.

Forma 2: volver el archivo a como estaba en un commit anterior. A veces no quieres revertir "el último commit" entero, sino traer un archivo específico al estado que tenía en un commit bueno conocido. Para eso, recuperas la versión de ese archivo desde ese commit:

git checkout <hash-del-commit-bueno> -- workflows/order-triage.json

Esto trae el order-triage.json tal como estaba en el commit bueno, y lo deja en tu working tree listo para commitear. Es quirúrgico: toca solo ese archivo, no el resto del repositorio. Útil cuando sabes exactamente cuál era la última versión buena de un workflow y quieres esa, sin importar qué otros commits hubo en medio.

¿Cuál usar? La regla práctica:

  • Si el problema es "el último cambio fue malo, cancélalo" y quieres que la historia lo muestre limpio y compartible, usa git revert.
  • Si el problema es "quiero este workflow exactamente como estaba en tal versión buena", usa el git checkout <commit> -- archivo.

En los dos casos, el resultado que te importa es el mismo: en tu repositorio, workflows/order-triage.json vuelve a ser la versión buena. Y ese es solo el primer paso del rollback. Porque el repositorio no es la instancia.

La regla que evita destruir el trabajo de otros. Existe una tercera forma, git reset --hard, que borra commits del historial en vez de neutralizarlos. No la uses para un rollback en un repositorio compartido. Borrar historia en un repo donde trabaja más gente destruye el trabajo en vuelo de los demás y reescribe una historia que otros ya tienen. Para revertir, git revert es la forma segura: deja la historia intacta y agrega la corrección encima. Reescribir historia es una operación delicada que esta guía deliberadamente no usa para operar producción.

Del repositorio a la instancia: el rollback completo

Aquí está el punto que más se olvida y que hace la diferencia entre un rollback que funciona y uno que no. Volver el archivo a la versión buena en el repositorio no arregla prod. El workflow que está roto corre en la instancia de prod, no en tu repositorio. Arreglar el repo es necesario pero no suficiente: falta llevar esa versión buena de vuelta a la instancia.

Recuerda el modelo del Módulo 1: el repositorio es la fuente (source), la instancia es donde corre (runtime). Un rollback toca los dos, en orden:

  1. En el repositorio (source): vuelves order-triage.json a la última versión buena, con git revert o git checkout <commit> -- archivo, y lo commiteas. Ahora la fuente de verdad dice, otra vez, "esta es la versión correcta".
  2. En la instancia (runtime): re-importas esa versión buena a prod con el import:workflow de la lección 2, y la activas. Ahora la instancia corre, de nuevo, la versión buena.

Los dos pasos, siempre. Si haces solo el 1, tu repositorio está sano pero prod sigue roto —la refacción está en la cajuela pero no la pusiste—. Si haces solo el 2 —re-importas una versión vieja sin arreglar el repo—, prod funciona pero tu repositorio miente, y el próximo que promueva desde él va a re-romper todo. El rollback es volver la versión buena a la fuente y al runtime.

Esta es, exactamente, la promoción de la lección 2 puesta al servicio de la reversión. No hay un comando nuevo de rollback: hay el import:workflow que ya conoces, importando una versión anterior en vez de una nueva. Un rollback es una promoción hacia atrás en el tiempo: promueves a prod la versión que funcionaba ayer.

Rollback contra "roll forward": cuándo cada uno

Hay una decisión que conviene tener pensada de antemano, porque en el incidente no hay tiempo de deliberarla: ¿revertir a la versión anterior (rollback) o arreglar el problema con un cambio nuevo hacia adelante (roll forward)?

  • Rollback es volver atrás, a la versión buena conocida. Es lo correcto en la enorme mayoría de los incidentes, por una razón simple: la versión anterior ya sabías que funcionaba, así que volver a ella es predecible y rápido. Bajo presión, lo predecible gana.
  • Roll forward es arreglar el bug con un cambio nuevo que va hacia adelante, en vez de retroceder. Tiene sentido en un caso acotado: cuando volver atrás es imposible o peor que seguir. Por ejemplo, si la versión "anterior" también estaba rota de otra forma, o si un cambio de datos ya ocurrió y retroceder el workflow no lo deshace. En esos casos, el arreglo hacia adelante puede ser la única salida.

La regla práctica bajo presión: rollback por defecto, roll forward solo cuando el rollback no es una opción viable. El instinto de "mejor lo arreglo bien de una vez" empuja al roll forward, pero un arreglo nuevo hecho con prisa, sin probar, es justo lo que rompió prod en primer lugar. Volver a lo conocido primero, arreglar bien después, en dev, con calma. El roll forward de emergencia es la excepción que confirma la regla, no el camino habitual.

Qué es un runbook

Ahora la segunda mitad de la lección, y la que la vuelve profesional. Saber revertir no basta; hay que tenerlo escrito.

Un runbook es un procedimiento operativo escrito como una lista de pasos numerados, pensado para ejecutarse bajo presión, por alguien que quizás no diseñó el sistema. El nombre viene de operaciones: el "libro" que "corres" (run) cuando pasa algo. No es documentación explicativa —no cuenta por qué las cosas son como son—; es una receta de emergencia: haz esto, después esto, después verifica esto. Su valor está en que, en el peor momento —producción caída, gente esperando, el pulso acelerado—, no tienes que pensar ni recordar: sigues los pasos.

La analogía es la lista de emergencias de un piloto. Cuando falla un motor, el piloto no improvisa ni trata de recordar lo que aprendió hace años: saca la tarjeta de emergencia correspondiente y ejecuta los pasos en orden, uno por uno, sin saltarse ninguno. Esa tarjeta la escribieron con calma, en tierra, gente que pensó con cuidado qué hacer cuando falla un motor. El piloto no la diseña en el aire; la ejecuta. Un runbook es esa tarjeta para tu sistema: se escribe con calma, cuando todo funciona, para ejecutarse sin pensar cuando nada funciona.

Un buen runbook tiene una anatomía reconocible. Estos son sus elementos:

  • Título y disparador. Qué situación cubre este runbook. "Cuándo usar esto": por ejemplo, "cuando order-triage en prod está procesando pedidos mal después de una promoción".
  • Precondiciones. Qué necesitas tener a mano antes de empezar: acceso al repositorio, acceso al contenedor de prod, saber cuál era el último commit bueno.
  • Responsable. Quién ejecuta este runbook. En un equipo, quién es la persona (o el rol) que tiene la autoridad y el acceso para hacerlo.
  • Los pasos, numerados. La secuencia exacta, cada paso una acción concreta y verificable. Sin ambigüedad, sin "y entonces arreglas el problema": pasos que se ejecutan, no que se interpretan.
  • La verificación. Cómo sabes que funcionó. La señal concreta de que prod volvió a la normalidad: los pedidos vuelven a procesarse bien, el nodo del CRM ya no falla.
  • Qué hacer después. El seguimiento una vez pasada la emergencia: depurar el cambio malo en dev, con calma, para entender qué pasó.

Fíjate en que el runbook incluye responsable y verificación, no solo pasos. Sin responsable, en una emergencia dos personas hacen el rollback a la vez y se pisan, o nadie lo hace porque cada uno cree que le toca al otro. Sin verificación, ejecutas los pasos y no sabes si funcionó —y en producción, "creo que ya está" no es suficiente—. Un runbook sin esos dos no es un runbook; es una lista de comandos.

Ejemplo trabajado: el runbook de rollback de order-triage

Escribamos el runbook real de Cumbre, el que va en el repositorio (en docs/runbook-rollback.md) y que la lección 8 incluye en el entregable. Este es el documento que sigues cuando order-triage rompe producción.

# Runbook: rollback de order-triage en prod

## Cuándo usar esto
Cuando order-triage, en el entorno prod, está procesando pedidos de forma
incorrecta después de una promoción, y hay que volver a la última versión buena.

## Responsable
El operador de guardia con acceso al repositorio cumbre-automations y al
contenedor n8n-prod. Una sola persona ejecuta; las demás observan.

## Precondiciones (ten esto a mano antes de empezar)
- Acceso de escritura al repositorio cumbre-automations.
- Acceso al contenedor n8n-prod (docker exec).
- El hash del último commit bueno conocido (míralo con: git log --oneline
  workflows/order-triage.json).

## Pasos
1. Párate en el repositorio:
       cd cumbre-automations

2. Identifica el último commit bueno de order-triage:
       git log --oneline workflows/order-triage.json
   Anota el hash del commit ANTERIOR al que rompió prod. Ejemplo: a1b2c3d.

3. Vuelve el archivo a esa versión buena en el repositorio:
       git checkout a1b2c3d -- workflows/order-triage.json
       git commit -m "rollback: order-triage a la última versión buena (a1b2c3d)"

4. Copia el JSON bueno al contenedor de prod:
       docker cp workflows/order-triage.json n8n-prod:/tmp/order-triage.json

5. Re-importa la versión buena en prod:
       docker exec -u node -it n8n-prod n8n import:workflow \
         --input=/tmp/order-triage.json

6. Abre order-triage en el editor de prod. Verifica que la lógica es la
   versión buena y que las credenciales (AI Agent, HTTP Request) resuelven.

7. Activa order-triage en prod (interruptor de activación en el editor).

## Verificación (cómo sabes que funcionó)
- Un pedido de prueba entra y se procesa como antes del incidente.
- El nodo del CRM ya no falla en las ejecuciones nuevas.
- Los pedidos reales vuelven a clasificarse correctamente.

## Qué hacer después (ya sin presión)
- En dev, reproduce y depura el cambio que rompió prod. Entiende la causa.
- Cuando tengas el arreglo, promuévelo por el flujo normal:
  dev -> staging (con prueba en sandbox) -> revision de diff -> prod.
- Actualiza este runbook si algo del procedimiento no funcionó como esperabas.

Léelo con atención a lo que lo hace ejecutable bajo presión y no solo "correcto":

  • Cada paso es una acción concreta con su comando exacto. No dice "revierte el workflow"; dice git checkout a1b2c3d -- workflows/order-triage.json, el comando literal. Quien lo ejecuta no tiene que recordar la sintaxis a las tres de la mañana: la copia del runbook.
  • Los pasos combinan las dos mitades del rollback. Los pasos 1-3 arreglan el repositorio (source); los pasos 4-7 arreglan la instancia (runtime). El runbook no olvida la segunda mitad, que es la que la gente salta.
  • La verificación es concreta y observable. No dice "confirma que funciona"; dice "un pedido de prueba entra y se procesa como antes". Es una señal que puedes ver, no una sensación.
  • Hay un "después". El runbook para el sangrado (rollback) y separa explícitamente la cirugía (depurar en dev) para después. No mezcla apagar el incendio con investigar su causa.

Qué esperar al ejecutar este runbook en un incidente real: en cinco o seis minutos, prod vuelve a correr la versión que funcionaba, mientras el cambio que falló espera en dev para ser depurado con calma. Compara eso con la alternativa sin runbook: media hora recordando comandos, buscando cuál era el commit bueno, dudando de si ya arreglaste el repo o solo la instancia, todo con pedidos rotos entrando. El runbook convierte el pánico en procedimiento.

Ensayar el rollback antes de necesitarlo

Aquí está el consejo que separa a quien tiene un runbook de quien puede usarlo: ensáyalo antes del incidente. Un runbook que nunca ejecutaste es una hipótesis, no un plan.

La razón es simple y dura: un runbook escrito y no probado casi siempre tiene un error. Un comando con un nombre de contenedor equivocado, un paso que asume un acceso que no tienes, una verificación que no se puede observar. Y el peor momento para descubrir ese error es durante el incidente real, cuando cada minuto cuesta pedidos. Ensayarlo con calma —provocar a propósito un "problema" en staging y correr el runbook para revertirlo— es donde encuentras esos errores sin que cuesten nada.

El ensayo es sencillo y lo puedes hacer hoy: en staging (no en prod), promueve un cambio cualquiera, y después ejecuta tu runbook de rollback para volver atrás, siguiendo los pasos al pie de la letra, sin improvisar. Si algún paso no funciona como está escrito —el comando falla, la verificación no se puede observar—, ese es un hallazgo valioso: corrígelo en el runbook. Cuando el ensayo corre limpio de principio a fin, tienes un plan de verdad, no una intención.

Piénsalo como el simulacro de incendio de un edificio. No se hace el simulacro durante el incendio; se hace antes, en frío, para que cuando el fuego sea real, todos sepan la salida sin pensar. Nadie considera el simulacro una pérdida de tiempo el día que hay un incendio de verdad. Ensayar el rollback es tu simulacro de incendio, y el "incendio" en producción va a llegar algún día. Mejor haber ensayado.

Hay un beneficio extra del ensayo que conviene nombrar: te da confianza para promover. Cuando sabes que tu rollback funciona —porque lo ensayaste—, promueves a prod con más tranquilidad, porque sabes que si algo sale mal, tienes la salida probada. La red de seguridad no solo te salva cuando caes; te da el valor de caminar por la cuerda. Un equipo que ensayó su rollback despliega más seguido y con menos miedo, porque el costo de un error dejó de ser catastrófico.

Errores comunes

Arreglar el repositorio y olvidar re-importar a la instancia (práctico, la mitad olvidada). Qué pasa: alguien revierte order-triage.json a la versión buena en el repo, lo commitea, y da el rollback por hecho. Pero prod sigue corriendo la versión rota, porque nadie re-importó la buena a la instancia. Los pedidos siguen fallando mientras la persona cree que ya lo arregló. Por qué pasa: se confunde arreglar la fuente con arreglar el runtime; el repo se ve bien y da falsa sensación de terminado. Cómo detectarlo: si revertiste en el repo pero no corriste import:workflow contra prod, te falta la mitad que de verdad arregla producción. Cómo corregirlo: el rollback son dos pasos, source y runtime. El runbook los incluye a los dos precisamente para que no se salte el segundo. Arreglar el repo prepara la refacción; re-importar es ponerla en el auto.

Ponerse a depurar el bug en prod durante el incidente (conceptual). Qué pasa: prod está roto, y alguien, en vez de revertir, empieza a investigar por qué falla el cambio nuevo, editando en prod, probando hipótesis, mientras los pedidos siguen rotos. La investigación toma media hora; el rollback habría tomado cinco minutos. Por qué pasa: el instinto de "arreglar la causa" es fuerte, y revertir se siente como "rendirse". Cómo detectarlo: si estás depurando en producción con pedidos cayendo, invertiste el orden. Cómo corregirlo: primero el torniquete, después la cirugía. Revierte a la versión buena para parar el sangrado; depura la causa después, en dev, con calma. Producción no es el lugar para investigar; es el lugar para volver a funcionar lo antes posible.

No saber cuál era el último commit bueno (práctico). Qué pasa: llega el incidente, la persona abre el runbook, llega al paso "vuelve al commit bueno" y se da cuenta de que no sabe cuál era, porque los mensajes de commit son vagos ("cambios", "fix", "update") y no distinguen el bueno del malo. Por qué pasa: se descuidaron los mensajes de commit cuando todo funcionaba, y bajo presión no hay tiempo de reconstruir la historia. Cómo detectarlo: si al mirar git log de tu workflow no puedes decir en diez segundos cuál fue la última versión buena, tienes este problema latente. Cómo corregirlo: escribe mensajes de commit claros siempre —"order-triage: subir umbral a 5000", no "cambios"— para que el git log sea legible en una emergencia. El rollback depende de poder identificar el commit bueno rápido, y eso se gana con disciplina de commits antes del incidente.

Tener un runbook escrito pero nunca ejecutado (conceptual). Qué pasa: alguien escribe un runbook prolijo, lo guarda, y se queda tranquilo. Llega el incidente real, lo ejecuta por primera vez, y en el paso 5 el comando falla porque el nombre del contenedor estaba mal escrito. Ahora está depurando el runbook durante la emergencia. Por qué pasa: escribir el runbook se siente como terminar el trabajo; ejecutarlo en frío parece innecesario "porque ya está escrito". Cómo detectarlo: si tu runbook nunca corrió de principio a fin, no sabes si funciona; es una hipótesis. Cómo corregirlo: ensáyalo en staging, provocando un problema a propósito y revirtiéndolo con el runbook al pie de la letra. Los errores que encuentres en el ensayo son los que no vas a sufrir en el incidente. Un runbook probado es un plan; uno sin probar es un deseo.

Ejercicios

Ejercicio 1 — Elige la forma de revertir. Para cada situación, di si usarías git revert <commit> o git checkout <commit-bueno> -- workflows/order-triage.json, y por qué: (a) el último commit bajó el umbral a 100 y hay que cancelarlo, dejando la historia clara en un repo compartido; (b) quieres order-triage.json exactamente como estaba hace cinco commits, sin importar qué pasó en medio.

Ver solución

(a) git revert <commit>. Quieres cancelar un commit específico dejando la historia limpia y compartible: git revert crea un commit nuevo que deshace el malo sin borrarlo del historial, así que en el repo compartido queda el registro completo —el cambio malo y su reversión— y nadie pierde historia. Es la forma segura para producción y equipos.

(b) git checkout <commit-bueno> -- workflows/order-triage.json. Quieres un archivo específico en el estado de un commit concreto, sin que importe qué otros commits hubo entre medio. El checkout de archivo es quirúrgico: trae solo ese order-triage.json a como estaba en ese commit, listo para commitear, sin tocar el resto del repositorio.

En los dos casos, recuerda que revertir en el repositorio es solo la primera mitad: después hay que re-importar la versión buena a la instancia de prod para que el rollback llegue a producción.

Por qué funciona: la distinción es "cancelar un commit entero, con la historia visible" (revert) contra "traer un archivo a un estado conocido" (checkout de archivo). Confundirlas lleva a revertir de más o de menos. Y ninguna de las dos es git reset --hard, que borra historia y no se usa para operar producción en un repo compartido.

Ejercicio 2 — Encuentra el hueco en un runbook. Un compañero escribió este mini-runbook: "1. Revierte el workflow en el repo con git revert. 2. Verifica que prod ya funciona." ¿Qué le falta a este runbook para ser ejecutable de verdad? Nombra al menos tres cosas.

Ver solución

Le faltan varias cosas críticas:

  1. La mitad del runtime. Solo revierte en el repo (paso 1) y salta directo a verificar prod (paso 2), sin el paso intermedio de re-importar la versión buena a la instancia de prod con import:workflow. Tal como está, el repo queda bien pero prod sigue roto: la verificación del paso 2 fallaría siempre.
  2. Comandos exactos. "Revierte con git revert" no dice qué commit revertir ni cómo identificarlo. Bajo presión, hace falta el comando literal y el paso de mirar git log para encontrar el commit correcto.
  3. Responsable. No dice quién ejecuta. En una emergencia, sin un responsable, o dos personas se pisan o nadie actúa.
  4. Verificación concreta. "Verifica que prod ya funciona" es una sensación, no una señal. Debería decir algo observable: "un pedido de prueba entra y se procesa correctamente; el nodo del CRM ya no falla".
  5. Precondiciones y qué hacer después. No dice qué necesitas tener a mano antes (accesos, el hash del commit bueno) ni qué hacer con el bug una vez revertido (depurarlo en dev).

Por qué funciona: el ejercicio te entrena a leer un runbook con ojo crítico, que es como se mejoran. El hueco más grave es casi siempre el mismo: olvidar la mitad del runtime (re-importar a la instancia). Un runbook que arregla el repo pero no la instancia da la ilusión de haber resuelto el incidente cuando producción sigue caída.

Ejercicio 3 — Ensaya un rollback en staging. Describe, paso a paso, cómo ensayarías tu runbook de rollback de order-triage en staging, sin tocar prod, para descubrir errores antes de un incidente real. ¿Qué "problema" provocarías a propósito, y cómo sabrías que el ensayo fue exitoso?

Ver solución

Un ensayo posible:

  1. En staging, promueve a propósito una versión "mala" de order-triage —por ejemplo, una con el umbral cambiado a un valor absurdo como 100— siguiendo el flujo de promoción normal. Este es el "problema provocado": un cambio que quieres revertir.
  2. Verifica que staging ahora se comporta "mal" (manda todo a revisión manual con el umbral de 100). Este es tu incidente simulado.
  3. Ahora ejecuta tu runbook de rollback al pie de la letra, pero apuntando a staging en vez de prod (contenedor n8n-staging): identifica el último commit bueno, revierte el archivo en el repo, copia y re-importa la versión buena a staging, verifica y activa.
  4. Confirma la verificación: staging vuelve a comportarse con el umbral bueno.

Sabes que el ensayo fue exitoso si corriste el runbook de principio a fin sin improvisar ni corregir sobre la marcha. Si algún paso falló —un comando con el contenedor equivocado, una verificación que no pudiste observar—, ese es exactamente el hallazgo que buscabas: corrígelo en el runbook ahora, en frío, para que no te sorprenda en el incidente real de prod.

Por qué funciona: el ensayo en staging te da todos los beneficios de probar el rollback —encontrar los errores del runbook, ganar confianza, medir cuánto tarda— sin ninguno de los riesgos de tocar prod. Es el simulacro de incendio: se hace en frío, precisamente para que el día del fuego real no sea la primera vez. Y como bonus, te deja desplegar a prod con más tranquilidad, sabiendo que tu salida de emergencia está probada.

Resumen y siguiente paso

En esta lección construiste la salida de emergencia del sistema. Entendiste que un rollback es volver a la última versión buena conocida cuando un cambio rompió producción —el torniquete, no la cirugía; la llanta de refacción, no la reparación en el acotamiento— y que tu repositorio es lo que hace posible ese regreso, porque la versión buena vive ahí como un commit concreto. Distinguiste las dos formas de volver atrás en Git —git revert, que cancela un commit dejando la historia visible, y git checkout <commit> -- archivo, que trae un archivo a un estado conocido— y por qué git reset --hard no se usa para operar producción en un repo compartido. Grabaste que el rollback toca source y runtime: revertir en el repositorio y re-importar la versión buena a la instancia de prod, porque arreglar solo la fuente deja producción rota. Escribiste un runbook con su anatomía completa —disparador, precondiciones, responsable, pasos numerados con comandos exactos, verificación observable y qué hacer después— y viste por qué ensayarlo antes del incidente es lo que convierte un runbook escrito en un plan que de verdad funciona, además de darte confianza para promover.

Antes de avanzar deberías poder: explicar qué es un rollback y por qué no es lo mismo que depurar el bug; elegir entre git revert y git checkout <commit> -- archivo según la situación; describir las dos mitades del rollback (repo e instancia); y nombrar los elementos de un runbook y por qué se ensaya en frío.

La lección 6 cambia de registro: de la operación a la decisión. Ya sabes hacer todo el ciclo —promover, revisar, construir con IA, revertir— a mano, en Community, a costo cero. La lección 6 pone eso frente a la alternativa de pago: el Git nativo de n8n (Enterprise), con sus botones de push y pull integrados en la interfaz. Vas a comparar los dos flujos con honestidad, ver una matriz de decisión por tamaño de equipo, presupuesto y cumplimiento, y confirmar lo único que no cambia en ningún caso, pagues o no pagues: el repositorio sigue siendo la fuente de verdad, y el rollback que acabas de aprender funciona igual en los dos mundos.

Recursos

← Anterior4. MCP para construir workflows contra entornos no-prodSiguiente →6. Git nativo (Enterprise) vs el flujo CLI: la decisión