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

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

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

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

现在，问题：

1. 开发人员控制使用哪些软件包的最佳解决方案是什么？

在我看来，您建议的流程对于您现在的团队规模和未来一年的团队规模来说都过于复杂。

我明白你的原因think您需要三个单独的提要（开发、质量保证、发布），但我预测这将在一年内让您感到痛苦。我希望您希望在软件包从开发到质量检查再到发布的过程中增强对软件包稳定性/质量的信心——这是一个完全合理的要求。然而，单独的分支机构，特别是单独的builds许多人认为 Dev、QA 和 Release 是一种反模式。具体来说，在这本开创性的书中持续交付作者：谦卑和法利 http://continuousdelivery.com/，强烈建议仅使用一个代码库来进行构建，并且any如果测试通过，这些构建应该能够升级到生产：“仅构建代码一次”是关键。

我建议您：而不是您概述的模式：

1. 使用 CI 工具来建模部署管道 http://www.informit.com/articles/article.aspx?p=1621865：Jenkins、TeamCity、TW GO 等。这为将工件直接从初始 CI 构建一直流向生产而无需重新构建奠定了良好的先例
2. 使用语义版本控制（称为SemVer http://semver.org/在 .NET 世界中），以保护包使用者免受重大更改的影响，并向其他团队传达包更改的性质。
3. 使用版本范围约束packages.config这样构建就不会被新的主要版本的软件包破坏（带有重大更改）
4. 让开发团队负责从代码提交到生产的特定包 - 如果他们维护的包之一出现问题，他们需要快速提供修复，以便其他团队不会受到阻碍。团队还需要纪律，以确保他们通过 SemVer 传达包更改的性质（这是重大更改？新功能？错误修复？）
5. 如果您认为有必要，请使用 NuGet 的预发布功能从下游构建和测试中“隐藏”新的包版本。这可能允许开发团队更有效地进行更改，但如果您使用允许快速制作和交付新包版本的部署管道，则可能没有必要。

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