有关管理DLL的建议

Question

我正在努力找出处理我们公司dll更新的最佳方法。以前我们只有一个代码库，每个项目都是重复的。这不好玩。

• 新设置共有7个dll，然后是最终的Unity游戏。
• 5个dll是独立的，它们没有依赖关系。
• 6取决于前5个
• 7取决于前6个
• Unity项目取决于所有7

更新低级别dll时会出现问题。但我们假设我们已经改变了＃6。

• 在本地更新到＃6，测试更改，它可以正常工作
• 从Dev分支合并到Main分支 *此时＃7不知道＃6的变化，我们会说改变不会对＃7产生任何影响

我们是否应该构建＃6，更新＃7（从nuget包获得＃6），将＃7合并到Main，构建然后用所有需要的dll更新游戏？或者我们不应该在＃^中加载＃7来加载＃7，因为我们知道改变后会对该项目产生什么影响。

总的来说，我只是在寻找一些＆＃34;我们如何做到＆＃34;来自其他一些在如何管理他们的dll方面有更多经验的地方

Answer 1

如果DLL是公司内部但在项目/解决方案外部，那么我们只能通过nuget接受他们的DLL。

由团队维护内部依赖关系以通知相关项目是否需要进行更新（关键）​​。然后根据团队风格将其置于当前sprint中或计划为瀑布要求。否则，所有团队间依赖关系都将通过nuget部署，并在下一个或当前开发周期中自动获取，具体取决于团队实践。

无论如何，每个版本的QA都会执行完全回归，因此效果非常好。

因此，在您的情况下，对＃6的更改不会立即传播，除非＃6的团队认为它对组织至关重要，在这种情况下，所有相关项目都必须更新。 ＃7的团队会收到此消息，自行更新，测试，然后向您推送所需的更新。

Answer 2

这是我们在公司使用的方法。我们有一个本地NuGet，每个常见的dll都放在那里。其他项目可以通过NuGet包引用这些dll。当其中一个dll更新时，会自动创建一个新的包并推送到我们的本地NuGet。其余引用该dll的项目在那时已过时，因此我们应该手动更新这些项目上的NuGet包。

NuGet包的自动更新：

我们按照以下步骤使用TFS进行持续集成：

1. 一位开发人员修改其中一个包含其中一个dll的项目。
2. 他/她创建拉取请求（PR）。第一个构建运行以进行编译并运行测试。
3. 当PR获得批准时，将运行另一个构建以进行部署。
4. 第二个版本再次编译解决方案并再次运行测试。
5. 然后，此构建中的NuGet Packager步骤符合新包
6. 最后，NuGet Publisher步骤将发布到我们当地的NuGet。