如何对构建工具和库进行版本控制？
对于在源代码控制系统本身中包含编译器、库和其他工具有哪些建议？
在过去，我遇到过这样的问题：尽管我们拥有所有源代码，但构建产品的旧版本是一项忙于尝试获得 Visual Studio、InstallShield 和其他工具（包括正确的补丁版本）用于构建产品。 在我的下一个项目中，我想通过将这些构建工具检查到源代码管理中，然后使用它们进行构建来避免这种情况。 这也将简化设置新构建机器的过程——1）安装我们的源代码控制工具，2）指向正确的分支，3）构建——就是这样。
我考虑过的选项包括：
- 将安装 CD ISO 复制到源代码管理 - 尽管这提供了我们必须返回到旧版本时所需的备份，但它对于“实时”使用来说并不是一个好的选择（每个构建都会需要从安装步骤开始，这可以轻松地将 1 小时的构建变成 3 小时）。
- 将软件安装到源代码管理。 ClearCase 将您的分支映射到驱动器号； 我们可以将软件安装在该驱动器下。 这没有考虑安装工具的非文件部分，例如注册表设置。
- 安装所有软件并在虚拟机内设置构建过程，将虚拟机存储在源代码管理中，并弄清楚如何让虚拟机在启动时进行构建。 虽然我们轻松捕获“构建机器”的状态，但我们得到了虚拟机的开销，并且它无助于解决“向开发人员提供相同的工具”问题。
这似乎是配置管理的基本理念，但我一直无法找到任何资源来了解如何做到这一点。 有哪些建议？
What are the recommendations for including your compiler, libraries, and other tools in your source control system itself?
In the past, I've run into issues where, although we had all the source code, building an old version of the product was an exercise in scurrying around trying to get the exact correct configuration of Visual Studio, InstallShield and other tools (including the correct patch version) used to build the product. On my next project, I'd like to avoid this by checking these build tools into source control, and then build using them. This would also simplify things in terms of setting up a new build machine -- 1) install our source control tool, 2) point at the right branch, and 3) build -- that's it.
Options I've considered include:
- Copying the install CD ISO to source control - although this provides the backup we need if we have to go back to an older version, it isn't a good option for "live" use (each build would need to start with an install step, which could easily turn a 1 hour build into 3 hours).
- Installing the software to source control. ClearCase maps your branch to a drive letter; we could install the software under this drive. This doesn't take into account non-file part of installing your tools, like registry settings.
- Installing all the software and setting up the build process inside a virtual machine, storing the virtual machine in source control, and figuring out how to get the VM to do a build on boot. While we capture the state of the "build machine" with ease, we get the overhead of a VM, and it doesn't help with the "make the same tools available to developers issue."
It seems such a basic idea of configuration management, but I've been unable to track down any resources for how to do this. What are the suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
我认为虚拟机是最好的解决方案。 我们总是使用专用的构建机器来获得一致性。 在旧的 COM DLL 地狱时代，（COMCAT.DLL，任何人）都依赖于安装的非开发软件（Office）。 前两个选项不能解决任何共享 COM 组件的问题。 如果您没有任何共享组件问题，也许它们会起作用。
开发人员没有理由不能获取同一虚拟机的副本以便能够在干净的环境中进行调试。 如果您的架构中有很多物理层（例如邮件服务器、数据库服务器等），您的问题会更加复杂。
I think the VM is your best solution. We always used dedicated build machines to get consistency. In the old COM DLL Hell days, there were dependencies on (COMCAT.DLL, anyone) on non-development software installed (Office). Your first two options don't solve anything that has shared COM components. If you don't have any shared components issue, maybe they will work.
There is no reason the developers couldn't take a copy of the same VM to be able to debug in a clean environment. Your issues would be more complex if there are a lot of physical layers in your architecture, like mail server, database server, etc.
这对于您的环境来说是非常特定的。 这就是为什么您不会看到处理所有情况的指南。 我工作过的所有不同的商店都有不同的处理方式。 我只能就我认为最适合我的方式向您提供我的意见。
新工作站上的应用程序
受源头控制。
不受源代码控制的应用程序，
IDE、SDK 和数据库等内容
引擎。 将它们作为 ISO 文件保存在目录中。
This is something that is very specific to your environment. That's why you won't see a guide to handle all situations. All the different shops I've worked for have handled this differently. I can only give you my opinion on what I think has worked best for me.
application on a new workstation
under source control.
applications out of source control,
stuff like IDEs, SDKs, and database
engines. Keep these in a directory as ISO files.
我肯定会考虑围绕这个想法的法律/许可问题。 根据您的工具链的各种许可证是否允许？
如果您不喜欢虚拟机映像的想法，您是否考虑过重装一台能够构建版本的新开发机器？ 当然，在硬件发生变化时保持幻像运行可能会带来更多麻烦，而不是值得......
I would definitely consider the legal/licensing issues surrounding the idea. Would it be permissible according to the various licenses of your toolchain?
Have you considered ghosting a fresh development machine that is able to build the release, if you don't like the idea of a VM image? Of course, keeping that ghosted image running as hardware changes might be more trouble than it's worth...
请注意版本控制系统中库的版本控制：
不要忘记该集合将随着项目的每个新版本而演变。 UCM 及其“综合基线”可能会给出这个问题的初步答案。
打包方面（最小文件数量）很重要，因为：
Just a note on the versionning of libraries in your version control system:
Do not forget that set will evolves with each new version of your project. UCM and its 'composite baseline' might give the beginning of an answer for that.
The packaging aspect (minimum number of files) is important because:
我的组织有一个“只读”文件系统，所有内容都放入发行版和版本中。 发布链接（本质上是符号链接）指向您的项目正在使用的版本。 当新版本出现时，它只会添加到文件系统中，您可以将符号链接切换到它。 符号链接有完整的审核历史记录，您可以为不同版本创建新的符号链接。
这种方法在 Linux 上效果很好，但对于 Windows 应用程序来说效果不太好，因为 Windows 应用程序往往喜欢使用计算机本地的内容（例如注册表）来存储配置等内容。
My organisation has a "read-only" filesystem, where everything is put into releases and versions. Releaselinks (essentially symlinks) point to the version being used by your project. When a new version comes along it is just added to the filesystem and you can swing your symlink to it. There is full audit history of the symlinks, and you can create new symlinks for different versions.
This approach works great on Linux, but it doesn't work so well for Windows apps that tend to like to use things local to the machine such as the registry to store things like configuration.
您是否使用像 NAnt 这样的持续集成 (CI) 工具来进行构建？
作为 .Net 示例，您可以为每个构建指定特定框架。
也许无论您正在开发什么，流行的 CI 工具都有一些选项可以让您避免在版本控制系统中存储多个 IDE。
Are you using a continuous integration (CI) tool like NAnt to do your builds?
As a .Net example, you can specify specific frameworks for each build.
Perhaps the popular CI tool for whatever you're developing in has options that will allow you to avoid storing several IDEs in your version control system.
在许多情况下，您可以强制构建使用签入源代码管理的编译器和库，而不是依赖将来不可重复的全局计算机设置。 例如，对于 C# 编译器，您可以使用 /nostdlib 开关并手动 /reference 所有库以指向签入源代码管理的版本。 当然，也将编译器本身检查到源代码管理中。
In many cases, you can force your build to use compilers and libraries checked into your source control rather than relying on global machine settings that won't be repeatable in the future. For example, with the C# compiler, you can use the /nostdlib switch and manually /reference all libraries to point to versions checked in to source control. And of course check the compilers themselves into source control as well.
至于“弄清楚如何在启动时构建”：我已经使用由一名系统管理员和一名开发人员快速定制的构建场系统进行了开发。 构建从站向监工查询合适的排队构建请求。 非常漂亮。
如果其工具链要求与从属设备上的工具链版本匹配（包括操作系统），则请求“适合”从属设备，因为该产品是多平台的，并且构建可以包括自动化测试。 通常这是“当前最先进的技术”，但并非必须如此。
当从机准备好构建时，它只是开始轮询监工，告诉它安装了什么。 它不必提前知道需要构建什么。 它获取一个构建请求，该请求告诉它从 SVN 中检查某些标签，然后从这些标签之一运行脚本以从那里获取它。 开发人员不必知道有多少个构建从站可用、它们的名称是什么、或者它们是否忙碌，只需知道如何将请求添加到构建队列即可。 构建队列本身是一个相当简单的 Web 应用程序。 一切都非常模块化。
从机不一定是虚拟机，但通常都是。 从站的数量（以及它们运行的物理机器）可以扩展以满足需求。 显然，从属设备可以随时添加到系统中，或者在工具链崩溃时被摧毁。 这实际上是该方案的要点，而不是归档工具链状态的问题，但我认为它是适用的。
根据您需要旧工具链的频率，您可能希望构建队列能够根据需要启动虚拟机，否则想要重新创建旧构建的人还必须安排合适的从属设备出现。 这并不是说这一定很困难——这可能只是在他们选择的机器上启动正确的虚拟机的问题。
As for "figuring out how to build on boot": I've developed using a build farm system custom-created very quickly by one sysadmin and one developer. Build slaves query a taskmaster for suitable queued build requests. It's pretty nice.
A request is 'suitable' for a slave if its toolchain requirements match the toolchain versions on the slave - including what OS, since the product is multi-platform and a build can include automated tests. Normally this is "the current state of the art", but doesn't have to be.
When a slave is ready to build, it just starts polling the taskmaster, telling it what it's got installed. It doesn't have to know in advance what it's expected to build. It fetches a build request, which tells it to check certain tags out of SVN, then run a script from one of those tags to take it from there. Developers don't have to know how many build slaves are available, what they're called, or whether they're busy, just how to add a request to the build queue. The build queue itself is a fairly simple web app. All very modular.
Slaves needn't be VMs, but usually are. The number of slaves (and the physical machines they're running on) can be scaled to satisfy demand. Slaves can obviously be added to the system any time, or nuked if the toolchain crashes. That'ss actually the main point of this scheme, rather than your problem with archiving the state of the toolchain, but I think it's applicable.
Depending how often you need an old toolchain, you might want the build queue to be capable of starting VMs as needed, since otherwise someone who wants to recreate an old build has to also arrange for a suitable slave to appear. Not that this is necessarily difficult - it might just be a question of starting the right VM on a machine of their choosing.
跟进我自己的问题，我发现了这篇文章 在另一个问题的答案中引用。 虽然更多的是对这个问题的讨论而不是回答，但它确实提到了 VM 的想法。
Following up on my own question, I came across this posting referenced in the answer to another question. Although more of a discussion of the issue than an aswer, it does mention the VM idea.