DEVOPS持续交付体系下传统应用程序版本控制?

传统应用程序版本发布,主要依靠人工拉取历次版本进行手工比对,单次投产版本数量较多时,此方式耗时且极易出现因比对失误造成版本错乱现象,整体效率低下、效果不尽人意。DEVOPS交付体系下,对此类现象有针对性规避手段、改进机制嘛

1回答

顾黄亮顾黄亮  技术总监 , 苏宁消费金融有限公司
wwu赞同了此回答
其实人工拉取版本耗费时间并不多,也不会出什么问题,中间的问题出在,同一个版本的被多个开发团队进行不同需求的开发。笔者所在的团队也因为实际情况,采取这种开发方式。比如开发负责人拉取一个20220117的分支,然后A团队基于这个分支进行需求1、2、3的开发,B团队基于这个分支进...显示全部

其实人工拉取版本耗费时间并不多,也不会出什么问题,中间的问题出在,同一个版本的被多个开发团队进行不同需求的开发。
笔者所在的团队也因为实际情况,采取这种开发方式。比如开发负责人拉取一个20220117的分支,然后A团队基于这个分支进行需求1、2、3的开发,B团队基于这个分支进行需求4、5、6的开发,那肯定会出现问题的。
应该这样,对分支进行科学管理,采用行业比较规范的方式,如下。
master主干:线上的版本:主干的代码不做开发,目的是保留现在线上的版本,如果现在线上的代码出现任何的BUG或紧急添加新功能,就从master拉下来一个分支master_alter,master_alter分支的代码修改或添加后,然后测试打包发布,发布后把这个分支master_alter合并到master;删除master_alter分支,这时master任然是线上的版本;
release分支:预发布的版本、正在测试的版本:新需求已经开发完成,9.30号上线,这段的时间就是测试和修改BUG,我们给这个分支起名字叫release_930,等release_930版本的代码发布上线后,把release分支合并到master主干上,把release分支删除;
dev分支:正在开发的版本:假如公司出了两个新的需求,要给现在的商城项目添加一个新的功能叫购物车,然后我的这个分支叫dev_spc,日常的开发工作就一直在这个dev_spc这个分支上面;还要给商城加上店铺功能,然后我旁边哥们的分支就叫dev_shops,旁边这哥们他日常的开发工作就一直在这个dev_shops这个分支上面;开发完成后从dev分支合并到release分支,发布后再合并到master主干;master主干的代码不做开发用,保留现在线上的版本代码;

除此之外,笔者还是重点提一下代码合并。
每次上线之前,必须要对代码进行合并,举个例子,如果有abc三个版本,主干是A,由于实际情况比较复杂,基本上不可能由工具进行合并,合并由技术经理负责,有c合并到b,再由b合并到a,然后将a合并到A,因此需要由技术经理进行合并编排,认为规定合并逻辑和顺序,然后由工具进行合并。
代码合并采取人工加工具的方式最为稳妥。

收起
 2022-01-17

问题状态

  • 发布时间:2022-01-14
  • 关注会员:2 人
  • 问题浏览:712
  • 最近回答:2022-01-17