全体のAzureのWebロールの構成設定：アズールを使用する前にAzureの前に解放する環境
に、私たちは読み取り専用のだろう異なる環境で座っ設定ファイル（テスト、ステージング、生産など）。リリース中、問題の環境にすべてのアプリケーションファイル（設定ファイルなし）がデプロイされます。アプリケーションファイルは、接続文字列やその他の環境固有の詳細について環境の設定ファイルを読み込みます。私はこれがかなり標準的なセットアップだと思いますか？ Azureの後に解放
：
は、今、私たちは、Azureのウェブ役割に弊社のWebアプリケーションを移動しています。 WebロールはServiceConfiguration.Cloud.cscfgとServiceConfiguration.Local.cscfgのファイルを使用します。
クラウドサービスに公開する場合は、接続文字列を知る必要があります。テストクラウドサービスに公開したい場合は、それに応じてServiceConfiguration.Cloud.cscfgを編集する必要があります。ステージングまたはプロダクションクラウドサービスに公開する場合は、ServiceConfiguration.Cloud.cscfgをさらに変更する必要があります。
デプロイメントを行うときに、接続文字列から開発者を抽象化することをお勧めします。これにより、誤った環境を指す間違いを防ぐことができます（これには大きな影響があります）。これはどうすればできますか？
Azure管理ポータルでこれらの設定を変更できますが、この手順をリリースプロセスに含めると、開発者は管理ポータルにアクセスする必要があります。これは理想的な状況ではありません。エラー（管理ポータルへの「オープン」アクセス）にも余裕があります。
更新：
私はあなたがより多くの（名前変更）を追加することによって、あなたのサービスの設定ファイルを管理できることがわかった：正しいクラウドサービス（黒）を選択して
そして、正しいサービス構成（赤い矢印）を一緒に使用すると、開発者は設定の詳細を知る必要はありません。
クラウドサービスを展開する際に、誤ったサービス構成を選択する開発者の問題はまだあります（おそらく、これはこれを防止するためのスクリプトに自動化することができますか？）
私の主なIRKは、環境タイプです（青い矢印）。これは今私には役に立たない。
を持っている私がチェックする必要があると思いますが、私はこれが唯一のあなたが設定していないサービス定義を選択することができますだと思います。したがって、さまざまなエンドポイント（httpとhttps）、異なるVmサイズなどを環境間で使いたい場合は、問題にぶつかる可能性があります。私の答えの側面の解決策は、これを実行します。 –
@ Eoin：ああ、サービス定義に関しては良い点だ。これは問題になります。最後の質問：「展開パッケージ」を持たずにコードをバージョン管理できるか？コードが変更されたかどうかわからないので、Visual Studioから直接公開することは少し怖いです。 – davenewza
私たちの場合、私たちのソースコードはソース管理に使用するGitHubに格納されているので、ブランチを作成し、リリースの内容をロックし、Masterで開発を進めるための独自のプロセスを用意しています。プロダクションリリースを行うときは、サインしたブランチからデプロイするだけです。 –