在项目生命周期内记录构建/测试机器设置的最佳实践是什么？如果您需要为以前版本的产品提供补丁，则可能需要重新加载相同的编译器和支持工具以重新发布修补版本。你记录什么以及如何记录？显而易见的事情是：
操作系统版本和补丁级别，编译器/ IDE版本和补丁级别
第三方工具/库。
我的第一个想法是保留所有要求的日志文件。此日志文件将进入您的VCS。
答案 0 :(得分：2)
我正在将maven用于带有enforcerer插件的java，所以所有这些都存储在我的项目对象模型中，甚至是maven本身的版本。只要我设法从版本控制中获得正确的版本，我就可以免费使用。
答案 1 :(得分：2)
VMWare虚拟化（或其他类似产品）非常适合此类事物。构建一个完整的开发/构建/或测试环境，并将其设置为仅用于此目的。您可以将图像脱机，将其备份到DVD，然后在需要时将其重新打开。
答案 2 :(得分：1)
第三方工具和库与其他所有内容一起进入版本控制;我们有一个libs树，它位于我们的应用程序树旁边的VCS主干下，因此它包含在我们创建的任何分支或标签中。我尚未解决的一个问题是Windows工具和库需要自己的安装程序而不是耗尽VCS提供的任何目录。
对于操作系统和编译器，如果您无法并行安装多个编译器版本，我建议为每个版本创建一个VM。然后，您的项目Wiki可以记录哪个VM以及用于给定构建的编译器版本。这不像您的日志文件那样自动，但它提供了一个随时可用的环境（而不是可能需要重新安装一台机器来匹配您的日志文件）。有些项目会将整个编译器检查为版本控制，但这对我来说似乎有些过分（并且不适合需要自己的安装程序的IDE和编译器）。
我们不跟踪操作系统和编译器的补丁级别。我意识到修补程序可能会破坏或改变某些东西，但机会似乎很低，以至于成本效益比不存在。