> ## Documentation Index > Fetch the complete documentation index at: https://docs.replit.com/llms.txt > Use this file to discover all available pages before exploring further. # Publishが本番データベースを更新する仕組み > アプリを公開する際に、Replitが開発データベースのスキーマ変更を本番に対して比較、検証、適用する仕組みについて説明します。 Replitが管理するデータベースを使用するアプリを公開すると、Replitは本番データベースを開発データベースに合わせて自動的に更新します。移行(マイグレーション)を自分で記述したり実行したりする必要はありません。公開中、Replitは次の処理を行います: 1. 開発データベースと本番データベースのスキーマを比較します。 2. 本番を開発に一致させるために必要なSQLを生成します。 3. 列名の変更など、あいまいな点の解決をあなたに求めます。 4. 本番データベースのコピーに対してSQLを検証します。 5. アプリのビルド後、新しいバージョンが公開される前に、本番にSQLを適用します。 > [!NOTE] > > これはReplitがアプリ用に管理しているデータベースにのみ適用されます。公開したアプリがSupabase、ご自身で作成したNeonプロジェクト、Amazon RDSなどの外部データベースに接続している場合、Publishはそのデータベースを変更しません。代わりに、そのプロバイダーの移行ワークフローを使用してください。 ## ステップ1: Replitが変更を検出する 公開は**Provision**ステージから始まります。開発スキーマが本番と異なる場合、Publishペインに**Development database changes detected**と表示され、移行の生成が始まります。 ![Development database changes detectedを表示するPublishペイン](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/changes-detected.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=9213aa45a2b15109f3cffc451fb7efdf) 公開時には、テーブル、列、インデックス、制約、ビュー、列挙型(enum)、シーケンス、行レベルセキュリティポリシーが移行されます。一部のオブジェクトは引き継がれません。[サポートされていないデータベースオブジェクト](https://docs.replit.com/ja/help/troubleshooting/databases.md#サポートされていないデータベースオブジェクト)を参照してください。 ## ステップ2: あいまいな変更に関する質問に答える スキーマの変更には、2通りの意味に解釈できるものがあります。Replitが意図を判断できない場合、**Detected potential conflicts, please review**と表示して一時停止し、選択を求めます。オプションを選択して**Submit**を選択してください。 ### 名前変更か、新規作成か? 同じテーブルで列が1つ削除され、別の列が追加された場合、Replitは古い列の名前が変更されたのかどうかを尋ねます。 * **Yes, rename column**は、既存のデータを新しい名前のまま保持します。 * **No, create new column**は、空の列を追加し、古い列をそのデータごと削除します。 ![削除された列を新しく追加された列に名前変更するかどうかを尋ねるプロンプト](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/rename-column-prompt.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=fe35615b66e1cc80a57b0198926d5406) 同じ質問は、テーブル、列挙型、シーケンス、ビュー、スキーマでも表示されます。 ![削除されたテーブルを新しく追加されたテーブルに名前変更するかどうかを尋ねるプロンプト](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/rename-table-prompt.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=f3bfb9ba5604a051e845ae3617e42270) > [!WARNING] > > 実際には名前変更だったものに対して**create new**を選択することは、公開時に本番データを失う最も一般的な原因です。わからない場合は、公開をキャンセルして、何が変わったのかをAgentに尋ねてください。 ### データがあるテーブルへの一意制約 本番ですでに行があるテーブルに一意制約を追加する場合、Replitは制約が確認する行数を通知します。 * **Add the constraint as-is**は、既存の行のいずれかが制約に違反している場合、移行が失敗します。その後、データを修正して再度公開できます。 * **Remove all rows, then add the constraint**は、先にテーブルを空にします。他のテーブルが外部キーでこのテーブルを参照している場合、このオプションは表示されません。 ![すでに行があるテーブルに一意制約を追加する方法を尋ねるプロンプト](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/unique-constraint-prompt.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=0a399148516559f9f2711cc335254df2) ## ステップ3: 生成されたSQLを確認する すべての質問に答えると、ペインに**Generated migrations to apply to production database**と、Replitが実行する正確なSQLが表示されます。続行する前に必ず読んでください。 ![Publishペインに表示された、生成された移行SQL](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/generated-migrations.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=d8737c76546c059cdfcf0adead1e9e29) 移行に特別な注意が必要であることは、次の2つのサインでわかります: * **データ損失の警告。** 本番に行があるテーブルからデータが削除される可能性のある変更がある場合、ペインがオレンジ色になり、影響を受ける各テーブルが行数とともに一覧表示されます。これが表示される変更には次のものがあります: * 列やテーブルの削除または再作成 * 列の型、または値が必須かどうかの変更 * 必須列の追加 * インデックスや制約の追加または再作成 * **ダウンタイムの通知。** 変更が現在実行中のアプリのバージョンと互換性がない場合、Replitは移行を適用する前に実行中のアプリを停止し、ユーザーが変更の途中でデータベースに書き込めないようにします。詳細は\*\*What's happening?\*\*を展開してください。 ![影響を受けるテーブルを一覧表示するオレンジ色のデータ損失警告とダウンタイム通知がある移行](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/data-loss-warning.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=fc53902e5f2c4db51429cfc04f0e2746) > [!NOTE] > > 警告の一覧には、本番に行があるテーブルのみが含まれます。空のテーブルに対する`DROP TABLE`では警告が表示されないため、ペインがオレンジ色でなくてもSQLを読んでください。 ## ステップ4: Replitが移行を検証する Replitは本番データベースの一時的なコピーを作成し、それに対してSQLを実行します。ペインには**Validating database migrations...**と表示され、続いて**Database migrations validated successfully**と表示されます。 ![データベースの移行が正常に検証されたことを示すPublishペイン](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/validated.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=7127c8d7f2e63d87be279b5a0fff4e69) コピーでSQLが失敗した場合、ペインにはデータベースのエラーとともに**Migrations failed validation, please review**と表示され、次の3つの対処方法が示されます: | オプション | 動作 | | - | - | | **Ask Agent to investigate and fix the development schema** | Agentは失敗したSQLとエラーを読み取り、開発スキーマを本番の読み取り専用ビューと比較して、開発側を修正します。本番は変更されません。完了したら再度公開してください。 | | **Cancel deployment and retry once your schema conflicts are resolved** | 公開を停止します。本番には何も変更されません。 | | **Copy your development database schema & data to production** | 本番のスキーマ**とデータ**を開発のもので置き換えます。この操作は[データリカバリー](https://docs.replit.com/ja/features/data-and-storage/data-recovery.md)でのみ元に戻せます。保持する価値のある本番データがないアプリでのみ使用してください。 | ![3つの解決オプションとともに移行の検証失敗を示すPublishペイン](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/validation-failed.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=0ece6685e16081c9d3525121441ee5a0) > [!NOTE] > > [Databricks Lakebase](https://docs.replit.com/ja/connectors/warehouses/databricks.md)データベースを使用するアプリでは、この検証ステップはスキップされます。ペインでは、承認する前に生成されたSQLをご自身で確認するよう求められます。 ![Lakebaseではプレビュー検証が利用できないことを示すPublishペイン](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/lakebase-skipped.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=b6ad241f4884be8f6d085d53511e7beb) ## ステップ5(任意): 移行済みコピーでアプリをプレビューする 検証が成功したら、**Create preview deploy**を選択して、移行済みの本番コピーに対してアプリをビルドできます。ビルドが完了したら、**View preview**を選択して開きます。 ![プレビューデプロイのビルド中のPublishペイン](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/preview-building.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=18d331eba4d12dd001b6084d20481bac) ![View previewボタンとApprove and publishボタンが表示されたPublishペイン](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/preview-ready.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=1ed89987ab33ff747694a9460681cc4a) プレビューを使って、スキーマの変更が影響するアプリの部分を操作して確認してください。プレビューはコピーされたデータを使用するため、そこで行った操作が本番に影響することはありません。プレビューは作成から**2時間**で有効期限が切れます。もっと時間が必要な場合は、新しく作成してください。 ## ステップ6: 承認して公開する **Approve and publish**を選択して続行します。Replitは、確認した正確なSQLを公開リクエストとともに送信するため、確認した内容がそのまま実行されます。 その後、公開は残りのステージに進みます。移行は**アプリのビルドが完了した後、新しいバージョンが昇格される前**に実行されます: 1. セキュリティチェック 2. ビルド 3. 本番へのデータベース移行の適用 4. バンドルと新バージョンの昇格 Replitはこのタイミングで移行を適用するため、アプリのビルドコマンドや起動コードでデータベーススキーマを変更してはいけません。デプロイメントのビルドコマンドやサーバーのエントリポイントに、`drizzle-kit push`、`db:push`、`CREATE TABLE IF NOT EXISTS`文を追加しないでください。これらは公開のたびに、上記のレビューと検証の外で実行されてしまいます。 > [!WARNING] > > 承認すると、Publishペインから移行を取り消すことはできません。公開後にスキーマの変更を元に戻す必要がある場合は、開発環境で逆の変更を行って再度公開するか、[データリカバリー](https://docs.replit.com/ja/features/data-and-storage/data-recovery.md)を使用してください。 Publishペインを使わずにAgentに再公開を依頼し、開発と本番のスキーマが異なる場合、再公開はブロックされ、移行を確認するためにPublishペインへ誘導されます。 ## 本番を手動で変更する 単発の修正であれば、Databaseペインから本番に対して直接SQLを実行できます。データベーススイッチャーで**Production**を選択し、SQLコンソールを使用します。[データを操作する](https://docs.replit.com/ja/features/data-and-storage/work-with-your-data.md#run-sql-commands)を参照してください。 Replitは常にスキーマファイルではなく実際のデータベースを比較するため、手動での変更は次回の公開時の比較の一部になります。開発に存在しない列を本番で手動で追加した場合、次回の公開ではその列の削除が提案されます。 ## 次のステップ * [開発環境と本番環境のデータベース](https://docs.replit.com/ja/features/data-and-storage/development-and-production.md): 2つのデータベースの違いを理解します。 * [データリカバリー](https://docs.replit.com/ja/features/data-and-storage/data-recovery.md): 開発または本番のデータを復元します。 * [サポートされていないデータベースオブジェクト](https://docs.replit.com/ja/help/troubleshooting/databases.md#サポートされていないデータベースオブジェクト): Publishが移行できないオブジェクト。