El mòdul 2 va acabar amb una promesa: que l'artefacte reservalia/api:a3f9c21 que avui espera a ECR començaria a viatjar tot sol fins a dev, staging i prod, i que el divendres a la tarda tornaria a ser, senzillament, un divendres a la tarda. Aquesta lliçó és el primer pas per complir-la, i no consisteix a escriure YAML —això arriba a la 03-02—, sinó a entendre què separa exactament un artefacte publicat d'un artefacte desplegat, i què ha d'estar al seu lloc abans que una màquina toqui producció sense demanar permís. Reprendrem la distinció entre Lliurament Continu i Desplegament Continu, ara amb un pipeline real al davant; enumerarem els cinc requisits sense els quals automatitzar el desplegament només serveix per fallar més de pressa; dissenyarem la cadena d'entorns de Reservalia decidint què valida cadascun; i mirarem de cara les portes d'aprovació, inclosa la més popular de totes: el freeze dels divendres.

1. De "l'artefacte espera a ECR" a "l'artefacte viatja sol"
2. Lliurament Continu i Desplegament Continu: on és exactament la porta
3. Els cinc requisits previs d'un CD sa
4. La cadena d'entorns de Reservalia
5. Portes d'aprovació: manuals, automàtiques i finestres de desplegament
6. Què canvia en el repartiment de responsabilitats de l'equip
7. El flux complet commit → prod de Reservalia
8. Errors Comuns i Consells
9. Exercicis
10. Conclusió

Fem inventari honest de la situació de Reservalia en començar el mòdul 3.

Quan en Diego fusiona un pull request a main, el workflow ci.yml executa qualitat, test i build en paral·lel i, si els tres passen, el job publicar puja a ECR la imatge reservalia/api:a3f9c21. Quatre minuts després del merge existeix un artefacte immutable, verificat i traçable. I allà es queda.

El que passa a partir d'aquest punt encara és el ritual del divendres de la lliçó 01-04: en Diego obre un terminal, es connecta a la consola d'AWS, edita a mà la definició de tasca d'ECS perquè apunti a la nova etiqueta, executa les migracions des de psql i es queda mirant els logs durant tres hores. L'artefacte és del 2026; el procediment és del 2012.

Vist en un diagrama, el pipeline de Reservalia avui té una meitat automàtica i una meitat de persones:

Aquella fletxa de punts és tot el mòdul 3. I no és només lentitud: és la part del procés que no està escrita enlloc, no es revisa, no es prova i no es pot repetir igual dues vegades. La distància entre les dues meitats té un nom tècnic —el desplegament no està automatitzat— però també una conseqüència mesurable que ja coneixem:

Dues de les quatre mètriques no s'han mogut, i cap quantitat de proves addicionals no les mourà. Són mètriques de desplegament, i el desplegament és el que comencem ara.

A la lliçó 01-01 vam definir els tres termes de manera abstracta. Ara podem assenyalar el punt exacte del pipeline de Reservalia on hi ha la diferència, cosa molt més útil.

La confusió habitual és pensar que el Lliurament Continu és "CD a mitges". No ho és: és el 90 % de la feina. Tot el que és difícil —automatitzar el desplegament, fer els entorns equivalents, poder tornar enrere, tenir observabilitat— s'ha de resoldre igualment. L'única cosa que queda pendent al Desplegament Continu és treure una condició if d'un workflow.

Dit d'una altra manera: si ets capaç de desplegar a producció prement un botó que no fa por, ja has fet la part cara. Que el botó el premi una persona o una màquina és aleshores una decisió de negoci, no d'enginyeria, i depèn de coses com el sector (una fintech regulada pot necessitar deixar constància d'una aprovació humana), la maduresa de l'observabilitat o senzillament quanta confiança té l'equip. Reservalia arribarà al Lliurament Continu a la lliçó 03-02 i traurà la porta al final del mòdul, quan el rollback (03-05) i el monitoratge (03-06) estiguin muntats.

Marta: "M'estimo més desplegar deu vegades al dia canvis de vint línies que una vegada al mes un canvi de dues mil. No perquè sigui valenta, sinó justament pel contrari: perquè un canvi de vint línies que es trenca l'entenc en un minut."

Automatitzar el desplegament sense aquests cinc elements no accelera el lliurament: accelera la producció d'incidents. Cadascun respon una pregunta concreta.

1. Una suite de proves en la qual es confia. La pregunta és: si el pipeline és verd, desplegaries sense mirar? Si la resposta honesta és "depèn de què hagi canviat", la suite encara no és una autorització, és una opinió. Reservalia compleix aquest requisit des de la 02-04: unitàries sobre calcularForats, integració contra PostgreSQL real i una política de quarantena per a les proves inestables. Una sola prova flaky tolerada destrueix aquest requisit sencer, perquè ensenya l'equip a ignorar el vermell.

2. Un artefacte immutable. El que posaré a producció és exactament el que es va validar? Amb reservalia/api:a3f9c21 i el principi de "construir una vegada, promocionar el mateix digest" de la 02-06, sí. Si cada entorn reconstruís la imatge des del codi, el binari de prod seria un artefacte mai provat, tot i que el commit fos el mateix.

3. Entorns equivalents. El que funciona a staging funcionarà a prod? Només si s'assemblen en el que importa: mateixa versió de PostgreSQL (16), mateixa versió de Node (20.11.0, que és la de la imatge base), mateixa topologia de xarxa, mateixes variables de configuració encara que amb valors diferents. Equivalent no vol dir idèntic —prod té més instàncies i dades reals—, vol dir que no hi ha diferències que puguin canviar el comportament del programari. Aquest requisit és el que empeny cap a la Infraestructura com a Codi de la lliçó 03-03.

4. Un desplegament reversible. Si surt malament, quant trigo a deixar-ho com estava? És el requisit que més equips es salten i el que surt més car. La Nuria ho va dir al mòdul 1: "Un desplegament que no es pot desfer en cinc minuts no és un desplegament, és una aposta". Es desenvolupa a la 03-05.

5. Observabilitat suficient. Si alguna cosa es trenca, me n'assabento jo abans que el client? Desplegar automàticament sense senyals de producció és desplegar a cegues i esperar que soni el telèfon. És el contingut de la 03-06, amb què es tanca el mòdul.

Resumits en una taula, amb la comprovació concreta que permet saber si es compleixen de debò:

Tots cinc formen un sistema: fallar en un degrada els altres quatre. Sense observabilitat no saps quan fer servir el rollback; sense rollback l'observabilitat només et serveix per veure l'incendi en directe; i sense entorns equivalents les proves de staging deixen de ser una autorització per passar a prod, amb la qual cosa el requisit 1 s'esfondra encara que la suite sigui impecable.

Diego: "Si la CI triga més que anar a buscar un cafè, deixo de mirar-la. I si el desplegament triga tres dies, deixo de sentir-lo meu."

Un entorn no és "una còpia del sistema": és un lloc on es respon una pregunta que no es pot respondre abans. Si un entorn no respon cap pregunta nova, sobra i només afegeix latència al lead time.

Tres decisions d'aquest disseny mereixen explicació, perquè són les que sol equivocar un equip que munta la seva primera cadena d'entorns:

No hi ha entorn de "QA" separat de staging. Afegir un entorn que només serveix perquè algú miri el mateix que es pot mirar a staging allarga el lead time sense respondre cap pregunta nova. La regla és: un entorn més, una pregunta més.

Les dades de staging són una còpia anonimitzada, no una còpia. Copiar la base de dades de producció amb noms, telèfons i correus de clients reals a un entorn amb menys control d'accés és, a més d'una mala pràctica, un problema legal. El procés de Reservalia substitueix noms, telèfons i correus per valors generats, i conserva volum i distribució: 340 negocis, ~9.000 cites al mes, la mateixa proporció de cites cancel·lades. Això és el que fa que staging detecti un problema de rendiment que dev no veuria mai.

dev és un entorn desplegat, no el portàtil d'en Diego. "A la meva màquina funciona" no és una validació. dev és el primer lloc on l'artefacte s'executa sobre infraestructura d'AWS de debò, amb IAM, amb Secrets Manager i amb un ALB al davant. Moltes fallades —un permís que falta, una variable mal escrita— apareixen exactament allà i enlloc més.

Com que l'artefacte és el mateix als tres, saber en quin punt de la cadena és cada versió es redueix a preguntar a cada entorn qui és. Gràcies a l'endpoint /version de la 02-06, això és un bucle de tres línies:

curl -sf calla la barra de progrés i retorna error si l'HTTP no és 2xx; --max-time 5 evita que l'script es quedi penjat si un entorn no respon; jq -r extreu el camp commit sense cometes. Executat un dimarts qualsevol, la sortida de Reservalia hauria d'assemblar-se a això:

És a dir: la cadena avança i prod va dos commits per darrere. Aquesta foto en tres línies és l'instrument més barat que existeix per respondre la pregunta de la Nuria a les 23:40 —"quina versió hi ha desplegada?"— i la farem servir a totes les lliçons del mòdul.

Una porta és una condició que un desplegament ha de complir per avançar a l'entorn següent. N'hi ha tres famílies, i no valen el mateix.

La porta manual té un ús legítim i un d'il·legítim. Legítim: decidir quan es llança alguna cosa per raons de producte —una funcionalitat que ha de coincidir amb una campanya, un canvi que requereix avisar els negocis—. Il·legítim: "per si de cas". Una aprovació el revisor de la qual no té cap informació que el pipeline no tingui ja no és una porta de qualitat, és un segell de goma. Es nota fàcilment: si ningú no ha rebutjat mai una aprovació, la porta no filtra res.

I arribem al freeze dels divendres, que gairebé tots els equips han practicat alguna vegada. El raonament és intuïtiu: si despleguem el divendres i es trenca, arruïnem el cap de setmana d'algú. Mirem què produeix en realitat:

• La feina del dijous i del divendres s'acumula, així que el dilluns es desplega un lot molt més gran. I sabem des de la 02-07 que el risc d'un lot creix més de pressa que la seva mida.
• El dilluns és, per tant, el dia més perillós de la setmana, precisament pel freeze.
• L'equip aprèn que desplegar és perillós, cosa que reforça la política i tanca el cercle.

Per això el freeze és un símptoma, no una solució: és el que fa un equip que no pot tornar enrere en cinc minuts ni assabentar-se d'una fallada en dos. La cura no és prohibir els divendres, és fer que el desplegament del divendres sigui tan avorrit com el del dimarts. Reservalia mantindrà el freeze durant bona part d'aquest mòdul, i el retirarà —conscientment i amb dades— quan estiguin muntats el rollback de la 03-05 i les alertes de la 03-06.

Nota important: prohibir els desplegaments els divendres no impedeix que hi hagi incidents els divendres. Impedeix que hi hagi arreglaments els divendres, perquè un hotfix urgent xoca amb la mateixa política.

Automatitzar el desplegament no elimina feina humana: la desplaça. Val la pena fer-ho explícit, perquè el canvi cultural és on encallen la majoria de les adopcions de CD.

Dues conseqüències que convé acceptar des del principi:

L'autor del canvi es fa amo del seu canvi en producció. És el famós you build it, you run it. Quan el desplegament triga tres dies i el fa una altra persona, és fàcil desentendre-se'n. Quan el teu commit és en producció quaranta minuts després del merge, la retroalimentació és teva i és immediata. Això no vol dir que en Diego es converteixi en l'SRE de guàrdia; vol dir que veu les mètriques del seu canvi i hi participa quan alguna cosa es torça.

El pipeline passa a ser producció. Si el desplegament està automatitzat, el workflow té permisos sobre la infraestructura i una vulnerabilitat al pipeline és una vulnerabilitat en producció. Aquest canvi d'estatus —de "eina interna" a "sistema crític"— és la raó que existeixi la lliçó 04-03, dedicada a la seguretat del pipeline.

Aquest és el destí del mòdul: el diagrama tal com quedarà en acabar la lliçó 03-06. Encara no en saps implementar la major part, i no passa res; serveix com a mapa per situar cada lliçó.

Recorrent-lo de dalt a baix apareix l'índex del mòdul: 03-02 construeix les caixes de desplegament a dev i staging; 03-03 garanteix que aquestes tres caixes d'entorn surten del mateix codi; 03-04 converteix el desplegament a prod en un canari controlat; 03-05 dibuixa les dues fletxes de rollback; i 03-06 tanca el bucle amb les mètriques que decideixen si el canari avança o retrocedeix.

I hi ha una propietat del diagrama que convé subratllar: l'artefacte a3f9c21 apareix una sola vegada, al primer pas. Tota la resta són moviments del mateix digest. Aquest és el principi de la 02-06 portat fins al final.

Error 1: automatitzar el desplegament abans de poder tornar enrere. És l'ordre invers al sensat. Si despleges cinc vegades al dia i no saps revertir, has multiplicat per cinc l'exposició al risc sense tocar la capacitat de resposta. Rollback primer, freqüència després.

Error 2: dir staging a un entorn que no s'assembla a producció. Un staging amb SQLite, amb 30 registres de prova i una sola instància no respon cap pregunta útil; només genera una falsa sensació de validació i el clàssic "però si a staging funcionava".

Error 3: acumular entorns. He vist cadenes dev → test → qa → uat → preprod → prod. Cada baula afegeix dies de lead time i, gairebé sempre, cap no respon una pregunta que no respongui l'anterior.

Error 4: fer servir una còpia literal de la base de dades de producció a staging. Dades personals reals en un entorn amb menys control d'accés, més gent amb permisos i menys auditoria.

Error 5: confondre "tenim aprovació manual" amb "tenim control". Si l'aprovador no té informació addicional ni criteri per rebutjar, la porta només afegeix latència.

Consell 1: escriu quina pregunta respon cada entorn i posa-ho al README.md. És el millor filtre contra la proliferació d'entorns.

Consell 2: mesura el temps que un artefacte passa esperant a cada porta. Sol ser el component més gran del lead time, i és invisible fins que el mesures.

Consell 3: tracta el freeze dels divendres com a deute tècnic, amb data de retirada i condicions concretes per retirar-lo, no com una política permanent.

Un equip desplega a producció una vegada cada tres setmanes, amb aprovació d'un comitè. Té bona CI: proves fiables, artefactes immutables en un registre i main sempre verd. Vol passar a Lliurament Continu. Avalua els cinc requisits previs i indica quin abordar primer i per què.

Reservalia es planteja afegir un entorn preprod entre staging i prod, idèntic a prod però sense trànsit real. Argumenta a favor i en contra, i decideix, indicant quina dada consultaries per decidir.

El director de tecnologia proposa: "Ja que automatitzarem, traguem també l'aprovació de prod: Desplegament Continu pur des de demà". Estàs d'acord amb el destí, però no amb la data. Escriu tres condicions mesurables que s'haurien de complir abans de treure aquella porta.

Solució 1. L'equip ja compleix els requisits 1 i 2 (proves fiables, artefacte immutable). Queden per avaluar el 3, el 4 i el 5. El primer que cal abordar és el 4, el desplegament reversible, per dues raons. La primera és de risc: en passar d'un desplegament cada tres setmanes a diversos per setmana, l'exposició es multiplica, i sense capacitat de revertir cada incident dura el que duri el diagnòstic. La segona és cultural i més important: el comitè d'aprovació existeix perquè desplegar fa por, i la por ve del fet que un error és irreversible. Demostrar que qualsevol desplegament es desfà en cinc minuts és el que fa negociable l'existència del comitè; sense això, qualsevol proposta d'accelerar xocarà —amb raó— contra l'argument del risc.

L'ordre raonable a continuació seria: 5, observabilitat (sense senyal no saps quan revertir, així que el rollback queda a mercè que algú se n'adoni), i després 3, entorns equivalents, que és el més car i lent perquè implica Infraestructura com a Codi.

Solució 2. A favor: un preprod idèntic a prod permet validar canvis d'infraestructura i proves de càrrega sense risc, i és habitual en sectors amb requisits regulatoris. En contra: costa pràcticament el mateix que prod (uns 900 €/mes per a 340 negocis de pagament, difícil de justificar), afegeix una baula al lead time i, sobretot, no respon cap pregunta nova si staging ja té dades anonimitzades amb volum realista. El risc afegit és que un entorn sense trànsit real tampoc no detecta problemes de concurrència o de càrrega, que és justament el que se li demanaria.

Decisió: no afegir-lo. La dada que ho confirma és l'anàlisi dels incidents de producció dels últims sis mesos: quants haurien estat detectats per un preprod i no per staging? Si la resposta és zero o un, l'entorn no es paga. Si apareguessin diverses fallades lligades a diferències d'infraestructura, la resposta correcta continuaria sent probablement arreglar staging —fer-lo més semblant a prod mitjançant IaC, lliçó 03-03— abans que afegir un sisè entorn.

Solució 3. Tres condicions mesurables i verificables:

1. Rollback demostrat: el workflow de tornada enrere existeix, s'ha provat en un simulacre real i retorna prod a la versió anterior en menys de 5 minuts de manera mesurada, no estimada.
2. Detecció automàtica: hi ha alertes sobre símptomes (error rate i latència p95 de l'endpoint de reserva) que disparen en menys de 2 minuts, i el registre dels últims tres mesos mostra que cap incident de severitat alta no va ser detectat primer per un client.
3. Historial d'aprovacions buit de rebuigs: durant almenys 30 desplegaments consecutius, l'aprovació manual no n'ha rebutjat ni modificat cap. Si no filtra mai, no aporta informació i el seu cost en lead time és pur. Si sí que n'ha rebutjat algun, cal entendre per què abans de treure-la: probablement el pipeline no comprova alguna cosa que sí que hauria de comprovar.

Es pot afegir una quarta condició de transició: aplicar el Desplegament Continu primer al servei menys crític, o només als canvis que no toquen el domini de pagaments, i ampliar l'abast quan l'historial ho avali.

Aquesta lliçó ha establert el marc del mòdul. L'artefacte reservalia/api:a3f9c21 està llest des del mòdul 2; el que falta és el camí que el porta fins als 340 negocis, i aquest camí té forma de cadena d'entorns —dev per comprovar que arrenca sobre AWS real, staging per comprovar que aguanta dades i volum realistes, prod per als clients— amb portes entremig.

Les idees que convé endur-se: el Lliurament Continu és el 90 % de la feina i el Desplegament Continu és treure una condició d'un workflow, així que l'objectiu real és un botó que no faci por; un CD sa necessita cinc requisits —proves fiables, artefacte immutable, entorns equivalents, desplegament reversible i observabilitat— que formen un sistema on fallar en un degrada els altres; cada entorn ha de respondre una pregunta que no es pugui respondre abans, o sobra; les portes manuals valen per a decisions de producte i les automàtiques per mètrica per a decisions tècniques; i el freeze dels divendres és el símptoma d'un equip que no pot tornar enrere de pressa, no una política de qualitat.

També ha canviat el repartiment de papers: la Nuria construeix la plataforma en lloc d'executar desplegaments, la Marta cuida els objectius en lloc de coordinar releases, i en Diego es fa amo del seu canvi fins a producció. I el pipeline, que tindrà permisos sobre la infraestructura, deixa de ser una eina interna per convertir-se en un sistema crític.

La lliçó següent, Automatització del Desplegament, baixa de la teoria al fitxer: escriurem .github/workflows/cd.yml línia a línia, veurem com es dispara des del job publicar, com s'autentica contra AWS amb OIDC sense desar claus, com s'actualitza el servei d'ECS amb el digest exacte, on viu la configuració de cada entorn —perquè l'artefacte és el mateix i el que canvia és la configuració— i com es comprova amb un smoke test contra /version que el que està corrent és de debò el que crèiem haver desplegat.