Los cursos de CI/CD suelen fallar en el mismo punto: enseñan pipelines sobre un "hola mundo" que no tiene base de datos, ni migraciones, ni dos aplicaciones que compartan código, ni un equipo con opiniones distintas. Y luego, en un proyecto real, nada encaja. Este curso hace lo contrario: construiremos, paso a paso, el pipeline completo de una aplicación con la complejidad justa para que los problemas de verdad aparezcan. Esa aplicación se llama Reservalia. En esta lección la vamos a conocer a fondo: qué hace el producto, quién forma el equipo, cómo está organizado el repositorio, qué comandos existen ya —porque el pipeline no inventa nada, solo invoca lo que el proyecto ya sabe hacer—, qué entornos hay y a qué infraestructura desplegamos. Terminaremos con la hoja de ruta del curso aplicada a Reservalia y con lo que necesitas instalado para seguirlo. Todavía no escribiremos ningún workflow: la primera pieza real de pipeline se construye en la lección 02-02.

1. Qué es Reservalia
2. El equipo: Marta, Diego y Nuria
3. Cómo trabajan hoy (y por qué duele)
4. La estructura del repositorio
5. Los package.json y los comandos que el pipeline invocará
6. El entorno de desarrollo local con Docker Compose
7. Los tres entornos: dev, staging y prod
8. La infraestructura AWS de destino
9. La hoja de ruta del curso aplicada a Reservalia
10. Cómo seguir el curso si no usas Node.js
11. Qué necesitas instalado
12. Errores comunes y consejos
13. Ejercicios
14. Conclusión

Reservalia es una plataforma SaaS de reservas de cita para pequeños negocios de servicios: peluquerías, clínicas dentales, talleres mecánicos, fisioterapeutas, centros de estética. Es una empresa ficticia creada para este curso; cualquier parecido con la realidad es intencionado pero no real.

El producto tiene dos caras:

• El panel del negocio. El dueño de la peluquería configura sus servicios (corte, color, tratamiento), sus profesionales, los horarios de apertura y sus vacaciones. Consulta la agenda del día, confirma citas y ve estadísticas básicas.
• La página pública de reserva. El cliente final entra desde un enlace, ve los huecos libres, elige uno y reserva sin registrarse. Recibe una confirmación por correo y un recordatorio 24 horas antes.

Modelo de negocio: suscripción mensual por negocio, con tres planes. Ahora mismo tienen 340 negocios de pago y procesan unas 9.000 citas al mes.

No es un ejemplo de juguete, y esto importa. Reservalia tiene exactamente los ingredientes que hacen interesante un pipeline:

Si consigues automatizar Reservalia, sabrás automatizar tu proyecto.

Tres personas, tres puntos de vista. Los tres aparecerán durante todo el curso, y sus discusiones son las que probablemente tendrás tú con tu equipo.

Lleva cuatro años en Reservalia y arrastra la responsabilidad de que el producto funcione. Es quien decide qué se despliega y cuándo, y quien recibe la llamada del comercial cuando un cliente se queja.

• Qué le preocupa: que las incidencias no se repitan y poder justificar ante dirección el tiempo que el equipo dedica a "cosas que no son funcionalidades".
• Su papel en el curso: aporta el punto de vista de negocio. Es quien pregunta "¿cuánto cuesta esto y qué ganamos?" (la lección 01-02) y quien pulsará el botón de aprobación en la puerta manual del despliegue a producción.
• Su frase: "Prefiero desplegar diez veces al día y que cada despliegue me dé igual, que desplegar una vez a la semana y no dormir el jueves."

Tres años en la empresa. Escribe la mayor parte de apps/api y es, hoy, la única persona que sabe desplegar. Sabe perfectamente que el proceso actual es malo; lo que no ha tenido nunca es tiempo para arreglarlo.

• Qué le preocupa: que el pipeline le ralentice. Le da pánico un CI que tarde 40 minutos en decirle si su cambio está bien.
• Su papel en el curso: es el escéptico productivo. Cada vez que añadamos un paso al pipeline, Diego preguntará cuánto tiempo suma. Gracias a él, el pipeline final será rápido.
• Su frase: "Si el CI tarda más que ir a por un café, lo acabaré ignorando."

Se incorporó hace ocho meses, a media jornada compartida con otro producto. Montó la infraestructura de AWS a mano, desde la consola web, porque había que salir a producción ya. Lleva las guardias.

• Qué le preocupa: que la infraestructura no esté documentada en ninguna parte salvo en su cabeza, y que un rollback hoy signifique recompilar y volver a subir por SFTP con clientes esperando.
• Su papel en el curso: aporta la perspectiva de operación. Es quien insiste en la infraestructura como código (03-03), en el rollback (03-05) y en la monitorización (03-06).
• Su frase: "Un despliegue que no se puede deshacer en cinco minutos no es un despliegue, es una apuesta."

Recordemos el punto de partida, ahora con el detalle completo del proceso:

Y los problemas de este ritual, enumerados sin piedad:

Cada línea de esta tabla desaparecerá en algún momento del curso. Guárdala: en la lección final (07-06) la repasaremos entera.

Reservalia tiene un único repositorio en github.com/reservalia/reservalia, organizado como monorepo con workspaces de npm. Esta es su estructura tal como está hoy, antes de empezar:

Tres decisiones de esta estructura merecen explicación, porque condicionan todo el pipeline:

Monorepo con un único package-lock.json. Al usar workspaces de npm, hay un solo fichero de bloqueo en la raíz que gobierna las dependencias de api, web y tipos-compartidos. Ventaja: un único npm ci instala todo de forma coherente y reproducible. Consecuencia para el pipeline: la instalación se hace una vez en la raíz, no una por aplicación.

packages/tipos-compartidos. Aquí viven los tipos que la API y la web comparten (por ejemplo, la forma de una Cita). Es lo que garantiza que si Diego cambia el modelo de datos, la web deje de compilar en CI en lugar de romperse en producción. También significa que un cambio en ese paquete obliga a probar las dos aplicaciones: es la complicación que hace interesante el "ejecutar solo lo afectado" de la lección 04-04.

.nvmrc. Un fichero de una línea que dice qué versión de Node usa el proyecto. Es la pieza más barata de reproducibilidad que existe:

Con eso, el portátil de Diego, el de Marta y el runner de CI usan exactamente la misma versión. En la lección 01-01 vimos que la versión no fijada es uno de los enemigos clásicos de la build reproducible; este fichero lo resuelve.

Aquí está una idea central del curso, y conviene subrayarla:

El pipeline no inventa nada. Solo ejecuta, en una máquina limpia, los mismos comandos que tú ejecutas en tu portátil.

Por eso, antes de escribir ningún workflow, el proyecto debe tener sus comandos bien definidos. Si npm test no funciona en tu máquina, no funcionará en CI. Si funciona en tu máquina pero solo porque tienes una variable de entorno que nadie más tiene, fallará en CI. Un pipeline es, sobre todo, un revelador de suposiciones ocultas.

Punto por punto, porque cada línea tiene un motivo:

• "private": true evita que el paquete raíz se publique por accidente en el registro público de npm. En un monorepo es obligatorio.
• "workspaces" declara los subproyectos. Al ejecutar npm ci en la raíz, npm instala las dependencias de todos ellos y crea los enlaces entre tipos-compartidos y las aplicaciones que lo usan.
• "engines" documenta la versión de Node soportada. Combinado con .nvmrc, deja constancia explícita del requisito.
• --workspaces --if-present ejecuta el script en cada subproyecto que lo tenga definido, y no falla en los que no lo tengan. Es lo que permite que un solo npm test en la raíz pruebe la API, la web y el paquete compartido.

Con esto, el pipeline entero podría reducirse a cuatro comandos. Compruébalo:

Estos cinco comandos son, literalmente, el esqueleto del pipeline que construiremos en el módulo 2.

Detalles importantes para el pipeline:

• test:unidad y test:integracion están separados. Las unitarias son rápidas y no necesitan base de datos; las de integración necesitan un PostgreSQL levantado. Esta separación es la que nos permitirá, en 02-04, dar feedback rápido a Diego: primero las rápidas, y solo si pasan, las lentas.
• --max-warnings 0 en el lint. Sin esto, ESLint termina con código de salida 0 aunque haya avisos, y el pipeline se pondría verde con problemas dentro. Recuerda de 01-03: el pipeline solo entiende de códigos de salida.
• typecheck separado de build. tsc --noEmit comprueba los tipos sin generar ficheros. Es rápido y puede correr en paralelo con los tests.
• migrate existe como script. Hoy Diego pega SQL a mano; el proyecto ya tiene el comando, solo que nadie lo usa. En la lección 04-06 lo integraremos en el despliegue.
• Versiones exactas, sin ^. "express": "4.19.2" y no "^4.19.2". Junto con npm ci, garantiza que dos instalaciones den lo mismo. La estrategia completa de dependencias es materia de 04-02.

Fíjate en que los nombres de los scripts coinciden con los de la API: build, test, lint, typecheck. Esta convención no es cosmética: es lo que hace que npm run test --workspaces funcione y lo que permitirá que el pipeline trate ambas aplicaciones con la misma lógica.

Consejo transferible: unificar los nombres de los scripts entre subproyectos es una de las inversiones más rentables antes de montar un pipeline. Si en un proyecto el comando es npm test y en otro npm run test:ci, tu YAML se llenará de casos especiales.

Para que las pruebas de integración funcionen —tanto en el portátil como después en CI— hace falta un PostgreSQL. Reservalia lo levanta con Docker Compose:

Cuatro cosas que explicar, porque todas reaparecerán en el pipeline:

La versión está fijada: postgres:16.3. No postgres:latest. Si en local desarrollas contra PostgreSQL 16 y producción corre 15, tarde o temprano una consulta funcionará en tu máquina y fallará en producción. La versión de la base de datos es parte de la reproducibilidad.

El healthcheck es la línea más importante del fichero. Un contenedor de PostgreSQL "arrancado" no significa "listo para aceptar conexiones": hay unos segundos de inicialización. Sin healthcheck, las pruebas de integración fallan de forma intermitente porque la base de datos aún no acepta conexiones. Y eso es exactamente un test flaky, el veneno del que hablábamos en 01-02. La causa número uno de flakiness en CI es no esperar a que los servicios estén realmente listos.

Mailpit sustituye al proveedor de correo real. Reservalia envía confirmaciones y recordatorios. En local y en pruebas, esos correos no deben salir a internet: Mailpit los captura y los muestra en una web. La regla general que aplicaremos en 02-04: en pruebas, ningún servicio externo real.

La contraseña desarrollo está escrita en claro, y está bien. Porque es una base de datos local, efímera y sin datos reales. En staging y prod jamás haremos esto: allí las credenciales vienen de un gestor de secretos. Distinguir cuándo un valor es un secreto y cuándo no es parte de la materia de 04-03.

El flujo de trabajo diario de Diego, en cuatro comandos:

Cuando en el módulo 2 configuremos el CI, verás que el pipeline hace exactamente lo mismo: preparar Node, instalar dependencias, levantar los servicios necesarios y ejecutar comandos. No hay magia.

Un entorno (definido en 01-01) es una instancia desplegada y ejecutable del sistema, con su propia configuración y sus propios datos. Reservalia tendrá tres:

Dos principios que rigen los tres entornos y que conviene interiorizar ya:

Principio 1: el mismo artefacto en los tres. Es la regla de promoción de 01-01. La imagen reservalia/api:a3f9c21 que se prueba en dev es exactamente la misma que llega a staging y a prod. Lo único que cambia entre entornos es la configuración inyectada por fuera:

Principio 2: los datos de producción nunca salen de producción. Copiar la base de datos de prod a staging "para probar con datos reales" es una práctica frecuente y una muy mala idea: Reservalia guarda nombres, teléfonos y correos de clientes finales. staging usa datos generados con volumen realista, no datos reales.

Nuria montó esto a mano desde la consola de AWS. En el módulo 3 lo pasaremos a Terraform para que sea reproducible; de momento, esta es la foto de a dónde despliega el pipeline:

Qué hace cada pieza y por qué está ahí:

Y el recorrido completo de un cambio, del portátil de Diego al cliente final:

Este diagrama es el objetivo del curso. Al terminar el módulo 3, Reservalia tendrá exactamente este flujo funcionando.

Qué habrá cambiado en Reservalia al final de cada módulo:

Reservalia usa Node.js y TypeScript, pero el curso no trata sobre Node.js. Trata sobre pipelines. Si tu día a día es Python, Java, Go, PHP, Ruby o .NET, todo lo que aprendas se aplica igual: lo único que cambia son los comandos concretos de cada paso.

Aquí está la tabla de traducción. Guárdala:

Lo que es idéntico en todos los lenguajes —y es la inmensa mayoría del curso:

• Los conceptos: trigger, job, etapa, runner, artefacto, entorno, promoción.
• El criterio de éxito o fracaso: el código de salida de cada comando.
• La estructura del pipeline: instalar → verificar → construir → publicar → desplegar.
• La estrategia de entornos y la regla de construir una vez y promocionar.
• Los contenedores: un Dockerfile de Python y uno de Node se parecen muchísimo.
• Las estrategias de despliegue, el rollback, los feature flags y la monitorización.
• Las métricas DORA y todo lo relativo a seguridad y secretos.

Sugerencia práctica: si quieres sacar el máximo partido, adapta cada ejercicio a tu propio proyecto. Cuando en 02-02 configuremos npm ci && npm test, monta en paralelo el equivalente con pip install && pytest en un repositorio tuyo. Aprenderás el doble.

Para leer el curso y entender los ejemplos: nada. Todos los ficheros están completos en las lecciones.

Para reproducir los ejemplos, que es muy recomendable:

Opcionales, y solo a partir del módulo 3:

Comprobación rápida de tu entorno:

Si no puedes instalar nada (por ejemplo, en un ordenador corporativo restringido): puedes seguir prácticamente todo el curso creando un repositorio en GitHub desde el navegador y editando los workflows desde la interfaz web. Los runners de GitHub ejecutan en la nube. Es menos cómodo, pero funciona.

Error 1: querer automatizar antes de que los comandos funcionen en local. Si npm test no funciona en tu portátil, no funcionará en CI. El pipeline es un revelador de suposiciones ocultas: variables de entorno que solo tú tienes, servicios que están arrancados en tu máquina desde hace semanas, ficheros que nunca subiste al repositorio. Primero haz que funcione en una máquina limpia; luego automatízalo.

Error 2: no fijar las versiones de las herramientas. .nvmrc, engines, postgres:16.3 en lugar de postgres:latest, dependencias sin ^. Cada versión no fijada es una build que algún día dejará de funcionar sin que nadie haya tocado nada, y ese es el tipo de fallo más caro de diagnosticar.

Error 3: nombres de scripts distintos en cada subproyecto. Si apps/api usa npm test y apps/web usa npm run test:ci, tu pipeline se llenará de casos especiales. Unifica los nombres antes de escribir el primer workflow: es media hora de trabajo que ahorra días.

Error 4: copiar la base de datos de producción a staging. Es tentador ("probamos con datos reales") y es una fuga de datos personales esperando a ocurrir. Reservalia guarda teléfonos y correos de clientes finales. Genera datos ficticios con volumen realista.

Error 5: olvidar el healthcheck de los servicios auxiliares. "Contenedor arrancado" no es "servicio listo". Es la causa número uno de tests intermitentes en CI, y como vimos en 01-02, los tests flaky destruyen la confianza en el pipeline entero.

Consejo 1: si tienes un proyecto propio, úsalo en paralelo. Aplica cada lección a Reservalia y también a tu proyecto. La transferencia de conocimiento es mucho mayor cuando te enfrentas a las particularidades de tu propio código.

Consejo 2: escribe hoy tu propia tabla del ritual del viernes. Enumera todos los pasos manuales de tu proceso de despliegue actual, con su duración. Es una lista incómoda de leer y es exactamente el mapa de lo que vas a automatizar.

Consejo 3: un README.md que funcione es el primer paso de CI. Si un desarrollador nuevo puede clonar el repositorio y tener el proyecto funcionando siguiendo el README sin preguntar a nadie, tu proyecto está listo para automatizarse. Si no, arregla eso primero: el pipeline es exactamente ese README ejecutado por una máquina.

Sin escribir nada de YAML —todavía no toca—, y usando únicamente lo que sabes del repositorio de Reservalia, responde:

1. ¿En qué orden ejecutarías npm ci, lint, typecheck, test:unidad, test:integracion y build? Justifica el orden.
2. ¿Cuáles de esos pasos pueden ejecutarse en paralelo y cuáles obligatoriamente en serie?
3. ¿Qué paso necesita que haya un PostgreSQL levantado, y qué implica eso para el runner?
4. Un cambio toca solo apps/web/src/paginas/PanelNegocio.tsx. ¿Sería correcto ejecutar únicamente las pruebas de apps/web? ¿Y si el cambio tocara packages/tipos-compartidos/src/index.ts?

Reservalia necesita decidir, para cada valor de configuración, si es un secreto (va al gestor de secretos), una variable de entorno normal (puede estar en el repositorio) o algo que no debe existir en ese entorno. Completa la tabla y justifica los tres casos que te parezcan menos evidentes:

Imagina que Reservalia estuviera escrita en Python con FastAPI en vez de Node.js con Express. Escribe:

1. La estructura equivalente de apps/api/ (nombres de ficheros de configuración y de gestión de dependencias).
2. El equivalente de los cinco comandos del pipeline (npm ci, lint, typecheck, test, build).
3. Qué partes del docker-compose.yml cambiarían y cuáles no.
4. Qué partes del curso dejarían de aplicar. (Pista: pocas.)

Solución al Ejercicio 1

1. Orden y justificación

El principio que gobierna este orden se llama fail fast: coloca primero lo más rápido y lo que más probablemente falle. Si Diego se ha dejado un console.log o un tipo incompatible, quieres que lo sepa en 40 segundos, no después de esperar seis minutos a las pruebas de integración. Ordenar el pipeline al revés funciona igual de bien técnicamente, pero desperdicia el tiempo del equipo en cada fallo.

2. Paralelo frente a serie

• npm ci debe ir primero y solo: todo depende de él.
• lint, typecheck y test:unidad pueden ir en paralelo entre sí: son independientes, no comparten estado y ninguno necesita el resultado del otro.
• test:integracion puede ir en paralelo con los anteriores si el runner puede levantar PostgreSQL a la vez, aunque suele ejecutarse después para no pagar el coste de levantar la base de datos cuando algo trivial ya ha fallado. Es una decisión de compromiso entre velocidad y coste.
• build va al final: construir un artefacto de código que no pasa las pruebas es tiempo y dinero tirados.

Un matiz sobre typecheck en este monorepo concreto: como apps/web depende de packages/tipos-compartidos, la comprobación de tipos de la web puede requerir que el paquete compartido esté compilado. En proyectos con referencias de proyecto de TypeScript esto se resuelve solo; en otros, obliga a un build parcial previo. Es el tipo de detalle que descubres al montar el pipeline y que resolveremos en 02-03.

3. PostgreSQL en el runner

test:integracion lo necesita. Implicaciones para el runner:

• El runner debe poder ejecutar contenedores (los runners alojados de GitHub pueden).
• Hay que esperar a que la base de datos esté lista, no solo arrancada: healthcheck o espera activa. Sin esto, tests flaky garantizados.
• Hay que aplicar las migraciones antes de ejecutar las pruebas, para que el esquema exista.
• Cada ejecución debe partir de una base de datos limpia, o el estado de una prueba contaminará a la siguiente.

4. Ejecución selectiva

• Cambio solo en apps/web/src/paginas/PanelNegocio.tsx: sí, sería razonable ejecutar únicamente las pruebas de apps/web. La API no puede verse afectada por un cambio en un componente de React. Esto es ejecución selectiva y es una de las principales palancas de optimización (04-04).
• Cambio en packages/tipos-compartidos/src/index.ts: no. Ese paquete es una dependencia de las dos aplicaciones, así que hay que probar ambas. Este es precisamente el caso que hace peligrosa la ejecución selectiva mal implementada: si tu regla es "solo pruebo la carpeta que cambió", un cambio en el paquete compartido no probaría nada y podría romper las dos aplicaciones a la vez. La ejecución selectiva debe basarse en el grafo de dependencias, no en la ruta del fichero.

Solución al Ejercicio 2

Los tres casos menos evidentes:

DATABASE_URL. La clave está en separar la cadena de conexión de la contraseña. postgres://[email protected]:5432/reservalia no contiene ningún secreto: es un nombre de host interno que, sin credenciales y sin acceso de red, no sirve de nada. La contraseña se inyecta aparte. Meter la contraseña dentro de la URL es cómodo y convierte un valor público en un secreto, con todo lo que eso implica: no se puede loguear, no se puede poner en el repositorio, no se puede mostrar en un mensaje de error.

Clave de la pasarela de pago en dev y staging. Aunque sean claves de entorno de pruebas y no muevan dinero real, siguen siendo secretos: permiten hacer llamadas en nombre de Reservalia, consultar datos y agotar cuotas. Una clave de pruebas filtrada en un repositorio público es un incidente de seguridad menor, pero es un incidente. Regla práctica: si el proveedor la llama "clave secreta", es un secreto.

Clave de firma de tokens: distinta en cada entorno. Este es el caso más sutil y el más importante. Si staging y prod compartieran la clave de firma, un token emitido en staging —donde el equipo tiene acceso total y puede crear el usuario que quiera— sería válido en producción. Es una escalada de privilegios de manual. Los secretos criptográficos jamás se comparten entre entornos, ni siquiera "temporalmente para probar".

Un criterio general para clasificar: si al filtrarse permite a alguien hacer algo que no debería, es un secreto. Si solo revela cómo se llaman las cosas, es configuración. Volveremos sobre ello en 04-03.

Solución al Ejercicio 3

1. Estructura equivalente en Python/FastAPI

2. Los cinco comandos

Una observación interesante: Python no tiene paso de compilación, así que el artefacto se produce directamente al construir la imagen Docker. El pipeline tiene un paso menos, pero el resto de la estructura es idéntica.

3. Cambios en docker-compose.yml

• No cambia nada del servicio db: PostgreSQL 16.3, su healthcheck, su volumen y sus variables son exactamente iguales. La base de datos no sabe en qué lenguaje está escrita la aplicación.
• No cambia nada del servicio mailpit: captura SMTP, sea quien sea el emisor.
• Cambiaría únicamente el servicio de la aplicación, si se añadiera: la imagen base (python:3.12-slim en vez de node:20-slim) y el comando de arranque (uvicorn src.main:app --reload).

Es un buen indicador de cuánto de este curso es independiente del lenguaje: la infraestructura de desarrollo es prácticamente la misma.

4. Qué partes del curso dejarían de aplicar

Casi ninguna. Concretamente:

• Deja de aplicar: los comandos exactos de npm, la sintaxis de package.json y los detalles de las herramientas concretas de JavaScript (vitest, ESLint, tsc).
• Sigue aplicando íntegro: todo el vocabulario de 01-01; los beneficios y costes de 01-02; el mapa de herramientas de 01-03; las métricas DORA de 01-05; todo el módulo 3 (estrategias de despliegue, IaC, feature flags, rollback, monitorización); todo el módulo 4 salvo los ejemplos de sintaxis; el módulo 6 completo; y la estructura, el orden y la lógica de cada pipeline que construyamos.

Estimación honesta: más del 85 % del curso es independiente del lenguaje. Lo que cambia son las cadenas de texto dentro de los pasos run:.

Ya conoces el proyecto sobre el que trabajaremos durante todo el curso:

• Reservalia es una plataforma SaaS de reservas de cita con 340 negocios de pago, dos aplicaciones (apps/api en Node.js + Express + PostgreSQL y apps/web en React + Vite), un paquete de tipos compartidos y un monorepo con workspaces de npm.
• El equipo son Marta (tech lead, mira el negocio y el riesgo), Diego (backend, quiere un CI rápido y es el único que sabe desplegar) y Nuria (SRE, quiere infraestructura reproducible y rollback fiable). Sus tensiones son las que tendrás en tu equipo.
• El proyecto ya tiene sus comandos definidos: npm ci, lint, typecheck, test, build y migrate. Esta es la idea clave de la lección: el pipeline no inventa nada, solo ejecuta en una máquina limpia lo que el proyecto ya sabe hacer. Un pipeline es un revelador de suposiciones ocultas.
• Hay tres entornos —dev, staging y prod— gobernados por dos principios: el mismo artefacto se promociona a los tres, y los datos de producción nunca salen de producción.
• La infraestructura de destino es AWS: imágenes en ECR, ejecución en ECS Fargate detrás de un balanceador, datos en RDS PostgreSQL, secretos en Secrets Manager y registros en CloudWatch.
• Y sabes cómo seguir el curso con cualquier tecnología: más del 85 % es independiente del lenguaje; solo cambian los comandos dentro de cada paso.

Nos queda una última cosa antes de empezar a construir. Marta va a pedir tiempo del equipo para montar todo esto, y dentro de seis meses alguien preguntará si ha servido de algo. Para responder a eso hace falta haber medido el punto de partida antes de tocar nada. En la siguiente lección, Métricas DORA: Cómo se Mide la Entrega de Software, veremos las cuatro métricas estándar del sector —frecuencia de despliegue, lead time for changes, change failure rate y time to restore service—, cómo calcularlas a partir de datos que el propio pipeline genera, y estableceremos el cuadro de mando inicial de Reservalia: dónde están hoy y a dónde quieren llegar al final del curso.