13

WindowsAzureには次のセットアップがあります。

  • 独自の「テスト」データベースに接続された「テスト」ホスト型サービス。
  • 独自の「本番」データベースに接続された「本番」ホスト型サービス。

ビルドがテストで検証され、本番環境に移行する準備ができたら、本番環境でホストされるサービスで「ステージング」デプロイメントを起動し、簡単なスモークテストを実行して、新しいビルドが完全に壊れていないことを確認します。ステージングインスタンスは、本番環境にデプロイされる正確なビットでデプロイされるため、本番データベースと通信します。ステージングが祝福されたら、「VIPスワップ」ボタンを押すと、ビルドが本番環境でライブになります。すべてが良いです。

問題は、データベースモデルが変更されたときに発生します。コードファーストマイグレーションは完全に機能しています。新しい移行を追加し、パッケージマネージャーコンソールを使用してローカルに適用し、SQLスクリプトを生成して、新しいビルドをテストにプッシュするときにテストデータベースをアップグレードできます。問題は、ステージング/本番デプロイメントと一緒にコードファーストマイグレーションを使用する際のベストプラクティスは何ですか？モデルを変更してステージングに新しいビルドをデプロイすると、そのモデルに一致するデータベースが見つかることが期待されます。しかし、モデルの変更を本番データベースに適用すると、モデルが一致しないため、本番インスタンスは文句を言います。

ステージングスモークテストをスキップしました。ステージングにアップロードしてから、本番データベースを更新し、ほぼ同時に[VIPスワップ]ボタンを押します。次に、生産のスモークテスト。何かが大きく壊れている場合は、「VIPを交換」してデータベースの変更を元に戻します。

これを行うためのより良い方法はありますか、それともそれはほとんどそれですか？

ありがとう！

4

2 に答える 2

0

何も見つからなかったため、ベストプラクティスが何であるかわかりません。また、ユーザーは自分のプロジェクトに最適なものを使用していて、自分たちのために機能しているようです。1つのシナリオでは、ソリューションは、本番DBが空で、ステージングデータベースが最初にEFコードで作成され、移行が適用されるという、説明した計画と同様でした。テストが完了すると、スクリプトは別のデータベースに転送され、後で本番環境に接続されました。

于 2012-07-04T00:10:49.073 に答える
0

私はAzure、EFなど、およびあなたのような同様のトピックに取り組んできました。現時点では、シナリオのベストプラクティスはわかりません。ただし、展開のリスクを最小限に抑えるには、TFSやGithubの継続的インテグレーションツールを使用するのが理にかなっていると思います。次の記事があなたに視点を提供することを願っています。

ここをクリック

幸運を

于 2015-09-26T17:02:40.700 に答える