3

Twelve-Factor App宣言说它适用于 Web 应用程序，“......与底层操作系统有一个干净的合同，在执行环境之间提供最大的可移植性”[强调由我添加]

但后来它说：

十二因素应用程序也不依赖于任何系统工具的隐含存在。例子包括炮击到ImageMagick或curl。虽然这些工具可能存在于许多甚至大多数系统上，但无法保证它们将存在于未来可能运行该应用程序的所有系统上，或者未来系统上的版本是否与该应用程序兼容。如果应用程序需要使用系统工具，则应将该工具出售到应用程序中。

他们之前将“供应商”定义为：

范围为包含应用程序的目录（称为“供应商”或“捆绑”）。

例如，当（至少在 Linux 上）本机 64 位可执行文件不能在 32 位环境中运行时，应该如何做到这一点——更不用说在其他操作系统上运行了？还是有更好的方法来处理这个可移植性问题？

4

2 回答 2

3

在我看来，根本不应该这样做。这是因为：

  • 如果本机可执行文件是动态链接的，那么它们可能无法仅在未来的操作系统版本上运行，更不用说未来或过去的处理器架构了。
  • 据我了解，不可能通过静态链接来完全面向未来的本机可执行文件。你仍然可以有问题。Solaris 甚至不支持系统库的静态链接！
  • 库依赖项并不是本机工具可以拥有的唯一一种依赖项。也可能有其他问题。
  • 旧ImageMagick的 s - 甚至是curls - 可能存在安全漏洞，可能使您的应用程序受到损害。（这有点争议——它的有效性取决于你更信任谁来监视/应用安全更新——维护和升级服务器的人，还是开发人员？当然他们可能是同一个人——现在. 但我在这里的工作假设是服务器最终会应用更新，这反过来会保护您的应用程序免受系统可执行文件中已在更新中修复的安全漏洞的影响。）

我的观点：如果您选择的依赖管理系统直接无法处理本机可执行文件，请在自述文件中注明并完成它。如果您没有 README，请创建一个。并且（对于内部 Web 应用程序）将您需要的本机工具添加到您在设置服务器时使用的标准服务器映像或脚本中，并确保您对它们存在的原因进行了额外的记录。

于 2012-06-04T17:17:48.527 回答
0

这只是意味着您应该在您的供应商资源之间建立声明性依赖关系和干净的合同。

如果您的应用程序依赖于特定版本的软件，您必须与它签订一份干净的合同，以便您可以模拟/存根功能进行开发。此外，即使在 Windows 中，将依赖项管理作为应用程序的一部分也并非不可能（尽管您可能希望它发生在您的安装程序中，而不是应用程序本身）。

如果您的产品严重依赖其他软件，以至于即使在测试环境中也无法在没有它的情况下运行，那么必须将其捆绑在一起，并且您必须制定 EULA，或者，实际上，您没有产品。

于 2014-01-21T20:38:52.927 回答