Emdash CMS デプロイ検証と初回ログイン FAQ
デプロイ後の実用的な受け入れチェック、初回管理画面セットアップ、「部分成功」状態の切り分け。
デプロイ後、最初に何を確認すべき？
3 層の受け入れ順：
- フロントに到達できる：トップページが期待どおりの内容を返す。
- 管理画面に到達できる：
/_emdash/adminが読み込める。 - データを書ける：コンテンツを 1 件作成・読み取れる。
ルートに到達できるだけではデプロイ完了ではない。
フロントは動くのに管理初期化が失敗するのはなぜ？
よくある原因：
- バインドの不一致（
DB、MEDIAなど） - 環境変数やシークレットの欠落
- Free プラン向けに非対応の設定を残している
推奨の切り分け順：まずバインド、次に環境変数、最後に機能ティアの制約。
初回管理ログインは何をする？
通常：
- 管理者アイデンティティの作成
- 資格情報の登録（Passkey など）
- 初期システム状態の書き込み
ブラウザとアカウント状態に依存する。安定したネットワークと対応ブラウザで完了させる。
Passkey 設定が失敗したら最初に何を見る？
この順で：
- ブラウザ対応と Passkey の利用可否
- システム時刻の正確さ
- クロスオリジンやリバースプロキシのヘッダ問題
まずデータベースを疑わない。多くの認証失敗はクライアントかエッジプロキシ側。
最小限の本番受け入れスクリプトとは？
繰り返し可能な流れ：
- フロントのトップを開き、レスポンスを記録する。
- 管理にログインし、初期設定を完了する。
- テストコンテンツを作成・公開する。
- メディアを 1 件アップロードし取得を確認する。
- 公開コンテンツがフロントに見えることを確認する。
ルート・認証・書き込み・ストレージ・読み取りを検証する。
デプロイは成功したがコンテンツがない。どこから？
最短の診断：
- 項目は公開済みか（下書きではないか）。
- フロントは期待のコレクションを問い合わせているか。
- ランタイムログにクエリや権限エラーがないか。
多くの欠落は状態かクエリパスの問題で、プラットフォームの全面停止ではない。
チームは受け入れ品質をどう制度化するか？
リリースワークフローに組み込む：
- マージ前：ローカルまたは staging で 3 層受け入れ
- リリース後：当番が 10 分以内に最小スクリプトを実行
- インシデント後：再発防止のための決定的チェックを 1 つ追加
信頼できるローンチはプロセス管理から、暗黙の記憶からではない。
検証コマンド断片
# ランタイムチェックの例
curl -I https://your-site.workers.dev
curl -I https://your-site.workers.dev/_emdash/admin
npx wrangler tail your-worker-name