我已经读完了 Pro Nuget 这本书，我认为将它用于我们的依赖项会比我们当前的方法更好。此外，您可以构建应用程序部署包以将您的构建部署到各种环境，我们也在寻求更好的自动化。
其中一个想法是拥有多个 Nuget 提要；一个 ci 提要，每个成功的集成都会发布一个包，一个 qa 提要，您只发布您希望 qa 测试的版本，然后是一个发布提要，您只从他们成功测试的 qa 提要中复制包。
我喜欢这个想法，但建议通过以 -alphaXXXX 或类似结尾的版本将 ci 构建标记为预发布。但是，如果我这样做，我需要在升级到 qa 提要期间删除该名称。我认为您必须修改包才能做到这一点，但是 Nuget 包的部分吸引力在于，一旦构建，您就不会更改它们
另一个想法是，由于我们主要在主干中工作，所以当我创建 rc 分支时，我们的构建过程将停止添加版本的预发布部分。这似乎可行，然后从 qa 推广到发布提要将是一个简单的包副本。
有没有人在做这种方法，这是推荐的方法吗？我错过了什么吗？我在谷歌上搜索过，但没有发现很多关于这种方法的细节的讨论。
我是这本书的作者之一，所以我希望你喜欢它！我们正在编写包含大量新内容的第二版，并且正在处理这个特殊案例。
澄清一下，将 CI --> QA --> PROD 场景设置为示例包推广流程：如果您愿意，可以创建自己的。
您的观点是正确的：包装促销不应要求对包装或其内容进行任何修改。这实际上意味着在将包推广到另一个提要时，甚至不会重建包内的二进制文件。此规则的唯一例外是软件包预发布版本，可以调整或删除。注意：推广时语义版本应该保持不变！
这是http://www.MyGet.org的核心功能：这里是它的文档http://docs.myget.org/docs/reference/package-sources（场景：向上游推送包）。
上述原则应用于此功能，我们还负责提要安全/api 密钥。如果您不使用 MyGet，那么您需要自己执行此操作。逻辑步骤是：
许多开源项目都在使用这种方案，在 MyGet.org 上使用 CI 源，然后将上游推送到 NuGet.org。上游包源可以是任何其他 NuGet 源（例如 Chocolatey.org 库、Resharper 插件库、另一个 MyGet.org 源，...）。