Publicación y Versiones

Publicar es el momento en que tus ediciones se convierten en el sitio. Hasta ahí, todo lo que hiciste vive en borradores que solo ves vos. Esta página cubre qué hace realmente publicar, cómo deshacerlo, y cómo subir un sitio que construiste por afuera.

Qué hace publicar

Pasan tres cosas, en orden:

1. Se registra una versión — una instantánea numerada con la cantidad de páginas, quién publicó, cuándo, y una nota opcional sobre qué cambió.

2. Se regeneran los archivos estáticos a partir de tus páginas, tema y navegación.

3. Los archivos nuevos reemplazan a los viejos en la dirección de la App.

La versión es la parte que importa. No es una entrada de log: es una instantánea completa, que es lo que hace posible la sección siguiente.

Volver atrás

El historial de versiones lista todo lo que el sitio fue. Volver atrás publica de nuevo una versión anterior.

Ojo con la formulación: volver atrás es publicar, no borrar. La versión 12 sigue ahí después de que vuelvas a la 9 — simplemente hiciste que la 9 sea la actual, y el rollback mismo pasa a ser la entrada más nueva. No se pierde nada, y podés volver hacia adelante de la misma manera.

Por esto conviene escribir una nota de cambio en cada publicación. "Arreglada la tabla de precios" es lo que hace usable una lista de versiones tres meses después, cuando lo único que distingue las entradas es una marca de tiempo.

El estado de la App

Independiente de cualquier versión, la App tiene un estado:

Mantenimiento es el que la gente olvida que existe. Cuando necesitás bajar el sitio una hora sin darle a los visitantes un hostname muerto, esta es la herramienta correcta — no borrar el dominio, y no publicar una versión a medio hacer.

Los archivos generados, y cómo adueñarte de uno

Publicar regenera un conjunto específico de archivos dentro del sitio:

index.html
styles/global.css
404.html
robots.txt

Esos le pertenecen al generador, y cada publicación los reescribe.

Lo importante: la primera vez que editás o borrás uno vos mismo, pasa a ser tuyo. Desde ese momento el generador deja de escribir esa ruta, y tu versión sobrevive a todas las publicaciones futuras. Devolverlo es igual de explícito: quitás tu override y el generador retoma.

Sin esta regla, un global.css editado se revertiría en silencio en la próxima publicación, y un robots.txt borrado volvería de la tumba. Con ella, podés adueñarte exactamente de los archivos que te importan y dejar el resto administrado.

Publicar un sitio que construiste por afuera

No toda App se construye en el editor. Si tenés un sitio hecho con tu propia cadena de herramientas — un generador estático, el build de un framework, una carpeta de HTML — podés subir la salida ya construida.

Para eso existen las claves de deploy. Una clave de deploy está acotada a una sola App y le permite a un pipeline de CI subir archivos sin una sesión de usuario:

• Se muestra una sola vez, al crearla. Solo se guarda un hash, así que no se puede recuperar — perderla significa crear otra.

• Puede tener vencimiento, o ninguno.

• Registra cuándo se usó por última vez, que es cómo encontrás las que ya nadie usa.

Ponele a cada clave un nombre que diga dónde corre — "GitHub Actions, rama main" — porque más adelante lo único que vas a tener para decidir si una clave sigue haciendo falta es ese nombre y su fecha de último uso.

Además de las claves, los archivos de la App se pueden listar, subir, editar, renombrar, mover y borrar directamente. Sirve para un arreglo puntual, y es también cómo te adueñás de un archivo generado.

Cuándo aparecen los cambios

Un sitio publicado se sirve desde una caché cerca de tus visitantes. Después de publicar, la versión nueva puede tardar unos minutos en llegar a todas las ubicaciones.

Esto confunde porque los reflejos habituales no ayudan: un refresh forzado, una ventana privada y otro navegador le preguntan a la misma caché. Si una publicación parece no haber hecho nada, esperá unos minutos antes de dar por hecho que falló — y si estás probando, agregá un parámetro cambiante a la URL en vez de confiar en el botón de recargar.

Siguiente

• Dominios — poner el sitio en tu propia dirección

• Destinos de deploy — publicar la misma App también en otro lado

• Analítica — quién visitó, y qué leyó

Cómo se ve

La fila de arriba responde "qué está viendo el mundo ahora mismo": punto verde, Running v4, y la dirección en que se está sirviendo. Roll back está junto a Redeploy a propósito — volver atrás es publicar una versión anterior, no deshacer, así que es la misma clase de acción.

La tira bajo la dirección son los últimos despliegues como marcas de color con su tasa de éxito al lado. Está ahí para que una falla parcial no pase inadvertida: una App puede estar en vivo y aun así tener un destino que no la está recibiendo. Eso es exactamente lo que muestra la lista de actividad de abajo — la misma versión 4 tuvo éxito en un destino mientras un intento anterior en otro falló. Una fila fallida conserva su error, así distingues una credencial rechazada de una compilación que nunca arrancó.

El historial de versiones de la derecha es lo que hace reversible todo esto. Cada entrada es una instantánea con quién publicó y la nota que dejó, y Restore en una entrada antigua es cómo vuelves a ella. El campo de nota es opcional y casi siempre vale la pena llenarlo — seis semanas después es lo único que distingue dos versiones.