我应该如何支持和继续开发分叉的应用程序？答案

【问题标题】：How should I support and continue development on a forked application?我应该如何支持和继续开发分叉的应用程序？
【发布时间】：2009-07-06 17:30:23
【问题描述】：

我们有一个在大约 5 个位置运行的大型应用程序。这些位置都没有运行相同版本的应用程序。这使得修补和更新变得非常复杂。

试着按照这个例子：我们将调用我正在谈论的应用程序“应用程序 A”。现在我们想将应用程序 B 部署到这些位置之一，它必须实现应用程序 A。我们必须修改 A 以接受 B 的要求。但是，我们的 A 开发版本（每个位置最终将拥有的版本）也必须支持 B。这意味着我们必须回滚到需要 B 的站点上运行的软件的状态，并对我们的 A 开发版本进行这些更改。这也意味着其他 4 个位置正在实施不支持 B 的 A 版本。

因此，人们可以看到控制版本控制令人沮丧的地方。如果我们想支持站点 2-5，我们不能使用我们的源代码开发版本，我们必须回滚到该站点上的特定版本。最好的方法是什么？请记住，我们使用的是 Visual Studio 2008 和 Team Foundation Server。

【问题讨论】：

听起来像经典的“医生，我这样做的时候很痛！”情况。

标签： visual-studio version-control tfs versioning

【解决方案1】：

我建议的第一件事是重构您的应用，让所有应用都使用相同版本的核心产品。

尝试在逻辑上将特定功能分解到它们自己的模块中，并通过适配器类型模式访问该功能。

【讨论】：

感谢您的术语，约翰。正是我想要的——“分叉应用程序”和“适配器模式”。

【解决方案2】：

约翰指出了至关重要的第一步。在您的代码库内部稳定之前，不会有任何好事发生。

但是，即使您将应用拆分为具有明确定义的接口的可重用组件，您仍可能需要维护许多/所有这些组件的多个版本（“分支”）并并行开发它们的版本。这就是分支的用武之地。

我强烈建议您从头到尾阅读新的TFS Branching Guidance 论文。我对早期的修订非常批评，但文档团队确实改进了他们的产品。（部分归功于随着 TFS 获得更广泛采用而获得的额外反馈......但同样部分归功于最终关注远早于微软进入市场的既定 SDLC 规范）

【讨论】：

“除非您的代码库内部稳定，否则不会有任何好事” - 感谢 Richard 的评论，但这并不是我的真正意思。我的意思是取消分叉核心功能并通过某种类型的插件模型管理额外的、特定于位置的功能。所以每个人都有相同版本的应用程序 X，位置 y 有 y 插件，位置 z 有 z 插件。 KWIM？
如果可以实现 100% 分离，那就太好了。这并不总是可行的。或者它是可行的，但是直到很久以后你才发现需要另一个特定于 loc 的分支。熟悉分支还可以实现许多其他形式的并行开发，这些形式与您的模块化程度正交，例如如何在处理 X+1 的同时维护版本 X。