ToB产品的架构版本维护

这两年工作中比较大的一个感受就是随着产品的B端用户增多，产品的架构版本开始变得难以维护，这和我之前做C端产品是完全不一样的。本文就来分享一下ToB产品的架构版本维护中的坑，希望能让大家对架构版本有更多的了解。

我们开发了一套系统，从无到有写过来，这个时候我们还没有具体的客户，只是形成了一套初始的代码，这套系统具备第一个架构版本，我用A来表示。 

现在商务找到了我们第一名客户，我们需要交付给客户了，我们把这套系统做成版本B1，这个版本就是我们的客户版本。我们把B1的代码称为B。看起来，在这个时间，A和B的代码是完全一样的，不过由于B，我们还实际交付了B1的个性化信息（配置项，编译选项等）。

毫无疑问的，我们还是需要继续开发的，新开发的功能合入什么地方？显然是A。而对于B而言，我们就要不断基于它对应的场合进行优化，而且不能轻易加入新功能。A和B被不同的逻辑左右着，决定了我们对B分支的升级，是不会轻易做很大改动。

随着市场的扩展，我们除了B之外，就会发生C，D，E这样的客户版本。我当然希望用一个版本打所有的市场，但这个其实受市场本身的限制，在现实中需要很高的成本。

当我们有多个版本需要维护，那么就有挑战来了。

首先，我们平时的精力主要投在B，C，D上，我们对它们有更充足的质量保证措施，A反而被“冷落”了，由于我们的新特性做在A上的，B，C，D都缺某个特性，客户又急着要，临时把A做一个版本出来，拿去顶一下好不好？结果发现A的质量又跟不上，部署上去就无法给客户一个交代。。。

其实，这个问题的本质是：开发要不断补充特性，质量保证和性能调优要有稳固的特性，这两者都需要分支来支持，而质量保证和性能调优有很高的工作量要求，我们要控制这个工作量，就要正视这个工作量。

所以，到最后，我制定了一套统一做法：

1. 主干版本开发新特性并保证质量，交付局点时使用对应分支，维护不同的分支。

2. 分支上一般少新特性开发，仅问题修改。

3. 不同分支版本多了以后，就考虑版本收编，使用主干的版本升级。

由于制定了这套策略，我们会花更多的时间在A上，确保A一直处于“战备”状态，及时响应不同客户的更新诉求。

本篇是抛开了技术架构本身来谈版本的维护，接下来我会重点谈谈从架构的角度来做好ToB产品的版本维护。

描二维码或手动搜索微信公众号【架构栈】： ForestNotes

欢迎转载，带上以下二维码即可

              

点击“阅读原文”，所有【架构栈】近期的架构文章汇总

↓↓↓