管理多个代码分支和传递

最简单的解决方案是将产品切割为核心产品,将每个功能切割为插件。这样,每个客户都可以选择他们想要的功能。但即使是这样的解决方案也会很快让一家小公司不知所措。

实际上,您通常处于一种更糟糕的情况:您有一个新的功能,它可以帮助客户a并为客户B中断某些内容(例如,客户B还没有准备好修改其数据库,并且新功能在没有更改的情况下无法工作,因此这实际上使新版本对客户B不可用)。如果你是大的,你可以忽略客户B。

从目前的情况来看,你真的需要找到一种方法来说服你的客户继续前进。最简单的方法就是花钱:告诉他们要花多少钱才能得到一个量身定做的产品,如果你能找到一个适合每个人的解决方案,他们就能节省多少钱。邀请你的客户过来,一起建立一个变更列表,让每个人都同意这个计划。

另外,你真的必须有自动单元测试,所以你可以百分之百的确定今天离开房子的产品不可能比你四周前卖的更差。

即使有最好的版本控制系统(对我来说 git

我们有一个类似的设置一个(相当专业)产品和多个(但只有数百个订单)客户谁都想要自己的宠物功能。

据我所见,你可以走“现成”路线,你的产品是非客户特定的,你添加的任何功能都是为了产品的利益(可能应客户的要求);也可以走定制的咨询路线,每个客户都有自己独特的产品版本。

如果您的客户都需要基本相同的产品,那么您应该走第一条路,这意味着所有功能都属于所有客户。

隐藏特性很容易,维护多个并发版本是

如果您的客户要求选择他们的功能,一个可行的解决方案是为每个功能维护分支,然后非常仔细地从您的总分支复制相关的更改。

这意味着您的提交需要尽可能原子化——只修复一个问题——并且任何更改都不应该直接进入客户分支。但这种做法仍然非常危险。

我做过一些类似的项目。我们所做的是为系统的核心功能建立一个Commom分支,为产品的每个变体建立一个“客户”分支,这样你就可以实现每个客户端的特定功能和错误修复,并且仍然对产品的所有变体在“Commom”中使用相同的更改。

这种方法需要大量的配置管理工作(合并和构建),因此您可能需要一个特定的人员来处理这些任务。

编辑:

另外,你应该(如果还没有)有一个bug跟踪器系统,在这个系统中你应该记录你正在处理的客户机/分支。

我知道你说过有些客户不希望这样,但我看到了许多分行支持的最终结果。你不想那样。这是一场噩梦,将削弱您的开发、产品和测试团队。

别这么做。