El teu projecte funciona, està provat, es mesura i una màquina el vigila a cada push. I tanmateix continua vivint al teu portàtil, on no serveix a ningú. Desplegar és el que converteix un repositori en un producte, i és també el moment en què apareixen els problemes que cap entorn de desenvolupament no ensenya: les rutes que funcionaven a localhost i donen 404 al servidor, la memòria cau que serveix la versió antiga durant una setmana, el service worker que es queda enganxat amb codi de fa tres desplegaments, la clau d'API que creies protegida i que qualsevol pot llegir amb dos clics, i les capçaleres de seguretat que ningú no configura perquè ningú no les hi ha explicat. En aquesta lliçó aprendràs a preparar la compilació de producció entenent què fa cada part i per què cap clau secreta no pot viure al client; a triar on allotjar amb una taula comparativa honesta; a configurar el servidor de debò —rutes de SPA, memòria cau coherent amb el hashing i amb el service worker, compressió i capçaleres de seguretat explicades una a una—; a decidir què fer amb el backend sense escriure'l, amb l'advertiment que la validació del client mai no substitueix la del servidor; a muntar el desplegament continu amb vistes prèvies per branca i una estratègia de reversió que funcioni a les tres de la matinada; a monitorar en producció sense convertir-te en un problema de privacitat; i a actualitzar una PWA ja instal·lada sense deixar ningú amb una versió antiga. Acabaràs amb l'aplicació desplegada amb HTTPS, el seu flux de desplegament continu i una llista de comprovació de llançament signada.

1. Què canvia quan el codi surt de la teva màquina
2. La compilació de producció
3. Variables d'entorn i per què no hi ha secrets al client
4. On allotjar: taula comparativa honesta
5. Domini, HTTPS i certificats
6. Les rutes d'una SPA i la reserva a index.html
7. Memòria cau: la part que més es fa malament
8. Compressió
9. Capçaleres de seguretat, una a una
10. El backend: quines opcions hi ha sense escriure un servidor
11. La validació del client mai no substitueix la del servidor
12. Desplegament continu amb GitHub Actions
13. Entorns de vista prèvia per branca
14. Estratègia de reversió
15. Monitoratge d'errors en producció
16. Mètriques de camp amb web-vitals
17. Actualitzar una PWA ja instal·lada
18. La llista de comprovació de llançament
19. Errors Habituals i Consells
20. Exercicis
21. Conclusió

En desenvolupament, Vite fa moltíssimes coses per tu que en producció no existeixen. Convé veure la llista completa abans de res, perquè cada fila és una font de sorpreses:

La conseqüència pràctica és una regla d'or que estalvia moltíssim temps:

No despleguis mai res que no hagis provat amb npm run build i npm run preview a la teva màquina.

preview serveix la compilació real des de dist/, i allà apareixen la meitat dels problemes: rutes mal resoltes, imatges que no es van copiar, import dinàmics que en desenvolupament funcionaven per casualitat, i variables d'entorn que no es van injectar.

I una segona regla, del consell de 11-01 que tant de bo hagis seguit: el primer desplegament es fa amb l'aplicació buida, a la fita H1. Si ho vas fer, aquest apartat és un repàs. Si no, fes-ho ara abans de continuar: descobrir els problemes de configuració amb una pàgina en blanc costa una hora; descobrir-los amb tot el producte en joc costa un cap de setmana.

I el que produeix, comentat:

Aquí passen quatre coses i convé entendre cadascuna.

1 · Empaquetat. Els centenars de mòduls ES de src/ es combinen en uns pocs fitxers. En desenvolupament cada import era una petició; en producció són tres o quatre descàrregues. És el que fa possible complir el pressupost de «≤ 4 peticions» de 11-01.

2 · Divisió de codi (09-05). Les pantalles que no es veuen en arrencar surten en trossos a part, carregats quan calen:

3 · Minificació. S'eliminen espais, comentaris i noms llargs, i s'apliquen optimitzacions com el tree shaking: si importes una funció d'un mòdul i no fas servir les altres cinc, les altres cinc no s'inclouen. Això només funciona amb mòduls ES estàtics, que és una de les raons per les quals 05-04 hi insistia.

4 · Hashing del nom. index-C4f8a2b1.js conté un resum del contingut. Si el contingut canvia, el nom canvia. Aquesta és la peça que fa possible l'estratègia de memòria cau de l'apartat 7, i val la pena veure-la amb claredat:

És una solució elegant a un problema que semblava irresoluble, i explica per què index.html no porta hash: algú ha de ser el punt d'entrada estable que apunti als fitxers amb hash.

Configuració de Vite comentada:

base és la causa número u de desplegaments trencats. Si serveixes a https://usuari.github.io/orbita/, les rutes absolutes /assets/... apuntarien a l'arrel del domini, on no hi ha res. Amb base: '/orbita/', Vite genera /orbita/assets/.... A Netlify, Vercel o un domini propi, on l'aplicació és a l'arrel, base ha de ser '/'.

Sobre sourcemap: true, que té un matís que convé decidir conscientment: els mapes de codi permeten depurar en producció veient el teu codi original en lloc del minificat, i són imprescindibles perquè un servei de seguiment d'errors doni traces llegibles. La contrapartida és que exposen el teu codi font. Per a un projecte de portafoli amb repositori públic, no hi ha cap raó per amagar-lo. En un producte comercial, la pràctica habitual és generar-los i pujar-los al servei d'errors sense publicar-los al servidor.

Vite injecta al paquet les variables que comencin per VITE_:

I aquí ve el punt més important de tota la lliçó, que cal entendre sense ambigüitat:

import.meta.env.VITE_EL_QUE_SIGUI se substitueix literalment pel seu valor durant la compilació. Aquest valor acaba escrit en un fitxer .js que es descarrega al navegador de qualsevol. No és una variable: és una constant pública.

Comprova-ho tu mateix, i fes-ho ara:

Què pot anar al client i què no:

Per què la gent s'equivoca aquí, i amb quines conseqüències. El raonament erroni és: «està en una variable d'entorn, i les variables d'entorn són secretes». Ho són al servidor. En una compilació de client, la variable d'entorn només descriu on es va escriure el valor, no on acaba. I el valor acaba en un fitxer públic, minificat però perfectament llegible amb Ctrl+F.

Les conseqüències són reals i cares: claus de serveis al núvol filtrades en repositoris públics es detecten automàticament per robots en qüestió de minuts, i el resultat acostuma a ser una factura per ús aliè.

Què fer si el teu projecte necessita parlar amb un servei que exigeix clau secreta. Només hi ha una resposta correcta: un intermediari al servidor.

Netlify Functions, Vercel Functions i Cloudflare Workers permeten fer-ho amb vint línies i sense muntar un servidor complet. És l'apartat 10.

I la regla del repositori: .env a .gitignore, sempre, amb un .env.example versionat que documenti quines variables calen i amb valors d'exemple. Si algun cop confirmes un secret per error, canviar-lo és obligatori: esborrar-lo de l'historial no n'hi ha prou, perquè ja és en qualsevol clon que s'hagi fet mentrestant.

Una aplicació com la teva és un lloc estàtic: HTML, CSS, JavaScript i algunes imatges. No hi ha cap procés de servidor executant el teu codi. Això obre moltes opcions i totes són bones; les diferències són als detalls.

El que la taula no diu i convé saber:

GitHub Pages és l'opció més simple i té una limitació que afecta directament aquest projecte: no permet configurar capçaleres HTTP. Això significa que no hi pots posar una Content-Security-Policy real (només la versió en <meta>, que és més limitada), ni controlar el Cache-Control, ni configurar la reserva de SPA excepte amb el truc del 404.html. Per a un portafoli és perfectament vàlid; per practicar l'apartat 9 d'aquesta lliçó, no.

Netlify, Vercel i Cloudflare Pages fan essencialment el mateix des del punt de vista d'un lloc estàtic: connectes el repositori, cada push a main desplega, cada PR genera una URL de vista prèvia, i tens un fitxer de configuració per a capçaleres i redireccions. Triar-ne una per a aquest projecte és qüestió de preferència; les tres són excel·lents.

Un servidor propi amb Nginx és l'únic que t'obliga a entendre què està passant, i precisament per això és formatiu. També és l'únic on tu ets responsable de les actualitzacions de seguretat, les còpies de seguretat i el certificat.

Un avís sobre els plans gratuïts, perquè convé l'honestedat: són generosos i suficients per a un projecte personal, però tenen límits (minuts de compilació, amplada de banda, invocacions de funció) i canvien amb el temps. Llegeix els límits actuals abans de comprometre-t'hi, i tingues en compte que un projecte que creix pot acabar necessitant un pla de pagament.

Recomanació per a aquest mòdul: desplega a Netlify o Cloudflare Pages. Tens vistes prèvies per PR, capçaleres configurables i funcions de servidor si en necessites, sense cost i sense administrar res. I si vols l'exercici complet, munta a més una configuració de Nginx equivalent encara que sigui en local: entendre el fitxer de configuració ensenya més que qualsevol tauler de control.

HTTPS no és opcional, i no només per seguretat:

A més, les dades viatgen en clar: en una wifi pública, qualsevol pot llegir i modificar el que s'envia.

Com s'aconsegueix. A les plataformes de l'apartat anterior, automàticament i de franc: emeten i renoven el certificat per tu. En un servidor propi, amb Let's Encrypt i certbot:

El domini. Un domini propi costa entre deu i quinze euros a l'any i canvia completament la percepció del projecte. La configuració és un registre DNS:

I una decisió que cal prendre i no deixar a mitges: tria una forma canònica —amb www o sense www— i redirigeix l'altra amb un 301. Tenir les dues actives duplica el contingut per als cercadors, parteix la memòria cau i confon els usuaris. El mateix amb http → https, que ha de ser una redirecció permanent.

HSTS (Strict-Transport-Security) diu al navegador que mai no intenti connectar-se per HTTP al teu domini:

És una de les capçaleres més eficaces que existeixen. Amb un advertiment important: és difícil de revertir. Un cop un navegador l'ha vista, es nega a fer servir HTTP en aquell domini durant el max-age encara que tu treguis la capçalera. Comença amb un valor petit (max-age=300), comprova que tot funciona, i puja a un any.

Aquest és el problema que sorprèn tothom en el seu primer desplegament.

El teu encaminador (11-01) fa servir la History API: en navegar a la vista d'informe, la URL passa a https://orbita.example/informe. Funciona perfectament… fins que algú recarrega la pàgina o comparteix aquell enllaç.

La causa és simple: el servidor no sap res del teu encaminador. Busca un fitxer anomenat informe i no existeix.

La solució s'anomena reserva (fallback) a index.html: qualsevol ruta que no correspongui a un fitxer real retorna index.html, i llavors el teu JavaScript arrenca, llegeix la URL i pinta la pantalla corresponent.

Amb un advertiment important: la reserva ha de retornar codi 200, no 404, o els cercadors indexaran les teves rutes com a errors.

A Netlify (public/_redirects):

A Vercel (vercel.json):

A Cloudflare Pages (public/_redirects): idèntic a Netlify.

A Nginx:

try_files prova en ordre: el fitxer exacte, el directori, i si no n'existeix cap, index.html. És exactament la lògica que necessites.

A GitHub Pages no hi ha configuració de servidor, així que es fa servir un truc: crear un 404.html idèntic a l'index.html. GitHub el serveix per a rutes inexistents i l'aplicació arrenca. Funciona, però retorna codi 404, cosa que és dolenta per al SEO. És una de les raons per preferir una altra plataforma si t'importa la indexació.

I el detall que trenca la reserva: si apliques la regla a tot, /api/tasques també retornarà index.html, i el teu codi rebrà HTML on esperava JSON — amb un error d'anàlisi desconcertant. Exclou les rutes d'API abans de la regla general:

La memòria cau és on més s'equivoca la gent, i produeix dues errades oposades i igual de dolentes:

La solució correcta aprofita el hashing de l'apartat 2, i es resumeix en una regla de dues línies:

Els fitxers amb hash al nom: memòria cau d'un any, immutable. L'index.html, el service worker i el manifest: mai a la memòria cau.

La lògica és impecable: si el contingut canvia, el nom canvia, per tant un fitxer amb hash mai no necessita revalidar-se. I index.html, que és qui apunta als noms nous, s'ha de demanar sempre.

La taula completa:

no-cache no significa «no desar». Significa «desa, però revalida amb el servidor abans de fer servir». Amb ETag, la revalidació acostuma a retornar un 304 sense cos: cost mínim i sempre actualitzat. El que no desa res és no-store.

A Netlify o Cloudflare Pages (public/_headers):

A Nginx:

El cas especial del service worker mereix èmfasi perquè produeix l'errada més desconcertant de totes. Si sw.js se serveix amb memòria cau llarga, el navegador no descarrega el nou, així que el service worker antic continua servint la versió antiga de la teva aplicació indefinidament. L'usuari recarrega, esborra l'historial, i continua veient el mateix. Els navegadors moderns limiten la memòria cau de sw.js a 24 hores per defecte, però no hi confiïs: posa-hi no-cache explícit.

Com comprovar que està ben configurat:

Comprimir és l'optimització amb millor relació entre esforç i resultat que existeix: una línia de configuració i entre un 60 % i un 80 % menys de bytes en text.

Les plataformes gestionades ho fan soles i no has de configurar res. A Nginx:

Dos matisos importants:

• No comprimeixis el que ja està comprimit. PNG, JPEG, WebP, MP4 i WOFF2 ja ho estan. Tornar-los a comprimir gasta CPU i de vegades augmenta la mida.
• El teu pressupost de 11-01 està en bytes comprimits. Els 60 kB del pressupost es mesuren a la columna «Transferred» del panell Network, no a «Size». Confondre-les fa que et pensis que l'incompleixes quan el compleixes, o a l'inrevés.

Aquestes capçaleres són gratis, es configuren una vegada i tanquen classes senceres d'atacs. Van explicades d'una en una perquè copiar-les sense entendre-les produeix llocs trencats que ningú no sap arreglar.

És la més potent i la més delicada. Declara d'on pot carregar recursos la teva pàgina; tota la resta la bloqueja el navegador.

Directiva a directiva:

Per què la CSP és tan eficaç: és la segona línia de defensa contra XSS. A 11-03 vas aprendre la primera —textContent en lloc de innerHTML—, i la CSP és el paracaigudes de reserva: encara que un atacant aconsegueixi injectar <script>alert(1)</script> a la teva pàgina, script-src 'self' impedeix que s'executi, perquè no ve del teu origen.

Els dos esculls pràctics:

1. Els estils en línia. Si el teu codi fa element.style.color = 'red', la CSP amb style-src 'self' ho bloqueja. La solució correcta és fer servir classes CSS en lloc d'estils en línia — que és millor pràctica de tota manera. La solució mandrosa és 'unsafe-inline', que desactiva bona part de la protecció. Evita-la.
2. Els scripts en línia. Si tens <script> amb codi dins de l'HTML, es bloqueja. Vite no en genera cap per defecte, així que normalment no és problema.

Com implantar-la sense trencar res: comença en mode informe, que no bloqueja res i t'avisa del que bloquejaria:

Navega per tota la teva aplicació, mira els avisos de la consola, ajusta la política, i només llavors treu el -Report-Only.

A Netlify o Cloudflare Pages (public/_headers):

Com verificar-ho. Hi ha serveis públics que analitzen les teves capçaleres i et donen una puntuació amb explicacions. També n'hi ha prou amb:

Aconseguir una bona puntuació de capçaleres de seguretat és un detall petit amb molt de pes en una revisió tècnica: demostra que has pensat en el desplegament, no només en el codi.

El teu projecte pot funcionar perfectament sense servidor: les dades a localStorage, tot al navegador. És una decisió legítima si està documentada amb les seves limitacions (un sol dispositiu, sense privacitat real, sense compartir).

Si necessites més, hi ha tres camins:

Backend com a servei. Serveis com Supabase, Firebase o PocketBase et donen base de dades, API automàtica, autenticació i de vegades temps real, amb configuració en lloc de codi. Per a un projecte de portafoli que necessita usuaris i dades compartides, és l'opció amb millor relació entre esforç i resultat.

El que cal saber abans de triar-ne un:

• Depens del proveïdor. Migrar després té cost. Mitiga-ho mantenint la teva frontera del repositori (11-02): si el BaaS viu darrere de RepositoriSupabase, canviar-lo és reescriure un fitxer.
• Les regles de seguretat són responsabilitat teva. Aquests serveis exposen la base de dades directament al client, protegida per regles que tu configures. Una regla mal escrita exposa totes les dades de tots els usuaris. És l'errada més freqüent i més greu d'aquestes plataformes.
• Els plans gratuïts tenen límits i el servei pot canviar de preus o desaparèixer.

Funcions sense servidor. Quan només necessites amagar una clau o fer una operació puntual al servidor:

Fixa't que la variable no porta prefix VITE_: això és exactament el que la manté fora del paquet del client.

Backend propi. És el camí natural si vols créixer, i és el tema de la lliçó 11-07: Node.js amb Express o Fastify, una base de dades, autenticació amb tokens, i tota la lògica de servidor que la teva aplicació necessiti. Requereix aprendre coses noves i val la pena, però no és requisit d'aquest projecte.

Aquest apartat és curt, no té matisos, i és dels que més importen.

Tens quinze regles de negoci, R1 a R15, implementades i provades a domini/. Funcionen perfectament… al navegador. I el navegador és un entorn que l'usuari controla completament:

• Pot obrir DevTools i cridar les teves funcions amb el que vulgui.
• Pot modificar el teu codi abans que s'executi.
• Pot saltar-se la teva aplicació sencera i cridar l'API amb curl.

Si el servidor accepta això, les teves quinze regles no valen res.

La validació del client és una comoditat per a l'usuari. La validació del servidor és la que protegeix les dades. No són alternatives: són dues capes amb propòsits diferents, i totes dues són obligatòries així que hi ha servidor.

La bona notícia és que la teva arquitectura ja hi està preparada. domini/ és JavaScript pur sense dependències del navegador — aquella va ser la primera frontera de 11-01. Si escrius el backend en Node.js, pots importar exactament els mateixos fitxers i executar les mateixes regles al servidor:

Una sola implementació de les regles, executada als dos costats. Això és el que valia la pena de mantenir el domini lliure de dependències durant tot el projecte, i és un argument excel·lent per explicar en una entrevista (11-06).

I el que el servidor ha de validar a més de les teves regles, perquè són coses que el client no pot fer:

Desplegament continu significa que el que es fusiona a main arriba a producció automàticament, sense passos manuals. Amb la CI de 11-04 protegint la branca, això és segur: res no arriba a main sense lint, proves, cobertura, pressupost i recorreguts en verd.

Les decisions del fitxer:

La comprovació de fum és una idea que convé interioritzar: una verificació mínima i ràpida que el que s'ha desplegat respon i conté el que ha de contenir. Costa cinc línies i detecta el «s'ha desplegat una carpeta buida», que passa més del que sembla.

Els secrets del repositori (Settings → Secrets and variables): NETLIFY_AUTH_TOKEN i NETLIFY_SITE_ID van com a secrets (xifrats, no visibles ni als registres); API_URL va com a variable (no és secreta i així es pot llegir). No escriguis mai un token directament al YAML: el fitxer és al repositori.

Un entorn de vista prèvia és un desplegament temporal d'una branca, amb la seva pròpia URL. Netlify, Vercel i Cloudflare Pages ho fan automàticament en obrir una Pull Request.

Per què val la pena, encara que treballis sol:

Tres precaucions importants:

1. noindex a les vistes prèvies. Si Google indexa deploy-preview-42--orbita.netlify.app, tindràs contingut duplicat competint amb el teu lloc. Les plataformes acostumen a posar-l'hi, però comprova-ho.
2. No apuntis mai una vista prèvia a dades de producció. Una prova destructiva en una vista prèvia que escriu a la base real és un desastre evitable. Fes servir un entorn de dades separat.
3. Les vistes prèvies són públiques. Qualsevol amb la URL hi entra. No hi provis amb dades reals de ningú.

Tot desplegament pot sortir malament. La pregunta no és si passarà, sinó quant trigaràs a arreglar-ho quan passi — probablement a una hora incòmoda i amb pressa.

Les opcions, de millor a pitjor:

La primera és la bona, i cal provar-la abans de necessitar-la. Les plataformes gestionades desen tots els desplegaments anteriors i permeten tornar a qualsevol amb un clic, perquè cada desplegament és un conjunt immutable de fitxers estàtics.

El procediment escrit, que ha de ser al teu README o a docs/operacions.md:

El punt 1 és contraintuïtiu i és el correcte. La temptació és investigar mentre el lloc està trencat. Però cada minut d'investigació és un minut de servei caigut, i la pressa fa que es prenguin pitjors decisions. Revertir és reversible; arreglar amb pressa, no.

El punt 7 és el que converteix un incident en aprenentatge. I la pregunta clau del post mortem no és «qui s'ha equivocat» sinó «per què la CI no ho ha detectat», perquè la resposta és sempre una comprovació nova que evita tota una família d'errades futures.

Una precaució sobre la base de dades: si el teu desplegament incloïa una migració de dades (com les de 11-03), revertir el codi no reverteix les dades. Per això les migracions han de ser compatibles cap enrere sempre que es pugui: afegir camps, no reanomenar-los ni esborrar-los al mateix desplegament que els deixa de fer servir. La seqüència segura és en dos desplegaments: primer afegir i escriure als dos llocs, després deixar de fer servir el vell.

En desenvolupament, un error apareix a la teva consola. En producció, apareix a la consola d'un usuari que no la mirarà i no t'ho explicarà: simplement deixarà de fer servir la teva aplicació.

A 11-02 vas muntar un registre local amb les dues xarxes de seguretat globals (error i unhandledrejection). Ara cal enviar-lo a algun lloc.

Les opcions:

Serveis de seguiment d'errors. Sentry, Bugsnag, Rollbar i similars tenen plans gratuïts suficients per a un projecte personal, s'integren amb tres línies i agrupen errors idèntics —cosa que importa molt: una errada que passa 400 vegades és una entrada, no 400 correus.

I aquí ve la part que cal fer bé:

Un servei de seguiment d'errors envia dades dels teus usuaris a un tercer. Això és una decisió de privacitat, no només tècnica.

El que cal configurar abans d'activar-lo:

Dos detalls del codi: location.pathname en lloc de location.href evita enviar paràmetres de consulta que poden contenir cerques o identificadors; i sendBeacon envia sense bloquejar i funciona encara que la pàgina s'estigui tancant, que és justament quan passen molts errors.

Advertiment. No enviïs dades personals a un servei extern sense haver-ho previst al teu avís de privacitat i sense saber on s'emmagatzemen. En un projecte d'aprenentatge amb dades fictícies el risc és nul; en un producte real, activar un servei de seguiment sense més és un problema de compliment normatiu, no un detall tècnic.

A 09-01 vas aprendre la distinció que més confusió evita: laboratori (el teu Lighthouse, la teva màquina, la teva xarxa) davant de camp (usuaris reals, dispositius reals, xarxes reals). Els números de camp són sempre pitjors, i són els que importen.

Com llegir els resultats, que és on hi ha el valor:

Aquest últim punt és el que justifica tot l'esforç: enviar la versió amb cada mètrica permet atribuir una regressió a un desplegament concret. Sense això, només saps que va empitjorar en algun moment.

I una nota de privacitat: les mètriques de rendiment no són dades personals si no inclouen identificadors. No hi afegeixis un identificador d'usuari «per poder correlacionar»; el percentil 75 no el necessita.

Aquest és el problema més específic del desplegament d'una PWA, i produeix una situació exasperant: l'usuari té l'aplicació instal·lada, tu desplegues una correcció, i ell continua veient la versió antiga. Recarrega, i res.

La causa és al cicle de vida del service worker (07-05):

L'estat «En espera» és el problema. Per defecte, un service worker nou espera que totes les pestanyes de l'aplicació es tanquin. I com que molta gent no tanca mai del tot una PWA instal·lada, aquesta espera pot durar dies.

La solució completa, en tres peces.

Peça 1 · El service worker permet saltar-se l'espera sota demanda:

Peça 2 · L'aplicació detecta que hi ha una versió nova i ho diu:

Peça 3 · L'avís, que ha de ser discret i accessible:

Les quatre regles de l'actualització d'una PWA:

1. No recarreguis mai sense avisar. L'usuari pot estar escrivint. Una recàrrega sorpresa que perd un formulari és imperdonable.
2. La bandera recarregant és imprescindible. Sense ella, controllerchange pot provocar un bucle de recàrregues: és una errada real i molt desagradable.
3. sw.js amb Cache-Control: no-cache (apartat 7). Sense això, res d'això no funciona perquè el navegador ni tan sols descarrega el service worker nou.
4. Neteja les memòries cau velles a activate. Si no, s'acumulen versions i acabes ocupant centenars de megabytes al dispositiu d'una altra persona.

El pla d'emergència, que convé tenir escrit: si desplegues un service worker trencat que trenca l'aplicació per a tothom que la té instal·lada, la sortida és publicar un sw.js mínim que es desregistri a si mateix i netegi totes les memòries cau:

Desa'l. El dia que el necessitis, ho agrairàs.

El lliurable final de la fita. Es recorre sencera, es marca, i es desa signada i datada a docs/llancament.md.

Advertiment legal. Els punts 27 i 28 no són formalitats. A la Unió Europea, informar sobre el tractament de dades personals és una obligació, i l'ús de cookies o emmagatzematge no estrictament necessari requereix consentiment previ, informat i revocable — un bàner que només diu «acceptar» no ho compleix. Si el teu projecte és un exercici amb dades fictícies i sense analítica, el risc pràctic és nul, però acostuma't a incloure l'avís. Si algun dia publiques un producte amb usuaris reals, això requereix assessorament legal específic: ni aquesta lliçó ni cap documentació tècnica no ho substitueixen.

Un avís de privacitat honest per a un projecte com aquest és curt i s'escriu en deu minuts:

Posar un secret en una variable VITE_. Acaba escrit en un fitxer públic que qualsevol llegeix amb Ctrl+F, i els robots que rastregen repositoris el troben en minuts. Qualsevol cosa que doni accés a alguna cosa va darrere d'una funció de servidor. Comprova dist/ amb grep abans de cada desplegament, i automatitza-ho al flux.

No configurar la reserva de SPA. Tot funciona navegant des de la portada i dona 404 en recarregar o en obrir un enllaç compartit — que és exactament com arribarà la gent a qui ensenyis el projecte.

Memòria cau llarga a index.html. Els usuaris es queden amb la versió antiga durant dies i no hi ha manera de forçar-los a actualitzar. Els fitxers amb hash porten memòria cau d'un any; el punt d'entrada, no-cache.

Memòria cau a sw.js. Produeix l'errada més desconcertant que existeix: l'usuari recarrega, esborra l'historial, reinstal·la, i continua veient l'aplicació de fa tres desplegaments.

base mal configurat. A GitHub Pages amb subdirectori, sense base: '/repo/' la pàgina carrega en blanc i la consola s'omple de 404 sobre /assets/…. És l'errada número u del primer desplegament.

Afegir 'unsafe-inline' a la CSP perquè deixi de queixar-se. Desactiva bona part de la protecció contra XSS, que és justament el que la CSP existia per donar. Arregla l'estil o l'script en línia; gairebé sempre són dues línies.

Confiar només en la validació del client. Qualsevol pot cridar la teva API amb curl. Amb servidor, les regles hi van també — i el teu domini sense dependències fa que sigui el mateix codi.

Desplegar sense haver provat la reversió. El dia que la necessitis, amb el lloc caigut i pressa, no és el moment de descobrir com funciona. Prova-la avui, en fred.

Recarregar la PWA sense avisar quan hi ha versió nova. L'usuari pot estar escrivint. Avís discret, botó, i recàrrega només quan ho demani — amb la bandera que evita el bucle de recàrregues.

Enviar dades personals a un servei de seguiment d'errors. És un problema de compliment, no d'estil. Filtra abans d'enviar, envia pathname i no href, i declara el servei al teu avís de privacitat.

Consell · Desplega des del primer dia i sovint. Un desplegament per setmana durant dos mesos és avorrit i segur. Un desplegament enorme l'últim dia és la recepta d'un desastre.

Consell · Tingues un plafó de diagnòstic en producció. Una ruta discreta que mostri versió, commit, data de compilació, estat del service worker, espai ocupat i últims errors. Quan algú et digui «no em funciona», aquesta pantalla respon en deu segons.

Consell · Desa una captura de la línia base de producció. Lighthouse sobre la URL real, amb data. D'aquí a sis mesos sabràs si has millorat o empitjorat, i en tindràs la prova.

Consell · Prova el teu lloc desplegat en un mòbil de debò. No a l'emulador. Amb dades mòbils, no wifi. Descobriràs coses que cap estrangulament simulat no t'ensenya.

Aquests exercicis són la fita H6, primera part: l'aplicació desplegada amb HTTPS, el seu flux de desplegament continu i la llista de comprovació signada.

Exercici 1 — La compilació i el desplegament.

1. Configura vite.config.js amb base correcte per a la teva plataforma, sourcemap, manualChunks i chunkSizeWarningLimit amb el teu pressupost.
2. Crea .env.example versionat i .env.production ignorat, i documenta al README quines variables calen.
3. Compila i audita dist/: mida total, nombre de fitxers, i grep de secrets. Documenta els resultats.
4. Prova amb npm run preview tota l'aplicació abans de desplegar. Anota els problemes que apareguin només en producció (n'hi haurà almenys un).
5. Desplega a la plataforma que triïs, amb domini propi o subdomini de la plataforma, i HTTPS actiu.
6. Configura la reserva de SPA i comprova amb curl -I que retorna 200 en una ruta interna.
7. Configura la memòria cau completa segons la taula de l'apartat 7 i verifica-la amb curl -I sobre un fitxer amb hash, sobre index.html i sobre sw.js.
8. Configura les cinc capçaleres de seguretat, amb la CSP primer en mode informe i després activa, sense unsafe-inline.
9. Documenta cada decisió a docs/desplegament.md: quina plataforma, per què, i què implica.

Exercici 2 — Desplegament continu, vistes prèvies i reversió.

1. Escriu .github/workflows/desplegar.yml amb: verificació prèvia, compilació amb la versió del commit, comprovació automàtica de secrets, desplegament i comprovació de fum.
2. Configura els secrets i variables del repositori correctament (secrets xifrats, variables normals).
3. Activa les vistes prèvies per PR i comprova les tres precaucions: noindex, dades separades, i consciència que són públiques.
4. Prova la reversió de debò: desplega un canvi visible, reverteix a l'anterior, comprova que el lloc torna, i torna a publicar el nou. Cronometra quant trigues.
5. Escriu docs/operacions.md amb el procediment de reversió de set passos adaptat a la teva plataforma.
6. Configura el monitoratge d'errors amb filtratge de dades personals, i demostra que un error provocat a propòsit arriba amb la traça i sense dades d'usuari.
7. Instrumenta web-vitals enviant la versió, i recull almenys una sessió de dades de camp.
8. Implementa l'actualització de la PWA amb les tres peces de l'apartat 17, i demostra-ho: instal·la l'aplicació, desplega un canvi, i comprova que apareix l'avís, que el botó actualitza i que no hi ha bucle de recàrregues.

Exercici 3 — El llançament.

1. Recorre les 33 comprovacions de l'apartat 18 sobre el teu lloc desplegat. Marca cadascuna amb evidència (ordre executada, captura o URL), no de memòria.
2. Completa el bloc de contingut: <title>, descripció, Open Graph amb imatge de 1200×630, favicons en cinc mides, robots.txt, sitemap.xml, pàgina 404 pròpia i manifest.json complet.
3. Escriu l'avís de privacitat amb la plantilla de l'apartat 18.3, adaptat al que la teva aplicació fa realment.
4. Afegeix la llicència al repositori.
5. Executa Lighthouse sobre la URL de producció (no en local) i compara amb el teu pressupost de 11-01 i amb la teva línia base de 11-04. Documenta les diferències i explica-les.
6. Passa el lloc per un analitzador de capçaleres de seguretat i documenta la puntuació.
7. Obre'l en un mòbil real amb dades mòbils i anota tot el que no funcioni com esperaves.
8. Signa i data docs/llancament.md.

Criteris d'acceptació de l'exercici 1 — Desplegament

Rúbrica de l'exercici 1 (21 punts)

Llindar: 15/21, amb obligatòriament 3 a «Secrets». Un secret filtrat invalida l'exercici: és l'única errada d'aquesta lliçó amb conseqüències reals fora del projecte.

Criteris d'acceptació de l'exercici 2 — Continu i operacions

Criteris d'acceptació de l'exercici 3 — Llançament

Rúbrica global de la fita H6 primera part (24 punts)

Llindar: 17/24. Amb una condició que no es compensa: zero secrets al paquet. Tota la resta es pot millorar a la iteració següent; una clau filtrada, no.

Autoavaluació de la fita H6:

El teu projecte ja no viu al teu portàtil: és a internet, amb HTTPS, i qualsevol el pot fer servir.

Saps què canvia quan el codi surt de la teva màquina —nou diferències, cadascuna font de sorpreses— i tens la regla que n'evita la meitat: no despleguis mai res que no hagis provat amb build i preview. Coneixes la compilació de producció per dins: empaquetat que redueix peticions, divisió de codi que retarda el que no es veu, minificació que només funciona bé gràcies als mòduls ES estàtics de 05-04, i el hashing del nom, que és la peça elegant que permet tenir alhora memòria cau d'un any i actualització immediata — i que explica per què index.html és l'únic que no en porta. Amb base ben configurat, que és la causa número u de primers desplegaments en blanc.

Tens claríssim el més important de la lliçó: no hi ha secrets al client. import.meta.env.VITE_* no és una variable: és una constant pública escrita literalment en un fitxer que es descarrega. Saps què hi pot anar i què no, saps que el raonament erroni («està en una variable d'entorn») confon on es va escriure el valor amb on acaba, i saps que l'única resposta correcta quan cal una clau és un intermediari al servidor. Amb la verificació per grep automatitzada al flux, perquè les bones intencions s'obliden i els robots que rastregen repositoris no.

Saps on allotjar amb una taula honesta que inclou el que les comparatives no diuen: que GitHub Pages no permet capçaleres reals, que Netlify, Vercel i Cloudflare Pages són equivalents per a un lloc estàtic, que un servidor propi és l'únic que t'obliga a entendre què passa, i que els plans gratuïts tenen límits que canvien. I saps per què HTTPS no és opcional: sense ell no hi ha service worker, ni PWA, ni contextos segurs, ni confiança.

Saps resoldre el problema que sorprèn tothom —les rutes d'una SPA—, amb reserva a index.html que retorna 200 i no 404, a les quatre plataformes, i amb l'exclusió de les rutes d'API que evita rebre HTML on esperaves JSON.

Tens la memòria cau ben feta, que és on més s'equivoca la gent: un any i immutable per al que porta hash, no-cache per al punt d'entrada, el service worker i el manifest. Saps que no-cache significa «revalida», no «no desis». I saps que un sw.js cachejat produeix l'errada més desconcertant que existeix: usuaris atrapats en una versió de fa tres desplegaments per molt que recarreguin.

Saps configurar les capçaleres de seguretat una a una, entenent-les: la CSP com a segona línia de defensa contra XSS —amb connect-src impedint l'exfiltració, frame-ancestors evitant el clickjacking, i l'advertiment que 'unsafe-inline' desactiva justament el que la política venia a donar—, implantada primer en mode informe; nosniff, Referrer-Policy, Permissions-Policy i HSTS amb el seu max-age progressiu perquè és difícil de revertir.

Saps què fer amb el backend: que no tenir-ne és legítim si està documentat amb les seves limitacions; que un backend com a servei resol el multiusuari sense escriure servidor, amb l'advertiment que les regles de seguretat són teves i una de mal escrita exposa totes les dades; que una funció sense servidor de vint línies n'hi ha prou per amagar una clau; i que escriure el teu és el camí de 11-07. I saps, sense matisos, que la validació del client mai no substitueix la del servidor — amb la recompensa que el teu domini sense dependències del navegador es pot importar tal qual a Node i executar les mateixes R1–R15 als dos costats, que és exactament per això que valia la pena la primera frontera de 11-01.

Tens desplegament continu amb verificació prèvia, versió del commit injectada —cosa que fa possible atribuir una regressió a un desplegament—, comprovació automàtica de secrets i prova de fum, perquè que un desplegament acabi no significa que el lloc funcioni. Amb vistes prèvies per branca i les seves tres precaucions, i amb una estratègia de reversió la regla de la qual és contraintuïtiva i correcta: revertir primer, investigar després, perquè revertir és reversible i arreglar amb pressa no ho és. Amb el post mortem la pregunta clau del qual no és qui s'ha equivocat sinó per què la CI no ho ha detectat.

Saps monitorar en producció sense convertir-te en un problema de privacitat: filtrar abans d'enviar, pathname en lloc de href, sendBeacon perquè funciona mentre la pàgina es tanca, i la consciència que un servei de seguiment és un tercer que rep dades dels teus usuaris. I saps recollir mètriques de camp amb web-vitals, amb la distinció de 09-01 entre laboratori i camp, i amb la versió adjunta per poder atribuir.

Saps actualitzar una PWA instal·lada, que és el problema més específic del desplegament d'una aplicació web moderna: l'estat «en espera» que pot durar dies, les tres peces que el resolen, les quatre regles —avisar sempre, la bandera contra el bucle de recàrregues, no-cache a sw.js, netejar memòries cau velles— i el service worker d'emergència que convé tenir desat abans de necessitar-lo.

I tens la llista de comprovació de llançament amb els seus 33 punts en tres blocs: tècnic, contingut i descobribilitat, i legal i operatiu — inclosos l'avís de privacitat honest i específic, l'advertiment que el consentiment de cookies té requisits legals que un botó d'«acceptar» no compleix, i la llicència.

El producte està publicat. I aquí apareix el que separa un projecte acabat d'un projecte que a més serveix per a alguna cosa: ningú no sap que existeix, ningú no sap quines decisions hi ha al darrere, i tu encara no has practicat com explicar-ho. Una feina que no es pot ensenyar ni defensar val, a la pràctica, molt menys del que és. Convertir-la en alguna cosa que algú entengui en dos minuts, que puguis demostrar en cinc, i que sàpigues explicar en una entrevista tècnica sense sonar ni insegur ni fanfarró, és Presentació i Revisió del Projecte.