Reservalia ja té un artefacte immutable, un cd.yml que desplega tot sol i tres entorns que surten del mateix mòdul de Terraform. Queda la pregunta que hem anat esquivant: en l'instant exacte en què la versió nova substitueix la vella, com es fa aquell relleu? Avui Reservalia deixa que ECS reemplaci tasques sense criteri i creua els dits. Hi ha almenys sis maneres de fer-ho, i triar malament és la diferència entre un desplegament invisible i un tall de servei a les onze del matí. En aquesta lliçó veiem les sis amb el seu cost, el seu risc, el seu temps i la seva facilitat de tornada enrere; muntem un rolling update fi i un canary per pes d'ALB a Reservalia; entenem per què els health checks sostenen tot això; i acceptem el requisit que totes comparteixen: dues versions del programari conviuran, i s'han d'entendre.

1. Els quatre eixos amb què es compara una estratègia
2. Recreate: apagar i encendre
3. Rolling update: substituir per tandes
4. Blue-green: dos entorns complets i un interruptor
5. Canary: exposar una fracció del trànsit
6. Proves A/B: la que no és una estratègia tècnica
7. Shadow: trànsit duplicat sense conseqüències
8. Taula comparativa de les sis
9. Rolling update a ECS amb números reals
10. Un canary per pes d'ALB al 10 %
11. Health checks: liveness, readiness i el paper de /salut
12. Compatibilitat cap enrere: dues versions convivint
13. Què tria Reservalia per a prod
14. Errors Comuns i Consells
15. Exercicis
16. Conclusió

Cap estratègia no és "la bona". Cadascuna intercanvia quatre magnituds, i convé tenir-les anomenades abans de mirar la primera:

• Cost d'infraestructura: quanta capacitat extra cal durant el relleu. Duplicar un entorn de producció durant vint minuts costa diners de debò.
• Risc d'exposició: quin percentatge d'usuaris pateix la fallada si la versió nova és defectuosa. És la variable que mou el change failure rate de les mètriques DORA.
• Temps de desplegament: quant triga el relleu complet. Un desplegament de dues hores no es fa cinc vegades per setmana.
• Complexitat de la tornada enrere: quant es triga i quant s'ha de pensar per tornar a la versió anterior. És el time to restore, que a Reservalia és de 68 minuts i ha de baixar a menys de 10.

Hi ha un cinquè eix implícit: la complexitat operativa. Una estratègia que ningú de l'equip no entén a les tres de la matinada és una mala estratègia per bons que siguin els seus números.

En què consisteix. S'aturen totes les instàncies de la versió antiga i després s'arrenquen les de la nova. És el que feia el "ritual del divendres" de Reservalia amb el seu SFTP.

Quan triar-la. Quan el tall és acceptable (eines internes, processos per lots nocturns) o quan és inevitable: si la versió nova és incompatible amb l'antiga i no poden conviure ni un segon, recreate és l'única opció honesta. És l'estratègia per defecte de qualsevol sistema sense balancejador al davant.

En què consisteix. Se substitueixen les instàncies per grups: s'arrenca una tanda de la versió nova, s'espera que passi el health check, es retira la mateixa quantitat de l'antiga, i es repeteix fins a acabar. Durant el procés conviuen les dues versions.

Quan triar-la. És el valor per defecte raonable per a serveis sense estat darrere d'un balancejador. És el que ECS fa de manera nativa i el que Reservalia farà servir com a base.

En què consisteix. S'aixeca un entorn verd complet amb la versió nova, al costat del blau que continua servint trànsit. Es prova el verd en aïllament i, quan convenç, es canvia l'encaminament del balancejador de cop. El blau es manté encès una estona per si cal tornar.

Quan triar-la. Quan el time to restore és la prioritat absoluta i el pressupost permet duplicar capacitat. Compte amb un detall que s'oblida sempre: la base de dades no es duplica, així que la compatibilitat d'esquema continua sent obligatòria.

En què consisteix. Es desplega la versió nova en un grup petit i se li envia un percentatge reduït del trànsit —el canari a la mina—. S'observen mètriques d'error i latència durant uns minuts i, si es comporten, es puja el pes per etapes: 10 % → 50 % → 100 %. Si es degraden, es baixa a 0 %.

Quan triar-la. Per a canvis de risc mitjà-alt en serveis amb trànsit suficient perquè les mètriques siguin significatives. Amb 9.000 cites al mes, un canary al 10 % de Reservalia veu unes 30 peticions de reserva al dia: cal donar-li temps o combinar-lo amb mètriques de trànsit total, no només de l'endpoint crític.

Es confon constantment amb el canary perquè el mecanisme s'hi assembla: dues versions servint alhora i un repartiment d'usuaris. La diferència és quina pregunta respon cadascuna.

Una prova A/B no és un mecanisme de desplegament: s'implementa normalment sobre feature flags dins d'una única versió desplegada, que és justament el tema de la lliçó següent. Confondre-les porta a errors cars, com avortar un desplegament tècnicament correcte perquè una variant converteix pitjor, o mantenir dues versions desplegades durant setmanes "per mesurar".

En què consisteix. El trànsit real es copia cap a la versió nova, les respostes de la qual es descarten: els usuaris continuen rebent les de la versió antiga. Serveix per validar rendiment i correcció amb càrrega real i risc zero de cara a l'usuari.

El parany: si la versió mirall escriu a la base de dades, envia correus de confirmació de cita o cobra, el "risc zero" desapareix de cop. El shadow exigeix aïllar els efectes secundaris, i per això només compensa en canvis d'alt risc: reescriptures d'un motor de càlcul, migracions de tecnologia, refactoritzacions profundes de calcularForats.

ECS implementa el rolling update amb dos percentatges sobre desired_count. A prod, Reservalia té 4 tasques del servei reservalia-api:

• minimumHealthyPercent: el mínim de tasques sanes que hi ha d'haver en tot moment, en percentatge de desired_count.
• maximumPercent: el màxim de tasques simultànies, incloent-hi les de les dues versions.

Amb desired_count = 4, aquests dos números es tradueixen així:

Reservalia fa servir 100 / 200 a prod i 50 / 100 a dev, on una davallada de capacitat no molesta ningú i l'estalvi sí que importa. La seqüència que executa ECS amb 100/200 és: arrencar 4 tasques v2 → esperar que les 4 passin el health check del grup de destinació → registrar-les a l'ALB → desregistrar les 4 tasques v1 i esperar el connection draining → aturar-les.

Mentre el desplegament avança apareixen dues entrades: la PRIMARY (versió nova) i l'ACTIVE (l'anterior, en retirada). Quan només queda PRIMARY, el relleu ha acabat; és justament el que espera aws ecs wait services-stable a cd.yml.

Un paràmetre més, i és el que evita la meitat dels ensurts:

Amb el circuit breaker, si les tasques de la versió nova fallen repetidament en arrencar, ECS avorta el desplegament i restaura la definició de tasca anterior sense intervenció humana. És la tornada enrere automàtica més barata que existeix en aquesta plataforma.

Per a canvis delicats —tocar calcularForats, per exemple— Reservalia afegeix un mode canary. La peça clau és que un ALB pot repartir trànsit entre diversos grups de destinació amb pesos.

Dos detalls importants:

• TG_ESTABLE i TG_CANARY són dos grups de destinació, servits per dos serveis ECS (reservalia-api i reservalia-api-canary) que corren el mateix artefacte o un de diferent: és el pes, no el desplegament, el que decideix l'exposició.
• TargetGroupStickinessConfig fa que un usuari que ha caigut al canary hi continuï durant una hora. Sense això, un mateix usuari saltaria entre versions petició a petició, amb resultats incoherents si el canvi afecta la interfície.

La promoció per etapes s'automatitza com un job amb pauses d'observació:

comprovar-metriques.sh consulta CloudWatch i retorna un codi de sortida diferent de zero si el canary es comporta pitjor que l'estable; la fallada del pas atura el pipeline amb el canary encara al 10 %, és a dir, amb el 90 % dels usuaris intactes. Com es defineixen aquells llindars amb criteri és matèria de la lliçó 03-06.

Totes les estratègies anteriors depenen d'una resposta binària: aquesta instància nova està llesta per rebre trànsit? Qui la dona és el health check, i n'hi ha dos tipus que sovint es confonen.

A la 03-02, el smoke test cridava un únic /salut que feia les dues coses alhora; ara ho separem, perquè barrejar-les és exactament l'origen del problema. A Reservalia, /salut passa a ser el liveness: respon 200 amb un cos mínim i no toca la base de dades. Ha de ser barat perquè es crida cada pocs segons i perquè, si comprovés PostgreSQL, una caiguda de la base de dades provocaria el reinici en bucle de tots els contenidors, convertint una degradació en una caiguda total.

1. El readiness sí que comprova la connexió al pool de PostgreSQL: una tasca que no pot consultar la base de dades no ha de rebre cites.
2. També comprova que no quedin migracions pendents; una tasca amb esquema desactualitzat respon 503 en lloc de trencar peticions reals.
3. El codi 503 és el que fa que l'ALB no la registri. Retornar 200 amb un cos que diu "error" no serveix de res: el balancejador mira el codi, no el text.

Per què un health check que retorna 200 sense comprovar res és pitjor que cap. Perquè menteix amb autoritat. El rolling update pregunta "està llesta?", l'endpoint respon que sí abans que l'aplicació pugui atendre res, ECS retira les tasques de la versió antiga i el servei queda servit per instàncies que retornen errors. Sense health check, almenys l'operador sap que no té informació; amb un de fals, el sistema pren decisions destructives basades en una resposta buida. La regla: un readiness ha de poder dir que no. Si mai no has vist el teu /salut/llest retornar 503, probablement no comprova res.

Totes les estratègies llevat de recreate tenen la mateixa conseqüència: durant una estona, v1 i v2 atenen els mateixos usuaris sobre la mateixa base de dades. Si no són compatibles, l'estratègia elegant es converteix en un incident elegant.

El patró que resol gairebé tots els casos "no" és expandir i contraure: primer es desplega un canvi que afegeix el que és nou sense treure el que és vell (expandir), després es migren els consumidors, i només en un tercer desplegament s'elimina el que és antic (contraure). Reanomenar duracio es converteix així en tres passos segurs: retornar tots dos camps, actualitzar la web, deixar de retornar duracio.

El mateix s'aplica a les dades, i allà és més greu, perquè una migració d'esquema no es reverteix amb un canvi de pes a l'ALB. Afegir una columna és compatible; esborrar-la o reanomenar-la trenca la versió que continua corrent. Aquell terreny té lliçó pròpia: 04-06, Bases de Dades al Pipeline: Migracions Segures.

La Marta ho tanca així: rolling update 100/200 amb circuit breaker com a estratègia per defecte, i canary per pes d'ALB per als canvis marcats com a arriscats (els que toquen calcularForats, el càlcul de preus o el flux de pagament).

Les raons, en l'ordre en què les va exposar: el rolling update no costa infraestructura permanent i ECS ho fa nativament, així que és l'opció que l'equip pot operar sense cerimònies; el circuit breaker ja cobreix la fallada més freqüent, que és una versió que ni tan sols arrenca; blue-green es descarta perquè duplicar prod de manera sostinguda no cap al pressupost d'una empresa amb 340 clients de pagament; i el canary es reserva per al que realment s'ho mereix, perquè les seves esperes d'observació allarguen el desplegament i, amb el trànsit actual, exigeixen finestres llargues perquè els números signifiquin alguna cosa. El shadow queda anotat per al dia que calgui reescriure el motor d'agenda.

Error 1: triar canary per moda. Un canary sense mètriques fiables ni llindars definits és un rolling update lent i car amb una sensació falsa de seguretat. Primer l'observabilitat, després el canary. Error 2: creure que blue-green elimina el risc de dades. Els dos entorns comparteixen la base de dades: si la versió verda ha aplicat una migració destructiva, tornar al blau no retorna les dades.

Error 3: fer servir minimumHealthyPercent = 0 "perquè vagi ràpid". És recreate amb un altre nom, i a prod significa tall de servei. Error 4: un readiness que crida totes les dependències. Si /salut/llest consulta un servei extern de pagaments, una fallada d'aquell servei treu del balancejador totes les tasques sanes; comprova només l'imprescindible per atendre.

Error 5: canary sense adherència de sessió. L'usuari alterna entre versions petició a petició i veu comportaments incoherents; els informes d'error resultants són irreproduïbles.

Consell 1: assaja la tornada enrere. Una estratègia amb rollback teòric no provat té rollback de 68 minuts. Consell 2: escriu l'estratègia al codi d'infraestructura, no a la memòria de la Nuria; els percentatges viuen a infra/moduls/entorn/. Consell 3: davant el dubte entre dues estratègies, tria la que l'equip entengui millor a les tres de la matinada.

Reservalia ha de desplegar un canvi que reescriu calcularForats amb un algorisme nou, més ràpid però amb risc de retornar forats incorrectes en casos rars. El resultat és visible per a l'usuari i afecta reserves reals. Tria una estratègia, justifica-la davant de les altres cinc i descriu què mesuraries per decidir si promocionar.

El servei reservalia-api a staging té desired_count = 2, minimumHealthyPercent = 100 i maximumPercent = 100. En Diego llança un desplegament i el workflow es queda penjat fins que wait-for-service-stability esgota el temps. Explica què ha passat i proposa dues configuracions vàlides.

La Marta vol retirar el camp duracio de la resposta de GET /cites i substituir-lo per duracioMin. La web de Reservalia consumeix aquest camp i hi ha integracions de tres clients que també el fan servir. Dissenya la seqüència de desplegaments i digues quina estratègia faries servir en cadascun.

Solució 1. L'elecció és canary, complementat idealment amb una fase prèvia de shadow. Raonament: recreate i rolling update exposen tothom o una fracció no controlada, i aquí la fallada produeix reserves incorrectes —dany de negoci, no només error tècnic—. Blue-green exposa el 100 % tan bon punt es commuta, així que no acota el dany. Les proves A/B no apliquen: la pregunta és de correcció, no de preferència. El shadow és ideal perquè calcularForats és una funció de lectura i es poden comparar les sortides de v1 i v2 amb trànsit real sense que l'usuari vegi res; el seu límit és que no valida el flux complet de reserva. Amb el canary al 10 % mesuraria, a més d'errors 5xx i latència p95: el nombre de reserves creades per sessió (una caiguda indica forats que desapareixen), la taxa de conflictes en confirmar cita (dos usuaris reservant el mateix forat indica forats duplicats) i les reclamacions de suport. Amb ~30 reserves diàries al canary, la finestra d'observació s'ha de mesurar en dies, no en minuts, o cal apujar el pes inicial al 25 %.

Solució 2. Amb minimumHealthyPercent = 100 i maximumPercent = 100, ECS no pot retirar cap tasca antiga (trencaria el mínim de 2 sanes) ni arrencar-ne cap de nova (trencaria el màxim de 2 totals). El desplegament queda bloquejat: és una configuració impossible. Dos arreglaments vàlids: (a) 100 / 200, que permet arrencar fins a 2 tasques noves abans de retirar les antigues, sense pèrdua de capacitat i amb cost extra transitori; (b) 50 / 100, que permet retirar una tasca antiga per fer lloc a una de nova, sense cost extra però amb la capacitat reduïda a la meitat durant el relleu. A staging, la (b) és perfectament raonable; a prod, la (a).

Solució 3. Tres desplegaments seguint expandir-contraure. Desplegament 1 (expandir): l'API retorna duracio i duracioMin amb el mateix valor. És un canvi additiu i compatible, així que n'hi ha prou amb un rolling update normal. Desplegament 2 (migrar consumidors): la web passa a llegir duracioMin; s'avisa els tres clients d'integració amb una data límit i s'instrumenta l'ús del camp antic per saber quan deixa de llegir-se —sense aquella dada, la data límit és una suposició—. Desplegament 3 (contraure): quan la telemetria confirmi que ningú no consumeix duracio, s'elimina de la resposta; aquí convé un canary, perquè és l'únic pas que pot trencar un tercer desprevingut i el pes permet revertir en segons. L'error clàssic és intentar fer-ho en un sol desplegament confiant que "la web es desplega alhora": durant el rolling update conviuen totes dues versions de l'API i totes dues de la web, així que la incompatibilitat es manifesta igualment.

Ja no hi ha una sola manera de substituir una versió per una altra, sinó un menú amb preus. Recreate és simple i talla; rolling update és el valor per defecte sensat; blue-green compra un rollback instantani pagant capacitat doble; canary compra risc baix pagant temps; A/B no és una estratègia tècnica sinó una eina de producte; i shadow valida amb càrrega real sense exposar ningú, sempre que s'aïllin els efectes secundaris. Reservalia es queda amb rolling update 100/200 més circuit breaker, i reserva el canary per pes d'ALB per al que és arriscat.

A sota de totes elles hi ha dos fonaments que convé no oblidar: un readiness honest que sàpiga dir 503, perquè és el senyal sobre el qual s'apuntalen tots els automatismes, i la compatibilitat cap enrere, perquè tan bon punt s'abandona recreate hi ha dues versions convivint sobre la mateixa base de dades.

Tot i així, continuem lligats a una suposició optimista: que la fallada es detecta durant el desplegament. Moltes fallades apareixen hores després, quan el canary ja s'ha promocionat i la finestra d'observació s'ha tancat. A més, hi ha un problema previ: desplegar codi i activar una funcionalitat són la mateixa acció, així que una funcionalitat a mig fer obliga a mantenir branques de vida llarga. La lliçó següent, Feature Flags, Rollback i Recuperació davant Errors, separa el desplegament del llançament, construeix el botó de tornada enrere de Reservalia i converteix els 68 minuts de time to restore en un objectiu assolible.