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

Question

我刚刚观看了一个Intro to Artifactory视频，我试图评估它是否会适合以下情况。

在我的组织，我们正在开发的嵌入式设备，这就需要作为一个系统一起工作的软件“套装”。每个设备的软件构建都是相互独立完成的。例如，我可以在理论上为Device A编译并生成一个软件版本，而不必为Device B提供任何源代码或二进制文件。这些设备都需要作为集成套件的一部分一起玩，并且这些交互由ICD管理和描述。

有时有需要ICD水平的变化或驱动相关的变化将两个或多个设备的代码库的其他一些重要的结构变化。因此，这创建了我称之为“耦合”或可执行文件之间的相互依赖关系。例如，如果有人想为设备A运行版本4.5.0的软件，那么设备B必须配置其版本为4.19.0或更高版本的软件以保持兼容性。

目前，我们正在追踪所有与共享驱动器，它已经变得繁琐和恼人的电子表格和文档的可执行文件之间相互依存这些要求。

我所希望的是，像Artifactory的使我们能够拥有所有的可执行文件的软件的整个套件跟踪所有的二进制文件之间的这种元数据和关联的存储库。

因此，如果人们决定需要为设备A运行4.5.0软件，但没有所有关于其他设备依赖性需求的详细知识（并且在很多情况下，他们不是工程师并试图解释这对他们来说都很困难），他们可以对整个套件进行“结账”，它将包含Device B软件的4.19.0。 （如果一系列版本的Device C软件是兼容的，请抓住最新版本。）

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

会一个Distribution Repository是去对此的方式？

Answer 1

这是一个很大的问题。其实不止一个。所以这里是答案:)

• bintray是要走的路。它旨在为设备分发软件并支持您需要的元数据（请参阅下文）。
• artifactory非常适合开发过程 - 元数据一路。
• Distribution Repositories是你要使用的释放什么分布就绪神器

现在让我们谈谈元数据:)

你需要什么相关A版4.5.0有4.19.0B版本，这样做与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属性。

好消息是，当您通过分布存储库发布这些属性时，这些属性会通过工件提升至bintray。然后你可以配置你的设备to consume the correct combinations of artifacts。

它有道理吗？