DB移行およびAzure展開スロット

新しいWebアプリケーションをAzure Web App Service（以前のAzure Webサイト）にプッシュする予定です。展開スロットを利用して、運用環境にプッシュする前に展開をテストできるようにします。DBスキーマの変更が必要ない限り、これで十分です。しかし、スキーマの変更がある場合、同じdbバージョンで動作する2つのソフトウェアバージョンを持つことはできません。EF Migrationsを使用しているため、ステージングスロットへのプッシュにより、即座にDBが最新バージョンに更新されます。

だから私の質問は、データベースの移行が必要なときに展開スロットを使用するかどうかです。

大規模なSaaSプロバイダーではどのように行われますか。彼らは新しいバージョンで即座にDB移行を実行していますか？それは確かにいくつかのダウンタイムを引き起こすでしょう。

この問題のかなり複雑な解決策しか考えられませんが、簡単なものはありますか？

Azure App Serviceスロットとステージングとプロダクションで共有される単一のデータベースを使用したゼロダウンタイムリリースは可能ですが、すべてのデータベースの変更には下位互換性があることを確認する必要があります。ステージングおよび本番スロット。

これが機能することを保証するいくつかのルール：

• 新しいデータベース列はすべて、null可能またはデフォルト値を持つ必要があります
• 列名の変更は許可されていません
• 列の削除は許可されていません

列の名前変更や削除など、破壊的な変更を行う必要がある場合、これを行うには2つのリリースが必要です。

1. Webアプリの新しいバージョンをリリースする必要があります。これにより、名前変更または削除された列への依存関係が削除されます。
2. 破壊的な変更を実行する追加のリリースが作成されます

これは少し複雑に聞こえますが、実際には、破壊的な変更を頻繁に行うことはないでしょう。

スロット固有の構成アイテムを見ましたか？[WebApp /設定/アプリケーション設定]で、Webアプリの設定を指定できますが、このスロットにのみ適用するかどうかも定義できます。

したがって、ステージングスロットにスロット固有の接続文字列を設定し、スワッピングスロットにも移行を適用できます。