“真正可复制的版本”到底是什么？

他们到底是什么？为什么它们在持续交付方面很重要？

上下文：我在（我猜为reddit）的评论中看到，“真正可复制”的构建仍然是一项研究不足的技术，并且很难创建。

因此，我想知道为什么它们如此难以创建？

他们到底是什么？

这是来自reproducible-builds.org的报价：

可复制的构建是一组软件开发实践，可创建从人类可读源代码到计算机使用的二进制代码的可验证路径。

他们为什么重要？

IMO解释其重要性的最简单方法是将其视为备份程序的变体。

举个例子：

• 假设一家企业使用（取决于）某些软件供应商许可的某些软件包。而企业仅获取可执行文件，而不获取用于创建那些可执行文件的源等。

• 一切顺利，但在某些时候软件供应商出了点问题，例如，他们倒闭了（例如破产）。

• 从长远来看，这可能会给业务带来风险。即，如果没有适当的程序/协议使企业能够（合法）访问与（当年）使用可执行文件（由...使用）的软件供应商的任何东西相关的所有必需的源，文档，构建过程等。业务）被创建（并运送到业务）。

• 那就是“ 软件托管 ”的到来：如果达成这样的协议，人们会认为，通过第三方，企业仍然有可能获得“ 所使用的东西 ”以能够复制可执行文件，因此从此以后，企业可能会有机会继续使用该软件，并在适当的地方开始自行维护该软件（仅用于运行自己的企业）。

• 但是，上一个项目符号中的“ 无论使用什么 ”都是使这项工作最困难的部分。它要求第三方预先进行适当的验证。相信我，需要一段时间才能重新创建可执行文件，您可以证明该可执行文件除了（例如）链接日期外，还与软件供应商交付给软件代理的内容完全匹配。

为什么创建它们如此困难？

如果上述示例仍然不够清晰，请假设您是我的软件托管代理，请告诉我您需要什么作为输入来重新创建客户许可的软件副本。得到它？您没有忘记检查编译器的哪个版本，也许是我的操作系统，编译/链接选项，可重用组件（包括）的版本，库等？

为了提供一个尝试创建真正可重复构建的实际示例，请考虑以下内容：

从git仓库开始的构建管道，没有用户可以重写历史记录或删除未合并的分支。

签出源代码后的第一步“构建”是启动一个包含所有构建时间相关性的容器。

运行构建时间容器的输出是一个包含已编译二进制文件的容器。

对于构建的可重复性更重要的是，将以下标记添加到最终容器中：

• 原始存储库中源代码的确切哈希值以及git repo的URL和上传到工件存储库中的代码的tar球快照。
• 用于运行构建的构建容器的确切版本。
• 二进制文件已加载到的原始基本映像的确切版本。
• 用于创建二进制文件的所有构建时变量的值。
• 所有三个容器所使用的docker版本，以及它们在构建时在其下运行的版本。

通过添加所有这些元数据，我们可以确保将来在任何时候都可以提取出确切的构建依赖项集（通过构建容器），并使用一组确切的已知步骤编译二进制文件（包含在构建容器中） ），并将其打包到另一个具有所有运行时相关性的已知基础映像中（使用基础映像标签），并且所有这些都可以基于容器上的标签基于源代码的确切正确版本进行。

从理论上讲，这应该使我们能够准确地复制构建版本。

这样做的重要性在于，它使我们能够查看生产中正在运行的内容，并且即使一切都进行了重大改进，也可以返回并取出最初使用的代码，基本映像和构建容器的版本，以便例如，请在对该版本进行完全修复之前，先对该版本应用修补程序，以便我们可以重新部署，因为它与修补程序完全相同，唯一的差异是修补程序。