如何控制构建工具和库的版本？

Question

在源代码管理系统中包含编译器，库和其他工具有哪些建议？

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

我考虑的选项包括：

• 将安装CD ISO复制到源代码控制 - 虽然这提供了我们需要的备份，如果我们必须回到旧版本，它不是“实时”使用的好选项（每个构建都需要从安装步骤，可以轻松将1小时的构建时间转换为3小时）。
• 将软件安装到源代码管理。 ClearCase将您的分支映射到驱动器号;我们可以在这个驱动器下安装软件。这不会考虑安装工具的非文件部分，例如注册表设置。
• 安装所有软件并在虚拟机内设置构建过程，将虚拟机存储在源代码管理中，并确定如何让VM在引导时进行构建。虽然我们轻松捕获“构建机器”的状态，但我们获得了VM的开销，并且它对“为开发人员提供相同的工具问题”没有帮助。

这似乎是配置管理的基本概念，但我无法追踪任何资源以了解如何执行此操作。有什么建议？

Answer 1

我认为VM是您最好的解决方案。我们总是使用专用的构建机器来获得一致性。在旧的COM DLL Hell days中，在安装的非开发软件（Office）上存在依赖（COMCAT.DLL，任何人）。您的前两个选项无法解决任何共享COM组件的问题。如果您没有任何共享组件问题，可能会有效。

没有理由开发人员无法获取相同VM的副本以便能够在干净的环境中进行调试。如果您的架构中有很多物理层，例如邮件服务器，数据库服务器等，那么您的问题会更复杂。

Answer 2

这是一种非常特定于您的环境的东西。这就是为什么你不会看到处理所有情况的指南。我工作过的所有不同的商店都以不同的方式处理了这个问题。我只能就我认为最适合我的方式给出你的意见。

• 放置所需的一切来构建 应用于新工作站 在源头控制下。
• 保持大 应用程序不受源代码管理， IDE，SDK和数据库之类的东西 引擎。将它们作为ISO文件保存在目录中。
• 使用源代码维护一个文本文档，其中包含构建应用程序所需的ISO文件列表。

Answer 3

我肯定会考虑围绕这个想法的法律/许可问题。是否可以根据工具链的各种许可证进行许可？

如果您不喜欢虚拟机映像的想法，您是否考虑过重影一个能够构建版本的全新开发机器？当然，保持幻影图像作为硬件更改运行可能比它的价值更麻烦......

Answer 4

关于版本控制系统中库的版本控制的说明：

• 这是一个很好的解决方案但是 意味着打包（即将该库的文件数量减少到最低限度）
• 它没有解决'配置方面'（即“我的'3.2'项目需要什么特定的库？”）。 不要忘记，随着项目的每个新版本，该集合都会发展。 UCM及其“复合基线”可能会为此提供答案。

打包方面（最小文件数）非常重要，因为：

• 您不希望通过网络访问您的库（如动态视图），因为编译时间比使用本地访问的库文件时要长得多。
• 你确实希望在你的磁盘上获得这些库，这意味着快照视图，这意味着下载这些文件......这就是你可能会喜欢你的库的包装：你需要下载的文件越少，你就越好;）

Answer 5

我的组织有一个“只读”文件系统，其中所有内容都放在版本和版本中。 Releaselinks（主要是符号链接）指向项目使用的版本。当新版本出现时，它只是添加到文件系统中，您可以将符号链接转移到它。有符号链接的完整审计历史记录，您可以为不同版本创建新的符号链接。

这种方法在Linux上运行良好，但对于那些倾向于使用机器本地内容（如注册表）来存储配置等内容的Windows应用程序来说效果不佳。

Answer 6

您是否正在使用像NAnt这样的持续集成（CI）工具进行构建？

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

对于您正在开发的任何内容，流行的CI工具可能具有允许您避免在版本控制系统中存储多个IDE的选项。

Answer 7

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

Answer 8

根据我自己的问题，我在另一个问题的答案中提到了this posting。虽然对问题的讨论多于一个aswer，但确实提到了VM的想法。

Answer 9

至于“弄清楚如何构建引导”：我使用由一个系统管理员和一个开发人员快速定制创建的构建服务器场系统开发。构建从属服务器查询taskmaster以获取适当的排队构建请求。这很不错。

如果奴隶的工具链要求与奴隶上的工具链版本相匹配，那么请求“适合”从属 - 包括什么操作系统，因为产品是多平台的，并且构建可以包括自动化测试。通常这是“现有技术”，但不一定是。

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

奴隶不一定是虚拟机，但通常都是。可以缩放从站（以及它们运行的​​物理机器）的数量以满足需求。很明显，奴隶可以随时添加到系统中，或者如果工具链崩溃，则可能会被激活。这实际上是这个方案的要点，而不是存档工具链状态的问题，但我认为它是适用的。

根据您需要旧工具链的频率，您可能希望构建队列能够根据需要启动VM，否则想要重新创建旧构建的人也必须安排合适的从属服务器出现。并不是说这一定很难 - 可能只是在他们选择的机器上启动正确的VM的问题。