Tu proyecto funciona, está probado, se mide y una máquina lo vigila en cada push. Y sin embargo sigue viviendo en tu portátil, donde no le sirve a nadie. Desplegar es lo que convierte un repositorio en un producto, y es también el momento en el que aparecen los problemas que ningún entorno de desarrollo enseña: las rutas que funcionaban en localhost y dan 404 en el servidor, la caché que sirve la versión antigua durante una semana, el service worker que se queda pegado con código de hace tres despliegues, la clave de API que creías protegida y que cualquiera puede leer con dos clics, y las cabeceras de seguridad que nadie configura porque nadie se las ha explicado. En esta lección aprenderás a preparar la compilación de producción entendiendo qué hace cada parte y por qué ninguna clave secreta puede vivir en el cliente; a elegir dónde alojar con una tabla comparativa honesta; a configurar el servidor de verdad —rutas de SPA, caché coherente con el hashing y con el service worker, compresión y cabeceras de seguridad explicadas una a una—; a decidir qué hacer con el backend sin escribirlo, con la advertencia de que la validación del cliente nunca sustituye a la del servidor; a montar el despliegue continuo con vistas previas por rama y una estrategia de reversión que funcione a las tres de la madrugada; a monitorizar en producción sin convertirte en un problema de privacidad; y a actualizar una PWA ya instalada sin dejar a nadie con una versión antigua. Terminarás con la aplicación desplegada con HTTPS, su flujo de despliegue continuo y una lista de comprobación de lanzamiento firmada.

1. Qué cambia cuando el código sale de tu máquina
2. La compilación de producción
3. Variables de entorno y por qué no hay secretos en el cliente
4. Dónde alojar: tabla comparativa honesta
5. Dominio, HTTPS y certificados
6. Las rutas de una SPA y el fallback a index.html
7. Caché: la parte que más se hace mal
8. Compresión
9. Cabeceras de seguridad, una a una
10. El backend: qué opciones hay sin escribir un servidor
11. La validación del cliente nunca sustituye a la del servidor
12. Despliegue continuo con GitHub Actions
13. Entornos de vista previa por rama
14. Estrategia de reversión
15. Monitorización de errores en producción
16. Métricas de campo con web-vitals
17. Actualizar una PWA ya instalada
18. La lista de comprobación de lanzamiento
19. Errores Comunes y Consejos
20. Ejercicios
21. Conclusión

En desarrollo, Vite hace muchísimas cosas por ti que en producción no existen. Conviene ver la lista completa antes de nada, porque cada fila es una fuente de sorpresas:

La consecuencia práctica es una regla de oro que ahorra muchísimo tiempo:

Nunca despliegues algo que no hayas probado con npm run build y npm run preview en tu máquina.

preview sirve la compilación real desde dist/, y ahí aparecen la mitad de los problemas: rutas mal resueltas, imágenes que no se copiaron, import dinámicos que en desarrollo funcionaban por casualidad, y variables de entorno que no se inyectaron.

Y una segunda regla, del consejo de 11-01 que ojalá hayas seguido: el primer despliegue se hace con la aplicación vacía, en el hito H1. Si lo hiciste, este apartado es un repaso. Si no, hazlo ahora antes de seguir: descubrir los problemas de configuración con una página en blanco cuesta una hora; descubrirlos con todo el producto en juego cuesta un fin de semana.

Y lo que produce, comentado:

Cuatro cosas ocurren aquí y conviene entender cada una.

1 · Empaquetado. Los cientos de módulos ES de src/ se combinan en unos pocos ficheros. En desarrollo cada import era una petición; en producción son tres o cuatro descargas. Es lo que hace posible cumplir el presupuesto de «≤ 4 peticiones» de 11-01.

2 · División de código (09-05). Las pantallas que no se ven al arrancar salen en trozos aparte, cargados cuando hacen falta:

3 · Minificación. Se eliminan espacios, comentarios y nombres largos, y se aplican optimizaciones como el tree shaking: si importas una función de un módulo y no usas las otras cinco, las otras cinco no se incluyen. Esto solo funciona con módulos ES estáticos, que es una de las razones por las que 05-04 insistía en ellos.

4 · Hashing del nombre. index-C4f8a2b1.js contiene un resumen del contenido. Si el contenido cambia, el nombre cambia. Esta es la pieza que hace posible la estrategia de caché del apartado 7, y merece verla con claridad:

Es una solución elegante a un problema que parecía irresoluble, y explica por qué index.html no lleva hash: alguien tiene que ser el punto de entrada estable que apunte a los ficheros con hash.

Configuración de Vite comentada:

base es la causa número uno de despliegues rotos. Si sirves en https://usuario.github.io/orbita/, las rutas absolutas /assets/... apuntarían a la raíz del dominio, donde no hay nada. Con base: '/orbita/', Vite genera /orbita/assets/.... En Netlify, Vercel o un dominio propio, donde la aplicación está en la raíz, base debe ser '/'.

Sobre sourcemap: true, que tiene un matiz que conviene decidir conscientemente: los mapas de código permiten depurar en producción viendo tu código original en lugar del minificado, y son imprescindibles para que un servicio de seguimiento de errores dé trazas legibles. La contrapartida es que exponen tu código fuente. Para un proyecto de portafolio con repositorio público, no hay ninguna razón para ocultarlo. En un producto comercial, la práctica habitual es generarlos y subirlos al servicio de errores sin publicarlos en el servidor.

Vite inyecta en el paquete las variables que empiecen por VITE_:

Y aquí viene el punto más importante de toda la lección, que hay que entender sin ambigüedad:

import.meta.env.VITE_LO_QUE_SEA se sustituye literalmente por su valor durante la compilación. Ese valor acaba escrito en un fichero .js que se descarga en el navegador de cualquiera. No es una variable: es una constante pública.

Compruébalo tú mismo, y hazlo ahora:

Qué puede ir en el cliente y qué no:

Por qué la gente se equivoca aquí, y con qué consecuencias. El razonamiento erróneo es: «está en una variable de entorno, y las variables de entorno son secretas». Lo son en el servidor. En una compilación de cliente, la variable de entorno solo describe dónde se escribió el valor, no dónde acaba. Y el valor acaba en un fichero público, minificado pero perfectamente legible con Ctrl+F.

Las consecuencias son reales y caras: claves de servicios en la nube filtradas en repositorios públicos se detectan automáticamente por robots en cuestión de minutos, y el resultado suele ser una factura por uso ajeno.

Qué hacer si tu proyecto necesita hablar con un servicio que exige clave secreta. Solo hay una respuesta correcta: un intermediario en el servidor.

Netlify Functions, Vercel Functions y Cloudflare Workers permiten hacerlo con veinte líneas y sin montar un servidor completo. Es el apartado 10.

Y la regla del repositorio: .env en .gitignore, siempre, con un .env.example versionado que documente qué variables hacen falta y con valores de ejemplo. Si alguna vez confirmas un secreto por error, cambiarlo es obligatorio: borrarlo del historial no basta, porque ya está en cualquier clon que se hiciera mientras tanto.

Una aplicación como la tuya es un sitio estático: HTML, CSS, JavaScript y algunas imágenes. No hay proceso de servidor ejecutando tu código. Eso abre muchas opciones y todas son buenas; las diferencias están en los detalles.

Lo que la tabla no dice y conviene saber:

GitHub Pages es la opción más simple y tiene una limitación que afecta directamente a este proyecto: no permite configurar cabeceras HTTP. Eso significa que no puedes poner una Content-Security-Policy real (solo la versión en <meta>, que es más limitada), ni controlar el Cache-Control, ni configurar el fallback de SPA salvo con el truco del 404.html. Para un portafolio es perfectamente válido; para practicar el apartado 9 de esta lección, no.

Netlify, Vercel y Cloudflare Pages hacen esencialmente lo mismo desde el punto de vista de un sitio estático: conectas el repositorio, cada push a main despliega, cada PR genera una URL de vista previa, y tienes un fichero de configuración para cabeceras y redirecciones. Elegir entre ellas para este proyecto es cuestión de preferencia; las tres son excelentes.

Un servidor propio con Nginx es el único que te obliga a entender qué está pasando, y precisamente por eso es formativo. También es el único donde tú eres responsable de las actualizaciones de seguridad, las copias de seguridad y el certificado.

Un aviso sobre los planes gratuitos, porque conviene la honestidad: son generosos y suficientes para un proyecto personal, pero tienen límites (minutos de compilación, ancho de banda, invocaciones de función) y cambian con el tiempo. Lee los límites actuales antes de comprometerte, y ten en cuenta que un proyecto que crece puede acabar necesitando un plan de pago.

Recomendación para este módulo: despliega en Netlify o Cloudflare Pages. Tienes vistas previas por PR, cabeceras configurables y funciones de servidor si las necesitas, sin coste y sin administrar nada. Y si quieres el ejercicio completo, monta además una configuración de Nginx equivalente aunque sea en local: entender el fichero de configuración enseña más que cualquier panel de control.

HTTPS no es opcional, y no solo por seguridad:

Además, los datos viajan en claro: en una wifi pública, cualquiera puede leer y modificar lo que se envía.

Cómo se consigue. En las plataformas del apartado anterior, automáticamente y gratis: emiten y renuevan el certificado por ti. En un servidor propio, con Let's Encrypt y certbot:

El dominio. Un dominio propio cuesta entre diez y quince euros al año y cambia por completo la percepción del proyecto. La configuración es un registro DNS:

Y una decisión que hay que tomar y no dejar a medias: elige una forma canónica —con www o sin www— y redirige la otra con un 301. Tener las dos activas duplica el contenido para los buscadores, parte la caché y confunde a los usuarios. Lo mismo con http → https, que debe ser una redirección permanente.

HSTS (Strict-Transport-Security) le dice al navegador que nunca intente conectarse por HTTP a tu dominio:

Es una de las cabeceras más eficaces que existen. Con una advertencia importante: es difícil de revertir. Una vez que un navegador la ha visto, se niega a usar HTTP en ese dominio durante el max-age aunque tú quites la cabecera. Empieza con un valor pequeño (max-age=300), comprueba que todo funciona, y sube a un año.

Este es el problema que sorprende a todo el mundo en su primer despliegue.

Tu enrutador (11-01) usa la History API: al navegar a la vista de informe, la URL pasa a https://orbita.example/informe. Funciona perfectamente… hasta que alguien recarga la página o comparte ese enlace.

La causa es simple: el servidor no sabe nada de tu enrutador. Busca un fichero llamado informe y no existe.

La solución se llama fallback a index.html: cualquier ruta que no corresponda a un fichero real devuelve index.html, y entonces tu JavaScript arranca, lee la URL y pinta la pantalla correspondiente.

Con una advertencia importante: el fallback debe devolver código 200, no 404, o los buscadores indexarán tus rutas como errores.

En Netlify (public/_redirects):

En Vercel (vercel.json):

En Cloudflare Pages (public/_redirects): idéntico a Netlify.

En Nginx:

try_files prueba en orden: el fichero exacto, el directorio, y si no existe ninguno, index.html. Es exactamente la lógica que necesitas.

En GitHub Pages no hay configuración de servidor, así que se usa un truco: crear un 404.html idéntico al index.html. GitHub lo sirve para rutas inexistentes y la aplicación arranca. Funciona, pero devuelve código 404, lo cual es malo para SEO. Es una de las razones para preferir otra plataforma si te importa la indexación.

Y el detalle que rompe el fallback: si aplicas la regla a todo, /api/tareas también devolverá index.html, y tu código recibirá HTML donde esperaba JSON — con un error de análisis desconcertante. Excluye las rutas de API antes de la regla general:

La caché es donde más se equivoca la gente, y produce dos fallos opuestos e igual de malos:

La solución correcta aprovecha el hashing del apartado 2, y se resume en una regla de dos líneas:

Los ficheros con hash en el nombre: caché de un año, inmutable. El index.html, el service worker y el manifiesto: nunca en caché.

La lógica es impecable: si el contenido cambia, el nombre cambia, luego un fichero con hash jamás necesita revalidarse. Y index.html, que es quien apunta a los nombres nuevos, debe pedirse siempre.

La tabla completa:

no-cache no significa «no guardar». Significa «guarda, pero revalida con el servidor antes de usar». Con ETag, la revalidación suele devolver un 304 sin cuerpo: coste mínimo y siempre actualizado. Lo que no guarda nada es no-store.

En Netlify o Cloudflare Pages (public/_headers):

En Nginx:

El caso especial del service worker merece énfasis porque produce el fallo más desconcertante de todos. Si sw.js se sirve con caché larga, el navegador no descarga el nuevo, así que el service worker antiguo sigue sirviendo la versión antigua de tu aplicación indefinidamente. El usuario recarga, borra el historial, y sigue viendo lo mismo. Los navegadores modernos limitan la caché de sw.js a 24 horas por defecto, pero no confíes en eso: pon no-cache explícito.

Cómo comprobar que está bien configurado:

Comprimir es la optimización con mejor relación entre esfuerzo y resultado que existe: una línea de configuración y entre un 60 % y un 80 % menos de bytes en texto.

Las plataformas gestionadas lo hacen solas y no tienes que configurar nada. En Nginx:

Dos matices importantes:

• No comprimas lo ya comprimido. PNG, JPEG, WebP, MP4 y WOFF2 ya lo están. Volver a comprimirlos gasta CPU y a veces aumenta el tamaño.
• Tu presupuesto de 11-01 está en bytes comprimidos. Los 60 kB del presupuesto se miden en la columna «Transferred» del panel Network, no en «Size». Confundirlas hace que creas que incumples cuando cumples, o al revés.

Estas cabeceras son gratis, se configuran una vez y cierran clases enteras de ataques. Van explicadas de una en una porque copiarlas sin entenderlas produce sitios rotos que nadie sabe arreglar.

Es la más potente y la más delicada. Declara de dónde puede cargar recursos tu página; todo lo demás lo bloquea el navegador.

Directiva a directiva:

Por qué la CSP es tan eficaz: es la segunda línea de defensa contra XSS. En 11-03 aprendiste la primera —textContent en lugar de innerHTML—, y la CSP es el paracaídas de reserva: aunque un atacante consiga inyectar <script>alert(1)</script> en tu página, script-src 'self' impide que se ejecute, porque no viene de tu origen.

Los dos escollos prácticos:

1. Los estilos en línea. Si tu código hace elemento.style.color = 'red', la CSP con style-src 'self' lo bloquea. La solución correcta es usar clases CSS en lugar de estilos en línea — que es mejor práctica de todos modos. La solución perezosa es 'unsafe-inline', que desactiva buena parte de la protección. Evítala.
2. Los scripts en línea. Si tienes <script> con código dentro del HTML, se bloquea. Vite no genera ninguno por defecto, así que normalmente no es problema.

Cómo implantarla sin romper nada: empieza en modo informe, que no bloquea nada y te avisa de lo que bloquearía:

Navega por toda tu aplicación, mira las advertencias de la consola, ajusta la política, y solo entonces quita el -Report-Only.

En Netlify o Cloudflare Pages (public/_headers):

Cómo verificarlo. Hay servicios públicos que analizan tus cabeceras y te dan una puntuación con explicaciones. También basta con:

Conseguir una buena puntuación de cabeceras de seguridad es un detalle pequeño con mucho peso en una revisión técnica: demuestra que has pensado en el despliegue, no solo en el código.

Tu proyecto puede funcionar perfectamente sin servidor: los datos en localStorage, todo en el navegador. Es una decisión legítima si está documentada con sus limitaciones (un solo dispositivo, sin privacidad real, sin compartir).

Si necesitas más, hay tres caminos:

Backend como servicio. Servicios como Supabase, Firebase o PocketBase te dan base de datos, API automática, autenticación y a veces tiempo real, con configuración en lugar de código. Para un proyecto de portafolio que necesita usuarios y datos compartidos, es la opción con mejor relación entre esfuerzo y resultado.

Lo que hay que saber antes de elegir uno:

• Dependes del proveedor. Migrar después tiene coste. Mitígalo manteniendo tu frontera del repositorio (11-02): si el BaaS vive detrás de RepositorioSupabase, cambiarlo es reescribir un fichero.
• Las reglas de seguridad son tu responsabilidad. Estos servicios exponen la base de datos directamente al cliente, protegida por reglas que tú configuras. Una regla mal escrita expone todos los datos de todos los usuarios. Es el fallo más frecuente y más grave de estas plataformas.
• Los planes gratuitos tienen límites y el servicio puede cambiar de precios o desaparecer.

Funciones sin servidor. Cuando solo necesitas ocultar una clave o hacer una operación puntual en servidor:

Fíjate en que la variable no lleva prefijo VITE_: eso es exactamente lo que la mantiene fuera del paquete del cliente.

Backend propio. Es el camino natural si quieres crecer, y es el tema de la lección 11-07: Node.js con Express o Fastify, una base de datos, autenticación con tokens, y toda la lógica de servidor que tu aplicación necesite. Requiere aprender cosas nuevas y merece la pena, pero no es requisito de este proyecto.

Este apartado es corto, no tiene matices, y es de los que más importan.

Tienes quince reglas de negocio, R1 a R15, implementadas y probadas en dominio/. Funcionan perfectamente… en el navegador. Y el navegador es un entorno que el usuario controla por completo:

• Puede abrir DevTools y llamar a tus funciones con lo que quiera.
• Puede modificar tu código antes de que se ejecute.
• Puede saltarse tu aplicación entera y llamar a la API con curl.

Si el servidor acepta eso, tus quince reglas no valen nada.

La validación del cliente es una comodidad para el usuario. La validación del servidor es la que protege los datos. No son alternativas: son dos capas con propósitos distintos, y las dos son obligatorias en cuanto hay servidor.

La buena noticia es que tu arquitectura ya está preparada para esto. dominio/ es JavaScript puro sin dependencias del navegador — esa fue la primera frontera de 11-01. Si escribes el backend en Node.js, puedes importar exactamente los mismos ficheros y ejecutar las mismas reglas en el servidor:

Una sola implementación de las reglas, ejecutada en los dos lados. Eso es lo que valía la pena de mantener el dominio libre de dependencias durante todo el proyecto, y es un argumento excelente para contar en una entrevista (11-06).

Y lo que el servidor debe validar además de tus reglas, porque son cosas que el cliente no puede hacer:

Despliegue continuo significa que lo que se fusiona en main llega a producción automáticamente, sin pasos manuales. Con la CI de 11-04 protegiendo la rama, eso es seguro: nada llega a main sin lint, pruebas, cobertura, presupuesto y recorridos en verde.

Las decisiones del fichero:

La comprobación de humo es una idea que conviene interiorizar: una verificación mínima y rápida de que lo desplegado responde y contiene lo que debe. Cuesta cinco líneas y detecta el «se desplegó una carpeta vacía», que ocurre más de lo que parece.

Los secretos del repositorio (Settings → Secrets and variables): NETLIFY_AUTH_TOKEN y NETLIFY_SITE_ID van como secrets (cifrados, no visibles ni en los registros); API_URL va como variable (no es secreta y así se puede leer). Nunca escribas un token directamente en el YAML: el fichero está en el repositorio.

Un entorno de vista previa es un despliegue temporal de una rama, con su propia URL. Netlify, Vercel y Cloudflare Pages lo hacen automáticamente al abrir una Pull Request.

Por qué merece la pena, aunque trabajes solo:

Tres precauciones importantes:

1. noindex en las vistas previas. Si Google indexa deploy-preview-42--orbita.netlify.app, tendrás contenido duplicado compitiendo con tu sitio. Las plataformas suelen ponerlo, pero compruébalo.
2. Nunca apuntes una vista previa a datos de producción. Una prueba destructiva en una vista previa que escribe en la base real es un desastre evitable. Usa un entorno de datos separado.
3. Las vistas previas son públicas. Cualquiera con la URL entra. No pruebes ahí con datos reales de nadie.

Todo despliegue puede salir mal. La pregunta no es si ocurrirá, sino cuánto tardarás en arreglarlo cuando ocurra — probablemente a una hora incómoda y con prisa.

Las opciones, de mejor a peor:

La primera es la buena, y hay que probarla antes de necesitarla. Las plataformas gestionadas guardan todos los despliegues anteriores y permiten volver a cualquiera con un clic, porque cada despliegue es un conjunto inmutable de ficheros estáticos.

El procedimiento escrito, que debe estar en tu README o en docs/operaciones.md:

El punto 1 es contraintuitivo y es el correcto. La tentación es investigar mientras el sitio está roto. Pero cada minuto de investigación es un minuto de servicio caído, y la prisa hace que se tomen peores decisiones. Revertir es reversible; arreglar con prisa, no.

El punto 7 es el que convierte un incidente en aprendizaje. Y la pregunta clave del post mortem no es «quién se equivocó» sino «por qué la CI no lo detectó», porque la respuesta es siempre una comprobación nueva que evita toda una familia de fallos futuros.

Una precaución sobre la base de datos: si tu despliegue incluyó una migración de datos (como las de 11-03), revertir el código no revierte los datos. Por eso las migraciones deben ser compatibles hacia atrás siempre que se pueda: añadir campos, no renombrarlos ni borrarlos en el mismo despliegue que los deja de usar. La secuencia segura es en dos despliegues: primero añadir y escribir en los dos sitios, después dejar de usar el viejo.

En desarrollo, un error aparece en tu consola. En producción, aparece en la consola de un usuario que no la va a mirar y no te lo va a contar: simplemente dejará de usar tu aplicación.

En 11-02 montaste un registro local con las dos redes de seguridad globales (error y unhandledrejection). Ahora hay que enviarlo a algún sitio.

Las opciones:

Servicios de seguimiento de errores. Sentry, Bugsnag, Rollbar y similares tienen planes gratuitos suficientes para un proyecto personal, se integran con tres líneas y agrupan errores idénticos —lo cual importa mucho: un fallo que ocurre 400 veces es una entrada, no 400 correos.

Y aquí viene la parte que hay que hacer bien:

Un servicio de seguimiento de errores envía datos de tus usuarios a un tercero. Eso es una decisión de privacidad, no solo técnica.

Lo que hay que configurar antes de activarlo:

Dos detalles del código: location.pathname en lugar de location.href evita enviar parámetros de consulta que pueden contener búsquedas o identificadores; y sendBeacon envía sin bloquear y funciona aunque la página se esté cerrando, que es justo cuando ocurren muchos errores.

Advertencia. No envíes datos personales a un servicio externo sin haberlo previsto en tu aviso de privacidad y sin conocer dónde se almacenan. En un proyecto de aprendizaje con datos ficticios el riesgo es nulo; en un producto real, activar un servicio de seguimiento sin más es un problema de cumplimiento normativo, no un detalle técnico.

En 09-01 aprendiste la distinción que más confusión evita: laboratorio (tu Lighthouse, tu máquina, tu red) frente a campo (usuarios reales, dispositivos reales, redes reales). Los números de campo son siempre peores, y son los que importan.

Cómo leer los resultados, que es donde está el valor:

Ese último punto es el que justifica todo el esfuerzo: enviar la versión con cada métrica permite atribuir una regresión a un despliegue concreto. Sin eso, solo sabes que empeoró en algún momento.

Y una nota de privacidad: las métricas de rendimiento no son datos personales si no incluyen identificadores. No añadas un identificador de usuario «para poder correlacionar»; el percentil 75 no lo necesita.

Este es el problema más específico del despliegue de una PWA, y produce una situación exasperante: el usuario tiene la aplicación instalada, tú despliegas una corrección, y él sigue viendo la versión antigua. Recarga, y nada.

La causa está en el ciclo de vida del service worker (07-05):

El estado «En espera» es el problema. Por defecto, un service worker nuevo espera a que todas las pestañas de la aplicación se cierren. Y como mucha gente nunca cierra del todo una PWA instalada, esa espera puede durar días.

La solución completa, en tres piezas.

Pieza 1 · El service worker permite saltarse la espera bajo demanda:

Pieza 2 · La aplicación detecta que hay una versión nueva y lo dice:

Pieza 3 · El aviso, que debe ser discreto y accesible:

Las cuatro reglas de la actualización de una PWA:

1. Nunca recargues sin avisar. El usuario puede estar escribiendo. Una recarga sorpresa que pierde un formulario es imperdonable.
2. La bandera recargando es imprescindible. Sin ella, controllerchange puede provocar un bucle de recargas: es un fallo real y muy desagradable.
3. sw.js con Cache-Control: no-cache (apartado 7). Sin eso, nada de esto funciona porque el navegador ni siquiera descarga el service worker nuevo.
4. Limpia las cachés viejas en activate. Si no, se acumulan versiones y acabas ocupando cientos de megabytes en el dispositivo de otra persona.

El plan de emergencia, que conviene tener escrito: si despliegas un service worker roto que rompe la aplicación para todos los que la tienen instalada, la salida es publicar un sw.js mínimo que se desregistre a sí mismo y limpie todas las cachés:

Guárdalo. El día que lo necesites, lo agradecerás.

El entregable final del hito. Se recorre entera, se marca, y se guarda firmada y fechada en docs/lanzamiento.md.

Advertencia legal. Los puntos 27 y 28 no son formalidades. En la Unión Europea, informar sobre el tratamiento de datos personales es una obligación, y el uso de cookies o almacenamiento no estrictamente necesario requiere consentimiento previo, informado y revocable — un banner que solo dice «aceptar» no cumple. Si tu proyecto es un ejercicio con datos ficticios y sin analítica, el riesgo práctico es nulo, pero acostúmbrate a incluir el aviso. Si algún día publicas un producto con usuarios reales, esto requiere asesoramiento legal específico: ni esta lección ni ninguna documentación técnica lo sustituyen.

Un aviso de privacidad honesto para un proyecto como este es corto y se escribe en diez minutos:

Poner un secreto en una variable VITE_. Acaba escrito en un fichero público que cualquiera lee con Ctrl+F, y los robots que rastrean repositorios lo encuentran en minutos. Cualquier cosa que dé acceso a algo va detrás de una función de servidor. Comprueba dist/ con grep antes de cada despliegue, y automatízalo en el flujo.

No configurar el fallback de SPA. Todo funciona navegando desde la portada y da 404 al recargar o al abrir un enlace compartido — que es exactamente cómo llegará la gente a quien enseñes el proyecto.

Caché larga en index.html. Los usuarios se quedan con la versión antigua durante días y no hay forma de forzarlos a actualizar. Los ficheros con hash llevan caché de un año; el punto de entrada, no-cache.

Caché en sw.js. Produce el fallo más desconcertante que existe: el usuario recarga, borra el historial, reinstala, y sigue viendo la aplicación de hace tres despliegues.

base mal configurado. En GitHub Pages con subdirectorio, sin base: '/repo/' la página carga en blanco y la consola se llena de 404 sobre /assets/…. Es el fallo número uno del primer despliegue.

Añadir 'unsafe-inline' a la CSP para que deje de quejarse. Desactiva buena parte de la protección contra XSS, que es justo lo que la CSP existía para dar. Arregla el estilo o el script en línea; casi siempre son dos líneas.

Confiar solo en la validación del cliente. Cualquiera puede llamar a tu API con curl. Con servidor, las reglas van también allí — y tu dominio sin dependencias hace que sea el mismo código.

Desplegar sin haber probado la reversión. El día que la necesites, con el sitio caído y prisa, no es el momento de descubrir cómo funciona. Pruébala hoy, en frío.

Recargar la PWA sin avisar cuando hay versión nueva. El usuario puede estar escribiendo. Aviso discreto, botón, y recarga solo cuando lo pida — con la bandera que evita el bucle de recargas.

Enviar datos personales a un servicio de seguimiento de errores. Es un problema de cumplimiento, no de estilo. Filtra antes de enviar, envía pathname y no href, y declara el servicio en tu aviso de privacidad.

Consejo · Despliega desde el primer día y con frecuencia. Un despliegue por semana durante dos meses es aburrido y seguro. Un despliegue enorme el último día es la receta de un desastre.

Consejo · Ten un panel de diagnóstico en producción. Una ruta discreta que muestre versión, commit, fecha de compilación, estado del service worker, espacio ocupado y últimos errores. Cuando alguien te diga «no me funciona», esa pantalla responde en diez segundos.

Consejo · Guarda una captura de la línea base de producción. Lighthouse sobre la URL real, con fecha. Dentro de seis meses sabrás si has mejorado o empeorado, y tendrás la prueba.

Consejo · Prueba tu sitio desplegado en un móvil de verdad. No en el emulador. Con datos móviles, no wifi. Descubrirás cosas que ningún estrangulamiento simulado te enseña.

Estos ejercicios son el hito H6, primera parte: la aplicación desplegada con HTTPS, su flujo de despliegue continuo y la lista de comprobación firmada.

Ejercicio 1 — La compilación y el despliegue.

1. Configura vite.config.js con base correcto para tu plataforma, sourcemap, manualChunks y chunkSizeWarningLimit con tu presupuesto.
2. Crea .env.example versionado y .env.production ignorado, y documenta en el README qué variables hacen falta.
3. Compila y audita dist/: tamaño total, número de ficheros, y grep de secretos. Documenta los resultados.
4. Prueba con npm run preview toda la aplicación antes de desplegar. Anota los problemas que aparezcan solo en producción (habrá al menos uno).
5. Despliega en la plataforma que elijas, con dominio propio o subdominio de la plataforma, y HTTPS activo.
6. Configura el fallback de SPA y comprueba con curl -I que devuelve 200 en una ruta interna.
7. Configura la caché completa según la tabla del apartado 7 y verifícala con curl -I sobre un fichero con hash, sobre index.html y sobre sw.js.
8. Configura las cinco cabeceras de seguridad, con la CSP primero en modo informe y luego activa, sin unsafe-inline.
9. Documenta cada decisión en docs/despliegue.md: qué plataforma, por qué, y qué implica.

Ejercicio 2 — Despliegue continuo, vistas previas y reversión.

1. Escribe .github/workflows/desplegar.yml con: verificación previa, compilación con la versión del commit, comprobación automática de secretos, despliegue y comprobación de humo.
2. Configura los secretos y variables del repositorio correctamente (secretos cifrados, variables normales).
3. Activa las vistas previas por PR y comprueba las tres precauciones: noindex, datos separados, y conciencia de que son públicas.
4. Prueba la reversión de verdad: despliega un cambio visible, revierte al anterior, comprueba que el sitio vuelve, y vuelve a publicar el nuevo. Cronometra cuánto tardas.
5. Escribe docs/operaciones.md con el procedimiento de reversión de siete pasos adaptado a tu plataforma.
6. Configura la monitorización de errores con filtrado de datos personales, y demuestra que un error provocado a propósito llega con la traza y sin datos de usuario.
7. Instrumenta web-vitals enviando la versión, y recoge al menos una sesión de datos de campo.
8. Implementa la actualización de la PWA con las tres piezas del apartado 17, y demuéstralo: instala la aplicación, despliega un cambio, y comprueba que aparece el aviso, que el botón actualiza y que no hay bucle de recargas.

Ejercicio 3 — El lanzamiento.

1. Recorre las 33 comprobaciones del apartado 18 sobre tu sitio desplegado. Marca cada una con evidencia (comando ejecutado, captura o URL), no de memoria.
2. Completa el bloque de contenido: <title>, descripción, Open Graph con imagen de 1200×630, favicons en cinco tamaños, robots.txt, sitemap.xml, página 404 propia y manifest.json completo.
3. Escribe el aviso de privacidad con la plantilla del apartado 18.3, adaptado a lo que tu aplicación hace realmente.
4. Añade la licencia al repositorio.
5. Ejecuta Lighthouse sobre la URL de producción (no en local) y compara con tu presupuesto de 11-01 y con tu línea base de 11-04. Documenta las diferencias y explícalas.
6. Pásale el sitio a un analizador de cabeceras de seguridad y documenta la puntuación.
7. Ábrelo en un móvil real con datos móviles y anota todo lo que no funcione como esperabas.
8. Firma y fecha docs/lanzamiento.md.

Criterios de aceptación del ejercicio 1 — Despliegue

Rúbrica del ejercicio 1 (21 puntos)

Umbral: 15/21, con obligatoriamente 3 en «Secretos». Un secreto filtrado invalida el ejercicio: es el único fallo de esta lección con consecuencias reales fuera del proyecto.

Criterios de aceptación del ejercicio 2 — Continuo y operaciones

Criterios de aceptación del ejercicio 3 — Lanzamiento

Rúbrica global del hito H6 primera parte (24 puntos)

Umbral: 17/24. Con una condición que no se compensa: cero secretos en el paquete. Todo lo demás se puede mejorar en la siguiente iteración; una clave filtrada, no.

Autoevaluación del hito H6:

Tu proyecto ya no vive en tu portátil: está en internet, con HTTPS, y cualquiera puede usarlo.

Sabes qué cambia cuando el código sale de tu máquina —nueve diferencias, cada una fuente de sorpresas— y tienes la regla que evita la mitad de ellas: nunca despliegues nada que no hayas probado con build y preview. Conoces la compilación de producción por dentro: empaquetado que reduce peticiones, división de código que retrasa lo que no se ve, minificación que solo funciona bien gracias a los módulos ES estáticos de 05-04, y el hashing del nombre, que es la pieza elegante que permite tener a la vez caché de un año y actualización inmediata — y que explica por qué index.html es el único que no lo lleva. Con base bien configurado, que es la causa número uno de primeros despliegues en blanco.

Tienes clarísimo lo más importante de la lección: no hay secretos en el cliente. import.meta.env.VITE_* no es una variable: es una constante pública escrita literalmente en un fichero que se descarga. Sabes qué puede ir y qué no, sabes que el razonamiento erróneo («está en una variable de entorno») confunde dónde se escribió el valor con dónde acaba, y sabes que la única respuesta correcta cuando hace falta una clave es un intermediario en el servidor. Con la verificación por grep automatizada en el flujo, porque las buenas intenciones se olvidan y los robots que rastrean repositorios no.

Sabes dónde alojar con una tabla honesta que incluye lo que las comparativas no dicen: que GitHub Pages no permite cabeceras reales, que Netlify, Vercel y Cloudflare Pages son equivalentes para un sitio estático, que un servidor propio es el único que te obliga a entender lo que pasa, y que los planes gratuitos tienen límites que cambian. Y sabes por qué HTTPS no es opcional: sin él no hay service worker, ni PWA, ni contextos seguros, ni confianza.

Sabes resolver el problema que sorprende a todo el mundo —las rutas de una SPA—, con fallback a index.html que devuelve 200 y no 404, en las cuatro plataformas, y con la exclusión de las rutas de API que evita recibir HTML donde esperabas JSON.

Tienes la caché bien hecha, que es donde más se equivoca la gente: un año e inmutable para lo que lleva hash, no-cache para el punto de entrada, el service worker y el manifiesto. Sabes que no-cache significa «revalida», no «no guardes». Y sabes que un sw.js cacheado produce el fallo más desconcertante que existe: usuarios atrapados en una versión de hace tres despliegues por mucho que recarguen.

Sabes configurar las cabeceras de seguridad una a una, entendiéndolas: la CSP como segunda línea de defensa contra XSS —con connect-src impidiendo la exfiltración, frame-ancestors evitando el clickjacking, y la advertencia de que 'unsafe-inline' desactiva justo lo que la política venía a dar—, implantada primero en modo informe; nosniff, Referrer-Policy, Permissions-Policy y HSTS con su max-age progresivo porque es difícil de revertir.

Sabes qué hacer con el backend: que no tenerlo es legítimo si está documentado con sus limitaciones; que un backend como servicio resuelve el multiusuario sin escribir servidor, con la advertencia de que las reglas de seguridad son tuyas y una mal escrita expone todos los datos; que una función sin servidor de veinte líneas basta para ocultar una clave; y que escribir el tuyo es el camino de 11-07. Y sabes, sin matices, que la validación del cliente nunca sustituye a la del servidor — con la recompensa de que tu dominio sin dependencias del navegador se puede importar tal cual en Node y ejecutar las mismas R1–R15 en los dos lados, que es exactamente por lo que valía la pena la primera frontera de 11-01.

Tienes despliegue continuo con verificación previa, versión del commit inyectada —lo que hace posible atribuir una regresión a un despliegue—, comprobación automática de secretos y prueba de humo, porque que un despliegue termine no significa que el sitio funcione. Con vistas previas por rama y sus tres precauciones, y con una estrategia de reversión cuya regla es contraintuitiva y correcta: revertir primero, investigar después, porque revertir es reversible y arreglar con prisa no lo es. Con el post mortem cuya pregunta clave no es quién se equivocó sino por qué la CI no lo detectó.

Sabes monitorizar en producción sin convertirte en un problema de privacidad: filtrar antes de enviar, pathname en lugar de href, sendBeacon porque funciona mientras la página se cierra, y la conciencia de que un servicio de seguimiento es un tercero que recibe datos de tus usuarios. Y sabes recoger métricas de campo con web-vitals, con la distinción de 09-01 entre laboratorio y campo, y con la versión adjunta para poder atribuir.

Sabes actualizar una PWA instalada, que es el problema más específico del despliegue de una aplicación web moderna: el estado «en espera» que puede durar días, las tres piezas que lo resuelven, las cuatro reglas —avisar siempre, la bandera contra el bucle de recargas, no-cache en sw.js, limpiar cachés viejas— y el service worker de emergencia que conviene tener guardado antes de necesitarlo.

Y tienes la lista de comprobación de lanzamiento con sus 33 puntos en tres bloques: técnico, contenido y descubribilidad, y legal y operativo — incluidos el aviso de privacidad honesto y específico, la advertencia de que el consentimiento de cookies tiene requisitos legales que un botón de «aceptar» no cumple, y la licencia.

El producto está publicado. Y aquí aparece lo que separa un proyecto terminado de un proyecto que además sirve para algo: nadie sabe que existe, nadie sabe qué decisiones hay detrás, y tú todavía no has practicado cómo contarlo. Un trabajo que no se puede enseñar ni defender vale, en la práctica, mucho menos de lo que es. Convertirlo en algo que alguien entienda en dos minutos, que puedas demostrar en cinco, y que sepas explicar en una entrevista técnica sin sonar ni inseguro ni fanfarrón, es Presentación y Revisión del Proyecto.