配置管理工做流程

业内实践

git flowgit

固定远程分支:github

  • master分支: 主分支,和生产环境一致,存放已发布完成的版本
  • develop分支: 主开发分支,用于合并功能分支,维护公共的最新代码

临时远程分支:sql

  • release分支: 预发分支,发布时基于Develop分支建立一个Release分支,完成Release后,咱们合并到master和develop分支
  • feature分支: 功能分支,每一个功能对应的分支,合并到develop分支和release分支后删除
  • hotfix分支: bug修复分支,后合并到develop和master分支后删除

优势:shell

清晰明了,每一个分支都有都本身的做用,有工具或插件帮助操做者使用此流程。数据库

缺点:工具

更加适合于按版本发布的项目,不太适合持续发布。 有的服务更指望代码变更就发布一次,每次发布须要合并develop、release、master三个分支。gitlab

github flow单元测试

如图,github flow很是简单,只有一个固定的远程分支marter。每一个研发人员fork项目后,在本地用功能分支开发,开发完成后提交PR请求合并master分支。
PR请求经过后,合并至master分支并部署。master分支表明能够随时上线的版本,而且能够经过持续发布系统,无限发布到生产环境。测试

但有些时候,PR被合并了以后咱们可能也不会马上就发布到生产环境,长此以往,生产环境就会落后master。插件

综合git flow 和 github flow 的优缺点,在github flow的基础上,增长一个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日志规范

git checkout新分支时,分支名采用 feature_标题_erp#、bugfix_标题_erp#、refactor_标题_erp#

如:feature_batch_save_product_12345

git commit时提交日志规范以下:

<type>:<subject>
    
<body>

type 枚举:

  • feat 新增功能
  • fix 修复bug
  • docs 修改了文档、readme
  • style 不改变代码逻辑,仅修改代码样式
  • refactor 非功能性重构
  • test 测试用例

subject: 描述主要变动内容

body: 主体内容,更详细的说明文本,如erp地址等,能够为空

Code Review

提交Code Review以前要作什么?

  • 准备或者提交相关需求文档以备审查者询问
  • 编写符合规范的代码和合适的注释
  • 考虑代码是否有重构的可能
  • 单元测试所有经过,测试覆盖率达标

如何Code Review?

  • 了解需求:这个提交是为了解决什么问题,是需求单、BUG修复、仍是代码重构,
    若是不明确,须要及时和代码做者沟通和讨论
  • 检查代码业务逻辑是否符合需求
  • 代码是否符合相关代码规范
  • 确认是否有更好的方式方法重构代码
  • 检查单元测试用例是否考虑全面
  • 若是代码没有问题,也写上相似GOOD JOB之类的评论

Code Review以后能够作什么?

  • 对于代码审查人表示感谢
  • 若是代码审查没有经过,不要往内心去,审查的是代码,不是你
  • 尝试对每个评论作出回复
  • 等待合并分支,等待持续集成告诉你所有经过

项目结构规约

-doc 文档文件夹,用来存放概要、详设、API等文档资料 -src 程序源码文件夹,用来存放源码 -db 数据库文件夹,用来存放可执行的数据库相关变动DDL脚本文件,如V1__init.sql,V2__feature_batch_save_product_12345.sql -deploy (可选)用来存放部署相关文件,如shell脚本等 -.. 按项目自由配置 README.md 项目说明 Dockerfile

相关文章
相关标签/搜索