Capítulo 24 — Dominios personalizados, Preview Channels y despliegues avanzados en Firebase Hosting¶

Recursos visuales propuestos¶

Antes de desarrollar este capítulo conviene distinguir qué recursos ayudan a comprender el flujo operativo y cuáles deben reservarse para relaciones técnicas más complejas. El proceso de conexión de un dominio, el flujo de Preview Channels, la comparación entre producción y pruebas, el ejemplo de historial de versiones y el flujo de rollback se entienden mejor como imágenes didácticas, porque permiten visualizar tareas concretas y recorridos operativos cotidianos. En cambio, la arquitectura del proceso de despliegue profesional, el flujo Development → Preview → Production, la relación entre Firebase Hosting, DNS y SSL, y la arquitectura de versionado deben resolverse como diagramas SVG, ya que representan dependencias entre capas, objetos de infraestructura y secuencias técnicas con múltiples actores.[cite:1][cite:2]

Imágenes didácticas¶

Proceso de conexión de un dominio. Conviene como imagen didáctica porque ayuda a explicar el asistente paso a paso y los cambios DNS principales.
Flujo de Preview Channels. Debe ser imagen didáctica porque resume cómo un cambio pasa de desarrollo a URL compartible sin afectar producción.[cite:2]
Comparación entre producción y pruebas. Es mejor como imagen didáctica porque permite mostrar diferencias de uso y objetivo sin añadir complejidad estructural innecesaria.
Ejemplo de historial de versiones. Conviene como imagen didáctica porque ayuda al lector a relacionar releases y versiones con una vista operativa real.[cite:2]
Flujo de rollback. Debe ser imagen didáctica porque muestra una acción de recuperación concreta que el lector debe poder imaginar con facilidad.[cite:2]

Diagramas SVG¶

Arquitectura del proceso de despliegue profesional. Debe resolverse como SVG porque combina repositorio, CLI, preview channels, live channel, versiones y releases.[cite:2]
Flujo Development → Preview → Production. Conviene SVG porque requiere representar promoción de cambios y separación de ambientes.[cite:2]
Relación entre Firebase Hosting, DNS y SSL. Debe ser SVG porque explica verificación de dominio, registros DNS, aprovisionamiento de certificados y entrega segura.[cite:1]
Arquitectura de versionado. Debe ser SVG porque necesita mostrar la jerarquía site → channel → version → release y sus implicaciones de rollback y clonación.[cite:2]

Objetivos de aprendizaje¶

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

Comprender qué es un dominio personalizado y por qué aporta valor profesional frente al subdominio generado por Firebase.
Configurar dominios personalizados en Firebase Hosting entendiendo verificación, DNS, SSL y problemas frecuentes.[cite:1]
Explicar qué son los Preview Channels, para qué sirven y cómo mejoran la productividad y seguridad del flujo de publicación.[cite:2]
Administrar versiones, releases, historial y rollback con criterio operativo profesional.[cite:2]
Diseñar un flujo de trabajo Development → Testing/Preview → Staging → Production usando Firebase Hosting y Firebase CLI.
Aplicar estas prácticas al proyecto transversal del libro para minimizar riesgo en futuras actualizaciones.

Introducción¶

En los capítulos anteriores se estudió cómo funciona Firebase Hosting y cómo publicar una aplicación web en producción. Sin embargo, en un proyecto real eso no es suficiente. Publicar una app una sola vez es fácil; mantenerla viva, actualizable y estable mientras el equipo continúa desarrollando nuevas funciones es el verdadero reto profesional.

Aquí es donde entran tres capacidades clave de Firebase Hosting. La primera es el uso de dominios personalizados, que permiten que la aplicación deje de vivir únicamente bajo *.web.app o *.firebaseapp.com y pase a operar con una identidad propia de marca y negocio.[cite:1][cite:2] La segunda es el uso de Preview Channels, que ofrecen URLs temporales y compartibles para probar cambios antes de enviarlos a producción.[cite:2] La tercera es el manejo explícito de versiones, releases e historial, que convierte el despliegue en una operación trazable y reversible.[cite:2]

Estas tres piezas transforman Hosting de una herramienta cómoda de despliegue a una plataforma profesional de publicación. En equipos pequeños aportan orden y reducción de errores. En equipos medianos o grandes se vuelven fundamentales para coordinar revisiones, QA, validación con usuarios y salidas a producción con riesgo controlado.

Este capítulo se centra precisamente en ese salto de madurez. No se trata solo de aprender comandos, sino de entender qué ocurre internamente cuando un dominio se conecta, qué representa exactamente un preview channel, cómo se organiza el historial de versiones y cómo recuperar un estado estable sin interrumpir innecesariamente a los usuarios. El objetivo es preparar al lector para una operación profesional del proyecto oficial del libro y sentar la base para la futura integración con infraestructura más avanzada.

Desarrollo completo¶

Dominios personalizados¶

¿Qué es un dominio personalizado?¶

Un dominio personalizado es el nombre de dominio propio de una organización, producto o aplicación, conectado a un sitio de Firebase Hosting. En vez de servir la app únicamente desde el subdominio provisionado por Firebase, como miapp.web.app, el equipo puede publicarla bajo un dominio como plataformaeducativa.com o un subdominio como app.plataformaeducativa.com.[cite:1][cite:2]

Desde el punto de vista técnico, esto implica enlazar el dominio con el sitio de Hosting correcto, verificar su propiedad, actualizar registros DNS y permitir que Firebase aprovisione el certificado SSL correspondiente.[cite:1]

Ventajas frente al dominio `*.web.app`¶

El subdominio generado por Firebase es excelente para comenzar. Pero en producción, un dominio personalizado ofrece ventajas claras:

refuerza marca y credibilidad;
facilita recordación por parte de usuarios;
mejora percepción profesional ante clientes, instituciones y socios;
permite organizar subdominios por producto, entorno o función;
da más control sobre estrategia digital y continuidad tecnológica.

Además, en proyectos empresariales el dominio forma parte de la arquitectura del producto, no solo de su presentación. Un mismo proyecto puede necesitar separar app.empresa.com, admin.empresa.com, docs.empresa.com o staging.empresa.com según su estructura de despliegue.

Configuración paso a paso¶

La guía oficial de soporte de Firebase describe el flujo de conexión de dominio desde la página de Hosting del proyecto. Primero se abre el asistente Connect domain, luego se introduce el dominio deseado, se inicia la validación y, si es necesario, se completa la verificación de propiedad siguiendo las instrucciones mostradas por Firebase.[cite:1]

Después, el asistente ofrece normalmente dos modos:

Quick Setup, orientado al caso más común, donde se apuntan los registros DNS del dominio a Firebase Hosting.
Advanced Setup, pensado para migraciones sin downtime o escenarios donde el dominio ya está activo en otro proveedor y se requiere una transición más controlada.[cite:1]

Esta distinción es importante. Quick Setup simplifica y acelera. Advanced Setup existe para reducir riesgo en operaciones más delicadas.

Registros DNS¶

Los registros DNS son las entradas que le indican a Internet hacia dónde debe apuntar un dominio. En la configuración de Hosting, Firebase guía al usuario para agregar o modificar los registros requeridos en el proveedor DNS del dominio.

La guía oficial explica que, en Quick Setup, el dominio debe apuntarse a Firebase Hosting mediante registros A. En algunos casos también habrá pasos de verificación de propiedad mediante TXT o mediante comprobación sobre un sitio existente si se utiliza Advanced Setup.[cite:1]

Esto tiene una implicación operativa importante: Firebase Hosting no controla tu registrador de dominios ni tu panel DNS. El trabajo real ocurre en dos sistemas separados:

Firebase Hosting indica qué necesita.
El proveedor DNS ejecuta esos cambios.

Por eso muchos problemas de conexión no son de Firebase en sí, sino de registros mal configurados, conflictos con otras A records o propagación DNS incompleta.

Verificación del dominio¶

Firebase no conecta un dominio solo porque alguien lo escribió en un asistente. La guía oficial aclara que el proceso de validación existe para asegurar dos cosas: que el dominio no esté ya vinculado a otro proyecto Firebase y que quien intenta conectarlo sea realmente su propietario.[cite:1]

Este paso es esencial desde el punto de vista de seguridad. Si la plataforma no comprobara propiedad, sería posible secuestrar o interferir dominios ajenos. La verificación es, por tanto, una medida de protección tanto para el propietario del dominio como para el ecosistema de Hosting.

Certificados SSL automáticos¶

Una vez que el dominio apunta correctamente a Firebase Hosting, Firebase aprovisiona el certificado SSL para ese dominio. La guía oficial indica que esto ocurre dentro de las 24 horas posteriores a que los registros A se hayan apuntado a Hosting.[cite:1]

Aquí conviene desmontar una idea común. El certificado no es un accesorio adicional. Es un requisito crítico para operar una aplicación moderna de forma segura. HTTPS protege la integridad de la sesión, evita interceptaciones triviales, inspira confianza en el navegador y es prácticamente obligatorio para muchas capacidades web actuales.

Renovación automática¶

La documentación de soporte también deja claro que Firebase necesita mantener la evidencia de propiedad del dominio para poder asignar y renovar certificados SSL según corresponda. Esto forma parte del valor operativo del servicio: el equipo no tiene que gestionar manualmente vencimientos ni renovaciones periódicas como ocurría históricamente con otras soluciones.

En términos prácticos, la renovación automática reduce una fuente clásica de incidentes en producción: sitios que dejan de ser confiables porque alguien olvidó renovar un certificado o porque el proceso manual falló.

Problemas frecuentes¶

Los errores más comunes al conectar dominios personalizados suelen ser:

registros A o CNAME que todavía apuntan a otro proveedor;
TXT de verificación ausente o incorrecto;
propagación DNS todavía incompleta;
intento de conectar un dominio que ya está vinculado a otro proyecto;
confusión entre dominio raíz y subdominio;
esperar que el SSL aparezca instantáneamente cuando aún no se han estabilizado los registros.

La guía oficial advierte explícitamente que si el dominio conserva A records o CNAMEs que apuntan a otros proveedores, Firebase no puede aprovisionar el certificado SSL.[cite:1] Este es uno de los errores más frecuentes en migraciones parciales o configuraciones hechas a medias.

Preview Channels¶

¿Qué son los Preview Channels?¶

La documentación oficial de Hosting explica que cada sitio puede tener un canal live y canales preview. El canal live sirve el contenido en los subdominios provisionados por Firebase y en cualquier dominio personalizado conectado. Los preview channels, en cambio, sirven su propio contenido y configuración en URLs temporales y compartibles del tipo SITE_ID--CHANNEL_ID-RANDOM_HASH.web.app.[cite:2]

Esto significa que un preview channel no es una simple “vista previa visual”. Es un canal real de Hosting con su propia URL, su propio contenido desplegado y su propia configuración asociada.

¿Para qué sirven?¶

Sirven para probar cambios antes de enviarlos a producción. En un flujo profesional, un preview channel permite:

revisar una nueva funcionalidad sin afectar usuarios reales;
compartir una versión con QA, diseño, negocio o cliente;
validar correcciones de bugs en una URL pública aislada;
comprobar configuración de rewrites, headers o assets;
promover exactamente la versión probada hacia producción mediante clonación.[cite:2]

La utilidad más importante es organizativa: desacoplar revisión y publicación. El equipo deja de depender del entorno local de cada desarrollador para enseñar cambios.

Flujo de trabajo profesional¶

Un flujo maduro basado en Preview Channels puede verse así:

El desarrollador implementa el cambio.
Genera un build estable.
Publica ese build en un preview channel.
Comparte la URL temporal con revisores.
QA valida comportamiento funcional.
Si el resultado es correcto, se decide promover la versión.
La misma versión puede clonarse al canal live o servir de referencia para el deploy final.[cite:2]

Este modelo mejora productividad porque centraliza la revisión y reduce fricción entre desarrollo y validación.

Creación de un Preview Channel¶

La documentación oficial lista el comando:

firebase hosting:channel:create CHANNEL_ID

Este comando crea un preview channel en el sitio de Hosting por defecto usando el identificador especificado, pero no despliega contenido todavía.[cite:2]

En la práctica, muchas veces se usa directamente el comando de deploy al canal, que crea el canal si todavía no existe.

Publicación temporal¶

El comando principal es:

firebase hosting:channel:deploy CHANNEL_ID

La guía oficial explica que este comando despliega el contenido y configuración de Hosting al preview channel especificado, y que si el canal no existe aún, lo crea antes de desplegarlo.[cite:2]

Este detalle es muy útil porque convierte los preview channels en objetos ligeros y operativos. No hace falta una preparación compleja previa para cada prueba.

Duración¶

La documentación oficial indica que, por defecto, un preview channel expira 7 días después de su creación. También explica que puede configurarse una expiración específica mediante el flag --expires, con formatos como 12h, 7d o 2w, hasta un máximo de 30 días desde el despliegue.[cite:2]

Ejemplo:

firebase hosting:channel:deploy nueva-funcion --expires 7d

Esto es importante porque evita que el proyecto se llene indefinidamente de entornos temporales olvidados. La expiración automática no es un detalle menor; es una medida de higiene operativa.

Compartir versiones¶

Como cada preview channel tiene su propia URL pública, compartir una versión se vuelve extremadamente sencillo. La documentación oficial incluso incluye el comando:

firebase hosting:channel:open CHANNEL_ID

que abre el canal en el navegador o devuelve la URL correspondiente si no puede abrirlo.[cite:2]

Esto facilita revisiones distribuidas. Diseño puede revisar interfaz, QA puede probar flujos, negocio puede validar lenguaje y stakeholders externos pueden aprobar sin necesidad de instalar nada localmente.

Eliminación de canales¶

Firebase permite eliminar manualmente preview channels desde la consola o con CLI:

firebase hosting:channel:delete CHANNEL_ID

La documentación precisa que no se puede eliminar el canal live, pero sí los preview channels. Cuando se borra uno, el canal, sus releases y sus versiones asociadas se programan para eliminación dentro de 24 horas, salvo que alguna versión esté referenciada por otra release.[cite:2]

Esto tiene una implicación muy útil: el sistema evita borrar prematuramente una versión que sigue siendo relevante en otro canal.

Versionado¶

Versiones de Hosting¶

La documentación oficial define una version como el paquete de contenido y configuración servido por un canal, con un identificador único.[cite:2] Este concepto es central porque permite pensar el despliegue como un objeto concreto y no como un estado indefinido del servidor.

Releases¶

Una release es el evento que hace que un canal apunte a una versión específica. También contiene metadatos de despliegue como quién desplegó y cuándo lo hizo.[cite:2]

La diferencia entre version y release es muy importante:

la version es el contenido y configuración empaquetados;
la release es la publicación de esa version en un canal determinado.

Historial¶

Firebase muestra el historial completo de releases del live channel y también informa los preview channels disponibles desde el dashboard de Hosting.[cite:2] Este historial aporta trazabilidad operativa. El equipo puede saber qué se publicó, cuándo, por quién y con qué identificador de versión.

Rollback¶

La guía oficial explica que rollback crea una nueva release que sirve el mismo contenido que una release anterior del live channel.[cite:2] No se “deshace” el tiempo; se crea una nueva publicación que vuelve a apuntar a una versión previa conocida como estable.

Este detalle es extremadamente importante para la operación profesional. Un rollback bien entendido es una herramienta de continuidad, no un acto de improvisación.

Recuperación de versiones¶

Además del rollback directo, Firebase permite clonar una versión desde un canal a otro. La documentación oficial presenta el comando firebase hosting:clone para clonar la versión más reciente de un canal origen hacia un canal destino, incluso entre sitios o proyectos distintos.[cite:2]

Ejemplo conceptual:

firebase hosting:clone sitio-app:qa sitio-app:live

Esto habilita una estrategia muy poderosa: promocionar exactamente la versión validada en QA o preview a producción, evitando discrepancias entre “lo probado” y “lo finalmente publicado”.

Equipos de desarrollo¶

Flujo Development¶

En desarrollo, el objetivo es iterar rápido. Los cambios todavía son inestables y no deben tocar producción. En este punto, el equipo trabaja localmente o sobre ambientes efímeros de preview según necesidad.

Flujo Testing¶

En testing, el objetivo es validar funcionalidad, UI, accesibilidad y comportamiento real. Aquí los preview channels son especialmente valiosos porque ofrecen una URL pública verificable sin mezclar el trabajo en curso con el canal live.[cite:2]

Flujo Staging¶

Aunque Firebase Hosting no obliga a usar el término staging, muchos equipos lo implementan como un sitio, proyecto o canal intermedio para validaciones más cercanas a producción. La ventaja es separar claramente pruebas internas rápidas de una preproducción con mayor control.

Producción¶

Producción corresponde al canal live, que sirve contenido a los subdominios provisionados y a los dominios personalizados conectados.[cite:2] Todo cambio en este canal debe tratarse como una operación con impacto real en usuarios.

Buenas prácticas para equipos¶

Separar claramente desarrollo, validación y producción.
Nombrar preview channels con convenciones consistentes.
Definir responsables de publicación a producción.
Mantener trazabilidad entre commits, tickets y releases.
Usar dominios o subdominios diferenciados cuando el flujo lo requiera.
Evitar validaciones informales sobre entornos locales no reproducibles.
Promover versiones probadas, no reconstrucciones improvisadas.

Integración¶

GitHub¶

La documentación oficial y el ecosistema de Firebase permiten integrar flujos de publicación con GitHub, especialmente para crear previews automáticos asociados a Pull Requests. Aunque el CI/CD completo se profundizará más adelante, aquí importa entender que Preview Channels son una pieza natural del workflow moderno de revisión colaborativa.[cite:2]

Firebase CLI¶

La CLI es el centro operativo de esta arquitectura. Desde ella se crean canales, se despliegan previews, se listan canales, se abren URLs, se eliminan canales y se clonan versiones.[cite:2] Esto convierte a Firebase CLI en una herramienta de operación, no solo de despliegue inicial.

CI/CD (introducción)¶

Desde una perspectiva de integración continua y entrega continua, Preview Channels funcionan como entornos efímeros de validación. Permiten que cada cambio relevante tenga un espacio visible y comprobable antes de mezclarse con la experiencia de producción.

Automatización¶

Automatizar no significa quitar control, sino reducir tareas repetitivas y errores manuales. En este contexto, automatizar puede implicar:

crear previews por rama o PR;
establecer expiraciones coherentes;
clonar a live únicamente versiones aprobadas;
documentar el flujo de publicación mediante scripts;
centralizar revisiones en URLs reproducibles.

Ejemplos paso a paso¶

Ejemplo 1: conectar el dominio oficial de la plataforma educativa¶

Supóngase que el proyecto del libro utilizará el dominio plataformaeducativa.com.

Entrar en Hosting dentro del proyecto.
Elegir Connect domain para el sitio correspondiente.[cite:1]
Escribir plataformaeducativa.com.
Iniciar el proceso de validación.
Seguir las instrucciones para verificar propiedad si Firebase lo solicita.[cite:1]
Elegir Quick Setup salvo que se necesite migración sin downtime.
Ir al proveedor DNS y crear o modificar los registros indicados.
Esperar propagación.
Verificar que Firebase complete el aprovisionamiento de SSL dentro del plazo esperado.[cite:1]
Probar que el dominio carga correctamente por HTTPS.

Ejemplo 2: publicar una nueva funcionalidad en un Preview Channel¶

Supóngase que se agregó el módulo de credenciales digitales a la plataforma educativa.

Construir el frontend estable localmente.
Publicar el cambio en un canal efímero:

firebase hosting:channel:deploy credenciales-digitales --expires 7d

Obtener la URL del canal.
Compartirla con QA y con los responsables académicos.
Recoger observaciones.
Corregir si hace falta y volver a desplegar al mismo canal.
Una vez aprobado, decidir cómo promover esa versión.

Este flujo minimiza riesgo porque la nueva función se valida en un entorno real sin tocar el canal live.

Ejemplo 3: rollback ante un incidente¶

Supóngase que una actualización del panel administrativo rompe el acceso a expedientes.

Detectar el incidente.
Revisar el historial de releases del live channel.[cite:2]
Identificar la última release estable.
Ejecutar rollback desde la consola de Hosting, creando una nueva release que apunta a esa versión previa.[cite:2]
Confirmar recuperación funcional.
Corregir en desarrollo y volver a pasar por preview antes de intentar una nueva publicación.

Ejemplo 4: promover exactamente la versión validada¶

Supóngase que el canal qa-credenciales fue probado y aprobado. En vez de reconstruir localmente y arriesgar diferencias, el equipo puede clonar la versión validada hacia el canal live:

firebase hosting:clone sitio-educativo:qa-credenciales sitio-educativo:live

La documentación oficial explica que este comando despliega al canal destino y que, si la clonación ocurre dentro del mismo sitio, ambas releases pueden apuntar a la misma versión exacta.[cite:2] Esta es una de las prácticas más profesionales que ofrece Hosting.

Casos reales¶

Publicación de nuevas funciones¶

Cuando se lanza una nueva función importante, como un módulo de certificados o un tablero académico, los Preview Channels permiten mostrar el cambio a negocio y QA con una URL aislada. El equipo gana velocidad de revisión sin sacrificar la estabilidad del sitio productivo.[cite:2]

Corrección de errores¶

Para un bug puntual, los previews también son valiosos. Permiten demostrar que el error quedó corregido en un entorno accesible, sin necesidad de mezclar la solución con otros cambios todavía no listos.

Validación con usuarios¶

En proyectos reales, muchas validaciones no las hace solo el equipo técnico. A veces se necesita que usuarios finales piloto, directivos o responsables del proceso revisen el cambio. Un preview channel funciona muy bien como versión compartible para ese tipo de validación controlada.

Actualizaciones sin afectar producción¶

Este es quizá el mayor valor estratégico del capítulo. Gracias a la separación entre live y preview, el equipo puede mantener una operación continua de mejora sin convertir cada revisión en un riesgo directo para usuarios finales.[cite:2]

Buenas prácticas¶

Usar dominios personalizados en producción para reforzar identidad y profesionalismo.
Mantener DNS ordenado y documentado.
No mezclar cambios DNS improvisados con publicaciones urgentes.
Crear convenciones claras para nombres de preview channels.
Definir expiraciones coherentes según el ciclo de trabajo.[cite:2]
Revisar el historial de releases con frecuencia.
Conservar suficientes releases anteriores para rollback, pero sin crecer sin control en almacenamiento.[cite:2]
Promover exactamente las versiones ya probadas cuando el riesgo sea alto.[cite:2]
Tratar el live channel como entorno crítico.
Documentar procedimientos de rollback antes de necesitarlos.

Errores comunes¶

Conectar un dominio sin verificar si ya apunta a otro proveedor.
Olvidar registros necesarios y asumir que el problema está en Firebase.
Confundir dominio raíz con subdominio.
Esperar que el SSL se active instantáneamente sin dejar tiempo a DNS y aprovisionamiento.[cite:1]
Usar preview channels como sustituto permanente de ambientes bien gobernados.
Dejar previews huérfanos sin expiración o sin limpieza.
Publicar a live una reconstrucción diferente de la que fue validada.
No entender la diferencia entre version y release.[cite:2]
Hacer rollback sin analizar el incidente original.

Resumen¶

Los dominios personalizados, los Preview Channels y la administración de versiones convierten Firebase Hosting en una plataforma de despliegue realmente profesional. Conectar un dominio propio permite que la aplicación opere con identidad de marca, mientras que Firebase se encarga de validar propiedad, aprovisionar SSL y mantener la entrega segura una vez que los registros DNS apuntan correctamente al servicio.[cite:1]

Los Preview Channels aportan una capacidad decisiva para el trabajo en equipo. Cada sitio puede tener un canal live y múltiples preview channels, cada uno con su propia URL temporal, su contenido y su configuración. Esto permite revisar cambios, compartir versiones y validar funcionalidades antes de tocar producción, reduciendo riesgo y mejorando productividad.[cite:2]

El modelo interno de site, channel, version y release aporta trazabilidad real. Cada despliegue genera objetos administrables que hacen posible mantener historial, limitar releases retenidas, clonar exactamente una versión probada hacia otro canal y ejecutar rollback creando una nueva release que vuelve a apuntar a una versión estable anterior.[cite:2]

Aplicado al proyecto transversal del libro, este enfoque permite operar la plataforma educativa con una estrategia madura: dominio propio para producción, previews para nuevas funciones, historial claro para auditoría y rollback preparado para incidentes. El resultado es un sistema más seguro, más controlable y mucho más apto para equipos reales.

Conceptos clave¶

Dominio personalizado.[cite:1]
Verificación de dominio.[cite:1]
Registros DNS.[cite:1]
SSL automático.[cite:1]
Renovación automática.
Live channel.[cite:2]
Preview channel.[cite:2]
URL temporal compartible.[cite:2]
Version.[cite:2]
Release.[cite:2]
Release history.[cite:2]
Rollback.[cite:2]
Clonación de versiones.[cite:2]
firebase hosting:channel:deploy.[cite:2]
firebase hosting:channel:list.[cite:2]
firebase hosting:channel:delete.[cite:2]
firebase hosting:clone.[cite:2]

Preguntas de repaso¶

¿Qué es un dominio personalizado y por qué suele ser preferible al subdominio *.web.app en producción?[cite:1]
¿Qué función cumplen los registros DNS en la conexión de un dominio con Firebase Hosting?[cite:1]
¿Por qué Firebase verifica la propiedad del dominio antes de conectarlo?[cite:1]
¿Qué son los Preview Channels y qué problema resuelven dentro del flujo de publicación profesional?[cite:2]
¿Qué diferencia existe entre el canal live y un preview channel?[cite:2]
¿Cuál es la diferencia entre version y release en Firebase Hosting?[cite:2]
¿Qué ocurre cuando un preview channel expira?[cite:2]
¿Cómo puede un equipo promover exactamente la versión ya validada hacia producción?[cite:2]
¿Qué papel cumple rollback en una estrategia madura de operación?[cite:2]
¿Cómo aplicarías estas capacidades al proyecto educativo del libro para reducir riesgo en futuras actualizaciones?

Ejercicios prácticos¶

Diseña un plan de conexión para el dominio principal y un subdominio del proyecto del libro, indicando qué objetivo cumpliría cada uno.
Redacta un procedimiento operativo para conectar un dominio personalizado en Firebase Hosting sin omitir verificación, DNS ni validación HTTPS.[cite:1]
Propón una convención de nombres para preview channels basada en tipo de cambio, rama o ticket.
Diseña un flujo Development → Preview → Production para la plataforma educativa utilizando únicamente Firebase Hosting y Firebase CLI.
Explica con tus palabras qué ventajas ofrece un preview channel frente a compartir builds locales o capturas de pantalla.
Simula un incidente en producción y describe paso a paso cómo ejecutarías el análisis y el rollback.[cite:2]
Diseña una política de retención de releases para el sitio live y para preview channels, justificando costo y capacidad de recuperación.[cite:2]
Explica cuándo tendría sentido clonar una versión en vez de volver a construirla localmente.[cite:2]
Escribe un checklist de validación antes de promover una versión desde preview a live.
Propón cómo usarías estas capacidades para lanzar sin riesgo el módulo de credenciales digitales del proyecto transversal.

Bibliografía y referencias oficiales¶

Connect a custom domain: https://support.google.com/firebase/answer/9137747 [cite:1]
Manage live & preview channels, releases, and versions for your site: https://firebase.google.com/docs/hosting/manage-hosting-resources [cite:2]