Artifactory可以跟踪构建时独立可执行文件之间的运行时依赖性吗？

Question

我刚刚观看了Intro to Artifactory视频，我正在尝试评估它是否适合以下情况。

在我的组织中，我们正在开发一个＆＃34;套件＆＃34;用于嵌入式设备的软件，需要作为一个系统一起工作。用于这些设备中的每一个的软件构建彼此独立地完成。例如，我理论上可以编译并生成设备A的软件版本，而不需要设备B的任何源或二进制文件。这些设备都需要作为集成套件的一部分一起播放，这些交互由ICD控制和描述

有时需要进行ICD级别的更改或其他一些重要的体系结构更改，这些更改会导致两个或更多设备的相关更改。代码库。所以这就创造了我所说的＆＃34;耦合＆＃34;或可执行文件之间的相互依赖关系。例如，如果有人想要为设备A运行4.5.0版本的软件，则必须为设备B配置4.19.0或更高版本的软件以保持兼容性。

我们目前正在跟踪共享驱动器上带有电子表格和文档的可执行文件之间的所有这些相互依赖性要求，这已经变得麻烦和烦人。

我希望的是像Artifactory这样的东西可以让我们拥有一整套软件的所有可执行文件的存储库，这些软件可以跟踪所有这些元数据和二进制文件之间的链接。

因此，如果人们决定是否需要为设备A运行4.5.0软件，但是没有其他设备的依赖性要求的所有详细知识（在许多情况下，他们不是工程师，并试图解释它对他们来说很难），他们可以做一个＆＃34;结账＆＃34;整个套件，它将包括4.19.0的Device B软件。 （如果兼容各种版本的Device C软件，请抓住最新版本。）

对不起，如果这是一个愚蠢的问题，但我现在正在学习JFrog和Artifactory。 （我也想知道bintray是否可能是更合适的选择......）

Distribution Repository是否可以解决这个问题？

Answer 1

这是一个很好的问题。实际上，不止一个。所以这里是答案：）

• bintray是要走的路。它旨在为设备分发软件并支持您需要的元数据（见下文）。
• artifactory非常适合开发过程 - 元数据一直都是如此。
• Distribution Repositories是您将用于发布可随时发布的工件

现在让我们谈谈元数据：）

您需要将A版本4.5.0与B版本4.19.0联系起来，并使用Artifactory Properties完成此操作。您可以set them in the CI server during the build或单独using REST API。通常，您可以引入一些更高级别的发布版本并使用它注释所有组件（让我们说A:4.5.0和B:4.19.0都是Suite:1.0的一部分），或者您可以表达每个工件的矩阵（使用属性A:4.5.0注释Compatible.with=B:4.19.0。）

设置后，检索它们很容易。您可以使用Artifactory Query Language获取Suite:1.0的所有组件，使用matrix-params resolution请求包含A属性的最新Compatible.with=B:4.19.0工件。

好消息是，当您通过Distribution Repositories释放它们时，这些属性会通过工件升级到bintray。然后，您可以配置设备to consume the correct combinations of artifacts。

有意义吗？