【DevOps研发管理方案】三:代码管理
使用Git/SVN等开源版本控制系统进行代码托管。
目录
一、代码托管
使用Git/SVN等开源版本控制系统进行代码托管。
二、Git FLow 工作流程
推荐使用Git Flow的模式进行代码分支管理。在使用Git Flow工作流程管理代码时,必须按照以下步骤执行。
说明:
- 由开发管理员负责在统一代码仓库里创建空白的仓库,并clone到本地,初始化仓库,并push到远端。
- 在统一代码仓库上设置保护分支,把master、develop分支保护起来,只有开发管理员可push。
- 功能开发者clone代码到本地,然后初始化仓库。
- 然后再开始新建功能分支,进行开发工作。
- 新功能开发全部完成或部分完成后,功能开发者把最新代码push到远端同样的新功能分支里,并在统一代码仓库发起Merge request给开发管理员。
- 开发管理员review代码,选择合并代码到develop分支,并可选择删除已经合并的新功能分支。
- 当开发管理员处理完合并请求后,功能开发者切换到develop分支,直接删除自己的本地分支及远程分支,不要点击完成(Finish Feature),此时开发者pull远端develop分支最新代码即可,可忽视本地的push提醒。
- release、hotfix分支和feature分支操作类似。
- 不可点击完成新功能、完成发布版本、完成修复补丁,因为这样会导致自动合并代码到master或develop分支。
Git Flow 工作流程
三、 分支管理
1. 基本要求
【强制】每一次commit必须有注释,注释内容遵循注释规范。
【建议】任务拆分时,建议合理控制任务粒度,一个新功能任务可一人独立完成,即一个feature新功能分支一人独立完成。
【建议】一次commit只做一件事情,便于后期版本回滚。
【强制】正确为每个项目设置Git提交用到的user.name和user.email信息,以公司邮箱为准,不可随意设置以影响无法正确识别。
【强制】每一个项目根目录下都必须提供readme.md文件,用来说明当前项目的主要功能。
2. 版本号
【强制】版本号(tag)命名规则:主版本号.次版本号.修订号,如2.1.13。
- 主版本号:当API兼容性变化时,主版本号需要递增;
- 次版本号:当增加功能,但不影响兼容性,次版本号需要递增;
- 修订号:当修复bug但不影响兼容性,修订号需要递增;
【强制】版本号仅标记于master分支,用于标识某个可发布/回滚的版本代码。
【强制】对master标记tag意味着该tag能发布到生产环境。
【强制】对master分支代码的每一次更新(合并)必须标记版本号。
【强制】仅管理员对master进行合并和标记版本号。
3. 角色划分与权限
用户有四种角色划分:
- 功能开发者:模块中功能的开发人员,拥有浏览、push非主分支、提交Merge request的权限;
- 开发管理员:由项目模块开发的小组长(team leader)担当,拥有管理git项目、合并分支和代码的权限,可以进行代码审查;
- 发布管理员:由生产环境发布团队指定人员担当,拥有建立和管理Git项目、合并分支和代码、给master打tag版本号等权限;
- 测试管理员:由测试团队指定人员担当。
【强制】用户有五种角色权限:Guest、Reporter、Developer、Maintainer、Owner
- Guest:可以创建issue、发表评论,不能读写版本库;
- Reporter:可以克隆代码,不能提交,【测试管理员】赋予该权限;
- Developer:可以克隆代码、开发、提交、push,【功能开发者】赋予该权限;
- Maintainer:可以创建项目、添加tag、保护分支、添加项目成员、编辑项目,【开发管理员】、【发布管理员】赋予该权限;
- Owner:可以设置项目访问权限 - Visibility Level、删除项目、迁移项目、管理组成员。
注:开发管理员和发布管理员角色相同,但操作的项目范围不同。发布管理员可操作当前项目组下的所有项目。
组和项目有三种访问权限:Private、Internal、Public
- Private:只有组成员才能看到
- Internal:只要登录的用户就能看到
- Public:所有人都能看到
4. 分支说明
每个Git项目固定含有master、develop、feature、release、hotfix分支类型。主分支master和develop是保护分支,只能进行合并请求,均不可直接提交代码。
功能需求或常规Bug修复,从develop拉取feature分支;线上紧急问题修复,从master拉取hotfix分支。
名称 | master | release | develop | feature | hotfix |
说明 | 线上稳定版本 | 待发布分支 | 当前正在开发的分支 | 功能分支,每个功能需分别建立自己的子分支 | 紧急修复分支 |
命名规范 | master | release-xxx | develop | feature-功能名-版本号 | hotfix-功能名-版本号 |
分支命名 | master | release-v1.0.0 | develop | feature-login-v1.0.0 | hotfix-fixorderdetail-v1.0.1 |
pom文件版本定义 | xxx-1.0.0-RELEASE | xxx-1.0.0-RELEASE | xxx-1.0.*-SNAPSHOT | xxx-1.0.*-SNAPSHOT | xxx-1.0.0-RELEASE |
合并目标 | - | master/develop | master | develop | master/develop |
合并操作 | - | merge request | merge request | merge request | merge request |
创建人 | 发布管理员 | 发布管理员 | 开发管理员 | 开发者 | 开发者 |
生命周期 | 全过程 | 版本发布后 | 全过程 | 功能开发完成后 | 紧急修复bug并验证后 |
生产环境分支。
- 操作权限:仅管理员。
- 合并说明:-
- 推送说明:-
主开发分支,此分支包含:正在测试、等待测试的代码,属于不稳定代码分支。
- 操作权限:仅管理员。
- 合并说明:-
- 推送说明:-
新功能开发分支。
- 操作权限:仅允许对应开发人员操作。
- 创建说明:创建自develop。
- 合并说明:合并到develop:新功能开发完成,等待测试。
预发布分支。
- 操作权限:仅允许对应开发人员操作。
- 创建说明:创建自develop。
- 合并说明:
- 合并到develop:预发布环境测试通过,修复代码回归。
- 合并到master:预发布环境测试通过,发布。
生产环境问题修复分支。
- 操作权限:仅允许对应开发人员。
- 创建说明:创建自master。
- 合并说明:
- 合并到develop:问题修复完成并测试通过,修复代码回归。
- 合并到master:问题修复完成并测试通过,发布。
5. 分支创建规则
👉 新需求加入
如有一个订单管理的新需求需要开发,首先要创建一个 feature-[新功能] 分支,步骤如下:
- 基于 develop 创建新的本地分支 feature-[新功能]。
- 本地开发、测试。
- 需求在 feature-[新功能] 分支开发完毕,准备提测时,要先发送代码合并请求,经开发管理人员代码审核通过后,将代码合并到 develop 分支,等待测试人员测试,并删除该远程分支。
- 测试人员在 develop测试,不通过则回到第1步;测试通过后,研发人员再将代码发布到 release 供测试人员测试。
- 测试人员在 release 测试,不通过则回到第1步;测试通过后,研发人员再将代码发布到 master 和 develop 分支。
- 最后,待本次迭代内的所有特性均完成了测试,那么在 master 上打TAG标记版本号,准备发布新版本。
👉 普通迭代
若有一个订单管理的迭代需求,如果开发工时<1d,直接在 develop 开发,如果开发工时>1d,那就需要创建分支,在分支上开发。开发后的提测上线流程与新需求加入的流程一致。
👉 修复测试环境 Bug
在develop测试出现了Bug,需要新建分支进行修复。修复后的提测上线流程与新需求加入的流程一致。
👉 修复预上线环境 Bug
在 release 测试出现了Bug,则直接由开发者在release分支修复并提交。当测试完成之后,合并 release 分支到 master 和 develop 分支,此时 master 为最新代码,用于上线发布。
👉 紧急修复正式环境 Bug
上线运行一段时候后出现了严重Bug,需要紧急修复的,步骤如下:
- 基于线上版本的TAG创建新的分支hotfix-[BUG]。
- 本地开发、测试。
- 修复完毕,推到远程分支。
- 将该远程分支发布到测试环境。
- 测试不通过,则回到第2步;测试通过,则将 hotfix-[BUG] 代码合并到master 和develop 分支,同时删掉 hotfix-[BUG] 分支,打TAG,准备发布补丁版本。
6. 分支回收规则
- master分支:长期存在。
- develop分支:产生于master分支,并长期存在。
- feature分支合: 合并回develop分支,经测试通过后,删除feature分支,或者feature分支与前期需求不符,直接舍弃。
- release分支:在release分支上进行充分测试,并修复Bug,合并回develop分支和master分支后,然后删除release分支。
- hotfix分支: 紧急Bug修复完成后,合并回maste分支,测试验证通过,再合并到develop分支,然后删除hotfix分支。
更多推荐
所有评论(0)