Els cursos de CI/CD solen fallar en el mateix punt: ensenyen pipelines sobre un "hola món" que no té base de dades, ni migracions, ni dues aplicacions que comparteixin codi, ni un equip amb opinions diferents. I després, en un projecte real, no encaixa res. Aquest curs fa el contrari: construirem, pas a pas, el pipeline complet d'una aplicació amb la complexitat justa perquè apareguin els problemes de debò. Aquesta aplicació es diu Reservalia. En aquesta lliçó la coneixerem a fons: què fa el producte, qui forma l'equip, com està organitzat el repositori, quines ordres existeixen ja —perquè el pipeline no inventa res, només invoca el que el projecte ja sap fer—, quins entorns hi ha i a quina infraestructura despleguem. Acabarem amb el full de ruta del curs aplicat a Reservalia i amb el que necessites instal·lat per seguir-lo. Encara no escriurem cap flux de treball: la primera peça real de pipeline es construeix a la lliçó 02-02.

1. Què és Reservalia
2. L'equip: Marta, Diego i Nuria
3. Com treballen avui (i per què fa mal)
4. L'estructura del repositori
5. Els package.json i les ordres que el pipeline invocarà
6. L'entorn de desenvolupament local amb Docker Compose
7. Els tres entorns: dev, staging i prod
8. La infraestructura AWS de destinació
9. El full de ruta del curs aplicat a Reservalia
10. Com seguir el curs si no fas servir Node.js
11. Què necessites instal·lat
12. Errors comuns i consells
13. Exercicis
14. Conclusió

Reservalia és una plataforma SaaS de reserva de cites per a petits negocis de serveis: perruqueries, clíniques dentals, tallers mecànics, fisioterapeutes, centres d'estètica. És una empresa fictícia creada per a aquest curs; qualsevol semblança amb la realitat és intencionada però no real.

El producte té dues cares:

• El panell del negoci. El propietari de la perruqueria configura els seus serveis (tall, color, tractament), els seus professionals, els horaris d'obertura i les seves vacances. Consulta l'agenda del dia, confirma cites i veu estadístiques bàsiques.
• La pàgina pública de reserva. El client final entra des d'un enllaç, veu els forats lliures, en tria un i reserva sense registrar-se. Rep una confirmació per correu i un recordatori 24 hores abans.

Model de negoci: subscripció mensual per negoci, amb tres plans. Ara mateix tenen 340 negocis de pagament i processen unes 9.000 cites al mes.

No és un exemple de joguina, i això importa. Reservalia té exactament els ingredients que fan interessant un pipeline:

Si aconsegueixes automatitzar Reservalia, sabràs automatitzar el teu projecte.

Tres persones, tres punts de vista. Tots tres apareixeran durant tot el curs, i les seves discussions són les que probablement tindràs tu amb el teu equip.

Fa quatre anys que és a Reservalia i arrossega la responsabilitat que el producte funcioni. És qui decideix què es desplega i quan, i qui rep la trucada del comercial quan un client es queixa.

• Què li preocupa: que les incidències no es repeteixin i poder justificar davant de direcció el temps que l'equip dedica a "coses que no són funcionalitats".
• El seu paper al curs: aporta el punt de vista de negoci. És qui pregunta "quant costa això i què hi guanyem?" (la lliçó 01-02) i qui prémerà el botó d'aprovació a la porta manual del desplegament a producció.
• La seva frase: "Prefereixo desplegar deu vegades al dia i que cada desplegament m'importi ben poc, que desplegar un cop a la setmana i no dormir el dijous."

Tres anys a l'empresa. Escriu la major part d'apps/api i és, avui, l'única persona que sap desplegar. Sap perfectament que el procés actual és dolent; el que no ha tingut mai és temps per arreglar-lo.

• Què li preocupa: que el pipeline el faci anar més lent. Li fa pànic un CI que trigui 40 minuts a dir-li si el seu canvi està bé.
• El seu paper al curs: és l'escèptic productiu. Cada vegada que afegim un pas al pipeline, en Diego preguntarà quant temps hi suma. Gràcies a ell, el pipeline final serà ràpid.
• La seva frase: "Si el CI triga més que anar a buscar un cafè, acabaré ignorant-lo."

Es va incorporar fa vuit mesos, a mitja jornada compartida amb un altre producte. Va muntar la infraestructura d'AWS a mà, des de la consola web, perquè calia sortir a producció ja. Porta les guàrdies.

• Què li preocupa: que la infraestructura no estigui documentada enlloc tret del seu cap, i que un rollback avui signifiqui recompilar i tornar a pujar per SFTP amb clients esperant.
• El seu paper al curs: aporta la perspectiva d'operació. És qui insisteix en la infraestructura com a codi (03-03), en el rollback (03-05) i en el monitoratge (03-06).
• La seva frase: "Un desplegament que no es pot desfer en cinc minuts no és un desplegament, és una aposta."

Recordem el punt de partida, ara amb el detall complet del procés:

I els problemes d'aquest ritual, enumerats sense pietat:

Cada línia d'aquesta taula desapareixerà en algun moment del curs. Guarda-la: a la lliçó final (07-06) la repassarem sencera.

Reservalia té un únic repositori a github.com/reservalia/reservalia, organitzat com a monorepo amb workspaces d'npm. Aquesta és la seva estructura tal com està avui, abans de començar:

Tres decisions d'aquesta estructura mereixen explicació, perquè condicionen tot el pipeline:

Monorepo amb un únic package-lock.json. En fer servir workspaces d'npm, hi ha un sol fitxer de bloqueig a l'arrel que governa les dependències d'api, web i tipus-compartits. Avantatge: un únic npm ci instal·la tot de manera coherent i reproduïble. Conseqüència per al pipeline: la instal·lació es fa una vegada a l'arrel, no una per aplicació.

packages/tipus-compartits. Aquí viuen els tipus que l'API i la web comparteixen (per exemple, la forma d'una Cita). És el que garanteix que si en Diego canvia el model de dades, la web deixi de compilar en CI en comptes de trencar-se en producció. També significa que un canvi en aquest paquet obliga a provar les dues aplicacions: és la complicació que fa interessant l'"executar només allò afectat" de la lliçó 04-04.

.nvmrc. Un fitxer d'una línia que diu quina versió de Node fa servir el projecte. És la peça més barata de reproduïbilitat que existeix:

Amb això, el portàtil d'en Diego, el de la Marta i el runner de CI fan servir exactament la mateixa versió. A la lliçó 01-01 vam veure que la versió no fixada és un dels enemics clàssics de la build reproduïble; aquest fitxer ho resol.

Aquí hi ha una idea central del curs, i convé subratllar-la:

El pipeline no inventa res. Només executa, en una màquina neta, les mateixes ordres que tu executes al teu portàtil.

Per això, abans d'escriure cap flux de treball, el projecte ha de tenir les seves ordres ben definides. Si npm test no funciona a la teva màquina, no funcionarà en CI. Si funciona a la teva màquina però només perquè tens una variable d'entorn que ningú més no té, fallarà en CI. Un pipeline és, sobretot, un revelador de suposicions ocultes.

Punt per punt, perquè cada línia té un motiu:

• "private": true evita que el paquet arrel es publiqui per accident al registre públic d'npm. En un monorepo és obligatori.
• "workspaces" declara els subprojectes. En executar npm ci a l'arrel, npm instal·la les dependències de tots ells i crea els enllaços entre tipus-compartits i les aplicacions que el fan servir.
• "engines" documenta la versió de Node admesa. Combinat amb .nvmrc, deixa constància explícita del requisit.
• --workspaces --if-present executa l'script a cada subprojecte que el tingui definit, i no falla en els que no el tinguin. És el que permet que un sol npm test a l'arrel provi l'API, la web i el paquet compartit.

Amb això, el pipeline sencer es podria reduir a quatre ordres. Comprova-ho:

Aquestes cinc ordres són, literalment, l'esquelet del pipeline que construirem al mòdul 2.

Detalls importants per al pipeline:

• test:unitat i test:integracio estan separats. Les unitàries són ràpides i no necessiten base de dades; les d'integració necessiten un PostgreSQL aixecat. Aquesta separació és la que ens permetrà, a 02-04, donar retroalimentació ràpida a en Diego: primer les ràpides, i només si passen, les lentes.
• --max-warnings 0 al lint. Sense això, ESLint acaba amb codi de sortida 0 encara que hi hagi avisos, i el pipeline es posaria verd amb problemes a dins. Recorda de 01-03: el pipeline només entén de codis de sortida.
• typecheck separat de build. tsc --noEmit comprova els tipus sense generar fitxers. És ràpid i pot córrer en paral·lel amb els tests.
• migrate existeix com a script. Avui en Diego enganxa SQL a mà; el projecte ja té l'ordre, només que ningú no la fa servir. A la lliçó 04-06 la integrarem al desplegament.
• Versions exactes, sense ^. "express": "4.19.2" i no "^4.19.2". Juntament amb npm ci, garanteix que dues instal·lacions donin el mateix. L'estratègia completa de dependències és matèria de 04-02.

Fixa't que els noms dels scripts coincideixen amb els de l'API: build, test, lint, typecheck. Aquesta convenció no és cosmètica: és el que fa que npm run test --workspaces funcioni i el que permetrà que el pipeline tracti totes dues aplicacions amb la mateixa lògica.

Consell transferible: unificar els noms dels scripts entre subprojectes és una de les inversions més rendibles abans de muntar un pipeline. Si en un projecte l'ordre és npm test i en un altre npm run test:ci, el teu YAML s'omplirà de casos especials.

Perquè les proves d'integració funcionin —tant al portàtil com després en CI— cal un PostgreSQL. Reservalia l'aixeca amb Docker Compose:

Quatre coses per explicar, perquè totes reapareixeran al pipeline:

La versió està fixada: postgres:16.3. No postgres:latest. Si en local desenvolupes contra PostgreSQL 16 i producció corre 15, tard o d'hora una consulta funcionarà a la teva màquina i fallarà en producció. La versió de la base de dades és part de la reproduïbilitat.

El healthcheck és la línia més important del fitxer. Un contenidor de PostgreSQL "arrencat" no significa "llest per acceptar connexions": hi ha uns segons d'inicialització. Sense healthcheck, les proves d'integració fallen de manera intermitent perquè la base de dades encara no accepta connexions. I això és exactament una prova flaky, el verí del qual parlàvem a 01-02. La causa número u de flakiness en CI és no esperar que els serveis estiguin realment llestos.

Mailpit substitueix el proveïdor de correu real. Reservalia envia confirmacions i recordatoris. En local i en proves, aquests correus no han de sortir a internet: Mailpit els captura i els mostra en una web. La regla general que aplicarem a 02-04: en proves, cap servei extern real.

La contrasenya desenvolupament està escrita en clar, i està bé. Perquè és una base de dades local, efímera i sense dades reals. A staging i prod no ho farem mai: allà les credencials vénen d'un gestor de secrets. Distingir quan un valor és un secret i quan no és part de la matèria de 04-03.

El flux de treball diari d'en Diego, en quatre ordres:

Quan al mòdul 2 configurem el CI, veuràs que el pipeline fa exactament el mateix: preparar Node, instal·lar dependències, aixecar els serveis necessaris i executar ordres. No hi ha màgia.

Un entorn (definit a 01-01) és una instància desplegada i executable del sistema, amb la seva pròpia configuració i les seves pròpies dades. Reservalia en tindrà tres:

Dos principis que regeixen els tres entorns i que convé interioritzar ja:

Principi 1: el mateix artefacte als tres. És la regla de promoció de 01-01. La imatge reservalia/api:a3f9c21 que es prova a dev és exactament la mateixa que arriba a staging i a prod. L'única cosa que canvia entre entorns és la configuració injectada per fora:

Principi 2: les dades de producció no surten mai de producció. Copiar la base de dades de prod a staging "per provar amb dades reals" és una pràctica freqüent i una molt mala idea: Reservalia desa noms, telèfons i correus de clients finals. staging fa servir dades generades amb volum realista, no dades reals.

La Nuria va muntar això a mà des de la consola d'AWS. Al mòdul 3 ho passarem a Terraform perquè sigui reproduïble; de moment, aquesta és la foto d'on desplega el pipeline:

Què fa cada peça i per què hi és:

I el recorregut complet d'un canvi, del portàtil d'en Diego al client final:

Aquest diagrama és l'objectiu del curs. En acabar el mòdul 3, Reservalia tindrà exactament aquest flux funcionant.

Què haurà canviat a Reservalia al final de cada mòdul:

Reservalia fa servir Node.js i TypeScript, però el curs no tracta sobre Node.js. Tracta sobre pipelines. Si el teu dia a dia és Python, Java, Go, PHP, Ruby o .NET, tot el que aprenguis s'aplica igual: l'única cosa que canvia són les ordres concretes de cada pas.

Aquí tens la taula de traducció. Guarda-la:

El que és idèntic en tots els llenguatges —i és la immensa majoria del curs:

• Els conceptes: trigger, job, etapa, runner, artefacte, entorn, promoció.
• El criteri d'èxit o fracàs: el codi de sortida de cada ordre.
• L'estructura del pipeline: instal·lar → verificar → construir → publicar → desplegar.
• L'estratègia d'entorns i la regla de construir una vegada i promocionar.
• Els contenidors: un Dockerfile de Python i un de Node s'assemblen moltíssim.
• Les estratègies de desplegament, el rollback, els feature flags i el monitoratge.
• Les mètriques DORA i tot el relatiu a seguretat i secrets.

Suggeriment pràctic: si vols treure'n el màxim partit, adapta cada exercici al teu propi projecte. Quan a 02-02 configurem npm ci && npm test, munta en paral·lel l'equivalent amb pip install && pytest en un repositori teu. Aprendràs el doble.

Per llegir el curs i entendre els exemples: res. Tots els fitxers són complets a les lliçons.

Per reproduir els exemples, que és molt recomanable:

Opcionals, i només a partir del mòdul 3:

Comprovació ràpida del teu entorn:

Si no pots instal·lar res (per exemple, en un ordinador corporatiu restringit): pots seguir pràcticament tot el curs creant un repositori a GitHub des del navegador i editant els fluxos de treball des de la interfície web. Els runners de GitHub executen al núvol. És menys còmode, però funciona.

Error 1: voler automatitzar abans que les ordres funcionin en local. Si npm test no funciona al teu portàtil, no funcionarà en CI. El pipeline és un revelador de suposicions ocultes: variables d'entorn que només tens tu, serveis que estan arrencats a la teva màquina des de fa setmanes, fitxers que no vas pujar mai al repositori. Primer fes que funcioni en una màquina neta; després automatitza-ho.

Error 2: no fixar les versions de les eines. .nvmrc, engines, postgres:16.3 en comptes de postgres:latest, dependències sense ^. Cada versió no fixada és una build que algun dia deixarà de funcionar sense que ningú hagi tocat res, i aquest és el tipus de fallada més cara de diagnosticar.

Error 3: noms d'scripts diferents a cada subprojecte. Si apps/api fa servir npm test i apps/web fa servir npm run test:ci, el teu pipeline s'omplirà de casos especials. Unifica els noms abans d'escriure el primer flux de treball: és mitja hora de feina que estalvia dies.

Error 4: copiar la base de dades de producció a staging. És temptador ("provem amb dades reals") i és una fuita de dades personals esperant a passar. Reservalia desa telèfons i correus de clients finals. Genera dades fictícies amb volum realista.

Error 5: oblidar el healthcheck dels serveis auxiliars. "Contenidor arrencat" no és "servei llest". És la causa número u de tests intermitents en CI, i com vam veure a 01-02, els tests flaky destrueixen la confiança en el pipeline sencer.

Consell 1: si tens un projecte propi, fes-lo servir en paral·lel. Aplica cada lliçó a Reservalia i també al teu projecte. La transferència de coneixement és molt més gran quan t'enfrontes a les particularitats del teu propi codi.

Consell 2: escriu avui la teva pròpia taula del ritual del divendres. Enumera tots els passos manuals del teu procés de desplegament actual, amb la seva durada. És una llista incòmoda de llegir i és exactament el mapa del que automatitzaràs.

Consell 3: un README.md que funcioni és el primer pas de CI. Si un desenvolupador nou pot clonar el repositori i tenir el projecte funcionant seguint el README sense preguntar a ningú, el teu projecte està llest per automatitzar-se. Si no, arregla això primer: el pipeline és exactament aquell README executat per una màquina.

Sense escriure gens de YAML —encara no toca—, i fent servir únicament el que saps del repositori de Reservalia, respon:

1. En quin ordre executaries npm ci, lint, typecheck, test:unitat, test:integracio i build? Justifica l'ordre.
2. Quins d'aquests passos es poden executar en paral·lel i quins obligatòriament en sèrie?
3. Quin pas necessita que hi hagi un PostgreSQL aixecat, i què implica això per al runner?
4. Un canvi toca només apps/web/src/pagines/PanelNegoci.tsx. Seria correcte executar únicament les proves d'apps/web? I si el canvi toqués packages/tipus-compartits/src/index.ts?

Reservalia ha de decidir, per a cada valor de configuració, si és un secret (va al gestor de secrets), una variable d'entorn normal (pot ser al repositori) o una cosa que no ha d'existir en aquell entorn. Completa la taula i justifica els tres casos que et semblin menys evidents:

Imagina't que Reservalia estigués escrita en Python amb FastAPI en comptes de Node.js amb Express. Escriu:

1. L'estructura equivalent d'apps/api/ (noms de fitxers de configuració i de gestió de dependències).
2. L'equivalent de les cinc ordres del pipeline (npm ci, lint, typecheck, test, build).
3. Quines parts del docker-compose.yml canviarien i quines no.
4. Quines parts del curs deixarien d'aplicar. (Pista: poques.)

Solució a l'Exercici 1

1. Ordre i justificació

El principi que governa aquest ordre s'anomena fail fast: col·loca primer el més ràpid i el que més probablement falli. Si en Diego s'ha deixat un console.log o un tipus incompatible, vols que ho sàpiga en 40 segons, no després d'esperar sis minuts a les proves d'integració. Ordenar el pipeline al revés funciona igual de bé tècnicament, però malbarata el temps de l'equip a cada fallada.

2. Paral·lel davant de sèrie

• npm ci ha d'anar primer i sol: tot en depèn.
• lint, typecheck i test:unitat poden anar en paral·lel entre si: són independents, no comparteixen estat i cap no necessita el resultat de l'altre.
• test:integracio pot anar en paral·lel amb els anteriors si el runner pot aixecar PostgreSQL alhora, encara que se sol executar després per no pagar el cost d'aixecar la base de dades quan alguna cosa trivial ja ha fallat. És una decisió de compromís entre velocitat i cost.
• build va al final: construir un artefacte de codi que no passa les proves és temps i diners llençats.

Un matís sobre typecheck en aquest monorepo concret: com que apps/web depèn de packages/tipus-compartits, la comprovació de tipus de la web pot requerir que el paquet compartit estigui compilat. En projectes amb referències de projecte de TypeScript això es resol sol; en d'altres, obliga a un build parcial previ. És el tipus de detall que descobreixes en muntar el pipeline i que resoldrem a 02-03.

3. PostgreSQL al runner

test:integracio el necessita. Implicacions per al runner:

• El runner ha de poder executar contenidors (els runners allotjats de GitHub poden).
• Cal esperar que la base de dades estigui llesta, no només arrencada: healthcheck o espera activa. Sense això, tests flaky garantits.
• Cal aplicar les migracions abans d'executar les proves, perquè l'esquema existeixi.
• Cada execució ha de partir d'una base de dades neta, o l'estat d'una prova contaminarà la següent.

4. Execució selectiva

• Canvi només a apps/web/src/pagines/PanelNegoci.tsx: sí, seria raonable executar únicament les proves d'apps/web. L'API no pot veure's afectada per un canvi en un component de React. Això és execució selectiva i és una de les principals palanques d'optimització (04-04).
• Canvi a packages/tipus-compartits/src/index.ts: no. Aquest paquet és una dependència de les dues aplicacions, així que cal provar totes dues. Aquest és precisament el cas que fa perillosa l'execució selectiva mal implementada: si la teva regla és "només provo la carpeta que ha canviat", un canvi al paquet compartit no provaria res i podria trencar les dues aplicacions alhora. L'execució selectiva s'ha de basar en el graf de dependències, no en la ruta del fitxer.

Solució a l'Exercici 2

Els tres casos menys evidents:

DATABASE_URL. La clau està a separar la cadena de connexió de la contrasenya. postgres://[email protected]:5432/reservalia no conté cap secret: és un nom d'amfitrió intern que, sense credencials i sense accés de xarxa, no serveix de res. La contrasenya s'injecta a part. Ficar la contrasenya dins de l'URL és còmode i converteix un valor públic en un secret, amb tot el que això implica: no es pot registrar en logs, no es pot posar al repositori, no es pot mostrar en un missatge d'error.

Clau de la passarel·la de pagament a dev i staging. Encara que siguin claus d'entorn de proves i no moguin diners reals, continuen sent secrets: permeten fer crides en nom de Reservalia, consultar dades i esgotar quotes. Una clau de proves filtrada en un repositori públic és un incident de seguretat menor, però és un incident. Regla pràctica: si el proveïdor l'anomena "clau secreta", és un secret.

Clau de signatura de tokens: diferent a cada entorn. Aquest és el cas més subtil i el més important. Si staging i prod compartissin la clau de signatura, un token emès a staging —on l'equip té accés total i pot crear l'usuari que vulgui— seria vàlid en producció. És una escalada de privilegis de manual. Els secrets criptogràfics no es comparteixen mai entre entorns, ni tan sols "temporalment per provar".

Un criteri general per classificar: si en filtrar-se permet a algú fer una cosa que no hauria de poder fer, és un secret. Si només revela com es diuen les coses, és configuració. Hi tornarem a 04-03.

Solució a l'Exercici 3

1. Estructura equivalent en Python/FastAPI

2. Les cinc ordres

Una observació interessant: Python no té pas de compilació, així que l'artefacte es produeix directament en construir la imatge Docker. El pipeline té un pas menys, però la resta de l'estructura és idèntica.

3. Canvis al docker-compose.yml

• No canvia res del servei db: PostgreSQL 16.3, el seu healthcheck, el seu volum i les seves variables són exactament iguals. La base de dades no sap en quin llenguatge està escrita l'aplicació.
• No canvia res del servei mailpit: captura SMTP, sigui qui sigui l'emissor.
• Canviaria únicament el servei de l'aplicació, si se n'afegís un: la imatge base (python:3.12-slim en comptes de node:20-slim) i l'ordre d'arrencada (uvicorn src.main:app --reload).

És un bon indicador de quant d'aquest curs és independent del llenguatge: la infraestructura de desenvolupament és pràcticament la mateixa.

4. Quines parts del curs deixarien d'aplicar

Gairebé cap. Concretament:

• Deixa d'aplicar: les ordres exactes d'npm, la sintaxi de package.json i els detalls de les eines concretes de JavaScript (vitest, ESLint, tsc).
• Continua aplicant íntegrament: tot el vocabulari de 01-01; els beneficis i costos de 01-02; el mapa d'eines de 01-03; les mètriques DORA de 01-05; tot el mòdul 3 (estratègies de desplegament, IaC, feature flags, rollback, monitoratge); tot el mòdul 4 tret dels exemples de sintaxi; el mòdul 6 complet; i l'estructura, l'ordre i la lògica de cada pipeline que construïm.

Estimació honesta: més del 85 % del curs és independent del llenguatge. El que canvia són les cadenes de text dins dels passos run:.

Ja coneixes el projecte sobre el qual treballarem durant tot el curs:

• Reservalia és una plataforma SaaS de reserva de cites amb 340 negocis de pagament, dues aplicacions (apps/api en Node.js + Express + PostgreSQL i apps/web en React + Vite), un paquet de tipus compartits i un monorepo amb workspaces d'npm.
• L'equip són la Marta (tech lead, mira el negoci i el risc), en Diego (backend, vol un CI ràpid i és l'únic que sap desplegar) i la Nuria (SRE, vol infraestructura reproduïble i rollback fiable). Les seves tensions són les que tindràs al teu equip.
• El projecte ja té les seves ordres definides: npm ci, lint, typecheck, test, build i migrate. Aquesta és la idea clau de la lliçó: el pipeline no inventa res, només executa en una màquina neta el que el projecte ja sap fer. Un pipeline és un revelador de suposicions ocultes.
• Hi ha tres entorns —dev, staging i prod— governats per dos principis: el mateix artefacte es promociona als tres, i les dades de producció no surten mai de producció.
• La infraestructura de destinació és AWS: imatges a ECR, execució a ECS Fargate darrere d'un balancejador, dades a RDS PostgreSQL, secrets a Secrets Manager i registres (log) a CloudWatch.
• I saps com seguir el curs amb qualsevol tecnologia: més del 85 % és independent del llenguatge; només canvien les ordres dins de cada pas.

Ens queda una última cosa abans de començar a construir. La Marta demanarà temps de l'equip per muntar tot això, i d'aquí a sis mesos algú preguntarà si ha servit d'alguna cosa. Per respondre a això cal haver mesurat el punt de partida abans de tocar res. A la lliçó següent, Mètriques DORA: Com es Mesura el Lliurament de Programari, veurem les quatre mètriques estàndard del sector —freqüència de desplegament, lead time for changes, change failure rate i time to restore service—, com calcular-les a partir de dades que el mateix pipeline genera, i establirem el quadre de comandament inicial de Reservalia: on són avui i on volen arribar al final del curs.