環境に応じて異なるデータベースを使用するようにAzureにデプロイメントをセットアップする方法は？

Question

Azure Management Portalで、2つの配備をステージング環境と運用環境に簡単にスワップするには、そのVIPを交換します。ステージングバージョンのサービスで作業する場合、ステージングデータベースも使用したいので、実際の顧客データが壊れる危険はありません。ただし、ステージングサービスと運用サービスを交換した後は、現在の運用環境（および以前のステージング環境）で運用データベースを運用する必要があります。

だから、基本的に使用するデータベースインスタンスがステージングまたは生産環境で実行するかどうかに依存します。それを達成する良い方法はありますか？ VIPに依存し、それに基づいてデータベースの切り替えをハードコーディングすることは、おそらく最良のアイデアではないと思います。

Answer 1

従来の「ステージング環境」を使用した機能のサービスの「ステージングスロット」の使用を中止することをお勧めします。私がWindows Azureについて話しているときは、ステージングスロットを使用して新しい展開が実際に動作する前にテストすることを強く推奨します。彼らがより長期間にわたるテストを望むならば、私たちの多くはオンプレミスに慣れていて、別のサービスを使用しても、別のサブスクリプションを使用することもできます。

VIPスワップを実行する前に更新するプロダクションに固有の2番目のサービス構成を使用するか、またはサービスがどのスロットにあるかを検出できるようにするコードを記述するだけです2つの構成設定を適切に引き出します。

しかし、私が最初の段落で概説したように、私は物事を行う良い方法があると思います。 :)

Answer 2

Re： "ステージングバージョンのサービスで作業する場合、ステージングデータベースも使用したいので、実際の顧客データが壊れる危険はありません。"これを行うための組み込みの方法はありません。

実稼動データにリスクを伴うことなくテストする場合は、実稼働データベースにアクセスできない別のAzureアカウントでこのテストを行うことを検討してください。次に、システムがテストされ、稼働準備が整ったと思うときは、最終的なスモークテストのために、プロダクションインスタンスの隣にあるステージングスロットに持ち込んでください。

VIPスワップを実行する前にステージングインスタンスでいくつかのシナリオを実行したいが、運用データを汚染したくないシナリオを想像することができます。このため、多くの企業では特別なアカウントを使用しています。これらのアカウントに関連付けられたデータは、実際の顧客ではないことが知られています（または何らかの形でマークされている）ので、レポートや課金などは省略できます。

Re：「VIPに依存し、それに基づいてデータベースの切り替えをハードコーディングするのは、おそらく最良のアイデアではないと思います」ハードコーディングでは、上記のようなアプローチを使用すると、おそらく悪い考えではありませんが、それは設定ファイルから読み込むことを意味します。私は、「ステージングスロットにいて、コード内で何か違うことをしているかどうかを理解する」人たちについて聞いたことがありますが、私は上記のことをむしろお勧めします。

Answer 3

最近のAzure Webサイトのリリースでは、この記事の内容が変更されました。アプリ設定や接続文字列を「スロット設定」にして、特定のスロットに固定することができます。問題を解決するには、各スロットに接続文字列を設定し、「スロット設定」に注意してください。

これが現在推奨されているアプローチであるかどうかはわかりません。データベーススキーマの移行とロールバックは焼き付けられていないため、正しく処理する方法がわかりません。また、アプリの設定と接続文字列だけがこのように動作します。たとえば、system.netなどです。メールの設定をスロットに固定することはできません。そのためには、アプリの設定からメールサーバー情報などを取得するコードを変更するか、その他の方法を使用する必要があります。