私のチームでこれを処理する方法は、製品をソース管理に組み込むために必要なすべての参照を実際にチェックすることです。.NET フレームワーク自体以外のもの、およびビルド コントローラー/ビルド エージェントをインストールするために取得したものはすべて、チェックインされます。
正のビット:
- ビルド エージェントのセットアップは簡単です (「Server 2K8R2 をインストールし、ビルド エージェントをインストールし、ビルドを開始する」だけです)。
- 人々の開発ボックスに合わせて複雑な SDK のインストールを心配する必要はありません。参照はすべて、ソース管理にチェックインされた正確なバージョンです。
- バイナリバージョン コントロールが得られます。つまり、メンテナンス リリースを行い、特定の API の昨年のバージョンに対してビルドする必要がある場合、それは非常に簡単です。
負のビット:
- ソース管理を少し肥大化させる
- バイナリをソース管理にチェックインするのは奇妙に感じます
- バイナリをチェックインする方法の構造と清潔さを維持することに非常に注意する必要があります。そうしないと、簡単に制御不能になる可能性があります
それを超えて、ビルドエージェントからテストビットを機能させる限り..おそらく最も簡単な方法は、テストエージェントをインストールすることです. VS2010 の UI 自動化は、"CodedUI Test" フレームワークです。通常の VS ユニット テスト フレームワークを拡張しますが、動作させるには追加の登録が必要です。
より複雑ですが、長期的に非常に役立つのは、完全な "Visual Studio Lab Management" プラットフォームをセットアップすることです。欠点は、それを十分に活用するには、System Center Virtual Machine Manager サーバーと少なくとも 1 つの Hyper-V ホストを接続し、「クリーンな」VM スナップショット (使用する製品を除くすべて) を使用して仮想マシンを構築する必要があることです。再テストがインストールされています)。すべてが整ったら、非常に洗練されたエンドツーエンドのビルド、デプロイ、テストのエクスペリエンスが得られます.ビルドシステムを介して製品のビルドをトリガーし、それが完了すると、環境が完全にクリーンな状態に復元されます (残り物の心配はありません)最後のバージョンのビットがテストを破損するなど)、製品がこのテスト環境に公開され、テストが実行されます。
作業項目の追跡、テストケースの管理、プロジェクトの計画などに TFS を使用しているかどうかは不明です。使用していない場合は、ラボの管理が重すぎて処理できない可能性があります。その部分をいじることに興味がある場合は、ここで詳細を確認してください。:)