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

Question

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

• 发布Feed ：组件的稳定版本质量版本。
• QA-feed：在主分支（我们的集成分支）中构建的程序集。
• 开发Feed：在任何功能分支中构建的程序集（共享进度）。

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

---

现在，问题：

1. 开发人员控制使用哪些软件包的最佳解决方案是什么？ 我想开发人员必须手动编辑依赖关系源参数来明确定义从哪个Feed获取程序集：有时您需要发布程序集，有时需要QA程序集，有时您甚至需要前沿的开发版本。

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

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

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

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

---

所以，总结一下建议的过程......在构建期间我们要：

• 在本地和开发版本的依赖项规范中遵循dev设置的源。
• 在执行QA和发布版本时，Feed应限制为Release Feed。

作为旁注，QA Feed实际上不会被任何其他版本使用。但是，质量保证部门将使用它们，因为他们将使用它们进行测试。

Answer 1

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

我理解为什么你认为你需要三个独立的提要（Dev，QA，Release），但我预测这将在一年的时间内让你感到痛苦。我希望您希望增加对包的稳定性/质量的信心，因为它们从开发到QA再到发布 - 这是一个完全合理的要求。但是，对于Dev，QA和Release，单独的分支，尤其是单独的构建被许多人视为反模式。具体来说，在开创性的书籍Continuous Delivery by Humble and Farley中，强烈建议只使用一个代码库来构建，并且这些构建中的任何应该能够在测试时被提升为Production。传递：“仅构建一次代码”是关键。

我会建议你：

而不是你勾勒出的模式

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

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