代码分支和版本管理规范说明

说明:以下是前期公司内部试行的简单的代码分支版本流程管理规范,规范其实和运维有很大的关联,随着管理方式和流程的完善,代码版本管理流程也是会改变的。仅供参考!!!

分支说明

  • dev-xxx 为开发分支,xxx表示版本,建议使用上线年月日时间串,比如dev-20180612 或 为需求功能点名称,比如dev-xx需求
  • test 为测试分支 (如果存在多版本同时测试,可能存在 test-xxx 分支,意思是多个测试环境,有做压测或者是功能测试的)
  • master 主分支为 uat 回归测试分支(预生产/准生产分支)。(此分支会做分支保护,不允许直接 push 和 只有主程序员可以 merge )
  • prod 为生产发布分支
  • prod-xxx 为生产上线后备份tag

分支版本流程管理

代码分支和版本管理规范说明

图解

  • (1)在主工程仓库,基于 prod 分支创建新开发分支 dev-xxx
  • (2)开发人员 fork 主仓库到自己名下,(如果原来已经 fork 过,可以通过更新的方式更新获取到最新的masterdev-xxx代码),切换到分支 dev-xxx 进行开发;
  • (3)平时开发正常提交到自己的 fork 仓库,适当时机 PR merge 到 远程项目主仓库对应的 dev-xxx 分支;
  • (4) 如果要提测了,将 dev-xxx 分支代码合并提交到 test 分支;(建议是 fork 仓库的分支 dev-xxx 提交到了远程主仓库的 dev-xxx 分支,再用主仓库的远程dev-xxx分支合并到test 分支)
  • (5)QA 测试过程提 bug,开发人员改 bug 的话,就是重复(3)(4)步骤;
  • (6)QA 验证 test 分支代码通过后,就将 test 分支 PR 合并到 master分支,进行回归测试;
  • (7)如果 uat 测试有 bug,重复(3)(4)(6)步骤;如果 uat 测试失败,运维要回滚 uat 环境和生产一致。
  • (8)uat 测试通过,产品验收通过,则将代码覆盖更新到 prod 分支,进行上线安排,上线出问题还是要有紧急回滚机制。
  • (9)上线验收成功后,给生产 prod 分支版本打标签,如 prod-xxxx(xxx 为上线日期)

(一个完整流程到此结束)

情景举例说明

迭代新版本

当有新需求开发时,一般是经过需求评审后,定下的冲刺迭代版本,评估了开发周期,确认了上线时间。

  • 如果有多个需求(迭代)并行开发,上线时间不一样,那就是不同版本,这时候,需要基于 prod-xxxx 创建一个分支出来,比如取名为 dev-xxxx,然后基于此分支开发同版本的需求上线,要提交 Jenkins 构建的话就 merge 到对应的测试分支。
  • 如果新需求都是同一个版本,步骤同上,只是一个 dev 分支
  • 以上的新需求分支开发完成后,提测的话就 PRtest 分支,QA 完成功能测试没问题后,将 test 分支 merge 到 master 分支进行回归测试。

生产上有 bug,需紧急修复上线

  • 基于 prod-xxx 创建分支修改 bug,分支名称为bug-prod-xxx,改完自验没问题需要提交测试的时候,merge 到相应测试分支(如test),Jenkins 构建后验证通过,上线生产。上线完成后,别忘记了备份新生产分支prod-xxxx。然后其他正常使用的分支,需要拉取最新生产分支代码prod-xxxx,保证拥有最新的生产分支代码,避免 bug 又上线了(这个过程在以上把 master 定为准生产分支时规避掉了)。

故事举例:

(一)冲突的新需求情景:

2018-06-09 CRM 前端上线了,上线后开发人员备份了生产分支代码为 prod-20180609,第二天,前端开发人员紧接着开发新需求,并且新需求有两个版本,版本一 是在下周上线;版本二 是在月底上上线。版本一和版本二是不同的开发人员,启动开发时间是一样的。这时候,开发人员应该基于 master 分支创建出两个分支,假设为 dev-20180618-需求1dev-20180625-需求2,然后他们都是各自在各自分支里边开发,相互不影响。

  • 提交测试前的任何分支,都要拉取一下主分支master,合并最新生产代码(因为可能会有遗漏,有人改过没更新同步你们的分支),然后再 PRtest 分支测试。

(二)线上 BUG 情景:

问题来了:上线后第三天,线上用户反馈了 bug,需要紧急修复。

做法:基于远程仓库主分支的版本标签 prod-20180609 创建新分支bug-prod-xxx,在此新分支修改 bug,自测没问题后 PR 到主仓库 test(如果该分支已经被新需求占用,可以创建新分支test-bug,Jenkins 构建选对就好),jenkins构建后 QA 测试,没问题后,将 test 分支 mergemaster 分支,没问题后再覆盖更新到 prod上线,上线完成后,备份新生产分支,打标签prod-xxxx

(三)公共代码(非需求代码变动)情景:

修改公共代码的同学,需要自己创建一个专门用来改公共代码的分支出来。公共代码或者是公共类库和基础服务等代码改动了,也要和业务代码一样,提测走完测试流程。

以上是 代码分支和版本管理规范说明 的全部内容, 来源链接: utcz.com/p/232855.html

回到顶部