Versiones y publicación

Construir y servir son dos cosas distintas, y la plataforma las separa con dos piezas: las versiones (ramas de la app, cada una con su diseño y sus datos) y la publicación (qué dirección sirve qué versión).

La regla que lo resume todo: cada host sirve UNA versión de esta app. Publicar no es «poner en marcha» — es elegir qué versión sirve una dirección.

#Las versiones de una app

Una versión es una rama completa de la aplicación: las pantallas, el modelo, las APIs, los scripts, los workflows, los informes y los datos. Dos versiones no comparten nada — tocar una no toca la otra.

El menú de las versiones está en la cabecera del árbol de la app, junto al botón de ajustes. Lo que muestra es tu versión de trabajo:

Elemento	Qué hace
La lista de versiones	Hacer clic en una fila cambia tu versión de trabajo a ella. La marca señala la actual.
⟲ (en cada fila)	Abre el historial de esa versión — qué cambió, cuándo y por quién.
🗑 (en cada fila)	Borra la versión.
Nueva versión…	Crea una rama.
Merge selectivo…	Trae cambios elegidos de una versión a otra.

En una app que nunca tuvo versiones, el menú dice «Esta app aún no tiene historial.».

#Crear una versión

1. Abre el menú de las versiones y haz clic en Nueva versión….
2. Rellena el Nombre (por ejemplo 1.1) y elige A partir de — la versión de origen.
3. Haz clic en Crear versión.

«Crea una rama a partir de la versión de origen, con los datos copiados. La versión nueva no la sirve ningún host hasta que se asocie a uno.»

Dos consecuencias que vale la pena retener:

• Los datos se copian, no se comparten. La 1.1 nace con una copia de lo que la main tenía en ese instante; a partir de ahí, siguen vidas separadas.
• Nadie la ve, hasta que publiques una dirección que le apunte. Puedes trabajar meses en una versión sin que ningún usuario se entere.

En cuanto la versión se crea, pasas a trabajar en ella («Versión "1.1" creada — estás trabajando en ella.»).

#Borrar una versión

El 🗑 de una fila borra «el diseño, la base de datos y el historial de esta versión. Las otras versiones no se tocan». Dos protecciones:

• la versión main no se borra;
• la versión en la que estás trabajando tampoco — «cambia a otra antes de borrarla».

#Publicar

La publicación vive en Ajustes de la app → General, en la sección Publicación.

Cada fila es una dirección publicada: el host, la versión que sirve, y la ✕ para Despublicar.

Para publicar una dirección nueva:

1. Escribe el host en el campo (el ejemplo dice ej: mapas.empresa.com) — solo el nombre, sin https:// ni rutas.
2. Elige la versión que pasa a servir.
3. Haz clic en Publicar.

Confirmado, aparece «Host publicado.» y la fila nueva se suma a la lista.

#Antes de que haya dirección alguna

«Sin hosts publicados — la app responde en /app/{slug} con la versión de trabajo.» Es la dirección interna de siempre, y así es como se prueba una app antes de darle nombre propio.

Fíjate en la diferencia: en /app/{slug} corre la versión de trabajo de quien está viendo; en un host publicado corre la versión que el host sirve, para todo el mundo. Por eso, en producción, se publica siempre un host — para que lo que los usuarios ven no dependa de en qué rama está trabajando alguien.

#Despublicar

La ✕ de la fila (Despublicar) quita la dirección. La versión no se toca — simplemente deja de servirse ahí.

Para cambiar de versión en una dirección ya publicada, despublica y publica otra vez con la versión nueva. Es la operación de «poner la 1.1 en producción», y lleva segundos.

#La app corriendo

Una dirección publicada sirve la aplicación construida. Quien llega ahí no ve la plataforma: ve la pantalla de entrada de la app, con su tema.

A partir de ahí, lo que cada persona puede hacer depende de la cuenta con la que entra y de sus roles — materia de la página Usuarios de la app. Las pantallas de entrada, registro y recuperación son diseñables, y tienen página propia: Pantallas públicas y registro.

#Un flujo de trabajo saludable

Una forma común de organizar esto en un equipo:

1. main es la versión en producción. El host oficial (crm.empresa.pt) sirve la main.
2. Para un cambio grande, se crea una versión (1.1) a partir de la main y se trabaja ahí.
3. Para mostrarla a alguien antes de tiempo, se publica un segundo host (crm-teste.empresa.pt) que sirve la 1.1.
4. Cuando esté lista, el host de producción pasa a servir la 1.1 — o se trae lo que interesa a la main con el Merge selectivo….

#Lo que no viaja con la app

Cuando exportas una app en un paquete, el host queda fuera — es de esta instalación, y el mismo paquete instalado en otro sitio tendrá direcciones suyas. Quedan también fuera el historial de ejecuciones y las claves API. Ver Importar y exportar apps.

#Preguntas frecuentes

Cambié de versión y la app parece vacía. Cada versión tiene sus datos. La 1.1 solo tiene lo que existía en el origen en el momento en que fue creada, más lo que se hizo ahí desde entonces.

Publiqué el host y el navegador no encuentra nada. Falta el DNS: el nombre tiene que apuntar a esta instalación. Mientras eso no ocurre, usa /app/{slug} para probar.

¿Puedo tener dos hosts sirviendo la misma versión? Sí. Un host sirve una versión, pero nada impide que varias apunten a la misma — por ejemplo, una dirección corta y otra completa.

Borré una versión sin querer. No hay vuelta atrás: borra su diseño, sus datos y su historial. Es la razón para que las versiones en producción tengan siempre un host asociado — una versión servida por un host es una versión que nadie borra por descuido.