Artifactory：支持 n-2 个版本的包管理策略

Question

我是 Artifactory 的新手，正在尝试找出适合我公司需求的最佳策略。到目前为止，我们一直在使用内部包管理系统，并希望使用更多的行业标准解决方案。

我们的情况：

1. 我们有本地部署的软件。由于每个客户都有自己的软件更新故事和策略，因此我们需要支持的不仅仅是最新版本（比如说，我们支持最后两个版本）。
2. 我们有 40 多个 git 存储库构成一个安装程序。这 40 多个 git 存储库中的一些创建 npm 包或 nuget 包，而另一些则使用它们（有时还会创建自己的 nuget/npm 包。）
3. 每个版本都有自己的分支和 CI 管道，因此在 release-1.1 管道中更新包不会意外泄漏给 release-1.0 中包的任何使用者。这发生在所有 40 多个 git 存储库上。
4. 新版本分支/CI 管道大约每年产生两次。

我看到 Artifactory 提供了多个 repos 功能。在他们推荐的 repo 最佳实践文档https://jfrog.com/whitepaper/best-practices-structuring-naming-artifactory-repositories/ 中，它建议您使用成熟度分隔符，例如 dev 与 prod。

将此应用于我们的情况，一个想法是将每个版本视为成熟度，因此我们将拥有 dev、release-1.0、release-1.1 等工件存储库，并且每个工件发布存储库都绑定到自己的分支.这可以正常工作，但在人工方面需要更多的自动化。我可以看到制作单独的 Artifactory 存储库来管理权限，但是制作新的存储库只是为了过滤包对我们来说感觉有点过头了。版本之间没有权限差异。

或者，我们可以使用单个工件存储库，并且每个包都标有发布。比如说，1.0 版的 CI 管道将发布一个带有标签 release-1.0 的包。使用像 GitVersion 这样的工具来保证每个 CI 管道将产生唯一的版本号，这可以为所有包提供良好的过滤/分组机制，而无需每个版本的 repos 负担。 仅当 nuget update 或 npm update 可以使用基于标签的过滤来更新包版本。

jfrog cli 提供了一种基于来自特定工件存储库的标签下载文件的方法。要构建一个 git repo 包，我可以使用标签过滤从 40 多个 git repos 下载所有包，然后使用本地文件夹进行 nuget 更新。听起来不太理想。

我很惊讶 nuget 或 npm 还没有标签过滤更新功能。它们支持标签，但仅用于搜索。 我能想到的唯一方法是编写自定义脚本，该脚本将遍历 nuget.config 或 package.config（对于 npm）中的每个包引用，运行查询jfrog cli（或api）获取最新版本的包，然后一一更新。它会起作用，但我想知道这是否是正确的解决方案，因为它涉及一些自定义工作。

非常感谢包管理大师的任何建议。

Answer 1

我的问题可以通过使用 path 来解决，正如本文中使用 baseRev 所指出的那样。 https://www.jfrog.com/confluence/display/JFROG/Repository+Layouts

重要的是要认识到我们的版本不是成熟的（如在 dev 与 prod 中），而是长期存在的分支。不同之处在于，长寿分支的工件被再次编译，而 prod 工件按原样从 dev 工件中提升。因此，当我尝试通过应用成熟度实践来解决长期存在的分支问题时，它在这里和那里创造了尴尬的流程。

每个包含 40 多个 repos 的长期分支集都将在其中提供/使用它们自己的 nuget 包。为了在不为每个版本创建新仓库的情况下解决这个问题，我们可以利用本地仓库中的路径，例如 artifactory.my-server.com/api/nuget/nuget-local/master/* 与 artifactory.my-server.com/api/nuget/nuget-local/release-1/*。

很遗憾，you can use path for push, but not for install. 所以对于消费端，你需要为每个版本创建一个虚拟仓库，这对我们来说没什么大不了的。