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