version-control - 如何对构建工具和库进行版本控制？

Question

在源代码控制系统本身中包含编译器、库和其他工具有哪些建议？

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

我考虑过的选项包括：

将安装 CD ISO 复制到源代码控制 - 虽然这提供了我们需要返回到旧版本时所需的备份，但这不是“实时”使用的好选择（每个构建都需要从安装步骤开始，这很容易将 1 小时的构建时间变成 3 小时）。
将软件安装到源代码控制。ClearCase 将您的分支映射到驱动器号；我们可以在这个驱动器下安装软件。这不考虑安装工具的非文件部分，如注册表设置。
在虚拟机中安装所有软件并设置构建过程，将虚拟机存储在源代码管理中，并弄清楚如何让虚拟机在启动时进行构建。虽然我们轻松地捕获了“构建机器”的状态，但我们得到了 VM 的开销，并且它无助于“为开发人员提供相同的工具问题”。

这似乎是配置管理的一个基本概念，但我一直无法找到任何资源来了解如何做到这一点。有什么建议？

score 5 · Accepted Answer

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

开发人员没有理由不能复制同一个 VM 以便能够在干净的环境中进行调试。如果你的架构中有很多物理层，比如邮件服务器、数据库服务器等，你的问题会更复杂。

score 4 · Accepted Answer

这是非常特定于您的环境的东西。这就是为什么您不会看到处理所有情况的指南。我工作过的所有不同的商店都有不同的处理方式。我只能就我认为对我最有效的方法发表意见。

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

score 2 · Accepted Answer

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

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

score 1 · Accepted Answer

只需注意版本控制系统中库的版本控制：

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

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

您不想通过网络访问您的库（例如通过动态视图），因为编译时间比使用本地访问的库文件时要长得多。
您确实想在磁盘上获取这些库，这意味着快照视图，意味着下载这些文件......这就是您可能会欣赏库打包的地方：您必须下载的文件越少，您就越好;)

score 0 · Accepted Answer

跟进我自己的问题，我遇到了另一个问题的答案中引用的这篇文章。虽然更多的是对这个问题的讨论而不是回答，但它确实提到了 VM 的想法。

score 0 · Accepted Answer

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

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

score 0 · Accepted Answer

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

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

也许流行的 CI 工具可以让您避免在版本控制系统中存储多个 IDE。

score 0 · Accepted Answer

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

score 0 · Accepted Answer

至于“弄清楚如何在启动时构建”：我使用由一位系统管理员和一位开发人员快速定制的构建农场系统进行了开发。构建从属向任务主管查询合适的排队构建请求。这很不错。

如果请求的工具链要求与从站上的工具链版本匹配 - 包括什么操作系统，则该请求“适合”从站，因为该产品是多平台的，并且构建可以包括自动化测试。通常这是“当前最先进的技术”，但并非必须如此。

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

从站不必是虚拟机，但通常是。从站的数量（以及它们运行的物理机器）可以扩展以满足需求。奴隶显然可以随时添加到系统中，或者如果工具链崩溃，则可以使用核武器。这实际上是这个方案的重点，而不是你归档工具链状态的问题，但我认为它是适用的。

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

version-control - 如何对构建工具和库进行版本控制？

9 回答 9

Related

Reference