Categories
management|管理 technology|技术 中文

代码的分支管理、CICD以及版本定义

分支用途详解

  1. dev 分支是开发用的
  2. qa分支是测试用的
  3. uat是的在发布之前给内部人员(运营人员,或者老板们)使用的
  4. staging是用于压测的环境,上线前的最后验证
  5. master是用于生产环境部署的,是稳定的版本;部署的时候可以打tag,如:V0.1
  6. 还有两个目录: feature, bugfix。 feature是用于新功能开发,bugfix是修复bug的分支。

开发的流程描述

  1. 从dev拉取代码分支进行开发,开发完以后要merge request到dev,这个时候,会进行代码的code view
  2. dev是开发的前后端联调用的,开发者自己测试没问题了之后,就可以由前后端的lead merge到qa,qa人员就可以基于qa分支测试(转测)
  3. qa测试如果发现问题了,提交bug单给开发人员,开发人员在自己的feature分支开发修改(或者是创建bugfix分支修改),最后还是要回到第1步的流程;如果qa测试没问题,就继续
  4. 把qa测试成功的代码merge到uat供内部体验(可以省略本步骤)。如uat测试有问题,则反馈到产品,产品完善需求再从头开始开发流程。
  5. 把uat验证过的代码merge到staging,可以进行压力测试,也可以作为production环境上线的预演。
  6. 如果staging环境预演成功,就可以把代码merge到master进行上线了。这时候可以基于master分支打tag,如:V0.1.2

CICD

CICD的意思是:持续集成,持续部署。 一般来最好做到自动部署:dev代码有更新,自动部署到dev环境;qa有更新,自动部署到qa;uat和stagingg都是如此;prodcution环境需要devops手动部署。

版本定义的规则

可以在开发之前加一下产品需求的定义和版本的规划,在打tag的时候,就是对应的版本号了

产品版本号的管理建议:

1.一个完整的版本定义为V1.0,前面阶段性的版本用V0.1, V0.2这样的;

2. 线上版本的bug修复版本定义为: V0..1, V0..2 这样的。

3.版本号跟jira上的版本定义一致,跟发布版本的tag一致

Leave a Reply

Your email address will not be published.