El módulo 2 terminó con una promesa: que el artefacto reservalia/api:a3f9c21 que hoy espera en ECR empezaría a viajar solo hasta dev, staging y prod, y que el viernes por la tarde volvería a ser, sencillamente, un viernes por la tarde. Esta lección es el primer paso para cumplirla, y no consiste en escribir YAML —eso llega en la 03-02—, sino en entender qué separa exactamente un artefacto publicado de un artefacto desplegado, y qué tiene que estar en su sitio antes de que una máquina toque producción sin pedir permiso. Vamos a retomar la distinción entre Entrega Continua y Despliegue Continuo, ahora con un pipeline real delante; a enumerar los cinco requisitos sin los cuales automatizar el despliegue solo sirve para fallar más rápido; a diseñar la cadena de entornos de Reservalia decidiendo qué valida cada uno; y a mirar de frente las puertas de aprobación, incluida la más popular de todas: el freeze de los viernes.

1. De "el artefacto espera en ECR" a "el artefacto viaja solo"
2. Entrega Continua y Despliegue Continuo: dónde está exactamente la puerta
3. Los cinco requisitos previos de un CD sano
4. La cadena de entornos de Reservalia
5. Puertas de aprobación: manuales, automáticas y ventanas de despliegue
6. Qué cambia en el reparto de responsabilidades del equipo
7. El flujo completo commit → prod de Reservalia
8. Errores Comunes y Consejos
9. Ejercicios
10. Conclusión

Hagamos inventario honesto de la situación de Reservalia al empezar el módulo 3.

Cuando Diego fusiona un pull request en main, el workflow ci.yml ejecuta calidad, test y build en paralelo y, si los tres pasan, el job publicar sube a ECR la imagen reservalia/api:a3f9c21. Cuatro minutos después del merge existe un artefacto inmutable, verificado y trazable. Y ahí se queda.

Lo que ocurre a partir de ese punto es todavía el ritual del viernes de la lección 01-04: Diego abre una terminal, se conecta a la consola de AWS, edita a mano la definición de tarea de ECS para apuntar a la nueva etiqueta, ejecuta las migraciones desde psql y se queda mirando los logs durante tres horas. El artefacto es de 2026; el procedimiento es de 2012.

Visto en un diagrama, el pipeline de Reservalia hoy tiene una mitad automática y una mitad de personas:

Esa flecha de puntos es todo el módulo 3. Y no es solo lentitud: es la parte del proceso que no está escrita en ningún sitio, no se revisa, no se prueba y no se puede repetir igual dos veces. La brecha entre las dos mitades tiene un nombre técnico —el despliegue no está automatizado— pero también una consecuencia medible que ya conocemos:

Dos de las cuatro métricas no se han movido, y ninguna cantidad de pruebas adicionales las moverá. Son métricas de despliegue, y el despliegue es lo que empezamos ahora.

En la lección 01-01 definimos los tres términos de forma abstracta. Ahora podemos señalar el punto exacto del pipeline de Reservalia donde está la diferencia, que es mucho más útil.

La confusión habitual es pensar que la Entrega Continua es "CD a medias". No lo es: es el 90 % del trabajo. Todo lo difícil —automatizar el despliegue, hacer los entornos equivalentes, poder volver atrás, tener observabilidad— hay que resolverlo igual. Lo único que queda pendiente en el Despliegue Continuo es quitar una condición if de un workflow.

Dicho de otro modo: si eres capaz de desplegar a producción pulsando un botón que no da miedo, ya has hecho lo caro. Que el botón lo pulse una persona o una máquina es entonces una decisión de negocio, no de ingeniería, y depende de cosas como el sector (una fintech regulada puede necesitar dejar constancia de una aprobación humana), la madurez de la observabilidad o simplemente cuánta confianza tiene el equipo. Reservalia llegará a Entrega Continua en la lección 03-02 y quitará la puerta al final del módulo, cuando el rollback (03-05) y el monitoreo (03-06) estén montados.

Marta: "Prefiero desplegar diez veces al día cambios de veinte líneas que una vez al mes un cambio de dos mil. No porque sea valiente, sino justo por lo contrario: porque un cambio de veinte líneas que se rompe lo entiendo en un minuto."

Automatizar el despliegue sin estos cinco elementos no acelera la entrega: acelera la producción de incidentes. Cada uno responde a una pregunta concreta.

1. Una suite de pruebas en la que se confía. La pregunta es: si el pipeline está verde, ¿desplegarías sin mirar? Si la respuesta honesta es "depende de qué haya cambiado", la suite todavía no es una autorización, es una opinión. Reservalia cumple este requisito desde la 02-04: unitarias sobre calcularHuecos, integración contra PostgreSQL real y una política de cuarentena para las pruebas inestables. Una sola prueba flaky tolerada destruye este requisito entero, porque enseña al equipo a ignorar el rojo.

2. Un artefacto inmutable. ¿Lo que voy a poner en producción es exactamente lo que se validó? Con reservalia/api:a3f9c21 y el principio de "construir una vez, promocionar el mismo digest" de la 02-06, sí. Si cada entorno reconstruyera la imagen desde el código, el binario de prod sería un artefacto nunca probado, aunque el commit fuera el mismo.

3. Entornos equivalentes. ¿Lo que funciona en staging funcionará en prod? Solo si se parecen en lo que importa: misma versión de PostgreSQL (16), misma versión de Node (20.11.0, que es la de la imagen base), misma topología de red, mismas variables de configuración aunque con valores distintos. Equivalente no significa idéntico —prod tiene más instancias y datos reales—, significa que no hay diferencias que puedan cambiar el comportamiento del software. Este requisito es el que empuja hacia la Infraestructura como Código de la lección 03-03.

4. Un despliegue reversible. Si sale mal, ¿cuánto tardo en dejarlo como estaba? Es el requisito que más equipos se saltan y el que más caro sale. Nuria lo dijo en el módulo 1: "Un despliegue que no se puede deshacer en cinco minutos no es un despliegue, es una apuesta". Se desarrolla en la 03-05.

5. Observabilidad suficiente. Si algo se rompe, ¿me entero yo antes que el cliente? Desplegar automáticamente sin señales de producción es desplegar a ciegas y esperar a que suene el teléfono. Es el contenido de la 03-06, con el que se cierra el módulo.

Resumidos en una tabla, con la comprobación concreta que permite saber si se cumplen de verdad:

Los cinco forman un sistema: fallar en uno degrada a los otros cuatro. Sin observabilidad no sabes cuándo usar el rollback; sin rollback la observabilidad solo te sirve para ver el incendio en directo; y sin entornos equivalentes las pruebas de staging dejan de ser una autorización para pasar a prod, con lo que el requisito 1 se derrumba aunque la suite sea impecable.

Diego: "Si el CI tarda más que ir a por un café, dejo de mirarlo. Y si el despliegue tarda tres días, dejo de sentirlo mío."

Un entorno no es "una copia del sistema": es un lugar donde se responde una pregunta que no se puede responder antes. Si un entorno no responde ninguna pregunta nueva, sobra y solo añade latencia al lead time.

Tres decisiones de este diseño merecen explicación, porque son las que suele equivocar un equipo que monta su primera cadena de entornos:

No hay entorno de "QA" separado de staging. Añadir un entorno que solo sirve para que alguien mire lo mismo que se puede mirar en staging alarga el lead time sin responder ninguna pregunta nueva. La regla es: un entorno más, una pregunta más.

Los datos de staging son una copia anonimizada, no una copia. Copiar la base de datos de producción con nombres, teléfonos y correos de clientes reales a un entorno con menos control de acceso es, además de una mala práctica, un problema legal. El proceso de Reservalia sustituye nombres, teléfonos y correos por valores generados, y conserva volumen y distribución: 340 negocios, ~9.000 citas al mes, la misma proporción de citas canceladas. Eso es lo que hace que staging detecte un problema de rendimiento que dev jamás vería.

dev es un entorno desplegado, no el portátil de Diego. "En mi máquina funciona" no es una validación. dev es el primer sitio donde el artefacto se ejecuta sobre infraestructura de AWS de verdad, con IAM, con Secrets Manager y con un ALB delante. Muchos fallos —un permiso que falta, una variable mal escrita— aparecen exactamente ahí y en ningún otro sitio.

Como el artefacto es el mismo en los tres, saber en qué punto de la cadena está cada versión se reduce a preguntarle a cada entorno quién es. Gracias al endpoint /version de la 02-06, eso es un bucle de tres líneas:

curl -sf calla la barra de progreso y devuelve error si el HTTP no es 2xx; --max-time 5 evita que el script se quede colgado si un entorno no responde; jq -r extrae el campo commit sin comillas. Ejecutado un martes cualquiera, la salida de Reservalia debería parecerse a esto:

Es decir: la cadena avanza y prod va dos commits por detrás. Esa foto en tres líneas es el instrumento más barato que existe para responder la pregunta de Nuria a las 23:40 —"¿qué versión hay desplegada?"— y la usaremos en todas las lecciones del módulo.

Una puerta es una condición que un despliegue debe cumplir para avanzar al siguiente entorno. Hay tres familias, y no valen lo mismo.

La puerta manual tiene un uso legítimo y uno ilegítimo. Legítimo: decidir cuándo se lanza algo por razones de producto —una funcionalidad que debe coincidir con una campaña, un cambio que requiere avisar a los negocios—. Ilegítimo: "por si acaso". Una aprobación cuyo revisor no tiene ninguna información que el pipeline no tenga ya no es una puerta de calidad, es un sello de goma. Se nota fácilmente: si nadie ha rechazado nunca una aprobación, la puerta no está filtrando nada.

Y llegamos al freeze de los viernes, que casi todos los equipos han practicado alguna vez. El razonamiento es intuitivo: si desplegamos el viernes y se rompe, arruinamos el fin de semana de alguien. Miremos qué produce en realidad:

• El trabajo del jueves y del viernes se acumula, así que el lunes se despliega un lote mucho más grande. Y sabemos desde la 02-07 que el riesgo de un lote crece más deprisa que su tamaño.
• El lunes es, por tanto, el día más peligroso de la semana, precisamente por el freeze.
• El equipo aprende que desplegar es peligroso, lo que refuerza la política y cierra el círculo.

Por eso el freeze es un síntoma, no una solución: es lo que hace un equipo que no puede volver atrás en cinco minutos ni enterarse de un fallo en dos. La cura no es prohibir los viernes, es hacer que el despliegue del viernes sea tan aburrido como el del martes. Reservalia mantendrá el freeze durante buena parte de este módulo, y lo retirará —conscientemente y con datos— cuando estén montados el rollback de la 03-05 y las alertas de la 03-06.

Nota importante: prohibir los despliegues los viernes no impide que haya incidentes los viernes. Impide que haya arreglos los viernes, porque un hotfix urgente choca con la misma política.

Automatizar el despliegue no elimina trabajo humano: lo desplaza. Merece la pena hacerlo explícito, porque el cambio cultural es donde encallan la mayoría de las adopciones de CD.

Dos consecuencias que conviene aceptar desde el principio:

El autor del cambio se hace dueño de su cambio en producción. Es el famoso you build it, you run it. Cuando el despliegue tarda tres días y lo hace otra persona, es fácil desentenderse. Cuando tu commit está en producción cuarenta minutos después del merge, la retroalimentación es tuya y es inmediata. Esto no significa que Diego se convierta en el SRE de guardia; significa que ve las métricas de su cambio y participa cuando algo se tuerce.

El pipeline pasa a ser producción. Si el despliegue está automatizado, el workflow tiene permisos sobre la infraestructura y una vulnerabilidad en el pipeline es una vulnerabilidad en producción. Ese cambio de estatus —de "herramienta interna" a "sistema crítico"— es la razón de que exista la lección 04-03, dedicada a la seguridad del pipeline.

Este es el destino del módulo: el diagrama tal como quedará al terminar la lección 03-06. Todavía no sabes implementar la mayor parte, y no pasa nada; sirve como mapa para situar cada lección.

Recorriéndolo de arriba abajo aparece el índice del módulo: 03-02 construye las cajas de despliegue a dev y staging; 03-03 garantiza que esas tres cajas de entorno salen del mismo código; 03-04 convierte el despliegue a prod en un canary controlado; 03-05 dibuja las dos flechas de rollback; y 03-06 cierra el bucle con las métricas que deciden si el canary avanza o retrocede.

Y hay una propiedad del diagrama que conviene subrayar: el artefacto a3f9c21 aparece una sola vez, en el primer paso. Todo lo demás son movimientos del mismo digest. Ese es el principio de la 02-06 llevado hasta el final.

Error 1: automatizar el despliegue antes de poder volver atrás. Es el orden inverso al sensato. Si despliegas cinco veces al día y no sabes revertir, has multiplicado por cinco la exposición al riesgo sin tocar la capacidad de respuesta. Rollback primero, frecuencia después.

Error 2: llamar staging a un entorno que no se parece a producción. Un staging con SQLite, con 30 registros de prueba y una sola instancia no responde ninguna pregunta útil; solo genera una falsa sensación de validación y el clásico "pero si en staging funcionaba".

Error 3: acumular entornos. He visto cadenas dev → test → qa → uat → preprod → prod. Cada eslabón añade días de lead time y, casi siempre, ninguno responde una pregunta que no responda el anterior.

Error 4: usar una copia literal de la base de datos de producción en staging. Datos personales reales en un entorno con menos control de acceso, más gente con permisos y menos auditoría.

Error 5: confundir "tenemos aprobación manual" con "tenemos control". Si el aprobador no tiene información adicional ni criterio para rechazar, la puerta solo añade latencia.

Consejo 1: escribe qué pregunta responde cada entorno y ponlo en el README.md. Es el mejor filtro contra la proliferación de entornos.

Consejo 2: mide el tiempo que un artefacto pasa esperando en cada puerta. Suele ser el mayor componente del lead time, y es invisible hasta que lo mides.

Consejo 3: trata el freeze de los viernes como deuda técnica, con fecha de retirada y condiciones concretas para retirarlo, no como una política permanente.

Un equipo despliega a producción una vez cada tres semanas, con aprobación de un comité. Tiene buena CI: pruebas fiables, artefactos inmutables en un registro y main siempre verde. Quiere pasar a Entrega Continua. Evalúa los cinco requisitos previos e indica cuál abordar primero y por qué.

Reservalia se plantea añadir un entorno preprod entre staging y prod, idéntico a prod pero sin tráfico real. Argumenta a favor y en contra, y decide, indicando qué dato consultarías para decidir.

El director de tecnología propone: "Ya que vamos a automatizar, quitemos también la aprobación de prod: Despliegue Continuo puro desde mañana". Estás de acuerdo con el destino, pero no con la fecha. Escribe tres condiciones medibles que deberían cumplirse antes de quitar esa puerta.

Solución 1. El equipo ya cumple los requisitos 1 y 2 (pruebas fiables, artefacto inmutable). Faltan por evaluar el 3, el 4 y el 5. El primero que hay que abordar es el 4, el despliegue reversible, por dos razones. La primera es de riesgo: al pasar de un despliegue cada tres semanas a varios por semana, la exposición se multiplica, y sin capacidad de revertir cada incidente dura lo que dure el diagnóstico. La segunda es cultural y más importante: el comité de aprobación existe porque desplegar da miedo, y el miedo viene de que un error es irreversible. Demostrar que cualquier despliegue se deshace en cinco minutos es lo que hace negociable la existencia del comité; sin eso, cualquier propuesta de acelerar chocará —con razón— contra el argumento del riesgo.

El orden razonable a continuación sería: 5, observabilidad (sin señal no sabes cuándo revertir, así que el rollback queda a merced de que alguien se dé cuenta), y luego 3, entornos equivalentes, que es el más caro y lento porque implica Infraestructura como Código.

Solución 2. A favor: preprod idéntico a prod permite validar cambios de infraestructura y pruebas de carga sin riesgo, y es habitual en sectores con requisitos regulatorios. En contra: cuesta prácticamente lo mismo que prod (unos 900 €/mes para 340 negocios de pago, difícil de justificar), añade un eslabón al lead time y, sobre todo, no responde ninguna pregunta nueva si staging ya tiene datos anonimizados con volumen realista. El riesgo añadido es que un entorno sin tráfico real tampoco detecta problemas de concurrencia o de carga, que es justo lo que se le pediría.

Decisión: no añadirlo. El dato que lo confirma es el análisis de los incidentes de producción de los últimos seis meses: ¿cuántos habrían sido detectados por un preprod y no por staging? Si la respuesta es cero o uno, el entorno no se paga. Si aparecieran varios fallos ligados a diferencias de infraestructura, la respuesta correcta seguiría siendo probablemente arreglar staging —hacerlo más parecido a prod mediante IaC, lección 03-03— antes que añadir un sexto entorno.

Solución 3. Tres condiciones medibles y verificables:

1. Rollback demostrado: el workflow de vuelta atrás existe, está probado en un simulacro real y devuelve prod a la versión anterior en menos de 5 minutos de forma medida, no estimada.
2. Detección automática: existen alertas sobre síntomas (error rate y latencia p95 del endpoint de reserva) que disparan en menos de 2 minutos, y el registro de los últimos tres meses muestra que ningún incidente de severidad alta fue detectado primero por un cliente.
3. Historial de aprobaciones vacío de rechazos: durante al menos 30 despliegues consecutivos, la aprobación manual no ha rechazado ni modificado ninguno. Si nunca filtra, no aporta información y su coste en lead time es puro. Si sí ha rechazado alguno, hay que entender por qué antes de quitarla: probablemente el pipeline no está comprobando algo que sí debería.

Se puede añadir una cuarta condición de transición: aplicar el Despliegue Continuo primero al servicio menos crítico, o solo a los cambios que no tocan el dominio de pagos, y ampliar el alcance cuando el historial lo respalde.

Esta lección ha establecido el marco del módulo. El artefacto reservalia/api:a3f9c21 está listo desde el módulo 2; lo que falta es el camino que lo lleva hasta los 340 negocios, y ese camino tiene forma de cadena de entornos —dev para comprobar que arranca sobre AWS real, staging para comprobar que aguanta datos y volumen realistas, prod para los clientes— con puertas entre ellos.

Las ideas que conviene llevarse: la Entrega Continua es el 90 % del trabajo y el Despliegue Continuo es quitar una condición de un workflow, así que el objetivo real es un botón que no dé miedo; un CD sano necesita cinco requisitos —pruebas fiables, artefacto inmutable, entornos equivalentes, despliegue reversible y observabilidad— que forman un sistema donde fallar en uno degrada a los demás; cada entorno debe responder una pregunta que no se pueda responder antes, o sobra; las puertas manuales valen para decisiones de producto y las automáticas por métrica para decisiones técnicas; y el freeze de los viernes es el síntoma de un equipo que no puede volver atrás deprisa, no una política de calidad.

También ha cambiado el reparto de papeles: Nuria construye la plataforma en lugar de ejecutar despliegues, Marta cuida los objetivos en lugar de coordinar releases, y Diego se hace dueño de su cambio hasta producción. Y el pipeline, que tendrá permisos sobre la infraestructura, deja de ser una herramienta interna para convertirse en un sistema crítico.

La siguiente lección, Automatización del Despliegue, baja de la teoría al fichero: escribiremos .github/workflows/cd.yml línea a línea, veremos cómo se dispara desde el job publicar, cómo se autentica contra AWS con OIDC sin guardar claves, cómo se actualiza el servicio de ECS con el digest exacto, dónde vive la configuración de cada entorno —porque el artefacto es el mismo y lo que cambia es la configuración— y cómo se comprueba con un smoke test contra /version que lo que está corriendo es de verdad lo que creíamos haber desplegado.