nuget 包管理器需要哪些不同类型的存储库？
我正在 Jfrog Artifactory 中为我们正在启动的 .Net 项目创建以下存储库，并且我们计划使用 NuGet 作为我们的包管理器
productname-nuget-snapshot
productname-nuget-release
productname-nuget-thirdparty
我想知道上述存储库是否足够还是我们需要更多？当我查看一些现有的存储库名称时，我了解了以下内容，但不确定它们与 NuGet 的用途。
productname-nuget-staging
productname-nuget-local
productname-nuget-myd
productname-nuget-suo
productname-nuget-svs
请指导我在这方面遵循的最佳实践。
I am creating the following repos in Jfrog Artifactory for the .Net project we are starting, and we are planning to use NuGet as our package manager
productname-nuget-snapshot
productname-nuget-release
productname-nuget-thirdparty
I want the know whether the above repos are enough or do we require more? while I am going through some existing repo names I got to know the following but not sure about their purpose with NuGet.
productname-nuget-staging
productname-nuget-local
productname-nuget-myd
productname-nuget-suo
productname-nuget-svs
Please guide me about the best practices to follow on this regard.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
让我先从 Artifactory 方面详细阐述，然后您就可以决定存储库了。
Artifactory 附带 3 组存储库。
对于常规使用，一组以上3个存储库就足够了。
但是如果您有开发团队
在复杂/混合项目中，例如开发、暂存和发布阶段。 Artifactory 中可以通过多种不同方式进行 Artifact 推广。从较小事件的简单属性标记（例如“通过测试 X”）到工件已通过的较大质量门。例如从一个存储库到另一个存储库。在传统的开发模型中，这可能代表在软件生命周期的不同阶段拥有软件的实际团队。您可能有一个“沙箱”，而开发人员正在他们的办公桌上测试工件，并且您可能有一个“开发”或“快照”，用于在初始提交时在 CI 系统中发生的构建。然后，该工件将移动到“qa”、“preprod”或“staging”存储库，最后移动到“release”或“prod”存储库。当工件退役时，或者当它触发某些保留法规要求时，工件及其可能的所有依赖项都可以移至“存档”。请访问此页面了解完整详细信息。
现在您可以决定根据需要创建多少个存储库。
Let me first eloborate from Artifactory side, then you will be able to decide on the repositories.
Artifactory comes with 3 set of repositories.
For a regular usage, a set of above 3 repositories are good enough.
But if you have development team
In complext/hybrid projects, such as the development, staging and release stages. Artifact promotion can be done in many different ways within Artifactory. From simple property tagging for lesser events (e.g. “passed test X”), to larger quality gates the artifact has passed through. For example from one repository to another repository. In traditional development models this may represent actual teams who own the software in different stages of its life cycle. You may have a “sandbox”, while the artifact is being tested by developers at their desks, and “dev” or “snapshot” for builds that are occurring out of the CI system in the initial build-on-commit. The artifact will then move to a “qa”, “preprod” or “staging” repository, and finally to a “release” or “prod” repository. When an artifact retires, or when it triggers certain regulatory requirements for retention, the artifact and possibly all its dependencies can move to “archive”. Visit this page for the complete details.
It is now your call, on how many repositories you want to create according to your need.