プロジェクトのライフタイム中にビルド/テストマシンのセットアップを記録するベストプラクティスは何ですか？以前のバージョンの製品にパッチを提供する必要がある場合は、パッチを適用したリリースを再発行するために同じコンパイラとサポートツールを再ロードする必要があります。何をどのように記録しますか？明らかなのは、
OSバージョンとパッチレベル、
コンパイラ/ IDEバージョン、パッチレベル
サードパーティのツール/ライブラリです。
私の最初の考えは、すべての要件のログファイルを保持することです。このログファイルはVCSに保存されます。製品のライフサイクル中にビルド環境を維持する方法
VMWare仮想化（または他の同様の製品）は、この種のものに最適です。開発/ビルド/テスト環境全体を構築し、その目的のためだけにセットアップをしておきます。イメージをオフラインで取り出し、DVDにバックアップし、必要なときに単にオンに戻すことができます。
私は、enforcererプラグインでjavaにmavenを使用しています。これらはすべて、プロジェクトオブジェクトモデルに格納されています。私がバージョン管理から適切なバージョンを手に入れることができれば、私は自宅にいます。
サードパーティのツールとライブラリは、他のすべてと一緒にバージョン管理されます。私たちはアプリケーションツリーのすぐ横にあるVCSの幹の下にあるlibsツリーを持っているので、私たちが作成するブランチやタグに含まれます。私がまだ解決していない1つのシワは、VCSが提供するディレクトリがなくても、独自のインストーラを必要とするWindowsツールとライブラリです。
OSとコンパイラについては、複数のコンパイラバージョンを同時にインストールできない場合は、リリースごとにVMを作成することをお勧めします。次に、プロジェクトwikiは、特定のビルドに使用するVMとコンパイラのバージョンを記録できます。これはログファイルのように自動ではありませんが、ログファイルに一致するようにマシンを再インストールする必要はありません。一部のプロジェクトでは、コンパイラ全体をバージョンコントロールにチェックしていますが、これは私にとって残念です（独自のインストーラが必要なIDEやコンパイラではうまく機能しません）。
OSとコンパイラのパッチレベルは追跡されません。パッチが何かを壊したり変えたりする可能性があることは分かっていますが、そのチャンスは非常に低く、費用対効果の比率はそこにはないようです。