我们希望使用NuGet在组织中的开发人员之间共享程序集。目前，我们正在考虑设置三个NuGet源，如下：
- 发布源：程序集的稳定发布版本。
- QA源：在主干分支（我们的集成分支）上构建的程序集。
- 开发源：在任何特性分支上构建的程序集（共享进度）。
开发人员机器上的本地构建应该不会被发送到这些源中。只有构建服务器生成的构建才应该这样做。我们的构建服务器执行三种不同类型的构建，具体取决于分支：开发分支、QA分支和发布分支。每个都对应一个构建配置，可以触发源代码更改。在构建过程中，它们将把已构建的程序集NuGet包推送到相应的源中。开发构建将在版本号后添加"-dev"。QA构建将在版本号后添加"-qa"，而发布构建将有一个“纯”版本号。
现在，问题：
开发人员要控制使用哪些软件包最好的解决方案是什么？我猜开发人员必须手动编辑依赖源参数来明确定义从哪个源获取程序集：有时您需要发布程序集，有时需要QA程序集，有时甚至需要最新的开发版本。
我们还考虑将本地构建包推送到每个开发人员自己机器上的本地私有源中，以帮助加速构建。这在源方面是否会有问题？
如果这些定义是由开发人员在依赖文件中进行的（这也必须进行版本控制），则该设置将在提交到存储库时带入开发源中（与开发人员的重点相同，只是与其他人共享）。这可能是开发源的正确设置，也可能不是？
当源代码合并到QA分支时，依赖关系中定义的feeds仍然是开发者制作的，可能会从开发feeds获取程序集。对于QA构建，我认为这可能不是我们想要的。 QA构建应该限制feeds只使用发布程序集，因为您希望看到更改是否与发布组件一起按预期工作。您不希望使用其他“未经测试”的QA程序集进行测试。 这对他人也有意义吗？
在发布分支中，发布版本的构建应该仅使用发布feed的程序集，我猜？ 我觉得可能已经有共识了，因此可能根本不是问题：）。
因此，总结所建议的过程......在构建期间，我们应该：
- 遵循开发人员在本地和开发构建的依赖关系规范中设置的源。
- 在执行QA和Release构建时，应将feed限制为Release feed。
顺便说一句，QA feeds实际上不会被任何其他构建使用。但是，QA部门将使用这些进行测试。