Faire évoluer un site déployé | EmDash CMS Everything

EmDash stocke les collections, champs et taxonomies dans la base de données, à côté du contenu lui-même. Déployer du nouveau code ne les modifie pas : un déploiement remplace le code du Worker (ou serveur), tandis que le schéma et le contenu dans la base de données restent tels quels. Cette page explique comment modifier le modèle de contenu d’un site déjà déployé, en utilisant Cloudflare D1 comme exemple. Les mêmes workflows s’appliquent aux autres options de base de données.

Qu’est-ce qui change quoi

Un site passe par quatre workflows distincts. Chacun touche une couche différente :

Workflow	Ce qui change	Comment
Édition de contenu	Entrées, médias, paramètres	Panneau d’administration ou API de contenu
Déploiement de code	Templates, config, version EmDash	`wrangler deploy` — laisse schéma et contenu intacts
Bootstrap initial	Tout, à partir de zéro	Migrations + fichier seed + assistant de configuration, automatique au premier démarrage
Évolution du schéma	Collections, champs, taxonomies	Panneau d’administration ou `emdash schema` contre le site en production (cette page)

Le fichier seed ne participe qu’à la troisième ligne. Il est appliqué une seule fois, lorsque la base de données est vide et que l’assistant de configuration n’a pas été complété. Déployer un fichier seed modifié contre une base de données existante ne fait rien — l’évolution du schéma d’un site en production se fait toujours via le panneau d’administration ou l’API.

Modifier le schéma dans le panneau d’administration

Le panneau d’administration est le moyen principal de faire évoluer un site déployé. Ouvrez Content Types dans l’admin et ajoutez, modifiez ou supprimez des collections et des champs. Les modifications prennent effet immédiatement — l’API de contenu, le loader et l’interface d’édition lisent tous le schéma depuis la base de données à l’exécution.

Voir Collections & Champs pour les types de champs disponibles, les règles de validation et les options de widget.

Après avoir modifié le schéma, régénérez les types TypeScript utilisés par vos templates. La commande emdash types lit le schéma depuis une instance en cours d’exécution, elle peut donc pointer directement sur le site déployé :

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

Modifier le schéma depuis la CLI

Les commandes emdash schema communiquent avec une instance en cours d’exécution via son API REST, elles fonctionnent donc contre un site déployé de la même manière que contre le dev local. Authentifiez-vous une fois avec le flux d’appareil :

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

Alternativement, créez un token API dans l’admin sous Settings → API Tokens et passez-le avec --token ou la variable d’environnement EMDASH_TOKEN — utile pour la CI.

Puis faites évoluer le schéma avec les mêmes commandes que vous utiliseriez localement :

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

Comme ces commandes sont de simples appels CLI, elles peuvent être scriptées : une « migration » reproductible pour votre modèle de contenu est un script shell d’appels emdash schema, enregistré dans votre dépôt et exécuté contre chaque environnement successivement.

Voir la référence CLI pour la liste complète des commandes.

Garder le fichier seed synchronisé

Le fichier seed intégré dans votre build détermine avec quoi une base de données neuve est initialisée : un nouvel environnement de prévisualisation, une reconstruction de reprise après sinistre, ou un second déploiement du même site. Si le seed décrit encore le blog de démarrage alors que la production a évolué vers autre chose, chaque environnement neuf démarre avec le mauvais modèle.

Le build intègre le premier fichier seed trouvé à .emdash/seed.json, le chemin dans package.json#emdash.seed, ou seed/seed.json. Si aucun n’est présent, un seed par défaut intégré (le modèle de blog de démarrage) est intégré, et astro dev affiche un avertissement.

Après avoir fait évoluer le schéma d’un site déployé, exportez le modèle en production dans votre dépôt. emdash export-seed lit un fichier SQLite local, et wrangler d1 export en produit un depuis la base de données D1 déployée :

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

Le seed exporté contient les paramètres, collections, taxonomies, menus et zones de widgets du site en production. Ajoutez --with-content pour inclure les entrées. Committez le .emdash/seed.json mis à jour avec le code qui dépend du nouveau schéma, afin qu’un environnement neuf démarre toujours avec un modèle que le code comprend.

Répéter les modifications sur un environnement de prévisualisation

Une modification de schéma destructive (suppression d’un champ, restructuration d’une collection) est plus sûrement répétée contre une copie jetable de la production.

Ajoutez un environnement de prévisualisation avec sa propre base de données D1 à wrangler.jsonc :

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

Copiez la production dedans :

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

Déployez et exécutez la modification de schéma contre l’URL de prévisualisation :

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

Vérifiez que le site s’affiche et que l’admin se comporte comme prévu, puis exécutez les mêmes commandes contre la production.

Récupérer d’une erreur

Un champ a été supprimé par erreur. La colonne et ses données ont disparu de la base de données en production. Restaurez depuis un point de sauvegarde Time Travel de D1, ou rajoutez le champ et restaurez ses valeurs depuis un wrangler d1 export antérieur.
Un environnement neuf a démarré avec le mauvais modèle. Le seed intégré était obsolète ou absent. Mettez à jour .emdash/seed.json (voir Garder le fichier seed synchronisé), reconstruisez et pointez le déploiement vers une base de données vide pour redémarrer.
Le schéma et les templates ne concordent pas. Les déploiements et les modifications de schéma sont indépendants, ordonnez-les donc délibérément : les modifications de schéma additives (nouvelle collection, nouveau champ optionnel) vont en premier, puis le code qui les utilise. Pour les suppressions, déployez d’abord le code qui cesse d’utiliser le champ, puis supprimez le champ.