NuGet Enterprise - 针对不同成熟度级别的包的最佳实践

Question

我们希望使用NuGet在我们组织的开发人员之间共享程序集.我们目前正在设置三个NuGet源,如下所示:

• 释放进给:组件的稳定版本质量版本.
• QA-feed:在master-branch(我们的集成分支)中构建的程序集.
• 开发Feed:在任何功能分支中构建的程序集(共享进度).

不应将开发人员机器上的本地构建发送到任何这些源.只有构建服务器完成的构建才能执行这些操作.我们的构建服务器执行三种不同类型的构建,具体取决于分支,Development,QA和Release分支.其中每个都具有相应的构建配置,可在源更改时触发.在构建时,每个构建器都会将构建的组件 - nuget-packages推送到相应的feed.Development-builds将在版本中添加"-dev".QA版本将为版本添加"-qa",而版本版本将具有"纯"版本号.

---

现在,问题:

1. 什么是开发人员控制使用什么包的最佳解决方案？我想dev手动必须编辑依赖源param以显式定义从哪个feed获取程序集:有时你想要发布程序集,有时你需要QA程序集,有时你甚至想要最前沿的开发版本.

2. 我们还在考虑将本地构建包推送到每个开发者自己的机器上的本地私有源,以帮助加速构建.就哪些饲料来说,这会有问题吗？

3. 如果这些定义是由依赖项文件中的dev(也必须是版本控制的)创建的,那么当源被提交到repo时,该设置将被带入Development feed(与开发人员相同的构建焦点,只是与他人分享).这可能是也可能不是开发Feed的正确之处？

4. 当源被合并到qa-branch时,依赖关系中定义的提要仍然与开发者一样,可能从Development feed获取程序集.对于QA版本,我认为这可能不是我们想要的.QA版本应该仅限制发布程序集的订阅源,因为您希望查看更改是否按照发行版组件的预期工作.您不希望使用其他"未经测试"的QA程序集对其进行测试.这对其他人也有意义吗？

5. 在发布分支中,发布版本应该只使用发布供稿程序集,我想？我有一种感觉,可能会就此达成共识,所以也许根本不是一个问题:).

---

因此,总结一下建议的过程......在构建期间,我们将:

• 在本地和开发版本的依赖关系规范中遵循开发人员设置的源.
• 在执行QA和发布版本时,Feed应限制为Release Feed.

作为旁注,QA订阅源实际上不会被任何其他版本使用.但是,质量保证部门将使用它们,因为他们将使用这些进行测试.

Answer 1

在我看来,你建议的过程太复杂了,无论是现在的团队规模还是未来一年的团队规模.

我理解为什么你认为你需要三个独立的提要(Dev,QA,Release),但我预测这会在一年的时间内让你感到痛苦.我希望您希望增加对包的稳定性/质量的信心,因为它们从开发到QA再到发布 - 这是一个完全合理的要求.但是,Dev,QA和Release的单独分支,尤其是单独的构建被许多人视为反模式.具体来说,在Humble和Farley的连续交付的开创性书籍中,强烈建议只使用一个代码库来构建,如果测试通过,任何这些构建应该能够被提升为Production:"构建代码只有一次"才是关键.

而不是你勾勒出的模式,我建议你:

1. 使用CI工具,它允许您为部署管道建模:Jenkins,TeamCity,TW GO等.这为将工件直接从初始CI构建一直流向生产而没有重新构建设置了良好的先例
2. 使用语义版本控制(在.NET世界中称为SemVer)来保护包使用者免受更改,并将包更改的性质传达给其他团队.
3. 使用版本范围约束,packages.config以便新的主要版本的软件包不会破坏构建(具有重大更改)
4. 让开发团队负责从代码提交到生产的特定包 - 如果他们维护的其中一个包有问题,他们需要快速提供修复,以便其他团队不被阻止.团队还需要遵守纪律以确保他们通过SemVer传达包更改的性质(这是一个重大改变吗？一个新功能？一个错误修复？)
5. 如果您认为有必要,请使用NuGet的预发布功能从下游构建和测试中"隐藏"新的软件包版本.这可能允许开发团队更有效地进行更改,但如果您使用允许快速创建和交付新软件包版本的部署管道,则可能不需要.

简而言之,只需构建一次源代码,并设置自动化,以便可以使用部署管道快速推出对现有包的任何修复.