c# - Azureワーカーの役割をローカル/オンプレミスでホストするにはどうすればよいですか？

Question

いくつかの背景...

私たちは初めてAzureに参入し、赤ちゃんのステップでそれを実行しようとしています。今のところ、最初のアプリは、リクエストを処理するためのキューを監視するワーカーロール（メールの送信や画面のスクレイピングの実行など）であり、オンプレミスのMVCアプリとWCFサービスからキューに挿入するだけです。後でMVCアプリとWCFサービスをAzureに移動します。

私たちの開発ワークフローは基本的に次のようになります（重要でない方法で多少変更されています）。

1. ローカルおよび一部の共有サーバーで開発します。ソース管理にチェックインします。
2. 15分ごとに、ビルドサーバーがビルドされ、「開発」環境にデプロイされます（CIを兼ねて、ローカル以外の「開発」環境に到達する必要がある場合に備えます）
3. テクニカルテスターは、ビルドサーバーを手動でトリガーして、最後に成功した「開発」ビルドをテスト環境にデプロイします（または、データベースを含む/除外する以前にデプロイされたテストビルド）。
4. テクニカルテスターとビジネステスターは、ビルドサーバーを手動でトリガーして、最後に成功した「テスト」ビルド（または、データベースを含む/除外する以前にデプロイされたテストビルド）をQA環境にデプロイします。
5. ある時点で、QAが展開を承認したチェンジセットをマージします。
6. その後、本番ビルドサーバーはこのバージョンをステージングにデプロイし、その後本番環境にデプロイします（並列/独立環境でN回ホストします）。

お分かりのように、本番環境に到達する前に内部サポート担当者が攻撃するために、内部でホストされているバージョンのアプリがいくつかあります。これらのAzureへの依存度をかなり低くしたいと思います。サーバーの依存関係を完了する必要がないため、Azure Queuesやその他のメカニズムを引き続き使用しますが、ビルドサーバーをAzureにデプロイする必要はありません。これらの環境のすべてに対して（あるいは、すべてのホスティングに対して料金を支払います）。

では、Azureにデプロイされるコードを実際にテストする方法で、オンプレミスでワーカーロールを合理的にホストするにはどうすればよいでしょうか。

提案されているオプションの1つは、ラッパー/ファサードとしてワーカーロールを作成し、クラスライブラリ内ですべての実際の作業を実行することです。これが私たちの計画でした。ただし、これを「ホスト」できるようにするためのフォローアップは、スケジュールされたタスクまたはウィンドウとして実行できる方法で、ワーカーロールと同じ作業を実行する2番目のラッパー/ファサードアプリケーションを作成することです。サーバ。最終的に、プロジェクト全体がステージングに到達するまでテストされないため、このオプションは好きではありません。

実際に参照するクラスライブラリを呼び出す代わりにRun()、ワーカーロールの関数を呼び出す2番目のラッパー/ファサードアプリケーションを作成する場合と同様のことを行うことは可能ですか？

Answer 1

Azureエミュレーターが役立つと思いますか？これらは、実際のAzureプロバイダーとエミュレーターの違いです。

あなたの労働者の役割のためのファサードを持つことは合理的であるように思われます。そして、アダプターを使用して、考えられるクラウド（または他のホスティング）テクノロジーをそのファサードに適合させますか？いくつかのアイデアを投入しようとしています。私は以前にこのアプローチを実際に使用しましたが、「個人的な」プロジェクトでした。

PowerShellを使用して、役割などを構成します。Azureエミュレーターを次のように構成します。

Answer 2

正直なところ、ファサードアプローチは採用するのに最適なアプローチです。

最終的にサポートインフラストラクチャに依存する展開がある場合、同一または同等のインフラストラクチャに展開するまで、完全にテストすることは非常に困難です。確かに、Azureワーカーの役割の場合です。

アプリケーションの機能面をインフラストラクチャのタッチポイントから切り離すことで、コードが正常に動作することを確認し、ファサードが正常に動作することを証明してから、最終的な組み合わせを信頼性テストすることができます。

テスト環境が本番環境と同一でない限り、この効果には常に妥協の要素があります。

そして、それがAzureステージングデプロイメントの目的です。本番環境に切り替える前の最後のレベルの信頼性テスト。

純粋にテストの後の段階のために、非常に小さなデプロイメントを作成できます。ロールがデプロイされる時間に対して料金を支払うため、テストが完了した後でデプロイメントを削除すると、コストを最小限に抑えることができます。

最後に、ファサードパターンは一例であり、テスト容易性のための設計です。コードを因数分解して、デプロイ前にテストできる量を最大化し、テストの後の段階でのリスクを最小化します。