同一项目多个客户的分支模型建议

我们有一个非常大的项目，其中包含作为不同客户基础的几个应用程序。

每个客户都有自己的产品个性化，不同的里程碑，不同的要求等，因此每个项目将根据自己的需求独立发展。

项目的核心在每个项目中都是相似的（但不相等），并且组织的组成使得团队可以独立处理每个客户（但根据需要在他们之间进行沟通）。到目前为止，无论是通过搜索互联网还是提出一些绝妙的主意，我都找不到适合我们需求的方案：)

到目前为止，我们一直在努力使产品适应所有需求，并为需要的更改提供特定的分支，但是，尽管产品具有良好的体系结构，但它正逐渐成为一个大问题。这是我们面临的主要问题：

• 每个客户的里程碑不同：这意味着每个团队必须在不同的时间生产版本，而其余的提交都不会影响其稳定性或产品。
• 不同的要求，在某些情况下可能会或可能不会影响系统的核心。
• 大型团队（超过20个团队成员）
• 处理系统中的错误：如果团队发现其项目中的错误可能会影响其他客户，该怎么办？

注意：我们正在谈论的项目具有10 + M LOC。

注意：我们正在使用Team Foundation System，Visual Studio 2008和C＃（主要）。

关于如何解决这种情况的任何建议，消息来源或想法？市场上是否有类似问题的模型？

实际上，我建议您不需要分支模型，而需要一种完整的综合方法来处理不分支的系统的多维约束。在实践中，我认为维护多个具有某些共性但在分支中会有所不同的系统始终是一个问题，因此最好将所有内容都转换为一个可以整体发展但由不同配置组成的单个系统。这似乎太简单了，但是在这一领域已经进行了广泛的研究，并且有许多成功的工业应用。

这种方法的名称是软件产品线或有时称为产品线工程。从CMU SEI的“软件产品线”页面：

软件产品线（SPL）是一组软件密集型系统，这些系统共享一组共同的，受管的功能，这些功能可以满足特定细分市场或任务的特定需求，并以规定的方式从一组常见的核心资产开发而成。

关键思想是，每个需求，每个里程碑，每个功能（在此领域中都是关键术语）都是整个系统的最高层。在各个客户处部署的实际系统实质上是功能的集合。但是，每个功能不仅是混入系统中的物理组件，还被定义为依赖于其他功能或由其他功能启用（因此，通过选择一个功能，您可以自动包括其依赖性等）。

而不是维护所有这些分支，而是最终维护一个系统以及一组特定于客户的配置。

在实践中，很难或什至不可能迁移到具有非常大的系统的这种方法，但是即使那样，调查SPL中使用的方法以评估至少可以使用（部分）使用的方法也将是有用的。融入您的工作。

一些其他有用的链接：

• 维基百科：产品线工程
• CMU SEI的案例研究
• 软件产品线，一个包含大量入门资料的站点。

当我开始第一份工作时，我从事过类似的项目（但规模较小），并且遇到了相同的问题。我们还从所有客户的一般解决方案处理需求入手，但只有在需求变得矛盾的同一点上才有可能。我们按照您的建议做了，并为每个客户端启动了单独的版本。即使这样解决了需求和自定义的问题，它也成为解决错误和全局更改的维护噩梦。

因为应用程序中的代码仅是相似的，所以将一个客户版本到另一个客户版本的更改合并非常复杂，并且需要分别重新测试每个版本（我们没有自动测试！）。它经常导致不同版本的回归错误。在您的情况下，情况可能更糟，因为一个团队将解决其版本中的错误，而另一个团队将不得不合并他们不完全了解的版本中的更改（我们是一个团队，负责所有版本）。

除非您拥有一些共享的全局核心，否则您将遇到同样的问题。在我离开公司之前，我们发现我们的方法不正确。为了支持这种开发方案，我们需要共享的可扩展核心和数据模型，这些模型可以从上层可定制的应用程序层进行配置。此核心应用作每个客户特定定制的基础，并由单独的团队维护。这将带来一些管理上的麻烦，因为多个项目经理将需要来自同一团队的资源，但这是使体系结构保持一致，控制整个过程并使版本保持同步的唯一方法。

我可能是基础，但我认为您使用系统核心所面临的问题是每个使用组件并需要维护和支持其软件的不同发行版的人所面临的相同问题，并且这些不同的发行版都需要不同的版本组件版本。

例如

• 版本1.0需要库A 1.0，库B 2.0，库C 5.6
• 版本2.0需要库A 1.0，库B 3.7，库C 5.7
• 版本3.0需要库A 1.2，库B 3.7，库C 5.8

解决组件问题的方法是在版本控制系统中拥有所有版本的库（我们在源代码上构建它们），并通过更改其搜索路径（引用路径？）使每个项目使用正确的库版本。

在Delphi中，如果您在设计时不需要库，则可以通过项目的配置文件轻松地完成此操作（在源代码控制下），否则它仍然可以实现，但是由于您需要切换Delphi IDE才能使用而变得更加痛苦。以及正确的版本（此处受版本控制的注册（.reg）文件可以帮助您解决）。

您的核心系统的解决方案可能是将其视为您维护不同版本的库。从本质上讲，这意味着您需要为每个版本设置不同的分支。然后，客户端的应用程序可以通过引用适当的核心系统的分支文件夹来使用适当的核心系统“版本”。

核心系统的依存关系类似于上面的示例，而客户端应用程序的依存关系则“只是”有一个额外的参考：核心系统的版本。

使用多个客户端应用程序的另一个好处是，您可以选择何时开始使用特定版本的核心系统，并且不受特定客户端应用程序尚未使用的核心系统更改的影响。