Publishが本番データベースを更新する仕組み

Replitが管理するデータベースを使用するアプリを公開すると、Replitは本番データベースを開発データベースに合わせて自動的に更新します。移行(マイグレーション)を自分で記述したり実行したりする必要はありません。公開中、Replitは次の処理を行います:

1. 開発データベースと本番データベースのスキーマを比較します。
2. 本番を開発に一致させるために必要なSQLを生成します。
3. 列名の変更など、あいまいな点の解決をあなたに求めます。
4. 本番データベースのコピーに対してSQLを検証します。
5. アプリのビルド後、新しいバージョンが公開される前に、本番にSQLを適用します。

​

ステップ1: Replitが変更を検出する

公開はProvisionステージから始まります。開発スキーマが本番と異なる場合、PublishペインにDevelopment database changes detectedと表示され、移行の生成が始まります。 公開時には、テーブル、列、インデックス、制約、ビュー、列挙型(enum)、シーケンス、行レベルセキュリティポリシーが移行されます。一部のオブジェクトは引き継がれません。サポートされていないデータベースオブジェクトを参照してください。

​

ステップ2: あいまいな変更に関する質問に答える

スキーマの変更には、2通りの意味に解釈できるものがあります。Replitが意図を判断できない場合、Detected potential conflicts, please reviewと表示して一時停止し、選択を求めます。オプションを選択してSubmitを選択してください。

​

名前変更か、新規作成か?

同じテーブルで列が1つ削除され、別の列が追加された場合、Replitは古い列の名前が変更されたのかどうかを尋ねます。

• Yes, rename columnは、既存のデータを新しい名前のまま保持します。
• No, create new columnは、空の列を追加し、古い列をそのデータごと削除します。

同じ質問は、テーブル、列挙型、シーケンス、ビュー、スキーマでも表示されます。

​

データがあるテーブルへの一意制約

本番ですでに行があるテーブルに一意制約を追加する場合、Replitは制約が確認する行数を通知します。

• Add the constraint as-isは、既存の行のいずれかが制約に違反している場合、移行が失敗します。その後、データを修正して再度公開できます。
• Remove all rows, then add the constraintは、先にテーブルを空にします。他のテーブルが外部キーでこのテーブルを参照している場合、このオプションは表示されません。

​

ステップ3: 生成されたSQLを確認する

すべての質問に答えると、ペインにGenerated migrations to apply to production databaseと、Replitが実行する正確なSQLが表示されます。続行する前に必ず読んでください。 移行に特別な注意が必要であることは、次の2つのサインでわかります:

• データ損失の警告。 本番に行があるテーブルからデータが削除される可能性のある変更がある場合、ペインがオレンジ色になり、影響を受ける各テーブルが行数とともに一覧表示されます。これが表示される変更には次のものがあります:
  • 列やテーブルの削除または再作成
  • 列の型、または値が必須かどうかの変更
  • 必須列の追加
  • インデックスや制約の追加または再作成
• ダウンタイムの通知。 変更が現在実行中のアプリのバージョンと互換性がない場合、Replitは移行を適用する前に実行中のアプリを停止し、ユーザーが変更の途中でデータベースに書き込めないようにします。詳細は**What’s happening?**を展開してください。

​

ステップ4: Replitが移行を検証する

Replitは本番データベースの一時的なコピーを作成し、それに対してSQLを実行します。ペインにはValidating database migrations…と表示され、続いてDatabase migrations validated successfullyと表示されます。 コピーでSQLが失敗した場合、ペインにはデータベースのエラーとともにMigrations failed validation, please reviewと表示され、次の3つの対処方法が示されます:

​

ステップ5(任意): 移行済みコピーでアプリをプレビューする

検証が成功したら、Create preview deployを選択して、移行済みの本番コピーに対してアプリをビルドできます。ビルドが完了したら、View previewを選択して開きます。 プレビューを使って、スキーマの変更が影響するアプリの部分を操作して確認してください。プレビューはコピーされたデータを使用するため、そこで行った操作が本番に影響することはありません。プレビューは作成から2時間で有効期限が切れます。もっと時間が必要な場合は、新しく作成してください。

​

ステップ6: 承認して公開する

Approve and publishを選択して続行します。Replitは、確認した正確なSQLを公開リクエストとともに送信するため、確認した内容がそのまま実行されます。 その後、公開は残りのステージに進みます。移行はアプリのビルドが完了した後、新しいバージョンが昇格される前に実行されます:

1. セキュリティチェック
2. ビルド
3. 本番へのデータベース移行の適用
4. バンドルと新バージョンの昇格

Replitはこのタイミングで移行を適用するため、アプリのビルドコマンドや起動コードでデータベーススキーマを変更してはいけません。デプロイメントのビルドコマンドやサーバーのエントリポイントに、drizzle-kit push、db:push、CREATE TABLE IF NOT EXISTS文を追加しないでください。これらは公開のたびに、上記のレビューと検証の外で実行されてしまいます。 Publishペインを使わずにAgentに再公開を依頼し、開発と本番のスキーマが異なる場合、再公開はブロックされ、移行を確認するためにPublishペインへ誘導されます。

​

本番を手動で変更する

単発の修正であれば、Databaseペインから本番に対して直接SQLを実行できます。データベーススイッチャーでProductionを選択し、SQLコンソールを使用します。データを操作するを参照してください。 Replitは常にスキーマファイルではなく実際のデータベースを比較するため、手動での変更は次回の公開時の比較の一部になります。開発に存在しない列を本番で手動で追加した場合、次回の公開ではその列の削除が提案されます。

​

次のステップ

• 開発環境と本番環境のデータベース: 2つのデータベースの違いを理解します。
• データリカバリー: 開発または本番のデータを復元します。
• サポートされていないデータベースオブジェクト: Publishが移行できないオブジェクト。