我的组织有一个.NET解决方案（C＃MVC），我们正在努力保持我们的解决方案可重用但同时可扩展。
我们有4个客户
A，B，C，D
这些客户中的每一个都需要一个网站，每个网站都非常相似，比如90％相似。因此，我们创建了一个基本模板，其中包括数据层，核心，服务和Web层（包括控制器/帮助器/映射/验证）。所有客户端都将使用此模板。客户端不会共享代码的唯一部分是标记和将应用于该客户端的主题。甚至脚本/基本css也将在客户端之间共享。
直到现在，这已经相当好地工作了大约7个月。
客户A和B已经部署并投入生产。
我们目前正在开发客户端C，而客户端D尚未实施。
在客户端C上工作时，客户端A和B也需要修复错误/更改功能等。但是因为我们正在使用客户端C，所以模板并不总是“生产就绪”，因此将为客户端A和B发布代码未经测试的代码。我们现在一直在客户端C中直接实现大部分功能，以避免对模板进行更改。
当然，一个简单的选择是分支和处理分支，但因为我们被迫使用TFS，这使得它变得困难。我们很可能只是从那里开始分支和工作，但有没有其他建议（信息来源）来阅读其他人如何解决这个问题？
答案 0 :(得分：0)
根据我的经验，分支是使客户解决方案彼此更加独立的最佳方式。此外，您可以决定何时将更改合并到客户解决方案中，并且不会强制发布非生产准备的代码以及客户的错误修复。
直接的方法是让所有项目都在解决方案中，并为包含源代码中的完整解决方案的每个客户创建一个分支。这样，您可以对完整代码进行客户特定的更改。您的源代码树看起来与此类似：
如果要在共享基础组件和客户特定代码之间引入更大的分离，您可以考虑为基础组件创建单独的解决方案，并让客户特定的解决方案和项目引用二进制文件。虽然确保基本组件的更改（迟早）以相同的方式合并到客户项目中，但这要复杂得多并且需要大量的工作。此外，由于无法对基本组件进行客户特定更改，因此您的灵活性较低。我建议只有在您期望很多客户项目的情况下才这样做，因为这样您就可以获得一套经过测试的基本组件，这些组件对所有客户都是相同的。 您的解决方案树看起来像这样：
当然你可以混合两种方法（所描述的是极端）。我希望这会有所帮助。