关于管理DLL的建议

Question

我想弄清楚处理我们公司的DLL更新的最佳方法。以前，我们有一个单一的代码库，每个项目都重复一次。这并不好玩。

• 新的设置共有7个DLL，然后是最终的Unity游戏。
• 5个DLL的独立，他们没有依赖。
• 6取决于第一个5
• 7依赖于前6
• 统一的项目依赖于所有7

的问题上来更新低水平dll的时候。但让我们假设我们已经改变了＃6。

• 制作更新＃6本地，测试的变化，它的工作原理来自Dev分支
• 合并到主分支 *此时＃7是不知道＃6的变化，我们会说变化难道不不影响＃7的任何方式

我们应该＃6的生成，更新＃7（这是从NuGet包越来越＃6），合并＃7主，构建并更新与所有需要的DLL的游戏？或者我们不应该因＃^更新而加载＃7，因为我们知道更改将不会影响该项目。

总的来说，我只是在寻找一些“如何做”从在如何管理更多的老将经验其他一些地方的dll的

Answer 1

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

如果需要进行更新（关键）​​，则由团队维护内部依赖关系来通知相关项目。然后这会被放入当前冲刺中或根据团队风格计划为瀑布需求。否则，所有团队间依赖关系都将通过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。