Capítulo 23 — Despliegue profesional con Firebase Hosting¶

Recursos visuales propuestos¶

Antes de desarrollar este capítulo conviene separar los recursos visuales introductorios de los estrictamente arquitectónicos. El flujo del proceso de despliegue, la estructura del proyecto antes de publicar, la organización de firebase.json, el ejemplo de versión publicada y el flujo de actualización se comprenden mejor como imágenes didácticas, porque ayudan al lector a construir una secuencia mental clara del trabajo cotidiano. En cambio, la arquitectura completa del proceso de despliegue, el flujo Firebase CLI → Hosting → CDN, la integración entre Hosting y los demás servicios de Firebase, y el proceso de rollback deben resolverse como diagramas SVG, ya que muestran relaciones técnicas, rutas de publicación y dependencias entre múltiples componentes del sistema.[cite:1][cite:2]

Imágenes didácticas¶

Flujo del proceso de despliegue. Conviene como imagen didáctica porque resume una secuencia operativa de manera simple.
Estructura del proyecto antes de publicar. Es mejor como imagen didáctica porque el objetivo es que el lector identifique carpetas y archivos clave.
Organización de firebase.json. Debe ser imagen didáctica porque se trata de reconocer piezas de configuración sin añadir complejidad arquitectónica innecesaria.
Ejemplo de versión publicada. Conviene como imagen didáctica porque ayuda a entender el resultado visible de un despliegue.
Flujo de actualización. Debe ser imagen didáctica porque describe el ciclo natural de mejora continua de una aplicación publicada.

Diagramas SVG¶

Arquitectura completa del proceso de despliegue. Debe resolverse como SVG porque muestra la interacción entre repositorio local, CLI, Hosting, versiones, releases y CDN.[cite:1][cite:2]
Flujo Firebase CLI → Hosting → CDN. Conviene SVG porque requiere representar pasos secuenciales y transferencia de contenido desde el entorno local hasta la entrega global.[cite:1]
Integración entre Hosting y los demás servicios Firebase. Debe ser SVG porque explica cómo el frontend desplegado se conecta con Authentication, Firestore, Storage y Functions.[cite:1]
Proceso de rollback. Debe ser SVG porque involucra releases, versiones y reversión controlada a un estado previo del sitio.[cite:2]

Objetivos de aprendizaje¶

Al finalizar este capítulo, el lector será capaz de:

Comprender qué significa desplegar una aplicación y qué cambia entre un proyecto local y una aplicación publicada.
Preparar profesionalmente un proyecto para producción usando Firebase CLI y Firebase Hosting.[cite:1]
Configurar correctamente firebase.json, .firebaserc y el directorio público según el tipo de aplicación.[cite:1][cite:3]
Entender cómo funciona firebase deploy, qué diferencia existe entre un despliegue completo y uno parcial, y cuándo conviene usar cada opción.[cite:1][cite:3]
Validar despliegues, interpretar historial de versiones y comprender el modelo de releases y rollback en Firebase Hosting.[cite:2]
Integrar el despliegue del frontend con el resto del ecosistema Firebase manteniendo orden, seguridad y mantenibilidad.
Preparar el proyecto oficial del libro para futuras actualizaciones profesionales.

Introducción¶

Desplegar una aplicación significa moverla desde un entorno local de desarrollo hacia una infraestructura accesible por usuarios reales. No se trata solo de “subir archivos”; implica convertir un proyecto en un producto disponible, estable, reproducible y controlado. En un equipo profesional, el despliegue es parte del ciclo de ingeniería y no una actividad improvisada al final del proyecto.

Firebase Hosting simplifica ese proceso mediante una combinación de CLI, configuración declarativa y publicación sobre una CDN global. La documentación oficial resume el flujo en pocos pasos: preparar un directorio local, ejecutar firebase init para conectarlo a un proyecto, probar opcionalmente con herramientas locales o canales previos y finalmente publicar con firebase deploy.[cite:1] Aunque el proceso parece simple, detrás hay una arquitectura importante: Firebase crea una nueva versión del contenido, la asocia con una release y la distribuye mediante la infraestructura de Hosting.[cite:2]

Este capítulo enseña a desplegar de forma profesional. Eso significa entender el proceso completo, no solo memorizar comandos. Se explicará cómo preparar el proyecto del libro, cómo organizar la configuración, qué ocurre internamente al publicar, cómo diferenciar despliegues parciales y completos, cómo trabajar con targets, cómo validar una publicación y cómo revertir si algo falla. El objetivo es que el lector domine el despliegue como una práctica repetible y segura.

Desarrollo completo¶

¿Qué significa desplegar una aplicación?¶

Desplegar es publicar una versión ejecutable de la aplicación en un entorno real para que sea accesible desde Internet. En el caso de Firebase Hosting, desplegar implica subir el snapshot del contenido y la configuración del sitio a los servidores de Hosting para que ese conjunto se sirva desde la CDN global.[cite:1]

Conviene insistir en la palabra snapshot. En un despliegue profesional no se trabaja como si el servidor fuera una carpeta donde se copian archivos sueltos por FTP. Se publica un estado concreto del sitio, con sus archivos y su configuración, y ese estado queda asociado a una versión. Posteriormente, esa versión puede ser referenciada por una release, inspeccionada en historial o incluso reutilizada mediante rollback o clonación entre canales.[cite:2]

Flujo completo de publicación¶

De forma conceptual, el flujo completo es este:

El equipo desarrolla localmente.
Se genera el build de producción.
Se revisa la estructura del directorio público.
Se configura firebase.json.
Se asegura la asociación correcta del proyecto mediante .firebaserc.
Se valida localmente si hace falta.
Se ejecuta firebase deploy o un despliegue parcial.
Firebase crea una nueva versión y una nueva release para el canal correspondiente.[cite:1][cite:2]
La CDN empieza a servir el nuevo contenido.
El equipo valida la publicación en producción.

Preparación del proyecto¶

Antes de desplegar, el proyecto debe estar preparado. En un entorno profesional, preparar no significa solo “que funcione en local”. Significa, como mínimo:

tener un build reproducible;
separar código fuente de artefactos compilados;
definir claramente el directorio público;
conocer si se trata de una SPA o de un sitio estático tradicional;
identificar headers, redirects o rewrites necesarios;
confirmar qué recursos se sirven desde Hosting y cuáles dependen de otros servicios;
asegurar que el proyecto apunta al Firebase Project correcto.

En el proyecto oficial del libro, este momento es especialmente importante. La plataforma educativa incluirá frontend, autenticación, base de datos, almacenamiento y lógica adicional. Si el frontend se despliega sin una estructura clara, el crecimiento posterior será desordenado. Por eso, antes del primer despliegue conviene pensar la publicación como parte de la arquitectura general del sistema.

Configuración¶

`firebase init hosting`¶

La documentación oficial de Firebase Hosting indica que el primer paso para conectar un directorio local con Hosting es ejecutar firebase init y seleccionar Hosting como recurso a configurar.[cite:1][cite:3] En la práctica, muchos equipos ejecutan firebase init hosting o utilizan firebase init y luego marcan la opción correspondiente.

Internamente, este comando hace varias cosas importantes:

vincula el proyecto local con un Firebase Project;
pregunta cuál será el directorio público que contendrá los archivos servibles;
permite configurar la aplicación como SPA si corresponde;
genera o actualiza archivos como firebase.json y .firebaserc.

No es solo un asistente interactivo. Es el momento en que se formaliza la relación entre el proyecto local y la infraestructura de despliegue.

Configuración del directorio público¶

El directorio público es la carpeta cuyos contenidos se publicarán en Hosting. En una app simple podría ser public. En frameworks modernos suele ser dist, build o una carpeta generada por el proceso de compilación.

La decisión es importante porque Firebase Hosting despliega exactamente lo que se encuentra allí. Si el equipo apunta al directorio fuente en vez del build de producción, puede publicar archivos incorrectos, desarrollo no minificado o incluso estructura interna que no debería exponerse.

En una plataforma educativa como la del libro, una organización razonable puede ser:

apps/web/ para el código fuente del frontend;
apps/web/dist/ o apps/web/build/ como salida compilada;
functions/ para backend cuando aplique;
firebase.json y .firebaserc en la raíz del proyecto.

`firebase.json`¶

firebase.json es el archivo declarativo central del despliegue. Allí se define cómo debe comportarse Firebase Hosting respecto a qué carpeta publicar, qué archivos ignorar, qué rewrites aplicar, qué redirects servir y qué headers agregar.

En el caso más básico, puede verse así:

{
  "hosting": {
    "public": "dist",
    "ignore": [
      "firebase.json",
      "**/.*",
      "**/node_modules/**"
    ]
  }
}

Aunque parece un archivo pequeño, su papel es enorme. Es la fuente declarativa que convierte el despliegue en una operación repetible. Un equipo profesional no depende de clics manuales; depende de configuración versionada.

La documentación también muestra que cuando se tienen múltiples sitios de Hosting o múltiples configuraciones, hosting puede definirse como un arreglo de objetos con target, de forma que cada sitio tenga su propia carpeta pública y su propia configuración.[cite:3]

`.firebaserc`¶

.firebaserc almacena información de asociación entre el proyecto local y los proyectos o targets de Firebase. La documentación de deploy targets explica que la configuración de esos targets se guarda precisamente en este archivo.[cite:3]

Un ejemplo simple sería:

{
  "projects": {
    "default": "mi-proyecto-libro"
  }
}

En un entorno con múltiples ambientes, puede incluir alias como dev, staging o prod. Esto es crítico porque evita despliegues accidentales al proyecto equivocado. Un error de asociación aquí puede terminar publicando una versión de pruebas en producción.

Configuración para SPA¶

La documentación oficial y numerosos ejemplos de Hosting dejan claro que las SPA requieren una regla de rewrite que envíe las rutas del cliente a index.html, permitiendo que el router frontend resuelva la vista correcta.[cite:1]

Una configuración común es:

{
  "hosting": {
    "public": "dist",
    "ignore": [
      "firebase.json",
      "**/.*",
      "**/node_modules/**"
    ],
    "rewrites": [
      {
        "source": "**",
        "destination": "/index.html"
      }
    ]
  }
}

Sin esta regla, muchas rutas profundas de una SPA fallarán si el usuario recarga directamente en una URL interna. El problema no es del framework; es una cuestión de cómo el servidor interpreta la ruta solicitada.

Configuración para aplicaciones estáticas¶

En un sitio estático tradicional, normalmente no hace falta una regla global de rewrite hacia index.html. En ese caso, cada archivo HTML representa una ruta real del sitio y Firebase Hosting los sirve directamente desde la estructura del directorio público.

La diferencia entre sitio estático y SPA es clave. En el primero, las rutas suelen corresponder a archivos reales. En la segunda, las rutas pueden ser virtuales y pertenecer al router del frontend. Esta distinción afecta directamente la configuración del despliegue.

Despliegue¶

`firebase deploy`¶

La documentación oficial de Hosting define firebase deploy como el comando que sube el snapshot más reciente a los servidores de Hosting.[cite:1] No se limita a subir archivos; genera una nueva publicación que Firebase asocia con una versión y una release.

Desde la perspectiva del desarrollador, el comando parece simple:

firebase deploy

Pero internamente ocurren varias cosas:

la CLI lee firebase.json;
identifica los recursos configurados para despliegue;
empaqueta contenido y configuración;
comunica al proyecto de Firebase qué recursos actualizar;
Hosting crea una nueva versión;
esa versión queda asociada a una nueva release del canal correspondiente.[cite:2][cite:3]

Despliegue parcial¶

La documentación de deploy targets explica que firebase deploy --only hosting:TARGET_NAME despliega únicamente el contenido y configuración del sitio de Hosting especificado.[cite:3] También pueden usarse otras variantes para publicar solo ciertos recursos.

Ejemplos:

firebase deploy --only hosting

firebase deploy --only hosting:app

Esto es útil cuando no se desea desplegar todo el proyecto. En sistemas más grandes, el despliegue parcial reduce riesgo y acelera iteraciones porque publica solamente la parte relevante.

Despliegue completo¶

firebase deploy sin filtros crea una release de todos los recursos desplegables configurados en el directorio del proyecto.[cite:3] Si en el futuro el lector combina Hosting con reglas de Storage, Database o Functions, este comando puede afectar varios componentes de la plataforma.

Por eso, un despliegue completo no siempre es la mejor opción en el trabajo diario. Es potente, pero exige disciplina. Antes de usarlo conviene saber exactamente qué incluye el proyecto y qué se publicará.

Despliegue únicamente de Hosting¶

Cuando el objetivo es publicar exclusivamente el frontend, la forma más segura suele ser explicitarlo:

firebase deploy --only hosting

Si existen varios sitios, targets o ambientes, puede ser preferible aún más precisión:

firebase deploy --only hosting:webapp

Esta práctica reduce errores operativos. En entornos reales, muchos incidentes provienen no de bugs complejos, sino de comandos demasiado amplios ejecutados sin intención suficiente.

Validación del despliegue¶

Un despliegue no termina cuando la terminal devuelve éxito. Termina cuando la aplicación publicada ha sido validada. Como mínimo conviene revisar:

que la URL pública cargue correctamente;
que los assets críticos respondan;
que la SPA resuelva rutas internas;
que la autenticación siga funcionando;
que Firestore y Storage respondan desde producción;
que no existan errores 404 o 500 inesperados;
que la versión publicada corresponda con el commit o build esperado.

La documentación oficial también sugiere probar localmente con el emulador antes de desplegar, o incluso usar canales previos cuando se requiera revisar cambios antes de ir a producción.[cite:1][cite:3] Aunque preview channels se desarrollarán más adelante, es importante que el lector entienda que la validación profesional empieza antes del “go live”.

Historial de versiones¶

La documentación de gestión de recursos de Hosting explica la jerarquía de site, channel, version y release.[cite:2] Esta jerarquía es fundamental:

un site representa el sitio de Hosting;
un channel es una URL asociada a contenido y configuración específicos;
una version es el paquete de contenido y configuración desplegado;
una release es el evento que apunta una channel a una version concreta.[cite:2]

Comprender esto cambia la forma de pensar el despliegue. No se trata solo de archivos activos, sino de historial trazable y estados recuperables.

Integración¶

Firestore¶

El despliegue del frontend no despliega Firestore. Sin embargo, la app publicada en Hosting puede comenzar a consumir Firestore inmediatamente después de cargarse en el navegador. En el proyecto del libro, eso significa que paneles, tablas, fichas de estudiantes y contenidos académicos estarán disponibles desde la aplicación web ya publicada.

Authentication¶

Lo mismo ocurre con Authentication. La aplicación desplegada puede presentar formularios de acceso, validar sesiones y controlar experiencias según el rol del usuario. El despliegue del frontend, por tanto, debe entenderse como la publicación de la puerta de entrada visual a un backend ya operativo.

Storage¶

Una vez publicado el frontend, puede mostrar imágenes, credenciales, comprobantes, materiales didácticos o documentos servidos desde Cloud Storage. Esto refuerza una idea importante: desplegar la app no es desplegar todos los datos, sino la interfaz que orquesta el consumo de esos servicios.

Cloud Functions¶

Hosting puede integrarse con Functions para rewrites o contenido dinámico.[cite:1] En términos de despliegue, esto obliga a tener claridad sobre qué rutas son frontend puro y cuáles deben delegarse a backend. Aunque en este capítulo no se profundiza en funciones específicas, sí conviene entender que la publicación profesional debe respetar esa frontera.

Variables de entorno¶

En aplicaciones frontend modernas, las variables de entorno se resuelven normalmente en tiempo de build. Por eso, antes del despliegue es necesario asegurar que el build de producción use las credenciales y configuraciones correctas para el ambiente objetivo. Este punto es especialmente sensible cuando se trabaja con múltiples proyectos Firebase o con llaves públicas de configuración de apps web.

Automatización¶

Scripts npm¶

Un proyecto profesional no debería depender de recordar manualmente todos los pasos. Es preferible definir scripts claros en package.json, por ejemplo:

{
  "scripts": {
    "build": "vite build",
    "deploy": "npm run build && firebase deploy --only hosting",
    "deploy:prod": "npm run build && firebase use prod && firebase deploy --only hosting"
  }
}

Esto aporta repetibilidad, reduce errores y documenta el flujo operativo del equipo.

Organización del proyecto¶

La organización recomendada para el proyecto del libro debe facilitar crecimiento. Un ejemplo razonable:

proyecto-plataforma-educativa/
├── apps/
│   └── web/
│       ├── src/
│       ├── public/
│       └── dist/
├── functions/
├── firebase.json
├── .firebaserc
└── package.json

Esta estructura separa claramente fuente, salida compilada y servicios auxiliares.

Integración con Git¶

Todo despliegue profesional debe estar ligado al control de versiones. Aunque el comando firebase deploy puede ejecutarse manualmente, el verdadero control llega cuando el equipo sabe exactamente qué commit fue publicado, quién lo publicó y cómo revertirlo. Git aporta trazabilidad; Firebase Hosting aporta versiones y releases del sitio. Juntos forman una práctica mucho más segura que publicar cambios sin referencia de código.

Buenas prácticas de despliegue¶

Desplegar desde un árbol limpio y controlado.
Confirmar siempre el proyecto activo antes de publicar.
Versionar firebase.json y .firebaserc.
Separar ambientes con aliases claros.
Automatizar build y deploy.
Validar después de cada release.
Evitar deploys manuales improvisados desde equipos no controlados.
Documentar el flujo operativo del proyecto.

Producción¶

Estrategias de despliegue¶

No todas las publicaciones deben seguir el mismo modelo. Algunas estrategias comunes son:

despliegue manual controlado, útil en equipos pequeños;
despliegue automatizado desde ramas protegidas;
despliegue a canales previos antes de promover cambios;
uso de múltiples sitios o ambientes según el tipo de frontend.

La mejor estrategia depende del tamaño del equipo y del riesgo del sistema. En una plataforma educativa con usuarios reales, el objetivo no es desplegar más rápido a cualquier costo, sino desplegar con trazabilidad y estabilidad.

Actualizaciones¶

Cada actualización es una nueva versión del sitio. La documentación oficial destaca que cada deploy crea una nueva release y que el historial queda visible desde la consola de Hosting.[cite:2] Esto permite tratar cada publicación como un evento auditable.

Rollback¶

La documentación sobre gestión de recursos explica que se puede volver a una versión previa del live channel desde la consola, creando una nueva release que sirve el mismo contenido que una release anterior.[cite:2] Esto es muy importante: un rollback no “borra la historia”; crea un nuevo evento que apunta a una versión previa conocida como estable.

Desde el punto de vista operativo, rollback existe para responder a incidentes. No sustituye las pruebas, pero reduce el tiempo de recuperación cuando una publicación rompe el sitio.

Versionado¶

En Hosting, versionado no significa necesariamente semver visible al usuario. Significa que el contenido y la configuración publicados quedan encapsulados en versiones internas con identificadores únicos.[cite:2] El equipo puede usar Git para versionado de código y Hosting para versionado de releases publicadas.

Publicaciones seguras¶

Una publicación segura implica varias capas:

build reproducible;
proyecto Firebase correcto;
configuración verificada;
rutas críticas probadas;
assets optimizados;
rollback disponible;
control de acceso al despliegue;
validación posterior inmediata.

Optimización¶

Minificación¶

Firebase Hosting distribuye lo que recibe. Si el frontend no está minificado antes del deploy, la CDN no convertirá automáticamente un build de desarrollo en uno de producción. Por eso el proceso de build debe generar JS, CSS y HTML optimizados según el framework utilizado.

Compresión¶

La documentación oficial indica que Hosting sirve el contenido usando gzip o Brotli, eligiendo automáticamente la mejor opción de compresión para el archivo solicitado.[cite:1] Esto mejora rendimiento, pero no elimina la necesidad de preparar adecuadamente los assets.

Caché¶

La guía oficial de caché explica que el contenido estático solicitado se almacena automáticamente en la CDN y que la limpieza del contenido cacheado ocurre automáticamente cuando se despliega una nueva versión, hasta la siguiente solicitud.[cite:4] Además, para contenido dinámico se pueden usar encabezados Cache-Control cuando sea apropiado.[cite:4]

Comprender este punto es esencial para producción. No todo debe cachearse del mismo modo. Los archivos con hash en nombre pueden tener políticas agresivas de caché. El HTML principal, en cambio, suele requerir estrategias más conservadoras para que las nuevas versiones se propaguen adecuadamente.

Headers¶

Firebase Hosting permite definir headers desde firebase.json. Esto es útil para seguridad, caché y control del comportamiento del navegador. Aunque la estrategia detallada depende de cada proyecto, conviene verlos como parte del despliegue y no como una optimización tardía.

Redirects¶

Los redirects sirven para redirigir una ruta a otra. Son útiles en migraciones, consolidación de URLs, mantenimiento de enlaces heredados o reestructuración del sitio. En producción ayudan a evitar roturas funcionales y SEO negativo cuando cambian rutas públicas.

Rewrites¶

Los rewrites cumplen otro papel: permiten reescribir una ruta sin cambiar la URL visible para el usuario. En SPAs, el rewrite más conocido es enviar todas las rutas al index.html. También se usan para conectar ciertas rutas con Functions o Cloud Run cuando la aplicación requiere backend dinámico.[cite:1]

Ejemplos paso a paso¶

Ejemplo 1: preparar y publicar una SPA del proyecto del libro¶

Supóngase que la plataforma educativa tiene un frontend React compilado en apps/web/dist.

Crear o revisar el build de producción.
Confirmar que firebase login y la selección del proyecto son correctos.
Ejecutar la inicialización si todavía no existe configuración:

firebase init hosting

Elegir el proyecto oficial del libro.
Establecer apps/web/dist como directorio público.
Responder que sí a la configuración de SPA.
Revisar firebase.json.
Ejecutar el build final.
Publicar:

firebase deploy --only hosting

Validar la URL publicada, login, navegación y carga de recursos.

Ejemplo 2: múltiples sitios con deploy targets¶

La documentación oficial explica que los deploy targets son identificadores cortos que se asignan a recursos Firebase como Hosting sites, y que luego se referencian desde firebase.json.[cite:3]

Supóngase que el proyecto tiene dos sitios de Hosting: uno para la app principal y otro para un portal institucional.

Asignación de targets:

firebase target:apply hosting app miapp-app
firebase target:apply hosting portal miapp-portal

Configuración:

{
  "hosting": [
    {
      "target": "app",
      "public": "apps/web/dist",
      "rewrites": [
        {
          "source": "**",
          "destination": "/index.html"
        }
      ]
    },
    {
      "target": "portal",
      "public": "apps/portal/dist"
    }
  ]
}

Despliegue solo del sitio principal:

firebase deploy --only hosting:app

Esto ilustra muy bien la diferencia entre escalar un proyecto y desordenarlo. Los targets permiten precisión operacional.

Ejemplo 3: rollback operativo¶

Supóngase que una nueva publicación rompe el enrutado de la plataforma educativa. El flujo profesional sería:

Detectar el incidente.
Ir al historial de releases del sitio.
Identificar la release previa conocida como estable.
Ejecutar rollback desde la consola, creando una nueva release que vuelve a apuntar a esa versión anterior.[cite:2]
Abrir incidente técnico y corregir el problema en el repositorio antes de un nuevo deploy.

La enseñanza clave aquí es cultural: rollback no debe ser visto como fracaso, sino como parte normal de una operación madura.

Casos reales¶

Sitio institucional¶

Un sitio institucional suele requerir despliegues previsibles, pocos cambios simultáneos y especial cuidado con rutas públicas. Firebase Hosting permite publicar versiones nuevas sin necesidad de administrar infraestructura web tradicional y, gracias al historial de releases, mantener trazabilidad clara.[cite:1][cite:2]

Panel administrativo¶

En un panel administrativo SPA, la configuración de rewrites y la validación de autenticación son críticas. El equipo debe comprobar que la aplicación publicada respete navegación interna, control de acceso y consumo de Firestore o Storage según lo esperado.

Plataforma educativa¶

Este es el caso central del libro. La plataforma educativa crecerá con módulos, dashboards, expedientes, credenciales y contenidos multimedia. Su despliegue profesional exige:

build reproducible;
configuración clara de SPA;
separación por ambientes;
posibilidad de rollback;
validación después de cada publicación;
organización pensada para futuras actualizaciones.

Firebase Hosting encaja muy bien porque concentra la publicación del frontend en un flujo declarativo y repetible, dejando a Firestore, Authentication, Storage y Functions como servicios complementarios del backend de la aplicación.[cite:1]

SPA¶

Las SPA son uno de los escenarios más naturales para Hosting, precisamente porque la plataforma está optimizada para este tipo de aplicaciones.[cite:1] Pero esa afinidad no elimina la necesidad de una configuración correcta de rewrites y una estrategia cuidadosa de actualización.

Flutter Web¶

Flutter Web genera un conjunto de archivos que pueden distribuirse como frontend compilado. En este caso, Firebase Hosting resuelve bien la entrega global del sitio, siempre que el equipo entienda que el despliegue debe hacerse sobre la salida de producción y no sobre archivos fuente del proyecto.

Buenas prácticas¶

Mantener firebase.json pequeño, claro y versionado.
Separar configuración de SPA, redirects y headers con intención explícita.
Usar .firebaserc con aliases bien nombrados para evitar confusiones entre ambientes.
Ejecutar siempre el build de producción antes de desplegar.
Automatizar comandos repetitivos con scripts.
Desplegar únicamente los recursos necesarios cuando sea posible.[cite:3]
Revisar historial de releases con regularidad para entender la evolución del sitio.[cite:2]
Preparar procedimientos de rollback antes del incidente, no durante el incidente.
Tratar el despliegue como parte del diseño del sistema y no como una tarea administrativa secundaria.

Errores comunes¶

Publicar el directorio equivocado.
Desplegar una SPA sin rewrites hacia index.html.
Ejecutar firebase deploy sin confirmar qué recursos serán afectados.
Apuntar al proyecto Firebase incorrecto por una mala configuración de .firebaserc.
No validar la publicación inmediatamente después del deploy.
Depender de despliegues manuales poco repetibles.
Asumir que la compresión o el caché corregirán builds mal optimizados.[cite:1][cite:4]
Pensar que rollback reemplaza una estrategia de calidad.
No mantener trazabilidad entre commit publicado y release activa.

Resumen¶

Desplegar profesionalmente con Firebase Hosting significa mucho más que ejecutar firebase deploy. Significa preparar un build reproducible, declarar con precisión cómo debe publicarse el frontend, asociarlo al proyecto correcto y convertir la publicación en una operación segura, repetible y trazable.[cite:1][cite:3]

La documentación oficial muestra que Hosting trabaja con una jerarquía clara de sitios, canales, versiones y releases. Cada despliegue crea una nueva versión del contenido y una nueva release asociada al canal correspondiente, lo que permite historial visible, rollback y clonación entre canales cuando la estrategia del proyecto lo requiere.[cite:2]

firebase.json y .firebaserc son piezas centrales de este proceso. El primero define el comportamiento declarativo del despliegue; el segundo fija la relación entre el proyecto local, los proyectos Firebase y los posibles targets. Esta separación permite trabajar con orden, soportar múltiples ambientes y reducir errores humanos.[cite:3]

Para aplicaciones modernas, especialmente SPAs, el despliegue requiere atención adicional a rewrites, optimización del build, caché y validación posterior. Firebase Hosting aporta compresión automática, CDN global, historial de releases y una integración natural con el resto del ecosistema Firebase, pero el criterio arquitectónico sigue siendo responsabilidad del equipo.[cite:1][cite:4]

En el proyecto transversal del libro, este capítulo marca un punto decisivo: la plataforma educativa deja de ser solo un sistema construido en desarrollo y se convierte en una aplicación lista para ser publicada, actualizada y mantenida con prácticas reales de producción.

Conceptos clave¶

Despliegue.
Build de producción.
firebase init hosting.[cite:1][cite:3]
Directorio público.
firebase.json.[cite:3]
.firebaserc.[cite:3]
firebase deploy.[cite:1]
Deploy parcial.[cite:3]
Deploy completo.[cite:3]
Deploy targets.[cite:3]
Site, channel, version y release.[cite:2]
Rollback.[cite:2]
Rewrites.[cite:1]
Redirects.
Headers.
Caché CDN.[cite:4]
Compresión Brotli y gzip.[cite:1]

Preguntas de repaso¶

¿Qué significa desplegar una aplicación en un contexto profesional?
¿Qué diferencia hay entre publicar archivos manualmente y publicar un snapshot versionado en Firebase Hosting?[cite:1][cite:2]
¿Qué papel cumple firebase.json dentro del proceso de despliegue?[cite:3]
¿Para qué sirve .firebaserc y por qué es tan importante cuando existen varios ambientes?[cite:3]
¿Qué diferencia existe entre firebase deploy, firebase deploy --only hosting y firebase deploy --only hosting:TARGET_NAME?[cite:1][cite:3]
¿Por qué una SPA necesita normalmente una regla de rewrite hacia index.html?
¿Qué ocurre internamente en Firebase Hosting cuando se realiza un deploy exitoso?[cite:2]
¿Qué relación existe entre version, release y live channel?[cite:2]
¿Por qué rollback no debe considerarse un fracaso sino una práctica de operación madura?[cite:2]
¿Qué validaciones mínimas deben realizarse después de una publicación?

Ejercicios prácticos¶

Diseña la estructura de despliegue del proyecto educativo del libro indicando qué carpeta debería ser el directorio público y por qué.
Escribe una propuesta de firebase.json para una SPA del proyecto con directorio apps/web/dist y rewrite general hacia index.html.
Explica con tus palabras qué ocurriría si se publica una SPA sin rewrites adecuadas.
Diseña un flujo de publicación profesional que incluya build, validación, deploy y verificación posterior.
Propón una convención de aliases en .firebaserc para dev, staging y prod.
Imagina que el proyecto tiene dos sitios de Hosting. Describe cómo usarías deploy targets para publicarlos por separado.[cite:3]
Construye un checklist de validación posterior al deploy para la plataforma educativa.
Describe un procedimiento de respuesta ante incidente usando rollback y corrección posterior en Git.[cite:2]
Explica cuándo conviene un deploy parcial y cuándo un deploy completo.[cite:3]
Analiza qué riesgos operativos se reducen al automatizar el despliegue con scripts npm.

Bibliografía y referencias oficiales¶

Firebase Hosting: https://firebase.google.com/docs/hosting [cite:1]
Manage live & preview channels, releases, and versions for your site: https://firebase.google.com/docs/hosting/manage-hosting-resources [cite:2]
Deploy targets: https://firebase.google.com/docs/cli/targets [cite:3]
Manage cache behavior | Firebase Hosting: https://firebase.google.com/docs/hosting/manage-cache [cite:4]