一、背景:

大多数公司为了可以快速迭代,一般只有两个环境,一个是测试环境,另外一个是线上环境。这个时候问题就来了,如果线上出现bug要如何修复才不会影响当前版本测试。如果多个版本同时迭代开发,如何才能保证测试上线互不影响呢?

童鞋们可以先想想,后面会针对上述场景,进行详细的说明。

二、当前状况

2.1 当前环境

当前有两个环境:测试环境、生产环境。

两个环境都是采用k8s集群搭建而成

2.2 git分支

  • master:生产环境对应分支代码、分支会永久存在。

  • dev:开发环境对应分支代码、分支会永久存在。

2.3 问题场景

2.3.1 版本无法区分问题

不管当前有多少个版本的开发,都会统一在dev分支中开发,dev分支合并到master的条件是:dev最后一个版本测试完毕之后。基于当前这种流程,没办法将其它小版本单独发布到线上。

2.3.2 bug修复问题

因为当前只有两个环境,所以每当线上出现bug的时候,都是以master分支作为源头,创建一个bug分支,开发人员将bug分支修改完毕之后,就以当前的bug分支作为构建镜像的代码源,用来启动容器,这样势必会导致原本的dev分支的容器被覆盖,导致dev中的版本测试受到影响。

2.3.3 分支命名不规范

没有一个明确的分支命名规范,gitlab中出现各种各样的分支,没办法通过分支名字推测出分支的作用,有些分支都发布上线了,还是没有删除。

三、Git flow工作流程

在开始解决上述问题之前,我们先来了解一下Git flow工作流程,如下图所示:

图片

官方博客:https://nvie.com/posts/a-successful-git-branching-model/

官方给出的发布流程中有五个分支,其中除了develop和master两个分支是永久性存在的,其它的分支都是临时存在的,发布上线或者修复bug之后,都会删除。

3.1 分支介绍

  • feature branches:版本开发分支

  • develop:测试分支

  • release branches:预发布分支

  • hotfixes:bug修复分支

  • master:线上分支

3.2 具体流程

每一个版本的需求就是一个feature branches分支,当版本需求开发完毕之后,需要合并到develop中,提供给测试人员测试。当feature branches分支对应的版本测试完毕之后,将develop分支发布到release branches分支中,等待发布上线。发布完毕之后删除对应功能的feature branches分支。

release branches核实无误,将代码合并到master分支中,并打上对应的tag,最后将tag发布到线上。master线上发布完毕之后,删除对应的release branches分支。

线上如果出现bug,以master为源头创建一个hotfixes分支,修复完毕之后再合并到master和develop分支中。hotfixes分支合并完毕之后,也需要即可删除分支。

四、版本发布流程

正如齐白石老先生说的:“学我者生,像我者死”一样,Git flow分支模型确实非常优秀,可以解决很多问题,但是我们需要跟我们的实际项目进行适配。就比如我们master环境没有版本的概念,因为我们从始至终就只有一个线上环境,不像jdk一样,会同时维护多个版本的线上迭代。所以我们需要对这个Git flow分支模型进行改造。

4.1 改造点

4.1.1 feature branches合并release

feature branches分支对应功能测试完毕之后,直接将feature branches代码发布成release branches分支,不再通过原本的develop分支。这样的好处是可以有效的防止develop分支包含多个feature branches的功能,难以提取对应版本发布到release branches分支中。

4.1.2 master非tag发布

master直接用当前分支代码作为镜像代码源,因为线上只有当前最新版本,不需要划分多版本代码。但是每次发布时候都需要打tag,用于记录发布版本对应的说明,后期好回溯。

4.1.3 release branches分支

release branches代码永久性保留,release branches对应预发布环境。

4.1.4 部署bug分支环境

线上出现bug,为了不污染release环境,我们需要部署专门用来测试bug的环境。bug测试完毕之后才能合并到release环境中,等待版本上线。

4.2 环境

  1. 测试环境

  2. 线上环境

  3. release环境

  4. bug环境

bug环境对应镜像服务分支默认为release分支代码,如果出现bug,需要将涉及到的服务切换到bug分支。测试通过之后,将代码合并到release分支,并将镜像服务分支切回release,最后删除对应bug分支。

4.3 分支

  • feature branches:版本开发分支

  • dev:测试分支(永久分支,对应测试环境)

  • release branches:预发布分支(永久分支,对应预发布环境)

  • hotfixes:bug修复分支

  • master:线上分支(永久分支,对应线上环境)

4.4 分支命名规范

  • 版本开发分支命名规范:feature_产品版本号-需求说明

  • bug分支命名规范:hotfixes_负责人_bug说明

  • release branches(release_master):名称固定

  • dev:名称固定

  • master:名称固定

4.5 正常发布流程

  1. 根据产品需求,以master为源代码创建feature branches,命名规范为:feature_产品版本号-需求说明。

  2. feature branches开发自测完毕之后,合并到dev分支等待测试人员测试。

  3. 测试人员测试通过之后,通知分支开发负责人将需求发布到预发布环境。

  4. 开发人员将feature branches代码合并到release branches中,等待发布上线。

  5. 得到允许发布到线上的命令之后,将release branches代码合并到master分支,并打上tag记录。

  6. 将上线版本对应的feature branches删除。

4.6 bug修复流程

  1. 出现bug之后,以release branches为源码创建hotfixes分支,命名规范为hotfixes_负责人_bug说明。

  2. hotfixes分支开发自测通过之后,修改bug环境对应服务的分支指向,启动完毕之后通知测试人员开始测试。

  3. 测试人员测试通过之后,通过对应开发人员。

  4. 开发人员收到通知后,就可以将hotfixes分支代码合并到release branches和erp-dev分支中,并修改回bug环境对应服务的分支配置(默认为release分支)。

  5. release分支功能发布线上之后(bug修复的代码包含在里面),将对应的bug分支删除。

4.7 版本发布流程图

图片

五、demo流程演示

5.1 正常发布流程

以master分支为源头创建如下分支: 图片

现要求:

feature_v1_test1:开发时间为5天,从2021-04-06开始开发 预计发布日期2021-04-10
feature_v1_test2:开发时间为2天,从2021-04-06开始开发,预计发布日期2021-04-08
feature_v1_test3:开发时间为1天,从2021-04-06开始,预计发布日期2021-04-06

开始开发feature_v1_test1、feature_v1_test2、feature_v1_test3版本代码。 图片

开发完毕后,合并到dev中,等待测试人员测试。 图片图片

测试人员在dev环境中,将feature_v1_test3版本功能测试完毕后,开发人员将feature_v1_test3分支合并发布到release分支。

图片

release分支最后检测发现有bug,在release分支进行bug修复,修复完毕后合并到dev中 图片图片图片

release分支最后验收完毕,将release分支合并发布到master上线。 图片

发布master成功之后,将feature_v1_test3分支删除(本地和线上)。 图片

5.2 bug修复流程

以当前release分支为源头,创建一个hotfixes_linzhiqiang_login分支,用于修复线上bug。 图片

bug修复完毕之后,以hotfixes_linzhiqiang_login分支作为测试环境对应服务分支,测试通过之后,将hotfixes_linzhiqiang_login合并到release分支中,等待发布上线。

图片

release预发布测试bug是否正确被修复,测试通过则将release分支发布到master分支上线。

发布成功之后,则将bug分支删除,一般情况下,bug分支不需要发布到远程仓库中。

图片

5.3 注意事项

master每次发布都需要打个tag,对本次版本进行说明解释。

对应版本发布到线上之后,需要删除对应的feature branches分支代码。

六、总结

上面讲述了如何利用Git flow适配我们自己项目发布流程。但是当前版本发布流程还是会存在某些特殊问题。

6.1 feature branches当天多版本上线问题

如果feature branches分支中有两个版本需要当天发布,一个是中午,一个是下午,因为目前我们release分支只有一个分支,所以没办法兼容这种情况,遇到需要特殊处理。

6.2 bug时效高于release分支

如果release分支预计是当天晚上发布,但是当天早上有一个紧急的bug需要立即修复。这个时候就不能以release分支作为源头拉取bug分支了,必须以master为源头拉取分支。修复之后合并到master和release分支中。

6.3 feature branches合并到release分支冲突

因为我们是从feature branches直接合并到release分支的,过程中跳过dev分支,如果修改同一个文件,会大大增加冲突概率。

虽然特殊问题需要特殊处理,但是这种情况发生概率极低,就算发生了也有解决方案。所以总体来说当前的发布流程可以满足大多数情况。

-----------------------

公众号:林老师带你学编程

网站:www.wolzq.com

代码无非增删改查,关注老师给你Coding

图片

林老师带你学编程http://www.wolzq.com 

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐