logo标签列表

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

version-controlbuild-processbuild-automationclearcase
6
如何在源代码控制系统中包含编译器、库和其他工具？
过去，我遇到过这样的问题：尽管我们拥有所有的源代码，但构建旧版本的产品仍需四处奔波，试图获得用于构建产品的确切正确配置的Visual Studio、InstallShield和其他工具（包括正确的补丁版本）。在我的下一个项目中，我想通过将这些构建工具检入源代码控制系统中，并使用它们进行构建来避免这种情况。这也会简化设置新的构建机器的事情——1）安装我们的源代码控制工具，2）指向正确的分支，3）构建——就这么简单。
我考虑的选项包括：
- 将安装CD ISO复制到源代码控制系统中——尽管这提供了我们需要的备份，以便我们回到旧版本，但这不是“实时”使用的好选择（每次构建都需要从安装步骤开始，这可能会使一个1小时的构建变成3小时）。 - 将软件安装到源代码控制系统中。ClearCase将您的分支映射到驱动器号；我们可以在此驱动器下安装软件。这没有考虑到安装工具的非文件部分，比如注册表设置。 - 在虚拟机中安装所有软件并设置构建过程，将虚拟机存储在源代码控制系统中，并找出如何在启动时让VM进行构建。虽然我们轻松捕获了“构建机器”的状态，但我们需要承担VM的开销，而且它对于“使相同的工具可用于开发人员问题”没有帮助。
这似乎是配置管理的基本思想，但我一直无法找到任何资源来解决这个问题。有什么建议吗？
你需要回去重建旧版本的原因是什么？是为了调试目的吗？还是因为你没有归档最终产品？ - JKueck
9个回答
5
我认为虚拟机是您的最佳解决方案。我们通常使用专用的构建机器来保证一致性。在旧的COM DLL Hell时代，非开发软件（如Office）安装了依赖项（COMCAT.DLL，任何人都可以），存在共享COM组件的问题，您前两个选项都无法解决。如果您没有任何共享组件问题，也许它们会起作用。
开发人员可以复制同一个虚拟机以便在干净的环境中进行调试，这样就没有理由了。如果您的架构中有很多物理层，例如邮件服务器，数据库服务器等，则您的问题会更加复杂。
4

这是很具体的环境需求，因此你不会看到一份适用于所有情况的指南。我曾经为不同的商店工作过，它们都有不同的处理方式。我只能给出我认为对我最有效的建议。

  • 将构建应用程序所需的所有内容放入源代码控制下的新工作站中。
  • 不要将大型应用程序放入源代码控制中，例如IDE、SDK和数据库引擎。将这些文件保存在一个包含ISO文件的目录中。
  • 维护一个文本文档，其中包含源代码和构建应用程序所需的ISO文件列表。
2
我会考虑与您的工具链相关的法律/许可问题。根据各种许可证，这个想法是否可行？
如果您不喜欢虚拟机镜像的想法，您是否考虑过使用全新的开发机器来构建发布版本？当然，保持该ghosted镜像的运行可能比它值得的麻烦更多...
1

关于在版本控制系统中对库进行版本控制的注意事项：

  • 这是一个好的解决方案，但它意味着打包（即将该库的文件数量减少到最小）
  • 它不能解决“配置方面”的问题（即“我的‘3.2’项目需要哪些特定的库集？”）。不要忘记，每个新版本的项目都会发生变化。UCM及其“组合基线”可能为此提供了一些答案。

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

  • 您不希望通过网络访问库（如动态视图），因为编译时间比使用本地访问的库文件长得多。
  • 您确实希望将这些库放在磁盘上，这意味着快照视图，也就是下载这些文件...这就是您可能欣赏库的打包方式的地方：您下载的文件越少，您就越好；）
0

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

这种方法在Linux上运作得很好，但对于倾向于使用本地机器（如注册表）存储配置等内容的Windows应用程序来说，情况并不那么理想。

0
你是否正在使用像NAnt这样的持续集成（CI）工具来进行构建？
例如，在.Net中，您可以为每个构建指定特定的框架。
也许您正在开发的流行CI工具有选项，可以避免在版本控制系统中存储多个IDE。
0
在许多情况下，您可以强制构建使用编译器和库，这些编译器和库已检入到您的源代码控制中，而不是依赖于全局机器设置，这些设置将来可能无法重现。例如，在使用C#编译器时，您可以使用 /nostdlib 开关，并手动 /reference 所有库以指向已检入源代码控制的版本。当然，也要将编译器本身检入源代码控制。
0
跟进我的问题，我发现这篇帖子被引用在另一个问题的答案中。虽然更多地是讨论问题而不是回答，但它提到了虚拟机的想法。
0
关于“如何在启动时构建”的问题：我使用了一个由一名系统管理员和一名开发人员快速自定义创建的构建农场系统进行开发。构建从属机会向任务主管查询适合的排队构建请求。这很不错。
如果一个请求的工具链要求与从属机上的工具链版本匹配（包括操作系统，因为产品是多平台的，构建可以包括自动化测试），则该请求对从属机来说是“合适”的。通常这是“最先进的状态”，但不必如此。
当从属机准备好构建时，它只需开始轮询任务主管，告诉它安装了什么即可。它不必预先知道它需要构建什么。它获取一个构建请求，该请求告诉它从SVN中检出某些标记，然后运行其中一个标记的脚本以继续进行。开发人员不必知道有多少构建从属机可用，它们叫什么或者它们是否繁忙，只需知道如何将请求添加到构建队列中。构建队列本身是一个相当简单的Web应用程序。所有都非常模块化。

从编程角度来看，从属机器不一定是虚拟机，但通常都是。从属机器（以及它们运行的物理机器）的数量可以根据需求进行扩展。从属机器可以随时添加到系统中，或者在工具链崩溃时被删除。这实际上是这个方案的主要优点，而不是您对工具链状态归档的问题，但我认为它是适用的。

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

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接