代码版本及发布管理


1. Git Flow流程

image.png

1.1 Git Flow中的分支

Git Flow模型中定义了主分支和辅助分支两类分支。其中主分支用于组织与软件开发、部署相关的活动;辅助分支组织为了解决特定的问题而进行的各种开发活动。分支的名字是一种共识,更重要的是它承担的责任。

1.2 主分支

主分支是所有开发活动的核心分支。所有的开发活动产生的输出物都会反映到主分支的代码中。主分支分为master分支和development分支。

1.2.1 master分支

master分支上存放的应该是随时可供在生产环境中部署的代码,它承担的责任就是:仅在发布新的可供部署的代码时才更新到master分支上的代码。当开发活动告一段落,产生了一份新的可供部署的代码时,master分支上的代码会被更新。同时,每一次更新,最好添加对应的版本号标签(TAG)。

示例:

测试完成后,由测试主管把release代码合并至master并打好Tag标签,运维人员根据安排进行发布,同时release分支也需要合并到develop上

 

1.2.2 develop分支

develop分支是保存当前最新开发成果的分支,它承担的责任就是功能开发完毕等待最后QA的验收,通常这个分支上的代码也是可进行每日夜间发布的代码。当代码已经足够稳定时,就可以将所有的开发成果合并回master分支了。

示例:

在进行版本迭代开发的时候,开发人员从develop上建立feature分支,并把feature分支拉取到本地,开始进行功能开发,每天功能开发完成后,由技术leader审核通过,并合并到develop分支上,再开始一个新功能的开发。

问题:

1. Gitlab支持代码 Review,只有通过审批的代码才能merge到分支上,但这会带来效率上的问题。通常是开发者的feature分支开发、自测验收通过后,merge到测试环境的develop分支

2. QA提bug issue,开发者从develop切分支修正再次合并、部署、验收。

1.3辅助分支

辅助分支是用于组织解决特定问题的各种软件开发活动的分支,它的生存周期伴随着它的功能完成而消失。辅助分支包括:

· 用于并行开发新功能时所使用的feature分支;

· 用于辅助版本发布的release分支;

· 用于修正生产代码中的缺陷的hotfix分支。

当这些分支完成它的使命之后在merge到主分支之后,也将被删除。

Git Flow开发模型从源代码管理角度对通常意义上的软件开发活动进行了约束,让小组各个成员之间的开发相互隔离,能够有效避免处于开发状态中的代码相互影响而导致的效率低下和混乱,各自开发团队根据自己的特点和节奏自行剪裁或扩展。

 示例:

线上出现BUG需要紧急修复的时候,开发人员从master上建立hotfix分支,建立 hotfix环境,直接进行测试与代码合并,当测试通过后合成到master上发布,然后把hotfix分支合并到develop上,再安全的删除hotfix分支

 

2. 产品部署流程

2.1  自动同步

在开发及测试环境,通过脚本自动同步到相应环境。

2.2  自动发布

在生产环境,在发布服务器上提交发布申请,通过后自动发布至对应的目标机群。

2.3  部署工具walle简介

walle部署在一台宿主机提供一个web UI,方便用户自主更新代码部署到目标机群。Walle是一个跑在LNMP(LAMP)上的PHP服务,宿主机与目标机群建立信任,通过操作bash命令来实现代码同步、自定义高级任务。

image.png

2.4 申请及部署图示

image.png

2.5 部署流程

部署是在一台宿主机拉取代码,做编译、配置后,向目标机群分发,执行相关目标机群任务。部署流程拆分为以下6个环节,其中1-5为在宿主机进行,6在目标机群执行。

1. 权限、目录检查,开辟一个上线的独立空间以并行发布,防止同时部署出现代码污染

2. pre-deploy任务,代码检出前的一些操作任务,如环境检查

3. 代码从git/svn版本库中检出

4. post-deploy任务,代码检出之后操作任务,如java的mvn编译,php的composer插件安装

5. 保留在独立空间的代码均会被同步至目标机群的一个版本库中

6. 全量更新:当所有机器都分发完毕,开始做pre-release任务(java暂停服务)、切换版本软链、post-release任务( java启动服务)

 

3. 代码审查

3.1分配角色成员

Git 中的五种角色:

Guest:访客,没有什么权限;

Reporter:可以使用 git@172.18.2.121:test_group_001/top_proj_002.git 拉代码,但是不能push 到仓库的默认分支;

Developer:项目的开发人员,能够推送和删除没有保护的分支,刚创建的分支 默认 都是没有保护的

Master:项目管理人员,可以对没有保护和有保护的所有分支进行操作,几乎拥有所有权限;

Owner:系统管理员,拥有所有权限;

 

3.2 锁定受保护的分支:

Git不熟悉的时候,时常苦恼于各个分支不受约束,任何开发人员都可以向任何分支直接推送任何提交,各种未经审查的代码、花样百出的 Bug 就这样流窜在预发布分支上。

其实我们可以通Gitlab的受保护分支(Protected Branches)解决该问题,该功能可用于:

· 阻止 Master 角色以外的开发人员 直接向此类分支推送代码,保持稳定分支的安全性;

· 在向受保护分支合并代码前,强制进行代码审查

一般来说,需要锁定我们的受保护分支——主分支 master 和预发布分支 release-*,以阻止开发者直接向这两类分支中推送代码:

3.3 发起合并请求

对于开发人员而言:

· From 是你的特性分支 feature-*

· To 只可能是预发布分支 release-*

· Title  Description 要填写恰当的分支描述;

· Assign to 是该项目的 Master。

3.4  审查合并请求:

Master 收到合并请求后,进行代码审查。逐一查看 Commits 一栏提交的内容即可,对于需要改进的代码,可以直接在该行添加注释,非常方便。

3.5 处理合并的请求

可以有如下几种处理方式

关闭

对于完全不合格的垃圾代码、或者废弃的特性分支的合并请求,Master 点击右上角的 Close 按钮即可。合并请求将被关闭,相当于扔进回收站。

改进

 对于分支内需改进的代码,Developer 直接修正并推送即可,合并请求将会自动包含最新的推送提交。

接受

Master 审查无误后,可以接受该次合并请求。点击 Accept Merge Request 按钮 将自动合并分支,勾选 Remove source-branch 控件,将同时删除该特性分支

4. 项目知识管理wiki)

当代码仓库比较少的时候,使用集中式的wiki,保存所有项目的api文档、设计文档、部署文档是可行的,但是当项目大的时候,代码仓库会越来越多,建议使用gitlab自带的wiki存放相关的api文档和设计、部署文档,界面友好,支持markdown风格,可以项目代码关联。或者使用其它wiki

image.png

作者头像
南宫俊逸创始人

君子好学,自强不息~

上一篇:Linux下防御DDOS攻击的操作梳理 (网摘)
下一篇:数易DJ舞曲音乐管理系统(免费版)

发表评论