-1

这个问题可能太宽泛了，但是...

我有 300 个项目（比如 project1_v1.sln、project2_v1.sln...）都依赖于 1 个类库（比如 classLib_v1.sln），每 3 个月我们需要对类库（接口和实现）进行一次小修改，其中会破坏一些项目，然后你修复这些项目并部署......讨厌......

但....

与其修改现有项目，不如将它们重新生成为新的“分支”版本......

所以...克隆 classLib1.sln 以使 classLib2.sln 进行修改，然后将 project1_v1.sln 重新生成为 project1_v2.sln，它引用 classLib2 而不是 classLib1 ...编译...并修复。

即每个项目都有 2 个版本。

感觉就像某种产品的自动化“生产线”。

我们确实使用 TFS，但我们的版本控制是非常线性的，所以我特别不知道如何处理这样的事情而不会造成混乱。

想法？

有几个有用的响应，但要明确一点，这不是要避免重大更改，代码会中断，而是要自动更改（引用），然后使用该自动化告诉我们代码在哪里坏了。

依赖注入被认为是一种解决方案，并且可以使用，但您仍然需要自动更改配置，缺点是可配置的 DI 不是类型安全的，因此编译器无法再告诉您您在哪里有问题。

4

3 回答 3

2

如果更新接口导致重建，并且目标不是针对现有消费者对新更改进行重建，那么不应对导致重建的现有接口进行更改。

如果提供了新功能，则应创建一个新接口，该接口可以继承自通用接口作为基础，甚至可以继承以前的接口；因此只会向新消费者公开新功能。

于 2017-06-12T12:37:22.320 回答
1

这可以使用依赖注入来完成，而不是一直重新编译代码，您依赖于 xml 配置，这样您就不需要每次依赖项更改时都重新编译代码。但请注意，在您添加新功能或方法而不是删除或重命名您使用的功能或方法之前，这将起作用。

以下是与您有同样问题的问题之一。

依赖注入 - 通过配置文件在运行时选择 DLL 和类实现

现在，还有一件事。tfs 有一个可供您利用的持续集成过程选项，因为您应该是 tfs 的管理员。您可以指定一个 Gated Check-In 选项，以保护您在更改代码时避免崩溃。这是文档门控签到

现在，您还可以为所有项目在 tfs 上放置一个触发器，如果​​它们指向特定文件夹以监视该文件夹的更改，如果有人签入了对存储在那里的依赖 dll 或项目的更改，那么您可以在 tfs 上启动自动构建，以查看该特定项目是否正确编译或不使用该新依赖项。

于 2017-06-12T13:15:01.150 回答
1

最终，我认为这是一个关于 CI 和源代码控制的问题（不是软件架构、DI 和任何其他类似的东西），有时，不可避免地你必须应用一个破坏某些东西的更改（除非你不将你的代码与任何抽象结合起来...... ..并使用 CTRL C 分享行为！）。

所以答案是……研究如何使用源代码控制和 CI 来进行一系列应用程序的开发、UAT 和生产版本

于 2017-06-12T14:23:20.973 回答