Light Merge 代码合并实践

测试交流1 333字数 1663阅读5分32秒阅读模式

前言

好几个月没发帖子了,开始了产生懒惰情绪,挺羡慕能持续输出的同学,一直保持高质量输出.其实最近这几个月,做的东西偏效能方向,提供给开发、测试、项目管理使用,大部分时间是全职开发.其中有很多需求来自开发同学,通过平台化建设提高他们的工作效率.

本文讲述了一个解决代码合并老大难的问题,如何通过 “Light Merge 自动化代码合并” 技术解决,提高代码合并质量、降低开发合并代码时间.文章源自玩技e族-https://www.playezu.com/192504.html

背景

我司是一个互联网快速发展公司,项目迭代比较快、后端服务越来越多.慢慢的开始暴露出互联网创业公司在技术上的问题了.文章源自玩技e族-https://www.playezu.com/192504.html

几大问题痛点:文章源自玩技e族-https://www.playezu.com/192504.html

1、后端服务架构不统一文章源自玩技e族-https://www.playezu.com/192504.html

2、服务环境没有严格隔离文章源自玩技e族-https://www.playezu.com/192504.html

3、代码分支混乱文章源自玩技e族-https://www.playezu.com/192504.html

4、上线后经常会丢老功能文章源自玩技e族-https://www.playezu.com/192504.html

综上所属,应该是互联网创业公司通用的技术痛点,当业务规模达到了一定量的时候,必须会进行重构系统或者有系统架构优化.文章源自玩技e族-https://www.playezu.com/192504.html

痛点

我司目前的上线流程是在测试环境测试完成,然后把多功能分支合并到 master 分支.文章源自玩技e族-https://www.playezu.com/192504.html

1、但是有可能功能分支没有拉最新的 master 分支,导致功能分支合并到 master 分支后,有些线上功能被覆盖了.文章源自玩技e族-https://www.playezu.com/192504.html

2、最终上线的也是 master 分支,QA 回归测试的时候,并不会把所有功能都回归测试,只会关注新分支的功能.

原因

1、代码管理问题,我司没有专门的代码管理人员,依托于运维管理权限而已.代码仓库、分支使用规范目前没有标准.
2、对于上线 master 代码分支,开发权限在本地操作合并代码.
3、开发人员没有好的习惯,把当前的开发分支定期拉群线上 master 分支代码.

分支合并

单分支合并

1、之前我们公司都是使用单分支合并的流程,这种分支合并是很危险的.并且开发很多是把代码拉到本地合并提交,在这个过程中很有可能导致代码老功能被冲掉.

2、开发经常是同时开发一个项目,同一个项目也是频繁有多个分支合并,这样也会出现可能导致代码老功能被冲掉.

3、每当上线的前,开发都有大量的时间合并代码分支做上线准备,还经常合并错.

3、对于测试同学,也没有时间全量回归测试以前的功能.

Light Merge 代码合并实践插图

所以单分支合并,是对人员时间、信息同步能力、责任心的多重考验.在多人写作上,这种模块已经跟不上目前的项目迭代效率.

Light Merge 分支合并

Light Merge 是在 “携程” 上已经有应用了

参考文章:https://cloud.tencent.com/developer/article/1157076, 本文的作者是 “苏玲”,在极客时间也有专门讲 git 代码管理的课程.

Light Merge 的目的

提高协同开发过程中分支合并部署效率及敏捷度,所谓敏捷度在 LightMerge 中主要体现在一下功能:

  1. 可以轻松选择需要部署分支
  2. 可以从已经部署分支中剔除不需要分支
  3. 可见已经有哪些分支部署
  4. 冲突指名分支

Light Merge 代码合并实践插图1

Light Merge 的职责范围

LightMerge 不等于自动构建、不等于自动部署、他处于这些步骤的上游,能让我们自由控制对分支的部署,能基于开发分支为粒度自由组合部署。

Light Merge 代码合并实践插图2

Light Merge 功能及特点

  1. 合并冲突自动告警
  2. 多分支自动 merge
  3. 自由选择需集成的特性分支
  4. 高效定位可集成的特性分支的最大集合
  5. 设置非常简单
  6. 支持 CI
  7. 与 Merge Request 有机结合

Light Merge 思想

Light Merge 借鉴了搭积木的思想,"随意搭配"

Light Merge 代码合并实践插图3

Light Merge 是一种 Git 分支策略.利用 Base 分支和 Feature 分支的不同组合,快速增删发布分支代码,以支持敏捷开发.

Light Merge 的实现原理很简单,首先我们把分支切到 base 分支,然后依次合并各个 feature 分支,最后将结果强推到 dest 分支.

Light Merge 使用场景

当多个项目要一起上线,并且是同一个代码仓库 A,就可以使用 Light Merge 进行代码分支合并.

Light Merge 代码合并实践插图4

项目开发

基于上述问题,我们单独立项准备开发 Light Merge 功能,涉及前端、后端

Light Merge 的前端

对于前端就两个页面,合并详情页、合并后的列表页面.

合并详情页中,需要代码项目组、代码地址、新分支、功能分支参数、基础分支等参数

新分支会先从基础分支拉一个分支,如果不存在的话就创建,如果存在的话需要先删除.

点击合并完成后,如果没有冲突,提示合并成功.如果合并失败的话,会提示冲突信息

Light Merge 代码合并实践插图5

列表中展示代码合并状态

Light Merge 代码合并实践插图6

合并完成后在 gitlab 上能看到合并状态

Light Merge 代码合并实践插图7

合并完成后在 gitlab 上能看到 commit 信息

Light Merge 代码合并实践插图8

合并失败后,展示冲突内容

Light Merge 代码合并实践插图9

我司是使用企业微信沟通,在项目组中创建 webhook 通知,合并信息会发到群中.

Light Merge 代码合并实践插图10

Light Merge 的后端

后端整体的代码是基于 python flask 框架提供 API 服务,其中使用 “gitlab” 库操作 git,安装方式 “pip install gitlab==1.0.2”.

python 操作 gitlab 需要使用 “private_token”,在 gitlab 中 setting 中可以参考对应的 “private_token”

如下代码,初始化 gitlab

class GitLabInFo():
def __init__(self):
self.gl = gitlab.Gitlab(gitlab_host, private_token=gitlab_access_token)
logger.info("登录gitlab...")

如下是 “核心” 代码片段,这块有个重要的是,如果有没有关闭的 mr,不能提交新的 mr,所以需要先关闭.

Light Merge 代码合并实践插图11

合并分支,先创建 mr,再合并.

Light Merge 代码合并实践插图12

合并分支有失败的情况,需要捕获异常,获取冲突信息.

Light Merge 代码合并实践插图13

如果一个分支合并失败,本次 Light Merge 任务结束.

Light Merge 代码合并实践插图14

结语

Light Merge 代码合并,已经在公司推广使用了 3 个月了.现在开发已经很少手动进行代码合并分支了,极大了提高开发效率、减少合并代码上的失误.软件测试招聘

 
    • rhyme
      rhyme 9

      羡慕 “大部分时间是全职开发 ” 扩展一下,做一个 CodeReview 服务,合并代码 +Code Review文章概念略多,想确认下,Light Merge 是不是相当于:

      1、从 master 拉出一个新分支
      2、选择一堆开发完待测试的 feature 分支,逐个 git merge 到这个新分支
      3、全部成功则可以基于这个分支进行测试,有冲突则提示信息,让开发改为手动 merge

      这三个点?

      实际实践中,有个疑问点,修改 bug 是在 feature 分支上修,还是直接基于合并后的新分支修?是否会遇到某个功能,在单独 feature 分支独立没问题,但 merge 后的新分支有问题的情况?1、上述三点是对的
      2、bug 是在 feature 分支上修复,然后再 Light Merge
      3、merge 后的新分支有问题的情况,目前没有这种情况,除非代码没有合并上大佬,小白 求源码。

    匿名

    发表评论

    匿名网友
    确定

    拖动滑块以完成验证