Artifactory 能否跟踪构建时独立可执行文件之间的 运行 时间依赖性？
Can Artifactory track run-time dependencies between build-time independent executables?
我刚看了一个 Intro to Artifactory 视频，我正在尝试评估它是否适合以下情况。
在我的组织中，我们正在为需要作为一个系统协同工作的嵌入式设备开发 "suite" 软件。为这些设备中的每一个设备构建软件都是相互独立完成的。例如，理论上我可以为设备 A 编译和生成软件版本，而无需设备 B 的任何源代码或二进制文件。这些设备都需要作为集成套件的一部分一起运行，并且这些交互由 ICD 管理和描述.
有时需要进行 ICD 级更改或一些其他重要的架构更改，这些更改会推动对两个或更多设备的代码库进行相关更改。所以这会创建我所说的 "couplings" 或 可执行文件 之间的相互依赖关系。例如，如果有人想要 运行 设备 A 的软件版本为 4.5.0，则设备 B 必须配置 4.19.0 或更高版本的软件以保持兼容性。
我们目前正在跟踪共享驱动器上的电子表格和文档的可执行文件之间的所有这些相互依赖性要求，这已经变得麻烦和烦人了。
我所希望的是，像 Artifactory 这样的东西将使我们能够拥有一个包含整个软件套件的所有可执行文件的存储库，以跟踪所有这些元数据和二进制文件之间的链接。
因此，如果人们决定需要 运行 设备 A 的软件 4.5.0，但不了解其他设备的依赖性要求的所有详细知识（在许多情况下，他们并不了解）工程师并试图向他们解释这一切是困难的），他们可以对整个套件进行 "checkout"，它将包括设备 B 软件的 4.19.0。 （如果一系列版本，例如设备 C 软件兼容，请获取最新版本。）
抱歉，如果这是一个愚蠢的问题，但我现在只是在学习 JFrog 和 Artifactory。 （我也想知道 bintray 是否是更合适的选择...）
Distribution Repository 是解决这个问题的方法吗？
这是一个很好的问题。其实不止一个。所以这里是答案:)
bintray 是要走的路。它旨在为设备分发软件并支持您需要的元数据（见下文）。artifactory 非常适合开发过程 - 元数据。 - Distribution Repositories 是您要用于发布可发布的工件
现在我们来谈谈元数据:)
您需要将 A 版本 4.5.0 与 B 版本 4.19.0 相关联，这是通过 Artifactory Properties. You can either set them in the CI server during the build, or separately using REST API 完成的。通常，您可以引入一些更高级别的发布版本并用它注释所有组件（假设 A:4.5.0 和 B:4.19.0 都是 Suite:1.0 的一部分），或者您可以表达每个工件的矩阵（用 属性 Compatible.with=B:4.19.0 注释 A:4.5.0）。
设置后，检索它们很容易。您可以使用 Artifactory Query Language to get all the components of Suite:1.0, of ask for the latest A artifact that has Compatible.with=B:4.19.0 property on it by using matrix-params resolution。
好消息是，当您通过 Distribution Repositories 发布它们时，这些属性会与工件一起提升到 bintray 。然后您可以配置您的设备 以使用正确的工件组合 。
有道理吗？
我刚看了一个 Intro to Artifactory 视频，我正在尝试评估它是否适合以下情况。
在我的组织中，我们正在为需要作为一个系统协同工作的嵌入式设备开发 "suite" 软件。为这些设备中的每一个设备构建软件都是相互独立完成的。例如，理论上我可以为设备 A 编译和生成软件版本，而无需设备 B 的任何源代码或二进制文件。这些设备都需要作为集成套件的一部分一起运行，并且这些交互由 ICD 管理和描述.
有时需要进行 ICD 级更改或一些其他重要的架构更改，这些更改会推动对两个或更多设备的代码库进行相关更改。所以这会创建我所说的 "couplings" 或 可执行文件 之间的相互依赖关系。例如，如果有人想要 运行 设备 A 的软件版本为 4.5.0，则设备 B 必须配置 4.19.0 或更高版本的软件以保持兼容性。
我们目前正在跟踪共享驱动器上的电子表格和文档的可执行文件之间的所有这些相互依赖性要求，这已经变得麻烦和烦人了。
我所希望的是，像 Artifactory 这样的东西将使我们能够拥有一个包含整个软件套件的所有可执行文件的存储库，以跟踪所有这些元数据和二进制文件之间的链接。
因此，如果人们决定需要 运行 设备 A 的软件 4.5.0，但不了解其他设备的依赖性要求的所有详细知识（在许多情况下，他们并不了解）工程师并试图向他们解释这一切是困难的），他们可以对整个套件进行 "checkout"，它将包括设备 B 软件的 4.19.0。 （如果一系列版本，例如设备 C 软件兼容，请获取最新版本。）
抱歉，如果这是一个愚蠢的问题，但我现在只是在学习 JFrog 和 Artifactory。 （我也想知道 bintray 是否是更合适的选择...）
Distribution Repository 是解决这个问题的方法吗？
这是一个很好的问题。其实不止一个。所以这里是答案:)
- Distribution Repositories 是您要用于发布可发布的工件
现在我们来谈谈元数据:)
您需要将 A 版本 4.5.0 与 B 版本 4.19.0 相关联，这是通过 Artifactory Properties. You can either set them in the CI server during the build, or separately using REST API 完成的。通常，您可以引入一些更高级别的发布版本并用它注释所有组件（假设 A:4.5.0 和 B:4.19.0 都是 Suite:1.0 的一部分），或者您可以表达每个工件的矩阵（用 属性 Compatible.with=B:4.19.0 注释 A:4.5.0）。
设置后，检索它们很容易。您可以使用 Artifactory Query Language to get all the components of Suite:1.0, of ask for the latest A artifact that has Compatible.with=B:4.19.0 property on it by using matrix-params resolution。
好消息是，当您通过 Distribution Repositories 发布它们时，这些属性会与工件一起提升到
有道理吗？