处理特定于客户的软件补丁的现实方法是什么？

我正在尝试收集其他人解决以下问题的有效方法。在工作中，我们被迫发布仅希望特定客户看到的软件补丁（安装在最终用户系统上）。定制代码位于其自己的源代码控制分支中。问题是我们有两条并行的代码行（和构建脚本）保持同步，并且每次我们修补原始代码时，我们都必须修补和测试客户特定的代码。

我很好奇，其他组织如何处理这种情况？我们向业务解决方案开放，而不仅仅是技术（与源代码控制相关）解决方案。例如，我们已经讨论过告诉客户他们无法在该分支上接收更新。

我们的分支策略是这样的（基于Visual Studio TFS分支指南，尽管我们正在使用Subversion）

当您开始发布客户特定的补丁程序时，您已经立即创建了必须随产品一起维护的产品的新版本。这意味着必须在两个版本之间传播更改。通常，客户特定的修补程序是客户应拥有的自定义内容，包括源代码。

这似乎不大可能，一个补丁修复的东西也不会让它到主线分支，除非这是一个不太理想的临时的办法解决眼前的问题。如果是这种情况，则仅需要维护补丁，直到预期的修复程序进入主线为止。

在我看来，关键是“可见的”-根本没有单独的代码分支，而是可以改变行为的配置选项？

您认为这是短期还是长期的事情？事实是，企业已经决定适应这个客户，因此从短期来看，这已经是一个主要由商业实践解决的业务决策（接受额外费用/向客户收取费用）。

如果是长期的，那么如果您重构软件以通过配置（或设置等）轻松满足客户需求，您可能会看到节省。

如果这是相对短期的，则意味着您将很快将这些更改合并回main / development分支，并且所有用户也将看到这些更改，那么在当前情况的限制内工作可能是可以接受的。就像我说过的那样，应该在做出适应客户的决定时做出决定。

长话短说。从技术上长期解决它，短期内解决它。

当然，有一点就是抛硬币。如果您在那时，那么我将做开发人员喜欢的任何事情。

我们也使用颠覆-我们碰​​到了这种情况。

这里有一些要记住的要点：

1. 虽然有必要一定要避免为客户提供专门的分支机构，但必须将其需求减至最少。总是问是否有可能推广可能适用于所有人的解决方案。

2. 客户特定的分支机构必须源自新版本。假设您有一个1.2版，并且从1.2.1版到1.2.11版都已经衍生了-应该允许客户分支所有补丁，因此客户分支必须与主版本保持兼容。

3. 开始新的不兼容版本时，需要重新创建客户特定的分支。不幸的是，您可能需要以某种方式重新进行工作。一种解决方案是从客户分支中创建所有补丁，然后将其提取，然后将仍然兼容的任何内容应用于新的客户分支。

4. 始终在任何情况下都不应将客户特定的更改推回发布分支或主干。但是，理想情况下，应尝试以减少此类特定于客户的工作的方式来概括该工作。

我试图将这些想法放在一起显示：

如何在代码中引入扩展机制？

您的主要代码有：

class Foo
{
}

程序启动时，将在其启动文件夹中检查DLL /道德等效项以进行本地自定义。如果找到一个，它将加载并且可能包含公司特定版本的Foo

class FooForABC : Foo
{
}

FooForABC实现与Foo相同的行为，但会根据需要重写功能以提供ABC所需的特定行为。该技术应足够灵活以处理您需要支持的任何方案。