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

Question

将您的编译器，库和其他工具纳入您的源代码管理系统本身的建议是什么？

在过去，我遇到了一些问题，虽然我们有所有的源代码，但构建产品的旧版本是一个急于尝试获取Visual Studio，InstallShield和其他工具（包括正确的补丁版本）用于构建产品。在我的下一个项目中，我希望通过将这些构建工具检入源代码控制来避免这种情况，然后使用它们进行构建。这也可以简化建立新机器的工作 - 1）安装我们的源代码控制工具，2）指向正确的分支，3）构建 - 就是这样。

选项我已经考虑包括：

• 复制安装光盘ISO到源代码控制 - 虽然这提供了如果我们回到旧的版本中，我们所需要的备份，这是不是一个好“实时”使用选项（每个构建需要从安装步骤开始，可以轻松将1小时构建转换为3小时）。
• 安装软件源代码控制。 ClearCase将你的分支映射到一个盘符;我们可以在该驱动器下安装该软件。这不考虑安装工具的非文件部分，如注册表设置。
• 安装的所有软件和设置构建过程在虚拟机中，存储虚拟机的源代码控制，并找出如何让虚拟机在引导做一个版本。尽管我们很容易捕捉到“构建机器”的状态，但是我们获得了虚拟机的开销，而且它无法帮助“为开发人员提供相同的工具”。

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

Answer 1

我的组织具有“只读”的文件系统，这里的一切投入和版本。发布链接（基本上是符号链接）指向您的项目正在使用的版本。当新版本出现时，它只是添加到文件系统中，并且可以将符号链接放到文件系统中。有完整的符号链接审计历史记录，您可以为不同版本创建新的符号链接。

这种做法在Linux上的伟大工程，但它并不适用于Windows的应用程序，往往喜欢用的东西本地的机器，如注册表来存储配置一样的东西这么好。

Answer 2

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

开发人员没有理由不能在同一个虚拟机的副本上进行调试。如果体系结构中有许多物理层，比如邮件服务器，数据库服务器等，则问题会更复杂。

Answer 3

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

为.NET例如，您可以指定每个构建特定的框架。

也许流行的CI工具，无论你正在开发的有自己的选择，让你避免你的版本控制系统中存储数的IDE。

Answer 4

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

你有没有考虑鬼影新开发的机器，是能够建立版本中，如果你不喜欢一个VM图像的想法？当然，保持运行的硬件变化是幻影图像可能会更麻烦比它的价值......

Answer 5

这是这是非常具体的环境。这就是为什么你不会看到一个指导来处理所有情况。我工作过的所有不同的商店都有不同的处理方式。我只能给你我对我认为最适合我的看法。

• 建源控制下的新工作站 在 应用需要将所有的东西。
• 保持较大的 应用程序脱离源代码管理， 像IDE，SDK和数据库 引擎的东西。将这些文件保存在ISO文件的目录中。
• 维护一个带有源代码的文本文档，其中包含构建应用程序所需的ISO文件列表。

Answer 6

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

Answer 7

在我自己的问题的后续行动，我碰到在回答另一个问题引用this posting。虽然更多的讨论这个问题比aswer，它确实提到了VM的想法。

Answer 8

至于“搞清楚如何建立在启动”：我用一个构建农场系统自定义创建一个系统管理员和一个开发发展很快。构建从站查询taskmaster是否有合适的排队构建请求。这很好。

的请求是“合适的”用于从属如果工具链的要求相匹配的从机的工具链版本 - 包括什么操作系统，因为该产品是多平台和构建可以包括自动测试。通常这是“当前的艺术状态”，但不一定是。

当奴隶是准备建，它只是开始投票的工头，告诉它有安装了什么。它不必事先知道它预计会建立什么。它获取一个构建请求，告诉它要检查某些标记出SVN的，然后从这些标签中的一个运行一个脚本来把它从那里。开发人员不必知道很多构建奴如何可用，他们叫什么，或者他们是否很忙，只是如何添加到构建队列的请求。构建队列本身是一个相当简单的Web应用程序。所有非常模块化。

奴隶不一定是虚拟机，但通常是。从站（与物理机，他们正在运行的）的数量可以扩展到满足需求。奴隶显然可以随时添加到系统中，或者在工具链崩溃时加入。这实际上是这个方案的主要观点，而不是归档工具链状态的问题，但我认为这是适用的。

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

Answer 9

对图书馆的版本控制系统的versionning刚一说明：

• 这是一个很好的解决方案但它意味着包装（即减少库的文件的数量降到最低）
• 它没有解决'配置方面'（即“我的'3.2'项目需要什么特定的一组库'）。
  不要忘记，随着项目的每个新版本都会发生变化。 UCM及其“复合基线”可能会为此提供答案的开始。
  • 你不想通过网络访问您的库（比如虽然动态视图），因为编译时间是：因为

  的包装方面（文件的最小数量）是非常重要的比使用本地访问的库文件时长得多。

• 你确实想要在磁盘上获得这些库，这意味着快照视图，这意味着下载这些文件......这是你可能会喜欢你的库的包装：你需要下载的文件越少，你越好;）