11

Azure より前にリリース:

Azure を使用する前は、さまざまな環境 (テスト、ステージング、運用など) に読み取り専用の構成ファイルが置かれていました。リリース中に、すべてのアプリケーション ファイル (構成ファイルを除く) が問題の環境にデプロイされます。次に、アプリケーション ファイルは、接続文字列やその他の環境固有の詳細について、環境の構成ファイルを読み取ります。これはかなり標準的な設定だと思いますか?

Azure の後にリリース:

現在、Web アプリケーションを Azure Web Roles に移行しています。Web ロールの使用ServiceConfiguration.Cloud.cscfgServiceConfiguration.Local.cscfgファイル。

クラウド サービスに発行するときは、接続文字列を認識している必要があります。テスト クラウド サービスに公開する場合は、それにServiceConfiguration.Cloud.cscfg応じて編集する必要があります。ステージングまたは本番クラウド サービスに公開する場合は、ServiceConfiguration.Cloud.cscfgさらに変更する必要があります。

私は、開発者がデプロイを行うときに、接続文字列から離れて開発者を抽象化することを強く望んでいます。これにより、誤った環境を指し示すミス (大きな影響を与える可能性があります) を防ぐことができます。これはどのように行うことができますか?

これらの構成設定は Azure 管理ポータルで変更できることは理解していますが、この手順をリリース プロセスに含めることは、開発者が管理ポータルにアクセスする必要があることを意味します。エラー (および管理ポータルへの「開く」アクセス)。

アップデート:

サービス構成ファイルをさらに追加 (および名前変更) することで管理できることがわかりました。

ここに画像の説明を入力

次に、正しいクラウド サービス (黒) と正しいサービス構成 (赤い矢印) を一緒に選択することで、開発者は構成の詳細を意識する必要がなくなります。

ここに画像の説明を入力

開発者がクラウド サービスにデプロイするときに間違ったサービス構成を選択するという問題はまだあります (しかし、おそらくこれをスクリプトに自動化して、これを防ぐことができますか?)

私の主な悩みは、環境タイプ (青い矢印) です。これは今の私には何の役にも立ちません。

4

1 に答える 1

5

各環境に 1 つずつ、複数のクラウド デプロイ プロジェクトを作成して、それぞれが異なる ServiceConfiguration を持つようにすることをお勧めします。

私のアプリケーションには、3 つのアプリケーション プロジェクト (1 つの WebRole と 2 つのワーカー ロール) があります。

次に、ターゲット環境ごとに 1 つずつ、合計 6 つの Cloud Deployment プロジェクトがあります。各展開プロジェクトには同じ Web ロールとワーカー ロールが含まれていますが、cscfg&csdefファイルは異なります。

ソリューション組織

アプリケーション レベルでは、app.config および web.config ファイルは、SlowCheetahを使用した構成変換によって処理されます。基本的に、構成マネージャーには、展開ごとに異なるビルド構成があります。Debugだからとの代わりにRelease, Debug, QA,UatTestありSAndboxますProduction

于 2013-07-03T14:05:14.977 に答える