对于将编译器，库和其他工具包含在源代码控制系统本身中的建议是什么？

过去，我遇到了这样的问题：尽管我们拥有所有源代码，但构建产品的旧版本却是在试图获得Visual Studio，InstallShield和其他工具(包括正确的修补程序版本)用于构建产品。在我的下一个项目中，我想通过将这些构建工具检入源代码控制中，然后使用它们进行构建来避免这种情况。这也将简化设置新构建机器的过程，-1)安装我们的源代码控制工具，2)指向正确的分支，3)构建-就是这样。

我考虑过的选项包括：

• 将安装CD ISO复制到源代码控制-尽管这提供了我们必须返回到较旧版本时所需的备份，但这不是"实时"使用的好选择(每个构建都需要从安装步骤开始，这很容易将1个小时的构建转换为3个小时)。
• 将软件安装到源代码管理。 ClearCase将分支映射到驱动器号；我们可以将软件安装在此驱动器下。这没有考虑安装工具的非文件部分，例如注册表设置。
• 安装所有软件并在虚拟机内部设置构建过程，将虚拟机存储在源代码管理中，并弄清楚如何使VM在引导时进行构建。在我们轻松捕获"构建机器"的状态的同时，我们获得了VM的开销，并且对于"使开发人员可以使用相同的工具"这一问题无济于事。

看来配置管理是一个基本概念，但是我一直无法找到任何有关执行此操作的资源。有什么建议？

解决方案

我的组织有一个"只读"文件系统，所有内容都放入发行版和版本中。发布链接(本质上是符号链接)指向项目正在使用的版本。当出现一个新版本时，它将被添加到文件系统中，我们可以对其链接进行链接。符号链接具有完整的审核历史记录，我们可以为不同版本创建新的符号链接。

这种方法在Linux上效果很好，但是对于倾向于使用计算机本地内容(例如注册表)存储诸如配置之类的Windows应用程序的情况，效果并不理想。

我认为VM是我们最好的解决方案。我们始终使用专用的构建机器来获得一致性。在旧的COM DLL地狱时代，安装的非开发软件(Office)依赖于(COMCAT.DLL，任何人)。前两个选项无法解决共享COM组件的任何问题。如果我们没有任何共享组件问题，也许它们会起作用。

开发人员没有理由无法复制同一虚拟机的副本以在干净的环境中进行调试。如果体系结构中有很多物理层，例如邮件服务器，数据库服务器等，问题将更加复杂。

我们是否正在使用像NAnt这样的持续集成(CI)工具来进行构建？

作为一个.Net示例，我们可以为每个构建指定特定的框架。

对于正在开发的任何内容，流行的CI工具也许都具有一些选项，这些选项将使我们避免在版本控制系统中存储多个IDE。

我肯定会考虑围绕该想法的法律/许可问题。根据工具链的各种许可，这是允许的吗？

如果我们不喜欢VM映像的想法，我们是否考虑过将能够构建该发行版的新开发机器重影？当然，随着硬件的变化而使重影映像继续运行可能比它值得的麻烦更多。

这是非常针对环境的。这就是为什么我们不会看到处理所有情况的指南。我工作过的所有不同商店的处理方式都不同。对于我认为最适合我的内容，我只能发表看法。

• 将构建应用程序所需的一切都放在源代码控制下的新工作站上。
• 大型应用程序应不受源代码控制，如IDE，SDK和数据库引擎之类。将它们作为ISO文件保存在目录中。
• 维护带有源代码的文本文档，其中包含构建应用程序将需要的ISO文件列表。

在许多情况下，我们可以强制构建使用检入到源代码管理中的编译器和库，而不是依赖将来无法重复使用的全局计算机设置。例如，对于Ccompiler，我们可以使用/ nostdlib开关并手动/ reference所有库以指向签入源代码管理的版本。当然，还要将编译器本身检查到源代码控制中。

在回答我自己的问题后，我遇到了在另一个问题的答案中引用的帖子。尽管对这个问题的讨论多于对问题的讨论，但它确实提到了VM的想法。

至于"弄清楚如何在启动时进行构建"：我使用的是由一名系统管理员和一名开发人员非常快速地自定义创建的构建服务器场系统。生成从属查询任务主管以获取合适的排队生成请求。很好

如果请求的从属工具链要求与从属服务器上的工具链版本(包括哪个OS)相匹配，则该请求"适合"从属服务器，因为该产品是多平台的，并且构建可以包含自动化测试。通常，这是"当前技术水平"，但不是必须如此。

当一个从服务器准备好构建时，它就开始轮询任务管理器，告诉它安装了什么。它不必事先知道预期要构建什么。它获取一个构建请求，告诉它从SVN中检查某些标签，然后从这些标签之一运行脚本以从那里获取它。开发人员不必知道如何向构建队列添加请求，就可以知道有多少可用的构建从属，被称为什么或者它们是否忙。构建队列本身是一个相当简单的Web应用程序。都是非常模块化的。

从站不必是VM，但通常是。可以缩放从站(及其运行的物理机)的数量，以满足需求。很明显，从站可以随时添加到系统，或者如果工具链崩溃则可以从站。这实际上是该方案的重点，而不是我们在归档工具链的状态时遇到的问题，但是我认为这是适用的。

根据需要旧工具链的频率，我们可能希望构建队列能够根据需要启动VM，因为否则，想要重新创建旧构建的人还必须安排合适的从属出现。并非一定一定很困难，这可能只是在他们选择的计算机上启动正确的VM的问题。

只是关于版本控制系统中库的版本控制的注释：

• 这是一个很好的解决方案，但是它意味着打包(即，将该库的文件数减少到最少)
• 它不能解决"配置方面"(即"我的'3.2'项目需要什么特定的库集？")。不要忘记，该设置会随着项目的每个新版本一起发展。 UCM及其"综合基准"可能会为此提供一个答案。

打包方面(最少文件数)很重要，因为：

• 我们不希望通过网络访问库(例如通过动态视图)，因为编译时间比使用本地访问的库文件时要长得多。
• 我们确实希望将这些库保存在磁盘上，即快照视图，即下载这些文件...，这是我们可能会欣赏库打包的地方：必须下载的文件越少越好；)