コードファーストの移行とステージング環境でテストするためのベストプラクティス：アズール：私は、Windows Azureの中で次のセットアップを持っている
- 「テスト」独自の「テスト」データベースに接続ホスティングサービス。
- "本番"ホストサービスが、それ自身の "本番"データベースに接続しています。
ビルドがテストに検証し、生産に行く準備ができているとき、私たちは生産ホスティングサービスでは、「ステージング」の展開をスピンアップし、新しいビルドがないことを確認するために迅速なスモークテストを行います完全に壊れた。ステージング・インスタンスは、本番環境にデプロイされる正確なビットでデプロイされるため、本番データベースと通信しています。ステージングが祝福されたら、「VIP Swap」ボタンを押して、ビルドを本番稼働中に実行します。すべてが良いです。
データベースモデルが変更されると問題が発生します。 Code First Migrationは完全に機能しています。新しい移行を追加し、パッケージマネージャコンソールでローカルに適用してから、新しいビルドをテストするためにテストデータベースをアップグレードするSQLスクリプトを生成することができます。問題は、ステージング/プロダクションの展開と一緒にコードファーストマイグレーションを使用する場合のベストプラクティスは何ですか？モデルの変更を含むステージングに新しいビルドをデプロイすると、そのモデルに一致するデータベースが見つかることが予想されます。しかし、モデルの変更を本番データベースに適用すると、そのモデルが一致しないためにプロダクションインスタンスが不満を持ちます。
私はステージングスモークテストをスキップしました。ステージングにアップロードしてから、本番データベースを更新し、同時に「VIPスワップ」ボタンを押します。その後、生産についての煙検査。何かが重大に壊れている場合は、「VIPを交換」を元に戻し、データベースの変更を元に戻します。
これを行うには良い方法がありますか、それともそれほどですか？
ありがとうございます！
幸運いくつかがあれば、私は今考えることができる唯一のことは、「最新にアップグレードする」自動を無効にする、または自分のDbMigratorを広げていますステージングとプロダクションを区別する方法です。最善の方法は、ステージングデータベースをターゲットにしてアップグレードすることができ、別のDBをターゲットに交換するときです。しかし、スワップするときに何も起こらないので、どうしたらよいのか分かりません。 – FRoZeN
これは本当に壊れています。ステージングと移行は互換性がありません。スワップする前にステージングWebサーバーを移行しウォームアップする方法はありません。運用Webサーバーは、移行が適用されるとすぐに停止します。私はエンティティフレームワークが漸進的な変更（例えばテーブルの追加）を処理できると仮定します。これを行う唯一の方法は、別のステージングデータベースを使用することです。 –