版本的故事(一)为什么要写版本的故事

随着组织的发展,开发人员越来越多,很多公司开始建立专门的技术部门开发共用组件。能不能做出好用的共用组件,技术能力当然是必不可少的。但是经历了很多项目的生生死死,越来越觉得版本管理也是一个十分重要的因素。很多基础组件做的时候红红火火,做了两年就恍恍惚惚了。有很多老的版本漂流在外,新的项目和老的项目开始出现依赖冲突,现场部署不下去了。询问组件的开发者哪个版本能用,也给不出一个确切的答复,只好“全部升级最新版本”。共用组件生存在调用链的最低层,全部升级涉及多少产品,开发工作量运维工作量多么的巨大。

于是一些团队不得已把这些共用组件源码拿过来,搞个目录自己管了,从此分道扬镳,再不用标准版了。两年过去,新人成为老人,铁打的公司流水的团队人员来了又走,只留下一堆代码仓库和外面好多不知道来历的二进制包。哪个项目组要是使用了这些祖传组件,开发的人都头疼。明明是一件好事,却做成了这个样子。

但是共用需求毕竟存在,每隔两年又会有一批新人雄心勃勃的开始下一个新的共用组件。于是一代代循环下去,每一代人都做不长、做不大。我们一次一次的搭建二层小楼,却建不起来高楼大厦。

这就是我为什么要写版本的故事。开发大型软件一定要解决跨时空、跨团队的信息沟通问题。“版本”是一个非常重要的信息,它标志了软件产品的型号。如果研发团队没有把版本管好,很可能导致多年之后、另一个工序产生麻烦,产生诸如:“某个二进制包找不到代码基线,所以无法修复这个缺陷”、“某个产品版本搞不清依赖关系,不好升级部署”,此类问题。这件事情是为未来打算、为他人打算,所以经常得不到重视。

技术固然重要,没有技术,产品做不出来,做出来跑的不快。但是版本管的不好麻烦也很大。就好比一家工厂,设计人员和技术工人肯定是非常重要的,但是如果不在设计图纸和零部件包装盒贴上型号标签(这个型号标签就等同于软件的版本号),以至于设计师经常找不到某个型号的图纸在哪里,生产线上出了缺陷也无法判断影响哪些批次的零件,生产过程就容易出现返工和浪费,也很难生产出复杂的产品。

版本管理对技术发展也有很大的促进作用。跟踪和记录组件版本可以帮助我们理清产品的依赖关系,比如“某个组件在哪些产品中使用,如果我们不再维护这个组件的 1.x 版本会影响哪些产品”、“某个产品从什么版本开始引入了某项技术,在哪些环境中部署过”。这些信息对技术演进有非常重要的作用。如果没有这些数据,我们就无法判断技术升级的影响范围。一处更改会造成大范围的错误,于是只能放弃升级,产品被锁死在陈旧的技术上。行业在变,产品年年不变,限制企业的技术竞争力。

这是一个系列的写作,我会结合代码管理、构建管理、集成测试、产品发布、部署这些过程,详细说明版本管理过程。一个组件、一个产品应该怎样编制版本号,把这个版本号烙印在二进制包里,在开发、测试、发布的过程中管理某个版本的状态。最后部署这个软件的时候,怎样分析依赖关系,找到合适的版本。六个月之后,当产品经理要求在某个老版本上更新一个功能的时候,应该怎样做。

posted on 2020-08-29 21:17  小陆  阅读(342)  评论(0编辑  收藏  举报