FACTUAL ACTIVITY RECORD · 実際の作業をもとにした活動記録
Database migrationをSupabase CLI標準経路へ戻す
独自接続を外し、link・履歴確認・dry-run・適用の順序でproduction適用まで確かめる
目的
初回のproduction migrationは、Supabase CLIのlink後に置いた独自psql preflightがCA rootを発見できず、databaseを変更する前に停止した。Provider標準の接続と履歴管理だけで継続運用できる経路へ簡素化する必要があった。
実装
標準migration workflowから直接psql、repository管理CA、独自TLS設定、preflight／postflight SQLを削除した。処理順はsupabase link、linked履歴確認、標準のdry-run、migration適用、再度の履歴確認とdry-runへ統一した。
標準migration workflowを更新し、manual実行の確認条件と標準CLI sequenceを静的に検査しながら、直接接続やCA管理の再導入を拒否するようにした。Migration SQLやschema設計自体は変更していない。
図を描画しています…
確認したこと
確認結果
変更前の失敗はdatabase変更前であり、原因が標準CLIではなく追加した直接接続にあることを確認した。
標準経路で初期migrationがproductionへ適用され、migration履歴が一致し、再dry-runで未適用がないことを確認した。
Dashboardでは初期schema、ACL、default privilegeを確認し、Data APIの公開schemaをapiだけへ修正した。
完了とした根拠
標準CLI sequenceの検証とproduction適用が成功し、履歴一致、未適用0件、初期database境界まで確認できたことを完了条件とした。