我们是NuGet的大用户,我们有25-30个包,我们在网络共享上提供.
我们希望能够在消费应用程序中构建和发布新软件包之前对其进行测试.理想情况下,这可以使用类似于Maven的快照并具有特定开发包(例如快照功能)来完成.
有没有其他人想出一个理想的非合法的方式呢？
我们偏爱的方法是生成包装配件,然后手动覆盖packages /目录中的装配,即替换实际的项目引用,但这似乎并不特别干净.
更新:
我们使用CI构建服务器,它在每次提交时都会创建构建,并且具有特定的手动触发的NuGet构建,该构建可以使用特定标记的代码库版本.我们不希望在每次提交时都创建一个NuGet构建,但是我们希望能够在触发手动NuGet包构建之前在野外测试可能的候选者.
如果您使用 NuGet 包来分发库，则不应仅限于测试库。您还应该测试软件包本身（如果您的二进制文件正常但安装不正确，消费者仍然会遇到问题）。重点是改善这种体验。
一种方法是拥有额外的 CI 或 QA 存储库。您当前拥有的实际上是您的“生产”存储库，其中包含可消耗的版本，被视为高质量的成品。
更进一步，您可以有一个逻辑包升级流程（基于持续集成，甚至使用持续交付方法），其中： - 每次签入都会在 CI 存储库上生成一个包 - 测试人员挑选一个 CI 包进行 QA，并且如果发现可以将其提升为 QA feed 或 Production feed（无论您喜欢什么，都取决于测试的质量及其自动化程度）
有多种方法可以实现此场景，使用简单的网络共享、内部 NuGet.Server 或 Gallery 实现，或者简单地使用http://myget.org以最小的成本和零的努力进行尝试。
希望有帮助！
干杯，泽维尔
| 归档时间： |
|
| 查看次数： |
3454 次 |
| 最近记录： |