热修复开发流程

创建热修复版本

由SM在【分支管理】的“迭代版本”模块,点击新建热修复版本,创建新的热修复版本。热修复版本号为四位版本号,前三位继承自所选的日常迭代版本,第四位则是固定为序号,系统自动根据对应日常迭代版本从1开始生成。

热修复版本新建后,SM需要点击版本记录行的开始迭代按钮,让热修复版本进入开发中状态,如果当前是日常版本的第一个热修复版本,此时系统会拉取所选日常迭代版本对应的tag,在当前产品所有git项目仓库下初始化生成R2分支,如果不是日常版本的第一个热修复版本,则拉取上一个热修复版本的tag初始化R2分支。

新建特性

热修复版本的特性在新增热修复版本时会自动创建,此时仅需点击特性的编辑按钮,补充完整特性信息即可。热修复特性不支持手工新建,故热修复版本仅允许存在一个特性。

  • “特性名称”与“分支名称”均默认生成,可修改。
  • “关联需求/缺陷”支持选择与手工录入两种模式,通过“产品管理”模块对产品设置需求源类型完成。
  • “关联项目”则选择当前特性要调整代码的相关仓库,保存后已选择的仓库不能取消选择,只能追加选择仓库。

补充完整特性信息后,由SM或开发人员点击特性记录行的“开始开发”按钮,特性进入“开发中”状态,此时系统自动拉取R2代码去gitlab中创建对应BG特性分支。

特性提测

特性进入开发中状态后,开发人员在本地进行编码,编码完成后,将本地代码push到远端特性分支,点击特性分支记录行的提测按钮完成特性提测,此时系统会发送企业微信提测通知给特性测试人员。可通过“批量分配测试人员”对特性设置测试人员,未设置则发送给产品团队下的所有测试人员。

热修复接测

测试人员收到开发人员提测通知后,可点击特性记录行的特性合R2按钮,进行特性代码合并操作。

代码合并成功后,点击构建R2按钮进行热修复测试构建。

进入热修复测试构建界面,按照步骤依次选择sql文件、需构建的仓库,点击构建则会自动触发测试构建,构建实时日志可直接点击“构建管理”模块查看;也可通过点击特性记录行的查看日志按钮,在查看日志界面中通过点击“构建详情”自动跳转到构建管理模块查看。构建时所有选择的仓库均构建结束后,会发送企业微信通知给对应开发和测试人员。

构建的具体步骤依赖于对应仓库的流水线模板步骤,通常会包含如clone->sonar->doker_build->deploy这些步骤,各项目团队可根据自身情况定义流水线步骤(目前未开放可视化定义界面,需要找云擎团队协助自定义)。

热修复测试发现BUG

热修复测试构建成功后,测试人员可以开始对特性进行测试了,测试过程中发现的BUG,开发人员可以随时进行修复,修复后可随时提测。

热修复测试通过

当热修复特性所有功能测试完成,相关BUG修复且已验证通过,则可点击特性列表的热修复通过按钮,将特性、版本置为“热修复通过”状态,此时gitlab中对应的特性分支将置为受保护状态,开发无法再次提交代码到此特性分支。此时只要热修复版本未发布,还可以通过取消热修复通过操作,对特性进行BUG修复处理。

复制热修复特性到日常迭代版本

热修复发布不会将代码合并到master分支,需要在版本发布前,将热修复特性手工复制到当前正在开发中、或尚未进入开发的日常迭代版本中,通过日常迭代版本的发布一起合并到master。

版本发布

热修复测试通过,在确认相关配置、版本sql均无误后,可点击版本列表的发布按钮,对版本进行发布,发布后版本无法撤回。发布操作将对R2分支打tag。

results matching ""

    No results matching ""