团队代码协作规范 及 产品发布流程 v2

基于Gitflow 工作流 + 测试/预演/生产 环境 产品发布上线流程

团队代码协作规范 及 产品上线发布流程

团队代码协作规范 - 基于git flow工作流

git-flow

分支解释:

  • master :不允许开发者对代码进行修改和提交。该分支上的代码随时可以部署到生产环境
  • develop:是开发过程中代码中心分支。不允许开发者直接进行修改和提交(只允许MR(PR),以下MR 均指 Merge Request)
  • Release:临时分支:上线的准备工作和预演环境的bug。绝不能包含需求变更或功能变更等重大修正。这一阶段的提交数应该限制到最低
  • Hotfix:临时分支,修复紧急bug的分支;紧急bug定义:无法等到下个版本的bug
  • Feature:开发分支,已完成的feature 需要在适当时间删除;需要其他开发者对对此次MR进行code review,在通过审核后Accept Merge Request 发布到dev

优势:

  • 通过不同分支间的交互规划了一套软件开发、集成、部署的工作流
  • 基于不同分支完成不同环境的发布
  • CodeReview,开发者的代码,可以在MR 到dev branch 过程进行peer review,再MR 到release branch 时做 lead review
  • 可直接集成各种CI tools,进行持续发布;不过一般情况是,测试环境采取 auto deploy,预演和生产环境 manual deploy

实施要求:

  • 整个团队的纪律性要求很高
  • 要求团队成员熟练掌握git 指令、gitflow原理流程
  • 有git-flow 扩展指令集,推荐使用sourceTree 做为git-flow gui 工具

注意事项:

  • 两条主分支:develop & master,贯彻整个流程始终
  • feature 分支,粒度划分要细,建议不超过一周,杜绝出现long-lived-branches;多人协作时;建议每日从dev pull 一次代码;建议发起mr前均需要pull 一次代码,修复冲突后才能mr到dev 分支
  • develop和master分支,需要设置为protected branch,杜绝直接commit和merge代码
  • release分支,只做bug 修复,bug修复完后,发布上线,同时要将修复的代码 mr 到dev
  • hotfix分支,线上出现bug需要进行紧急修复,可以从master 拉一个hotfix分支,修复后及时mr 到master 和 dev 分支;线上出现重大bug,或者bug一时难以修复,需要基于上一个tag进行回滚操作。

产品发布流程 - 基于git flow工作流

git-flow

(1)(2)(3)步骤说明

(1)上测试环境,feature 通过merge request 到dev:

  • 在 MR 前,需要从dev 作 pull 操作
  • 在 MR 前,需要功能自测 ,核心服务通过unit test
  • MR 过程中需要assign to peer developer 作 Peer review,双方均需对此次mr 负有责任;Code Reviewer之Peer Review,审查代码逻辑错误,建议更好的实现
  • MR 完成后,基于dev 分支 发布到测试环境;(可以手动,也可以自动)
  • 发布到测试环境后,由QA&UI 负责校验 任务是否达到DoD标准,未能通过检验,返回给研发进行修改

(2)上预发布环境,从dev 发起 merge request 到release:

  • 在MR前,需要当前sprint 内所有task 均达到DoD标准,所有bug fixed
  • 在MR前,需要QA/Tester通过对测试环境的功能测试、性能测试、兼容性测试
  • 在MR前,需要UI Designer通过对产品进行还原度确认
  • 在MR前,需要由Team Leader/架构师 作 Lead Review,对代码架构进行审查,保证代码的重构与复用
  • 基于release 分支发布到预发布环境;release 分支的改动要在上线前MR回dev和master
  • 发布release,意味着此次sprint 的研发结束,后续的研发 就要算作next release 版本

(3)上生产环境,从release 发起merge request 到 master:

  • 在MR前,需要通过QA/Tester通过All Test Case的回归测试
  • 在MR前,需要需求方/PO confirmed,可以通过sprint review meeting 达成
  • 在MR后,需要基于master分支 建立tag进行备份
  • 发布上线后,做冒烟测试
  • 线上出现重大异常或一时无法修复的异常,需要即可基于上一个的tag进行回滚,修复完成后再重新上线

注意情况:

  • (1)(2)(3)在服务器到位情况下,需要优先配置好jenkins 各个环境的deploy item 配置
  • 上线频率需要控制好,一般约定周二、周四,一旦存在问题可以第二日进行修复

备注

以上流程,适用 多人协作、持续迭代、产品各个环节质量和可用性要求高的情况;对于简单项目/对产品可用性要求不高的项目可以在流程上做适当精简分支;具体操作:

  1. 精简掉release分支,变更为基于dev 发布上预演;
  2. 精简掉hotfix分支,变更为基于feature 修复,dev 上做验证,再上线
  3. 上线过程不接受任何成员提交的新需求的MR,只接受bug 修复的代码MR
坚持原创技术分享,您的支持将鼓励我继续创作!
分享