簡単に言えば、そうではありません。
EF の移行と Azure のデプロイは、まったく異なる 2 つの獣です。Azure のデプロイでは、更新スロットやステージング スロットなど、さまざまなオプションが提供されます。おそらく
Azure App Serviceに Web アプリをデプロイする を見たことがあるでしょう。他の読者にとっては、これが良い出発点です。
一般に、Azure デプロイ モデルは、IIS/Web サイト スタックへのアクティブな接続に関心があります。一般に、更新では、デプロイされているインスタンスをロード バランサー プールから取り出し、トラフィックを他のインスタンスにリダイレクトすることで、ユーザー アクセスが中断されないようにします。次に、インスタンスを 1 つずつ更新します。
これは、更新プログラムの展開中、常に複数のバージョンのコードが同時に実行されることを意味します。
EF モデルがコード バージョン間で変更されていない場合、Azure のデプロイは魔法のように機能し、ユーザーはそれが起こっていることさえ知りません。ただし、移行の一部として移行を適用する必要がある場合は注意してください
一般に、EF は、コードと DB のバージョンが一致する場合にのみモデルを読み込みます。EF 移行を使用して、モデルの複数のコード バージョンを同時にサポートするのは非常に困難です。
EF 移行は、データベース初期化子によって主に制御されます。詳細については、移行を使用してデータベースをアップグレードするを参照してください。
開発者は、データベースをいつどのようにアップグレードするかを選択できますが、Migrations とデプロイメントの更新を使用している場合は次の点に注意してください。
- 新しいコード コードは、古いデータ スキーマに対して簡単に実行できません。
- 古いコード/アプリが再起動すると、多くのデフォルトの初期化戦略がスキーマのロールバックを試みます。これが発生した場合は、ポイント 1 を参照してください。;)
- 間違ったバージョンのスキーマに対してロードする EF モデルを回避すると、そこにないスキーマ要素をコードが使用しようとすると、例外と一般的なエラーが発生します。
ライブ サイトで EF 移行を管理する最も簡単な方法は、EF 移行を含む展開のためにサイトのすべてのインスタンスを停止することです。メンテナンス ページまたはリダイレクトを使用できます。
この問題が発生する場合は、DB の更新を手動で適用することをお勧めします。失敗した場合は、展開がまだ開始されていないため、簡単に中止できます。
それ以外の場合は、更新をデプロイすると、起動する最初のインスタンスが移行を実行します (初期化子がそうするように構成されている場合)。
サイト コード/コンテンツとモデルの更新の両方を継続的に展開する必要がある場合、EF 移行は、このシナリオでは非常に制限的な OOTB であることがわかるため、開始するのに最適なツールではない可能性があります。