私は、独自の（SQL Azure）データベースを使用してプロダクションとステージングの両方を展開しています。ステージングのスキーマが変更され、本番環境に導入する必要がある場合は、本番データベースでデータベースをアップグレードするための明確な方法があります（ダウンタイムなし）。データベーススキーマが変更された場合のAzureシームレスアップグレード
私がVIPステージング< - > productionをスワップすると（と同時に接続文字列の変更を自動化する）、sql Azureデータベースのアップグレードを自動化する最適なプロセスは何ですか？
私は、RoleEnvironmentChanging（VIPスワップでもRoleEnvironmentChanginngが起きているとは確信していませんが）の環境変化を見つけ、その時点でデータベース（つまりprod）に対してSQLスクリプトを実行することを考えました。スクリプトは一度だけ実行され、複数のインスタンスが移行することを確認してください。
したがって、独自のSQL Azureデータベースと独自のSQL Azureデータベースを持つステージング展開がある本番展開があります。この状況では、アプリケーションは2つの異なるデータベースを指す接続文字列を持っています。
あなたの最初の要件は、デプロイメントを入れ替えるか、何かをするとき、その場でのデータベースのスキーマを変更することであり、私はそのデザインと、以下の懸念があります。あなたがする役割内の任意のコードを記述する場合
を「1回のみ」のアクションは、これが1回起こるという保証はありません。あなたが守るかもしれない
1.2最後のイメージを再作成時にあなたはVMがシステムによって再イメージ化する必要があり、このコードは、それが何をしたか、正確に同じことをするでしょうどのような状況では、このような
1.1のように、いくつかのシナリオに依存して、複数のタイムが起こるのだろうそれはロールスタートやVMのいくつかの外部キーのいくつかのレジストリメソッドによって開始されませんが発生することはない完全な証明メカニズムがあります。
あなたはあなたができるあなたの展開を交換する準備ができているとき、私はお勧めしますので、それの：
2.1は、生産関連のSQL Azureのスキーマに更新するスクリプトを実行します（これがため、アプリケーションのダウンロードへの影響はありません
2.2ステージング展開の構成を運用SQL Azureを指すように変更します（これにより、運用アプリケーションのダウンタイムはまったく発生しません）
2.3 SWAP the deplo yment（これも何のアプリケーションのダウンタイムを持っていません）
ありがとうございます。私は2でのあなたの提案は、私たちがやることだと思います（確かに当初）。しかし、1の懸念に関して、私はデータベース内の何かのバージョンテーブルを使用することを考えていたので、データベースは常にバージョンを知っていて、スクリプトが2回実行されないようにしています（EFの移行を使用すると、既にそのテーブルがある__MigrationHistory ... hmmm）。私はもちろん、ちょうど同じ時間に始まる2つのインスタンスに対して緩和する必要があります。 – Ian1971
はい、マシンの外で何かを使用している場合は動作します。オプション1）は、永続化しないVM自体のコードにコードを依存させる場合にのみ懸念されました。 – AvkashChauhan
私はこれまでのベストプラクティスを全面的に検討しており、誰も見つけられていません。
この方法では、約5分のダウンタイムがあります。私のデータベースは小さく、Vmの作成やユーザーのエラーを待つよりも優れています。
良い質問です。私が知っていることは、ほぼ確実です。（1）VIP交換はRoleEnvironmentChangingを引き起こさないでしょう。 （2）接続文字列を変更する唯一の方法は、プログラムでweb.configを編集し、その新しい接続文字列を別の場所（？）に置くことです。 （3）これまでの接続文字列の変更は自動化されていません。そのため、ステージング展開はまったく使用しません。したがって、サービスのアップグレード中にダウンタイムやエラーが発生した方が良いかもしれません。新しいバージョンを実稼働環境に/テストがステージングにパスした後でアップグレードしてください。 – astaykov