Evolucionar un sitio desplegado | EmDash CMS Everything

EmDash almacena colecciones, campos y taxonomías en la base de datos, junto al contenido mismo. Desplegar nuevo código no los cambia: un deploy reemplaza el código del Worker (o servidor), mientras que el esquema y el contenido en la base de datos permanecen como están. Esta página explica cómo cambiar el modelo de contenido de un sitio que ya está desplegado, usando Cloudflare D1 como ejemplo. Los mismos flujos de trabajo aplican para las otras opciones de base de datos.

Qué cambia qué

Un sitio pasa por cuatro flujos de trabajo distintos. Cada uno toca una capa diferente:

Flujo de trabajo	Qué cambia	Cómo
Edición de contenido	Entradas, medios, configuración	Panel de administración o API de contenido
Deploy de código	Templates, config, versión EmDash	`wrangler deploy` — deja esquema y contenido sin tocar
Bootstrap inicial	Todo, desde vacío	Migraciones + archivo seed + asistente de configuración, automático en primer arranque
Evolución del esquema	Colecciones, campos, taxonomías	Panel de administración o `emdash schema` contra el sitio en vivo (esta página)

El archivo seed solo participa en la tercera fila. Se aplica una vez, cuando la base de datos está vacía y el asistente de configuración no se ha completado. Desplegar un archivo seed modificado contra una base de datos existente no hace nada — evolucionar el esquema de un sitio en vivo siempre ocurre a través del panel de administración o la API.

Cambiar el esquema en el panel de administración

El panel de administración es la forma principal de evolucionar un sitio desplegado. Abre Content Types en el admin y añade, edita o elimina colecciones y campos. Los cambios toman efecto inmediatamente — la API de contenido, el loader y la UI de edición leen todos el esquema de la base de datos en tiempo de ejecución.

Consulta Colecciones y Campos para los tipos de campo disponibles, reglas de validación y opciones de widget.

Después de cambiar el esquema, regenera los tipos TypeScript que usan tus templates. El comando emdash types lee el esquema de una instancia en ejecución, así que puede apuntar al sitio desplegado directamente:

npx emdash types --url https://example.com

Cambiar el esquema desde la CLI

Los comandos emdash schema se comunican con una instancia en ejecución a través de su API REST, así que funcionan contra un sitio desplegado de la misma forma que contra dev local. Autentícate una vez con el flujo de dispositivo:

npx emdash login --url https://example.com

Alternativamente, crea un token API en el admin bajo Settings → API Tokens y pásalo con --token o la variable de entorno EMDASH_TOKEN — útil para CI.

Luego evoluciona el esquema con los mismos comandos que usarías localmente:

npx emdash schema add-field posts subtitle --type string --label "Subtitle" --url https://example.com
npx emdash schema remove-field posts legacy_field --url https://example.com
npx emdash schema create projects --label Projects --url https://example.com

Dado que estos comandos son simples llamadas CLI, pueden ser scriptados: una “migración” repetible para tu modelo de contenido es un script de shell con llamadas emdash schema, registrado en tu repositorio y ejecutado contra cada entorno sucesivamente.

Consulta la referencia de CLI para la lista completa de comandos.

Mantener el archivo seed sincronizado

El archivo seed incrustado en tu build determina con qué se inicializa una base de datos nueva: un nuevo entorno de vista previa, una reconstrucción de recuperación ante desastres, o un segundo despliegue del mismo sitio. Si la seed todavía describe el blog inicial mientras producción ha evolucionado a algo diferente, cada entorno nuevo arranca con el modelo incorrecto.

El build incrusta el primer archivo seed encontrado en .emdash/seed.json, la ruta en package.json#emdash.seed, o seed/seed.json. Si ninguno está presente, se incrusta una seed por defecto incorporada (el modelo de blog inicial), y astro dev registra una advertencia.

Después de evolucionar el esquema de un sitio desplegado, exporta el modelo en vivo de vuelta a tu repositorio. emdash export-seed lee un archivo SQLite local, y wrangler d1 export produce uno desde la base de datos D1 desplegada:

npx wrangler d1 export emdash-db --remote --output=./prod.sql
sqlite3 prod.db < prod.sql
npx emdash export-seed --database prod.db > .emdash/seed.json

La seed exportada contiene la configuración, colecciones, taxonomías, menús y áreas de widgets del sitio en vivo. Añade --with-content para incluir entradas. Haz commit del .emdash/seed.json actualizado junto con el código que depende del nuevo esquema, para que un entorno nuevo siempre arranque con un modelo que el código entiende.

Ensayar cambios en un entorno de vista previa

Un cambio de esquema destructivo (eliminar un campo, reestructurar una colección) es más seguro ensayarlo contra una copia desechable de producción.

Añade un entorno de vista previa con su propia base de datos D1 a wrangler.jsonc:

{
  "env": {
    "preview": {
      "d1_databases": [{ "binding": "DB", "database_name": "emdash-db-preview" }],
    },
  },
}

Copia producción en él:

npx wrangler d1 export emdash-db --remote --output=./prod.sql
npx wrangler d1 execute emdash-db-preview --remote --file=./prod.sql

Despliega y ejecuta el cambio de esquema contra la URL de vista previa:

npx wrangler deploy --env preview
npx emdash schema remove-field posts legacy_field --url https://preview.example.com

Verifica que el sitio renderiza y el admin se comporta como se espera, luego ejecuta los mismos comandos contra producción.

Recuperarse de un error

Un campo fue eliminado por error. La columna y sus datos han desaparecido de la base de datos en vivo. Restaura desde un punto de respaldo Time Travel de D1, o re-añade el campo y restaura sus valores desde un wrangler d1 export anterior.
Un entorno nuevo arrancó con el modelo incorrecto. La seed incrustada estaba desactualizada o faltaba. Actualiza .emdash/seed.json (ver Mantener el archivo seed sincronizado), reconstruye y apunta el deploy a una base de datos vacía para arrancar de nuevo.
El esquema y los templates no concuerdan. Deploys y cambios de esquema son independientes, así que ordénalos deliberadamente: los cambios de esquema aditivos (nueva colección, nuevo campo opcional) van primero, luego el código que los usa. Para eliminaciones, despliega primero el código que deja de usar el campo, luego elimina el campo.