デプロイ済みサイトの進化

このページ

EmDashはコレクション、フィールド、タクソノミーをコンテンツそのものと一緒にデータベースに保存します。新しいコードをデプロイしてもこれらは変わりません。デプロイはWorker(またはサーバー)コードを置き換えますが、データベース内のスキーマとコンテンツはそのまま残ります。このページでは、すでにデプロイされたサイトのコンテンツモデルを変更する方法を、Cloudflare D1を例に説明します。同じワークフローは他のデータベースオプションにも適用されます。

何が何を変更するか

サイトは4つの異なるワークフローを経ます。それぞれが異なるレイヤーに影響します:

ワークフロー変更されるもの方法
コンテンツ編集エントリ、メディア、設定管理パネルまたはコンテンツAPI
コードデプロイテンプレート、設定、EmDashバージョンwrangler deploy — スキーマとコンテンツはそのまま
初回ブートストラップすべて(空の状態から)マイグレーション + seedファイル + セットアップウィザード、初回起動時に自動
スキーマの進化コレクション、フィールド、タクソノミー管理パネルまたはemdash schemaを稼働サイトに対して実行(このページ)

seedファイルは3行目にのみ関与します。データベースが空でセットアップウィザードが完了していない場合に一度だけ適用されます。既存のデータベースに対して変更されたseedファイルをデプロイしても何も起こりません — 稼働中サイトのスキーマの進化は常に管理パネルまたはAPIを通じて行います。

管理パネルでスキーマを変更する

管理パネルはデプロイ済みサイトを進化させる主要な方法です。管理画面でContent Typesを開き、コレクションやフィールドを追加、編集、削除します。変更は即座に有効になります — コンテンツAPI、ローダー、編集UIはすべてランタイムにデータベースからスキーマを読み取ります。

利用可能なフィールドタイプ、バリデーションルール、ウィジェットオプションについてはコレクション&フィールドを参照してください。

スキーマ変更後、テンプレートが使用するTypeScript型を再生成します。emdash typesコマンドは実行中のインスタンスからスキーマを読み取るため、デプロイ済みサイトに直接指定できます:

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

CLIからスキーマを変更する

emdash schemaコマンドはREST APIを通じて実行中のインスタンスと通信するため、ローカル開発と同じようにデプロイ済みサイトに対して機能します。デバイスフローで一度認証します:

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

または、管理画面のSettings → API TokensでAPIトークンを作成し、--tokenまたは環境変数EMDASH_TOKENで渡します — CIに便利です。

次に、ローカルで使うのと同じコマンドでスキーマを進化させます:

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

これらのコマンドは単純なCLI呼び出しなのでスクリプト化できます。コンテンツモデルの再現可能な「マイグレーション」はemdash schema呼び出しのシェルスクリプトで、リポジトリにチェックインして各環境に順番に実行します。

完全なコマンドリストはCLIリファレンスを参照してください。

seedファイルを同期させる

ビルドに埋め込まれたseedファイルは、新しいデータベースが何で初期化されるかを決定します:新しいプレビュー環境、ディザスタリカバリの再構築、または同じサイトの2回目のデプロイ。本番が別のものに進化しているのにseedがまだスターターブログを記述している場合、すべての新しい環境は間違ったモデルでブートストラップされます。

ビルドは.emdash/seed.jsonpackage.json#emdash.seedのパス、またはseed/seed.jsonで最初に見つかったseedファイルを埋め込みます。存在しない場合、組み込みのデフォルトseed(スターターブログモデル)が埋め込まれ、astro devが警告を記録します。

デプロイ済みサイトのスキーマを進化させた後、ライブモデルをリポジトリにエクスポートします。emdash export-seedはローカルのSQLiteファイルを読み、wrangler d1 exportはデプロイ済みD1データベースからSQLを生成します:

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

エクスポートされたseedには、ライブサイトの設定、コレクション、タクソノミー、メニュー、ウィジェットエリアが含まれます。エントリを含めるには--with-contentを追加します。新しいスキーマに依存するコードと一緒に更新された.emdash/seed.jsonをコミットし、新しい環境が常にコードが理解するモデルでブートストラップされるようにします。

プレビュー環境で変更をリハーサルする

破壊的なスキーマ変更(フィールドの削除、コレクションの再構築)は、本番の使い捨てコピーに対してリハーサルするのが最も安全です。

  1. wrangler.jsoncに独自のD1データベースを持つプレビュー環境を追加します:

    {
      "env": {
        "preview": {
          "d1_databases": [{ "binding": "DB", "database_name": "emdash-db-preview" }],
        },
      },
    }
  2. 本番をコピーします:

    npx wrangler d1 export emdash-db --remote --output=./prod.sql
    npx wrangler d1 execute emdash-db-preview --remote --file=./prod.sql
  3. デプロイしてプレビューURLに対してスキーマ変更を実行します:

    npx wrangler deploy --env preview
    npx emdash schema remove-field posts legacy_field --url https://preview.example.com
  4. サイトがレンダリングされ管理画面が期待通りに動作することを確認し、同じコマンドを本番に対して実行します。

間違いからの回復

  • フィールドが誤って削除された。 カラムとそのデータはライブデータベースから消えています。D1のTime Travelポイントインタイムバックアップから復元するか、フィールドを再追加して以前のwrangler d1 exportから値を復元します。
  • 新しい環境が間違ったモデルでブートストラップされた。 埋め込まれたseedが古いか欠落していました。.emdash/seed.jsonを更新し(seedファイルを同期させるを参照)、再ビルドして空のデータベースにデプロイを向けて再度ブートストラップします。
  • スキーマとテンプレートが一致しない。 デプロイとスキーマ変更は独立しているため、意図的に順序付けます。追加的なスキーマ変更(新しいコレクション、新しいオプションフィールド)を先に行い、次にそれを使用するコードをデプロイします。削除の場合は、フィールドの使用を停止するコードを先にデプロイし、その後フィールドを削除します。