Artifactory：支持 n-2 版本的包管理策略
Artifactory: Package management strategy to support n-2 releases
我是 Artifactory 的新手，正在努力找出满足我公司需求的最佳策略。到目前为止，我们一直在使用内部包管理系统，并希望采用更多行业标准解决方案。
我们的情况：
- 我们有本地部署的软件。由于每个客户都有自己的软件更新故事和策略，因此我们需要支持的不仅仅是最新版本（比方说，我们支持最后 2 个版本）。
- 我们有 40 多个 git 存储库构成一个安装程序。其中一些 40+ git 回购创建 npm 包或 nuget 包，而其他一些使用它们（有时制作自己的 nuget/npm 包。）
- 每个版本都有自己的分支和 CI 管道，因此更新 release-1.1 管道中的包不会意外泄漏给 release-1.0 中包的任何消费者。这发生在所有这些 40+ git 回购协议上。
- 新版本branch/CI管道大约每年产生两次。
我看到 Artifactory 提供了多个 repos 功能。在他们推荐的 repo 最佳实践文档 https://jfrog.com/whitepaper/best-practices-structuring-naming-artifactory-repositories/ 中，它建议您使用成熟度分隔符，例如开发与生产。
要将此应用到我们的情况，一个想法是将每个版本都视为成熟度，因此我们将拥有 dev、release-1.0、release-1.1 等人工仓库，并且每个人工版本仓库都与其相关联自己的分支。这可以正常工作，但在人工方面需要更多的自动化。我可以看到制作单独的 Artifactory 回购协议来管理权限，但制作新的回购协议只是为了过滤包对我们来说感觉有点过分了。版本之间没有权限差异。
或者，我们可以使用单个工件存储库，并且每个包都标有版本。比如说，CI 版本 1.0 的管道将发布一个带有标签 release-1.0 的包。使用像 GitVersion 这样的工具保证每个 CI 管道将产生唯一的版本号，这可以为所有包提供很好的 filtering/grouping 机制，而无需每个版本回购的负担。 只有 nuget update 或 npm update 可以使用基于标签的过滤更新包版本。
jfrog cli 提供了一种根据来自特定人工仓库的标签下载文件的方法。要构建一个 git 回购包，我可以使用标签过滤从 40+ git 回购中下载所有包，然后使用本地文件夹进行 nuget 更新。听起来不太理想。
我很惊讶 nuget 或 npm 已经没有 带标签过滤的更新 功能。它们支持标签，但仅用于搜索。 我能想到的唯一方法是编写自定义脚本，该脚本将遍历 nuget.config 或 package.config 中的每个包引用（对于 npm ), 运行用jfrog cli（或api）查询得到最新版本的包，然后一一更新。它会起作用，但我想知道这是否是正确的解决方案，因为它涉及少量自定义工作。
非常感谢包管理大师的任何建议。
我的问题可以通过使用路径来解决，正如这篇文章中提到的 baseRev。
https://www.jfrog.com/confluence/display/JFROG/Repository+Layouts
重要的是要认识到我们的版本不是成熟的（如开发与生产），而是长期存在的分支。不同之处在于 long living branch 的工件被再次编译，而 prod 工件是从 dev 工件原样提升的。因此，当我尝试通过应用成熟度实践来解决长期存在的分支问题时，它到处都造成了尴尬的流程。
每个包含 40 多个回购协议的长期分支集都将 provide/consume 它们自己的 nuget 包包含在其中。为了在不为每个版本创建新的 repos 的情况下解决这个问题，我们可以利用本地 repo 中的路径，例如 artifactory.my-server.com/api/nuget/nuget-local/master/* vs artifactory.my-server.com/api/nuget/nuget-local/release-1/*.
不幸的是，you can use path for push, but not for install.
所以对于消费端，你需要为每个版本创建一个虚拟仓库，这对我们来说不是什么大不了的事情。
我是 Artifactory 的新手，正在努力找出满足我公司需求的最佳策略。到目前为止，我们一直在使用内部包管理系统，并希望采用更多行业标准解决方案。
我们的情况：
- 我们有本地部署的软件。由于每个客户都有自己的软件更新故事和策略，因此我们需要支持的不仅仅是最新版本（比方说，我们支持最后 2 个版本）。
- 我们有 40 多个 git 存储库构成一个安装程序。其中一些 40+ git 回购创建 npm 包或 nuget 包，而其他一些使用它们（有时制作自己的 nuget/npm 包。）
- 每个版本都有自己的分支和 CI 管道，因此更新 release-1.1 管道中的包不会意外泄漏给 release-1.0 中包的任何消费者。这发生在所有这些 40+ git 回购协议上。
- 新版本branch/CI管道大约每年产生两次。
我看到 Artifactory 提供了多个 repos 功能。在他们推荐的 repo 最佳实践文档 https://jfrog.com/whitepaper/best-practices-structuring-naming-artifactory-repositories/ 中，它建议您使用成熟度分隔符，例如开发与生产。
要将此应用到我们的情况，一个想法是将每个版本都视为成熟度，因此我们将拥有 dev、release-1.0、release-1.1 等人工仓库，并且每个人工版本仓库都与其相关联自己的分支。这可以正常工作，但在人工方面需要更多的自动化。我可以看到制作单独的 Artifactory 回购协议来管理权限，但制作新的回购协议只是为了过滤包对我们来说感觉有点过分了。版本之间没有权限差异。
或者，我们可以使用单个工件存储库，并且每个包都标有版本。比如说，CI 版本 1.0 的管道将发布一个带有标签 release-1.0 的包。使用像 GitVersion 这样的工具保证每个 CI 管道将产生唯一的版本号，这可以为所有包提供很好的 filtering/grouping 机制，而无需每个版本回购的负担。 只有 nuget update 或 npm update 可以使用基于标签的过滤更新包版本。
jfrog cli 提供了一种根据来自特定人工仓库的标签下载文件的方法。要构建一个 git 回购包，我可以使用标签过滤从 40+ git 回购中下载所有包，然后使用本地文件夹进行 nuget 更新。听起来不太理想。
我很惊讶 nuget 或 npm 已经没有 带标签过滤的更新 功能。它们支持标签，但仅用于搜索。 我能想到的唯一方法是编写自定义脚本，该脚本将遍历 nuget.config 或 package.config 中的每个包引用（对于 npm ), 运行用jfrog cli（或api）查询得到最新版本的包，然后一一更新。它会起作用，但我想知道这是否是正确的解决方案，因为它涉及少量自定义工作。
非常感谢包管理大师的任何建议。
我的问题可以通过使用路径来解决，正如这篇文章中提到的 baseRev。 https://www.jfrog.com/confluence/display/JFROG/Repository+Layouts
重要的是要认识到我们的版本不是成熟的（如开发与生产），而是长期存在的分支。不同之处在于 long living branch 的工件被再次编译，而 prod 工件是从 dev 工件原样提升的。因此，当我尝试通过应用成熟度实践来解决长期存在的分支问题时，它到处都造成了尴尬的流程。
每个包含 40 多个回购协议的长期分支集都将 provide/consume 它们自己的 nuget 包包含在其中。为了在不为每个版本创建新的 repos 的情况下解决这个问题，我们可以利用本地 repo 中的路径，例如 artifactory.my-server.com/api/nuget/nuget-local/master/* vs artifactory.my-server.com/api/nuget/nuget-local/release-1/*.
不幸的是，you can use path for push, but not for install. 所以对于消费端，你需要为每个版本创建一个虚拟仓库，这对我们来说不是什么大不了的事情。