Queda el quart front, i és el que més desplegaments trenca. Tot el que s'ha construït en tres mòduls descansa sobre una propietat que l'esquema de la base de dades no té: l'artefacte reservalia/api:a3f9c21 és immutable i se substitueix per l'anterior en quatre minuts, però una columna esborrada no torna. El rollback.yml de la 03-05 sap tornar a un digest anterior; no sap desfer un DROP COLUMN, i per això la mateixa lliçó ho va deixar escrit com l'únic motiu pel qual el botó de tornada enrere podria no funcionar. Aquesta lliçó tanca aquell forat i, amb ell, el mòdul. Veurem per què l'esquema és estat compartit i què implica això; com es versionen les migracions i per què s'executen des del pipeline i mai des del portàtil d'en Diego; desenvoluparem pas a pas el patró expand and contract sobre un cas real —reanomenar hora_inici a inici_utc sense tallar el servei—; classificarem els canvis d'esquema en segurs, perillosos i prohibits en calent; entendrem per què un ALTER TABLE pot tombar producció i com evitar-ho; col·locarem la migració al seu lloc exacte dins de cd.yml; i acabarem amb les dades de prova, l'anonimització i un advertiment de compliment normatiu que convé llegir sencer.

1. L'esquema és estat compartit i no es reverteix
2. Migracions versionades: convenció, eina i taula de control
3. Per què s'executen des del pipeline i mai des d'un portàtil
4. Expand and contract: el cas hora_inici → inici_utc
5. Classificació dels canvis d'esquema
6. Migracions i bloquejos: com un ALTER TABLE tomba producció
7. Backfill per lots sense saturar la base
8. On encaixa la migració a cd.yml
9. Dades de prova i anonimització
10. Errors Comuns i Consells
11. Exercicis
12. Conclusió i tancament del mòdul

Compara les dues meitats del sistema que Reservalia desplega:

L'última fila és la clau de tota la lliçó. Durant un rolling update de la 03-04 —o durant un canary al 10 %— conviuen en producció dues versions del codi parlant amb una sola base de dades. Si la migració deixa l'esquema en un estat que la versió antiga no entén, la meitat de les peticions falla mentre dura el desplegament. I si cal revertir el codi, la versió antiga es trobarà un esquema que ja no és el seu. Per això rollback.yml no salva una migració destructiva, i convé veure'n el cas concret. Suposa un desplegament que executa ALTER TABLE cites DROP COLUMN hora_inici i desplega el codi nou. Deu minuts després es detecta una fallada greu i la Nuria llança el rollback: la imatge anterior torna en quatre minuts… i falla a cada petició, perquè el seu codi pregunta per una columna que ja no existeix. El rollback de l'artefacte s'ha completat amb èxit i el servei continua caigut. Restaurar una còpia de seguretat tampoc no és la resposta: significa perdre totes les reserves creades des del DROP.

Nuria: "Un desplegament que no es pot desfer en cinc minuts no és un desplegament, és una aposta." I una migració destructiva converteix qualsevol desplegament en això.

La conclusió que ordena la resta: l'esquema ha de canviar de manera que cap versió desplegada no es trenqui, ni la nova ni l'anterior. Això no és una restricció del pipeline, és una restricció de disseny de cada canvi.

Una migració és un canvi d'esquema escrit com un fitxer versionat al repositori, no com una ordre teclejada a psql. Reservalia les desa a apps/api/src/db/migracions/ —la ruta que ja apareixia al CODEOWNERS de la 02-07, exigint revisió de la Marta o la Nuria— amb aquesta convenció de noms:

Marca de temps + descripció en snake_case. La marca ordena l'execució de manera determinista i evita el problema clàssic dels números correlatius: dues persones que treballen alhora creen 005_ i 005_, i el conflicte només apareix en fusionar. Amb marques de temps, dues migracions simultànies s'ordenen soles. L'eina —node-pg-migrate a Reservalia, però el mecanisme és universal (Flyway, Liquibase, Alembic, ActiveRecord)— manté una taula de control dins de la mateixa base de dades:

1. El nom com a clau primària és el que fa la migració idempotent: en arrencar, l'eina compara els fitxers del repositori amb les files d'aquesta taula i executa només el que falta. Tornar a llançar el job no repeteix res, que és el requisit de la 03-02.
2. El hash del contingut detecta l'error més perillós: que algú editi una migració ja aplicada. Si el hash del fitxer no coincideix amb el registrat, l'eina s'atura amb un error explícit. Una migració aplicada és història: es corregeix amb una migració nova, mai editant l'anterior, perquè l'entorn on ja es va executar no la tornarà a llegir.
3. I duracio_ms no hi és per curiositat. Una migració que a staging triga 200 ms i a prod triga 40 segons està dient que la taula és molt més gran i que el bloqueig de l'apartat 6 farà mal.

A la 01-04, el ritual del divendres incloïa en Diego llançant migracions a mà a psql connectat a producció. Allò va desaparèixer, i val la pena enumerar per què no ha de tornar ni tan sols "només aquesta vegada":

L'argument decisiu és el tercer. La deriva entre entorns de la 03-03 —el problema que va resoldre Terraform per a la infraestructura— existeix també a l'esquema, i és pitjor: una migració que a staging es va executar amb una variant i a prod amb una altra fa que les proves de staging deixin de significar res, i ningú no ho descobreix fins al dia de l'incident. Si l'esquema no està sota control de versions, no tens entorns equivalents per molt Terraform que escriguis.

El problema real de Reservalia: la columna cites.hora_inici és un timestamp sense zona horària, i amb negocis que comencen a operar fora de la Península els càlculs de calcularForats s'estan equivocant en els canvis d'hora. Cal passar a inici_utc de tipus timestamptz. És, en aparença, un ALTER TABLE ... RENAME COLUMN. I fer-ho així trencaria el servei: en l'instant del reanomenament, totes les tasques que encara corren la versió antiga comencen a fallar.

El patró expand and contract (expandir i contraure) resol això convertint un canvi incompatible en una seqüència de canvis compatibles. Quatre fases, cadascuna desplegable i reversible per separat:

Fase 1 · Expandir. S'afegeix la columna nova sense tocar la vella, i un trigger manté les dues sincronitzades mentre convisquin:

1. Nullable i sense valor per defecte: és el que fa que aquest ALTER TABLE sigui instantani i no reescrigui la taula (apartat 6).
2. El codi vell continua escrivint hora_inici i el trigger omple inici_utc. La versió antiga no s'assabenta de res.
3. El codi nou escriurà inici_utc i el trigger omplirà hora_inici, de manera que si cal revertir el codi, la columna vella està al dia. Aquesta direcció del trigger és la que fa el rollback segur, i és justament la que s'oblida. Després d'aquesta migració conviuen sense problema el codi vell, que escriu hora_inici, i el nou quan es desplegui, que escriurà inici_utc.

Fase 2 · Migrar les dades. El trigger només cobreix les files que es toquen; les 640.000 cites històriques cal omplir-les amb un backfill per lots (apartat 7). En acabar, inici_utc està completa. Fase 3 · Desplegar el codi nou. Ara, i no abans, apps/api/src/domini/agenda.ts passa a llegir i escriure inici_utc. El desplegament és un rolling update normal de la 03-04: durant uns minuts conviuen les dues versions, i totes dues funcionen perquè ambdues columnes estan completes i sincronitzades. I aquí hi ha la propietat que justifica tot el patró: si el canary detecta un problema, rollback.yml funciona sense tocar la base de dades.

Fase 4 · Contraure. Només quan han passat uns quants dies, el codi nou és estable a prod i s'ha verificat que ningú no llegeix ja la columna vella:

1. La restricció NOT NULL s'afegeix al final, quan ja se sap que no hi ha nuls. Posar-la a la fase 1 hauria trencat totes les escriptures del codi vell.
2. Aquest és l'únic pas irreversible del procés, i per això va en una migració a part, una setmana després i amb la seva pròpia revisió. Abans d'executar-lo convé una comprovació objectiva: buscar hora_inici al codi desplegat i consultar als logs si alguna consulta l'esmenta els últims set dies.

El cost és real i cal dir-ho: quatre pull requests i una setmana per al que semblava un reanomenament d'un minut. A canvi, zero segons d'indisponibilitat i un rollback possible en tot moment llevat dels cinc segons finals de la fase 4. Per a una taula amb 640.000 files i 340 negocis de pagament, l'intercanvi és evident.

Dos matisos sobre les files més traïdores. ADD COLUMN amb default depèn de la versió i del tipus de default: PostgreSQL 11 i posteriors gestionen un default constant sense reescriure la taula, però un default volàtil —now(), gen_random_uuid()— continua obligant a reescriure cada fila sota un bloqueig exclusiu. I el truc de NOT VALID val per a gairebé totes les restriccions: s'afegeix la restricció sense validar el que ja existeix (instantani, i ja s'aplica a les files noves) i després s'executa VALIDATE CONSTRAINT, que recorre la taula amb un bloqueig molt més suau que permet continuar escrivint.

Aquest és el mecanisme que convé entendre de debò, perquè explica incidents que semblen inexplicables. Un ALTER TABLE necessita un bloqueig exclusiu (ACCESS EXCLUSIVE) sobre la taula, i per obtenir-lo ha d'esperar que acabin les transaccions en curs. Fins aquí, res greu. El problema és el que passa mentre espera:

La cua de bloquejos de PostgreSQL respecta l'ordre d'arribada, així que un ALTER TABLE en espera bloqueja tots els que arriben després, inclosos els simples SELECT. El resultat és una caiguda completa provocada per una migració que encara no ha executat res. Tres defenses, i totes tres són barates:

1. lock_timeout fa que la migració falli de pressa en lloc de bloquejar la cua. Una fallada neta als tres segons és infinitament millor que una caiguda: es reintenta més tard, quan no hi hagi una consulta llarga en curs. És la línia que més incidents evita de tota la lliçó.
2. statement_timeout protegeix del cas contrari: una sentència que sí que va obtenir el bloqueig però triga deu minuts reescrivint la taula.
3. La tercera defensa és CREATE INDEX CONCURRENTLY, imprescindible en taules grans: construeix l'índex sense bloquejar escriptures, a costa de trigar més i de dues passades sobre la taula. Té dues peculiaritats que cal conèixer: no es pot executar dins d'una transacció —la majoria d'eines de migració emboliquen cada fitxer en una, així que cal desactivar-ho explícitament per a aquella migració—, i si falla deixa un índex invàlid que cal esborrar a mà abans de reintentar.

Omplir 640.000 files amb un sol UPDATE és l'altra manera clàssica de tombar producció: una transacció gegant que bloqueja files durant minuts, fa créixer el WAL, dispara el retard de la rèplica i satura la CPU. L'alternativa és avorrida i funciona: lots petits, amb pausa entre ells.

1. Lots de 1.000 files i pausa de 200 ms: cada transacció dura mil·lisegons i allibera els bloquejos de seguida. Els valors s'ajusten mirant la latència p95 del panell reservalia-api-prod mentre corre.
2. FOR UPDATE SKIP LOCKED evita esperar per files que una altra transacció està tocant: se salten i s'agafaran a la volta següent. Sense això, el backfill competeix amb el trànsit real.
3. La condició de parada és "no queden files pendents", no un comptador. Això fa l'script represa-ble: si s'interromp a mig fer, es torna a llançar i continua on era. És la mateixa idempotència de la 03-02, aplicada a dades.
4. La pausa és el que fa el backfill amable. Sense ella el bucle satura la base encara que cada lot sigui petit. És preferible un backfill que triga dues hores i que ningú no nota, que un de quatre minuts que dispara l'alerta ApiLatenciaReserves.

I dues regles més: el backfill s'executa per separat del desplegament, com un job sota demanda, perquè un procés de dues hores no bloquegi el pipeline; i es vigila mentre corre, amb el panell obert i la disposició a aturar-lo, que és trivial perquè es pot reprendre.

La migració és un job propi, anterior al desplegament del codi i amb les seves pròpies regles:

1. Un entorn propi, prod-migracions, amb la seva pròpia llista de revisors. Aprovar un desplegament de codi i aprovar un canvi d'esquema són decisions diferents: la primera es desfà en quatre minuts, la segona pot no desfer-se. Separar-les fa que l'aprovador vegi el SQL abans de dir que sí.
2. migrate:status abans d'aplicar imprimeix quines migracions s'executaran. És informació per a l'aprovador i queda al log del run: la resposta a "què es va canviar el dia 15?".
3. Els temps d'espera es fixen per connexió amb PGOPTIONS, de manera que s'apliquen a totes les sentències de la migració sense haver d'escriure'ls a cada fitxer.
4. La migració va abans del desplegament del codi, i això només és correcte perquè el patró de l'apartat 4 garanteix que l'esquema nou és compatible amb el codi antic. Si una migració no compleix aquella propietat, l'ordre no la salva: el problema és la migració.

Què fer si falla a mig fer. Primer, entendre què significa exactament: l'eina executa cada fitxer dins d'una transacció, així que una migració individual és atòmica, o s'aplica sencera o no s'aplica. El que no és atòmic és la sèrie: si n'hi ha tres de pendents i falla la segona, la primera va quedar aplicada i registrada. La taula migracions_aplicades diu exactament on es va aturar. I el procediment, que convé tenir escrit abans de necessitar-lo: (1) no reintentar a cegues —si va fallar per lock_timeout, reintentar en un moment tranquil és correcte; si va fallar per un error de SQL, reintentar dona el mateix error—; (2) el desplegament del codi no s'ha executat, perquè desplegar-prod depèn de migrar-prod, així que producció continua amb la versió anterior i l'esquema anterior més el que s'apliqués: si el patró es va respectar, això és un estat funcional; (3) corregir amb una migració nova, mai editant la que va fallar; i (4) anotar-ho com a incident a la taula incidents de la 03-06, perquè compta per al change failure rate. Un cas a part: un CREATE INDEX CONCURRENTLY no pot anar en una transacció, així que aquella migració no és atòmica i, si falla, deixa un índex invàlid que cal esborrar abans de reintentar. Mereix un comentari dins del mateix fitxer per a qui el trobi a les tres de la matinada.

La manera més ràpida de tenir un staging realista és copiar la base de dades de producció. No es fa. I no només per normativa:

L'alternativa és generar dades sintètiques amb un script que crea negocis, horaris i cites amb distribucions semblants a les reals —incloent-hi els casos difícils: horari partit, canvis d'hora, reserves solapades— però amb dades inventades. L'avantatge afegit és que són reproduïbles: les proves E2E de la 02-04 poden donar per fet que el negoci demo existeix amb una agenda coneguda.

1. Noms clarament falsos: si alguna cosa es filtra en un log o en una captura, es veu a l'instant que no és real.
2. Telèfons d'un rang no assignable, de manera que un enviament accidental d'SMS no arribi a ningú.
3. Dates triades expressament al voltant d'un canvi d'hora, que és justament el cas que va motivar la migració d'aquesta lliçó.

Si tot i així cal partir de dades reals —a vegades és l'única manera de reproduir un problema de rendiment amb volum real—, aleshores anonimització abans que les dades surtin de producció: substituir noms, telèfons i correus per valors generats, amb cura de mantenir les propietats estadístiques que importen (quantes cites per negoci, quina distribució horària). I amb dues cauteles: l'anonimització mal feta és reversible —un identificador que es conserva pot recompondre la identitat—, i el procés s'ha d'executar en un entorn tan protegit com producció, perquè durant una estona maneja dades reals.

Advertiment. Aquest apartat explica principis tècnics, no assessorament legal. El tractament de dades personals està regulat —RGPD a la Unió Europea, i normativa sectorial addicional si hi ha dades de salut— i les decisions sobre què es pot copiar, anonimitzar o conservar s'han de prendre amb el criteri d'un professional de protecció de dades i del responsable de compliment normatiu de la teva organització. Un curs tècnic no substitueix aquella revisió.

Error 1: fer RENAME COLUMN o DROP COLUMN en un desplegament normal. Trenca totes les tasques que encara corren la versió anterior i deixa el rollback inservible. Error 2: editar una migració ja aplicada en lloc d'escriure'n una de nova: l'entorn on ja es va executar no la tornarà a llegir, i els entorns divergeixen en silenci.

Error 3: contraure el mateix dia que s'expandeix. El valor sencer del patró és a l'espera entre la fase 3 i la 4; sense ella només has escrit més SQL per al mateix risc. Error 4: ALTER TABLE sense lock_timeout, que converteix una migració en espera en una caiguda completa per la cua de bloquejos. Error 5: backfill en un únic UPDATE, amb bloquejos llargs, WAL disparat i rèplica endarrerida; per lots i amb pausa.

Error 6: CREATE INDEX sense CONCURRENTLY sobre una taula gran en producció. Error 7: executar migracions des d'un portàtil "només aquesta vegada", que és exactament així com els entorns comencen a divergir. Error 8: copiar dades de producció a staging, amb tot el que implica en risc legal i de fuites.

Consell 1: revisa el SQL de les migracions amb la mateixa atenció que el codi, i amb CODEOWNERS que ho garanteixi. Consell 2: assaja la migració sobre una còpia amb el volum de producció i anota quant triga; és l'única dada que prediu el bloqueig. Consell 3: escriu a cada migració destructiva un comentari amb la data en què la columna va deixar de fer-se servir i qui ho va verificar, i Consell 4: tingues el procediment de fallada escrit abans de necessitar-lo.

En Diego necessita afegir a cites una columna estat de tipus text, obligatòria i amb valor per defecte 'confirmada', sobre una taula de 640.000 files i amb trànsit real. Escriu la seqüència completa de migracions i desplegaments, indicant quines versions del codi conviuen a cada moment i en quin punt exacte deixa de ser possible el rollback.

A les 10:15 d'un dimarts, un desplegament executa CREATE INDEX idx_cites_negoci ON cites(negoci_id) sobre una taula de 640.000 files. Als 40 segons, l'API deixa de respondre completament, incloses les peticions que no toquen cites. Explica el mecanisme exacte de la fallada, per què afecta peticions alienes a aquella taula i com s'hauria evitat.

Un equip vol reproduir a staging un problema de rendiment que només apareix amb volum real, i proposa restaurar-hi una còpia de seguretat de producció "només durant dos dies". Argumenta la resposta i proposa una alternativa concreta que resolgui la necessitat tècnica.

Solució 1. L'error de partida seria una sola migració amb ADD COLUMN estat text NOT NULL DEFAULT 'confirmada'. Encara que el default sigui constant i PostgreSQL modern no reescrigui la taula, el NOT NULL immediat trenca el codi antic, que fa INSERT sense aquella columna… i en realitat no el trenca, perquè el default l'omple; el problema real és l'invers i més subtil: si després cal revertir el codi, no passa res, però si la columna fos NOT NULL sense default, tots els INSERT del codi antic fallarien. La seqüència segura, que funciona en tots dos casos, és:

1. Migració 1 (expandir): ALTER TABLE cites ADD COLUMN estat text; — nullable, sense default. Instantani. Conviuen: codi vell (ignora la columna) i codi nou si estigués desplegat. Rollback: trivial.
2. Backfill per lots: omplir estat = 'confirmada' a les 640.000 files existents amb l'script de l'apartat 7. Sense bloquejos llargs, es pot reprendre.
3. Desplegament del codi nou: escriu sempre estat i tolera llegir NULL a les files que encara no s'hagin omplert si el backfill continua en curs. Conviuen les dues versions i totes dues funcionen; el rollback continua sent segur.
4. Migració 2 (endurir): quan el backfill ha acabat i el codi nou porta dies estable, ALTER TABLE cites ALTER COLUMN estat SET DEFAULT 'confirmada'; i després SET NOT NULL —precedit, en una taula gran, d'un CHECK (estat IS NOT NULL) NOT VALID + VALIDATE CONSTRAINT, per no recórrer la taula sota bloqueig exclusiu—.

El rollback deixa de ser possible al pas 4, i només parcialment: revertir el codi continua funcionant —la versió antiga simplement ignora la columna—, però el NOT NULL impedeix tornar a un codi que inserís files sense estat. Per això el pas 4 va a part i uns quants dies després.

Solució 2. El mecanisme, en tres temps. (1) CREATE INDEX sense CONCURRENTLY pren un bloqueig que impedeix les escriptures sobre cites durant tota la construcció de l'índex, que en 640.000 files són desenes de segons. (2) Totes les escriptures sobre cites fan cua al darrere. (3) Cada petició encuada reté una connexió del pool; en quaranta segons, amb el trànsit d'un dimarts al matí, el pool queda exhaurit. I aquí hi ha la resposta a per què afecta peticions alienes a cites: el pool de connexions és un recurs compartit de tota l'aplicació, així que una petició a /api/negocis que només llegeix una altra taula tampoc no aconsegueix connexió i falla igual. És exactament el senyal de saturació que la 03-06 descrivia com l'únic que avisa abans: l'alerta PoolConnexionsAlt hauria saltat, encara que amb quinze minuts de finestra probablement massa tard.

Com s'hauria evitat, en tres capes: (a) CREATE INDEX CONCURRENTLY, que no bloqueja escriptures —recordant que no pot anar dins d'una transacció i que si falla deixa un índex invàlid per esborrar—; (b) SET lock_timeout = '3s', que hauria fet fallar la migració netament en lloc d'encuar tota l'aplicació, convertint una caiguda en un job vermell; i (c) haver assajat la migració sobre una còpia amb volum de producció, que hauria mostrat els 40 segons de construcció abans de tocar res. La primera és la solució, la segona és la xarxa de seguretat i la tercera és el que evita la sorpresa.

Solució 3. La resposta és no, i l'argument no és només normatiu. Les dades de les cites de Reservalia inclouen nom, telèfon i a vegades el motiu de la visita —potencialment dades de salut—; staging té menys controls d'accés, més persones amb permisos i logs més verbosos; i hi ha un risc específic i molt concret: si l'entorn té configurat el proveïdor d'SMS, un cicle de proves pot enviar recordatoris a clients reals, amb el flag recordatoris_sms activat sense pensar. El "només dos dies" tampoc no ajuda: els dos dies es converteixen en dos mesos, i una còpia de seguretat de staging presa durant aquella finestra pot sobreviure anys. L'alternativa que sí que resol la necessitat tècnica —que és legítima: reproduir un problema de rendiment exigeix volum realista— té tres peces. (1) Generar volum sintètic: l'script de l'apartat 9 escalat a 640.000 cites amb les mateixes distribucions que producció (cites per negoci, concentració horària, proporció d'horaris partits). El rendiment depèn del volum i la forma de les dades, no que els noms siguin verdaders. (2) Si el problema depèn d'una distribució molt específica, extreure de producció només les estadístiques —histogrames, cardinalitats— i fer-les servir per parametritzar el generador; se'n porten els números, no les dades. (3) Si res de tot això no basta, un bolcat anonimitzat en origen, dins del perímetre de producció, amb substitució irreversible de tots els camps personals, amb data de caducitat automàtica de l'entorn, amb les integracions externes desactivades per configuració, i amb l'aprovació prèvia del responsable de protecció de dades. És l'últim recurs, no el primer, i és precisament la decisió que un curs no pot prendre per tu.

El quart front està tancat. Reservalia ja no tracta l'esquema com un artefacte més: sap que és estat compartit, que una sola base de dades serveix totes les versions del codi desplegades alhora, i que per això el rollback.yml de la 03-05 —que retorna un digest en quatre minuts— no pot desfer un DROP COLUMN. Les seves migracions són fitxers versionats a apps/api/src/db/migracions/, amb marca de temps al nom, revisió obligatòria per CODEOWNERS i una taula migracions_aplicades que les fa idempotents i detecta per hash si algú edita una de ja aplicada. S'executen des del pipeline i mai des d'un portàtil, en un job migrar-prod amb el seu propi entorn d'aprovació —perquè aprovar codi i aprovar un canvi d'esquema són decisions diferents—, amb migrate:status al davant de l'aprovador i lock_timeout i statement_timeout fixats per connexió. I sobretot, Reservalia sap dissenyar el canvi perquè cap versió no es trenqui. El patró expand and contract va convertir el reanomenament d'hora_inici a inici_utc en quatre fases compatibles —expandir amb trigger bidireccional, migrar les dades per lots, desplegar el codi, i contraure una setmana després—, de manera que en tot moment el rolling update de la 03-04 i el canary conviuen amb un esquema que totes dues versions entenen i el rollback continua sent possible. Al voltant d'aquell patró hi ha una classificació clara de què és segur, perillós i prohibit en calent, amb l'alternativa de cada cas; la comprensió de per què un ALTER TABLE en espera tomba una aplicació sencera a través de la cua de bloquejos i del pool de connexions; un backfill per lots, pausat i represa-ble; i una política sobre dades de prova que descarta copiar producció i genera dades sintètiques, amb l'advertiment que aquella decisió es pren amb un professional de protecció de dades i no amb un curs.

Amb això, els quatre fronts que el mòdul 3 va deixar oberts estan resolts:

I el número que ho resumeix, mesurat amb la mateixa vara de la línia base del mòdul 1: el change failure rate ha baixat del 6,5 % al 3,8 %, per sota de l'objectiu del 5 % que era l'únic que quedava sense complir. Les quatre mètriques DORA són ara en verd —12 desplegaments per setmana, 3,5 hores de lead time, 3,8 % de fallades i 9 minuts de recuperació—, i les fallades que queden ja no són de procés: són les que qualsevol equip tindrà sempre, les que es descobreixen només quan el programari es troba amb usuaris reals.

Marta: "M'estimo més desplegar deu vegades al dia i que cada desplegament sigui avorrit." Aquell era l'objectiu des de la primera lliçó, i la feina d'aquests tres mòduls va consistir, exactament, a fer avorrit el que abans ocupava tres hores d'un divendres.

El que ve ara canvia de registre. Fins aquí hem construït un pipeline per a un producte, prenent a cada punt la decisió que convenia a Reservalia: monorepo de Node, GitHub Actions, contenidors sobre ECS, trunk-based amb squash. Totes aquelles decisions van ser raonades, però cap no és universal. El mòdul 5, Implementació de CI/CD en Projectes Reals, agafa el que s'ha après i ho sotmet a contextos que no s'assemblen al de Reservalia: una aplicació mòbil amb signatures, botigues i revisions que triguen dies; un sistema de microserveis on el graf de desplegament té desenes de nodes; i un projecte heretat sense proves al qual cal portar CI/CD sense poder-lo reescriure. Comença pel més proper, Cas d'Estudi: Projecte Web, que aterra el pipeline complet sobre una aplicació web real de principi a fi —inclosa la part d'apps/web que hem tractat sempre com a acompanyant de l'API— i serveix de pont entre el sistema que hem construït i els tres casos que el posaran a prova.