Stable与PreSale版本同时在线的一些思考

最近部门在讨论代码流程管理，无论是采用标准的gitflow还是github的分支模型都无法规避一个话题，如何同步实现Stable和PreSale兼容的事宜，目前将采用fork项目、双主分支同步开发的双模式方案尝试，但仔细思考，以上两种方式在研发过程有一个共性，均需要我们类似的维护多项目，但又需要指定里程碑的MR操作。先不去想是否是最合适的，但有一种可能大家都不是那么在意的傻瓜方式，通过版本(开关)管理系统实现灵活的多版本切换。下面从研发流程中的不同角色聊聊这个管理系统能够带来些什么好处：

1、我是开发者：如果要你同时维护两个项目，还是一样的功能，是不是比同时做两个不同的项目还要你的命。这还不够，长时间后的MR，我的天，该如何解决冲突，该如何解决可能带来的common部分的冲突。能够只维护一个项目，合并一个主分支，是件多么开心的事情。好吧，既然用了版本管理系统，我们日常系统需要如何处理呢？

服务提供方：

• 对于API级别的差异，通过PATH中的占位符体现差异，将版本规则定义在版本管理系统即可。个人不建议采用header来操作，path这么直观的定义方式比起“你是不是又忘记加version参数啦”更容易协作。当然该场景更多的都是服务调用方很明确我会采用哪个版本的API。那么动态不明确的规则就让管理系统帮助你吧。
• 对于服务级别的差异，其实就是如何实现灰度发布，在版本管理系统维护白名单规则即可，通过网关层动态路由即可。如果需要能够动态切换全局，也许我们的规则定义加上一个'全局应用'参数也不是不可以。

服务调用方：该何时加载版本管理系统中的规则呢，对于不同的客户端也是不一样的，比如

• 前端，也许可以在登录时加载至localstorage；在需要的页面多一次加载，如果需要也不是不可以；
• 后端服务，启动初始化加载+定时轮询更新；
• 如果有一个可以动态触发的配置中心也不是不可以，但通常能够实现的规则相对简单。

不同的场景有不一样的解决方案。

可是为什么说 傻瓜方式呢？是的，你会很讨厌在代码里面加入各种if语句来配合版本开关的使用，看起来确实不那么优雅。不着急，先想想，我们代码中的if还少吗，真的就那么在乎一个if判断吗？if条件的判断会让你的业务更加的清晰，清晰的留下版本和场景差异化的处理方式，并在调整版本取舍时仅仅做减法操作即可，删掉一段代码我想不会让你很难做吧。我们还会强制你git提交注明下为何删除了指定版本实现，一切都是有据可循。再来想想我们的代码是不是真的会因为一个if的引入而冗余，没错你可能是处女座的，不喜欢这样。但一旦组件化，一旦提取common method后，是不是没有那么的丑陋，而在我们进行单元测试编写，功能测试的时候是不是也更加有底气，无需为了两个项目单独编写，并担心复制过来的代码水土不服。也许有人觉得会让我们的安装包变大，可是能大多少呢，不如仔细想想添加的那个jar依赖是不需要的。

2、我是QA：类似的功能个性的差异，两个不同的分支亦或是项目。QA同事需要完整的面对两个环境进行验证，缺一不可。相同的case占比也许有90%，也许更高。不错，实现了case的复用，这就够了吗？QA们是不是

需要对应不同的项目（不同主分支）进行case的版本对应维护，又多了一个子项目了貌似，也许可以精简吧，但一定少不了更多的规范。这还不够，还需要等待每个项目漫长的自动化测试跑完，也许我们的机器资源有限，需要one by one的执行，浪费了多少的时间，QA们可能等着回家照顾孩子作业呢。要不跳过相同的case，谁能保证一定没有问题，静音5s钟，没有人能够保证，还是老实等待吧。

结合版本化管理系统，QA们仅仅需要维护一个完整项目的case，其中仅仅多了几个API的case，几个UI的case。一切本该如此简单。

3、我是OPS：要发布了，我的天，我要准备两套环境的发布。这有点搞事情哦。QA、CI、Stable环境是不是也要准备多一点点资源呢，具体还得看你们要不要，谁说一定不会要呢。没办法只能听开发的了，很失落吧一定。生产环境是不是一定要高可用呢，也许PreSale版本仅仅多了那么一个Beta功能，还是需要哦，这个是底线。好吧，至少又多了两台机器资源，我要去申请了，想想邮件怎么写吧。能不能不要这么复杂呢，采用版本管理系统吧，一切还是最初的那么简单。

4、我是架构师：这个场景和服务降级很类似啊，需要动态服务降级，不也要个管理系统么，通知对应的服务按照指定的规则紧急降级。配置中心也可以对一些相对简单的场景实现动态服务降级处理，但一些复杂的规则场景，真的还是需要一个管理系统，让一切业务都管理起来。回到正题，两个场景还真的很类似，不如试试版本管理系统也。何必让一个简单的代码流程管理如此复杂呢，甚至还找不到一个最佳解决方案。服务治理，不仅仅是做一些链路监控、服务注册发现、日志收集、服务监控，其实类似场景都应该被治理，被管理起来。

5、我是老板：最近怎么回事，费用多了不少。这些机器就是为了这两个功能？我想每个人都会算账的。

通过上述的5个角色简单的介绍了下为何我们需要这样的一个系统。

当然不能说这个方案就是最佳的，也不能说比fork方式更加优秀，一切还需要实践出真知。上述仅仅是个人的思考， 欢迎对此话题感兴趣，有过实践经验的人留言。

注：如果是PreSale功能，还是非常建议添加"预览版"、"Beta"等字样。首先用户看到相关字样，即明白这是一个新的功能，也许是我需要，这远比让他去看更新说明来的直观，当然如果特殊字样还能链接一个功能说明，那就太棒了。关键在于此时他的期望值可能仅仅停留在60分，而后一阶段我们做了些优化正式发版了，去掉特殊标签字样即可，但可能我们确实只能实现到80分，但对于客户来说还是有进步的，该功能的可用性更高了。但如果最初没有对应的"预览版"、"Beta"标签，对不起客户的期望值可能是105分，也许你真的做到了100分，但世界没有那么多的完美贴合，能给你80分可能有点难哦。