配置管理工作流程

发表于:2017-6-07 10:30  作者:lazio   来源:博客园

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 配置管理

  业内实践
  git flow
  固定远程分支:
  master分支:主分支,和生产环境一致,存放已发布完成的版本
  develop分支:主开发分支,用于合并功能分支,维护公共的最新代码
  临时远程分支:
  release分支:预发分支,发布时基于Develop分支创建一个Release分支,完成Release后,我们合并到master和develop分支
  feature分支:功能分支,每个功能对应的分支,合并到develop分支和release分支后删除
  hotfix分支:bug修复分支,后合并到develop和master分支后删除
  优点:
  清晰明了,每个分支都有都自己的作用,有工具或插件帮助操作者使用此流程。
  缺点:
  更加适合于按版本发布的项目,不太适合持续发布。有的服务更期望代码变动就发布一次,每次发布需要合并develop、release、master三个分支。
  github flow
  如图,githubflow非常简单,只有一个固定的远程分支marter。每个研发人员fork项目后,在本地用功能分支开发,开发完成后提交PR请求合并master分支。
  PR请求通过后,合并至master分支并部署。master分支代表可以随时上线的版本,并且可以通过持续发布系统,无限发布到生产环境。
  但有些时候,PR被合并了之后我们可能也不会立刻就发布到生产环境,久而久之,生产环境就会落后master。
  综合gitflow和githubflow的优缺点,在githubflow的基础上,增加一个production分支,用来标识目前已上线的版本。
  配置流程
  项目管理员创建gitlab仓库,创建并保护master分支,设立相关权限
  研发人员fork项目,生成自己的fork库
  研发人员clone自己的fork库至本地
  研发人员在本地新建功能分支,并提交至本地分支,也可以push功能分支至远程fork库备份
  研发人员定期与远程主干分支同步
  研发人员推送至自己的fork库
  不需要测试人员测试时:
  研发人员直接发起PR请求合并个人远程仓库的开发分支至项目远程仓库的master分支
  CI自动执行代码静态检查和单元测试
  项目管理员审核PR,合并请求完成开发流程
  需要测试人员测试时:
  研发人员通知项目管理员在项目远程分支中创建功能分支,研发人员发起PR请求合并个人远程仓库的开发分支至项目远程仓库的对应分支
  CI自动执行代码静态检查和单元测试
  项目管理员审核PR,合并至项目库的远程功能分支
  测试人员拉取功能分支测试
  测试人员提出PR请求,合并远程功能分支至master分支
  CI自动执行单元测试
  项目管理员审核PR,合并请求完成开发流程
  项目管理员在发布平台选择响应的master提交进行发布,发布后自动对master标记tag
  Git commit日志规范
  gitcheckout新分支时,分支名采用feature_标题_erp#、bugfix_标题_erp#、refactor_标题_erp#
  如:feature_batch_save_product_12345
  gitcommit时提交日志规范如下:
<type>:<subject>
  <body>  
  type枚举:
  feat新增功能
  fix修复bug
  docs修改了文档、readme
  style不改变代码逻辑,仅修改代码样式
  refactor非功能性重构
  test测试用例
  subject:描述主要变更内容
  body:主体内容,更详细的说明文本,如erp地址等,可以为空
  Code Review
  提交CodeReview之前要做什么?
  准备或者提交相关需求文档以备审查者询问
  编写符合规范的代码和合适的注释
  考虑代码是否有重构的可能
  单元测试全部通过,测试覆盖率达标
  如何Code Review?
  了解需求:这个提交是为了解决什么问题,是需求单、BUG修复、还是代码重构,
  如果不明确,需要及时和代码作者沟通和讨论
  检查代码业务逻辑是否符合需求
  代码是否符合相关代码规范
  确认是否有更好的方式方法重构代码
  检查单元测试用例是否考虑全面
  如果代码没有问题,也写上类似GOODJOB之类的评论
  Code Review之后可以做什么?
  对于代码审查人表示感谢
  如果代码审查没有通过,不要往心里去,审查的是代码,不是你
  尝试对每一个评论做出回复
  等待合并分支,等待持续集成告诉你全部通过
  项目结构规约
  -doc文档文件夹,用来存放概要、详设、API等文档资料
  -src程序源码文件夹,用来存放源码
  -db数据库文件夹,用来存放可执行的数据库相关变更DDL脚本文件,如V1__init.sql,V2__feature_batch_save_product_12345.sql
  -deploy(可选)用来存放部署相关文件,如shell脚本等
  -..按项目自由配置
  README.md项目说明
  Dockerfile

评 论

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海瀛东律师事务所 张楠律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2017, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道