我正在考虑为私人订阅源设置NuGet服务器,这看起来很简单(有一个循序渐进的指南)。我预见的问题是它看起来不像是支持多种环境。
我主要担心的是我们更新了一个软件包并将其用于我们的测试环境,但我们不希望我们的测试版或生产环境在出现问题时失败...我们要等到更新后才"批"在它可用于Beta之前,然后第二次批准使其可用于生产。
答案 0 :(得分:6)
在我目前的工作场所,我们遇到了类似的问题。在不稳定分支中正在开发的NuGet软件包应该可以在我们产品的Alpha版本上进行开发,但不能用于我们产品的Beta / RTM版本。因此,为了实现这一目标,我们设置了3个不同的NuGet存储库:
开发存储库:所有开发人员都具有只读访问权限的文件共享。文件共享有一个用于NuGet包的空间,另一个用于匹配的NuGet符号包。只有构建服务器(和构建工程师)具有对此存储库的写访问权。
QA存储库:类似于开发存储库的另一个文件共享。
生产存储库:Klondike NuGet server的私有实例,用作所有允许在生产版本中使用的NuGet包(及其源)的NuGet和符号服务器。
作为分支策略,我们使用GitFlow。使用此策略允许我们使用以下方法:
feature
分支上完成的构建将其NuGet包推送到开发存储库。hotfix
或release
分支上完成的构建将其NuGet包推送到QA存储库develop
或master
分支上不会进行编译构建。可以将包引入生产存储库的唯一方法是通过QA存储库进行升级。为了实现这一点,每个产品存储库都有一个指向master
分支的构建。当新的合并提交被推送到此分支时,构建将执行以下步骤:
nuspec
文件并从这些文件中获取软件包名称,确定哪些NuGet软件包已从新版本发布。这个工作流程显然可以扩展到包含开发存储库,但到目前为止我们还没有看到它的需要。
请注意,如果您想以这种方式推广软件包,那么为QA存储库提供的构建生成包含最终版本号(例如1.2.3)而不是预发布版本号(例如1.2.3)的软件包非常重要。 -alpha0001)否则促销构建无法确定要抓取的正确包。
这种方法的另一个好处是,当代码被推送到生产分支时,开发人员不必对他们的项目文件进行更改,因为项目文件已经引用了正确的NuGet包版本。
所以回答你的问题: