だから私はthis questionを見ましたが、より一般的なアドバイスを探しています：ビルドサーバーをどのように指定しますか？具体的には、新しいビルドサーバに使用するプロセッサ、HD、RAMなどを正確に決定するために必要なステップは何ですか？仮想化を使用するかどうかを決定するにはどうすればよいですか？ビルドサーバーのハードウェア構成
私は、購入するハードウェアの決定に来るために必要な一般的な手順を探しています。私に具体的な結論を導くステップ - あなたが余裕ができるくらい多くのRAMの代わりに "私は4ギグのRAMを必要とする"と思う。
P.S.私は意図的に具体的な説明をしていません。なぜなら、私が教えてくれる人の魚の答えを探しているのではなく、自分の状況にしか当てはまらない答えです。
答えは、あなたのコードを "ビルド"するためにマシンが必要とする要件です。それはあなたが話しているコードに完全に依存しています。
数千行のコードでは、その古いデスクトップをクローゼットから引き出すだけです。その数十億行のコードが、あなたにブレードエンクロージャのローンを提供することについて銀行経営者と話していたら！
ビルドサーバーから始めるのに最適な場所だと思いますが、新しい開発者マシンを購入し、古いビルドマシンをビルドサーバーとして再構築することをお勧めします。
考慮すべき点： 同時にいくつのプロジェクトを作成する予定ですか？ 1つのプロジェクトが別のプロジェクトが完了するまで待つことは受け入れられますか？
CIビルドまたはスケジュールビルドを行っていますか？
通常、ビルドにはどのくらいの時間がかかりますか？
どのようなソフトウェアを使用していますか？
ほとんどのWebプロジェクトは、大規模なサーバーを購入するだけでは意味がないほど十分に小さい（5分以下のビルド時間）。
例として、 私たちは約20人の開発者が6つのプロジェクトに積極的に取り組んでいます。我々はすべてのプロジェクトに対してCIを実行する単一のTFS Buildサーバーを使用しています。すべてのチェックイン時にビルドされるように設定されています。
すべてのプロジェクトは3分以内で完了します。
ビルドサーバは、4GBのラムを備えたシングルクアッドコアです。私たちがそれを使用する主な理由は、QAのパフォーマンスの開発とステージングのビルドにあります。ビルドが完了すると、そのアプリケーションは適切なサーバーに自動的にデプロイされます。また、これらのプロジェクトに対するユニットテストとWebテストの実行も担当しています。
使用するビルドソフトウェアの種類は非常に重要です。 TFSは各コアを活用して、ソリューション内のプロジェクトを並列に構築することができます。ビルド・ソフトウェアがそれを実行できない場合は、必要に応じて複数のビルド・サーバーを調べることがあります。
私は、現在ビルドに使用しているシステムのビルドに関するパフォーマンスメトリックを収集することから始めます。私は特に、CPUとメモリの使用率、ディスクから読み書きされたデータ量、生成されたネットワークトラフィック（ある場合）の量を調べます。 Windowsでは、perfmonを使用してすべてのデータを取得できます。 Linuxでは、vmstat、iostat、topなどのツールを使用できます。ボトルネックがどこにあるのかを把握する - あなたのCPUをビルドするのですか？ディスクバインド？ RAMのために飢えた？これらの質問に対する答えはあなたの購入決定を導くでしょう。あなたのビルドがCPUを叩いてもデータはほとんど生成されない場合、悲鳴を上げるSCSIベースのRAIDディスクを入れることはお金の無駄です。
これらのメトリックを収集する際に、さまざまなレベルの並列性を使用してビルドを実行することをお勧めします。 gnumakeを使用している場合は、-j 2、-j 4、および-j 8でビルドを実行してください。これは、ビルドがCPUまたはディスクに制限されているかどうかを確認するのに役立ちます。
あなたのニーズに合った適切なビルドサーバーが、実際には1つの大きなボックスではなく、安価なシステムのクラスタである可能性があると考えてください - gmake/distcc、pvmgmake、ElectricAccelerator、など）は、あなたが1つの大きなシステムにするよりも安価なコンピュータの配列を活用するのに役立ちます。
当店では、数千行のコードから数十万行に及ぶ16の製品をサポートしています。 3台のHPサーバー（約5年）、デュアルクアッドコアと10GBのRAMを使用しています。ディスクは7200 RPMのSCSIドライブです。コマンドラインでmsbuildを使用してコンパイルし、並列コンパイルを有効にします。
この設定では、最大のボトルネックはディスクI/Oです。私たちはソースコードを完全に抹消し、すべてのビルドで再チェックアウトし、削除とチェックアウトの時間は本当に遅いです。編集や出版の時間も遅いです。 CPUとRAMは遠隔課税されません。
私はこれらのサーバをリフレッシュする途中ですので、私はワークステーションクラスのマシンのルートを使い、3つではなく4つで、SCSIドライブを最高の/最速のSSDで置き換えています。このような設定をしている場合は、ディスクI/Oを考慮する必要があります。