家計簿アプリを作る #88：Cloudflare Pages への再デプロイ
家計簿アプリ作成シリーズの第88回です。前回のE2Eテスト導入の途中で、アプリ側にもいくつか修正が入ったので、本番環境へ反映します。
今回反映する変更
- 設定画面の
TabItemからkeyを削除(タブボタンと入力欄のIDが重複し、ラベルが別の要素に紐付いていた不具合の修正) - バックアップタブの
<Label>から、対応する入力欄の無いforを削除 - アカウント削除で
transactionTemplatesとbudgetAlertsが消えていなかったのを修正し、削除をdb.batch()でまとめて実行
Playwright関連のファイル(e2e/、playwright.config.ts、@playwright/test)は開発時にだけ使うもので、Workerには含まれません。テーブル・カラムの追加も無いので、マイグレーションは不要でした。
ローカルでnpm run buildは必要か
このアプリはGitHubにpushすると、Cloudflare側でビルドとデプロイが走る構成です。そのため、デプロイのためだけにローカルでビルドする必要はありません。
ローカルビルドに意味があるとすれば、push前にビルドエラーが無いか確かめる事前チェックとしてです。ただ今回はそれも済んでいました。playwright.config.tsのwebServerがnpm run build && npx wrangler devなので、npm run test:e2eを実行するたびにローカルでビルドが走っています。最新のコードでE2Eテストが通っていれば、ビルドも成功しているということです。
Cloudflare側のビルド設定を確認する
代わりに、Cloudflareのダッシュボードでビルド設定を確認しました。
| 項目 | 設定 |
|---|---|
| ビルドコマンド | npm run build |
| デプロイコマンド | npx wrangler deploy |
見ておきたかったのはビルドコマンドです。package.jsonのbuildはvite build && node scripts/patch-worker.jsで、お題81で作ったpatch-worker.jsがここで実行されます。Cloudflare側のビルドコマンドがvite buildだけになっていると、scheduledハンドラの無いWorkerがデプロイされます。その場合もビルドは成功し、画面も普通に動くので、月初にサマリーメールが届かないことで初めて気付くことになります。ローカルとCloudflareで同じコマンドが走っていることを確認できました。
本番環境での動作確認
設定画面
- タブを切り替えたとき、選んだタブだけがハイライトされること
- アカウントの削除タブで「パスワードを入力してください」の文字をクリックすると、タブが切り替わらずに入力欄にフォーカスが移ること
アカウント削除
漏れていたテーブルが本当に消えるかは、画面を見ても分かりません。本番の自分のアカウントは使わず、確認用のアカウントを作って確かめました。
- 確認用アカウントでログインし、クイック登録のテンプレートを1件作る
- 削除する前に、そのユーザーのIDを控えておく
npx wrangler d1 execute kakeibo-app-db --remote --command "SELECT id FROM user WHERE email = '確認用のメールアドレス'" - 設定画面からアカウントを削除する
- 控えたIDのテンプレートが残っていないことを確認する
npx wrangler d1 execute kakeibo-app-db --remote --command "SELECT COUNT(*) FROM transaction_templates WHERE user_id = '控えたID'"
件数が0になり、修正が本番でも効いていることを確認できました。
なお、E2Eテストは本番に向けては実行していません。テストはアカウントの作成と削除を実際に行うので、本番に向けると本番のDBを直接触ることになります。baseURLはlocalhost固定のままにしています。
まとめ
GitHub連携でデプロイしている場合、ローカルビルドは「デプロイの手順」ではなく「push前の確認」です。E2Eテストのサーバー起動にビルドが含まれているので、テストを回す習慣がそのまま確認を兼ねてくれます。確認すべきなのはむしろ、Cloudflare側でローカルと同じビルドコマンドが走っているかの方でした。