上线内容
1.餐饮2.1 3月22号上线
2.CRM3.4.2 3月23号上线
3.OMS大盘数据 3月29号上线
4.CRM3.4.3 3月31号上线
测试内容
开发内容
3月份项目上线情况
上线情况良好,缺陷率保持良好。👏
项目的开发梳理
唐兵贤:OMS产品运营、数据运营;HRMS
施晨辰:CRM;OMS基础信息;餐饮系统
陈嘉伟:微订房;SSO
4月份OMS优化清单
- OMS代码提交git整理 【陈嘉伟】
- 代码冗余删减(登录相关代码、动态表单)【唐兵贤】【陈嘉伟】
- 路由入口文件优化,挪到app.vue中【唐兵贤】
- 目前存在大量冗余的样式文件、以及不统一的文件(less,scss),统一成scss【施晨辰】
- npm包采用cdn方式引入【陈嘉伟】
- iview、element采用按需加载方式处理 【唐兵贤】
目标是4月16号整体验收
git规范
代码分支模式的选择并没有绝对的正确和错误之分,关键是与项目的规模和发布节奏相匹配。
除了 Git 命令,权限控制也是 Git 中极为重要的组成部分,本文主要介绍 GitLab 系统提供的最常用的权限控制功能。
分配成员角色
首先来了解下,Git 中的五种角色:
角色 | 描述 |
---|---|
Owner | Git 系统管理员 |
Master | Git 项目管理员 |
Developer | Git 项目开发人员 |
Reporter | Git 项目测试人员 |
Guest | 访客 |
开发的几种场景
分支 | 命名 | 说明 |
---|---|---|
主分支 | master | 主分支,所有提供给用户使用的正式版本,都在这个主分支上发布 |
开发分支 | develop | 开发分支,永远是功能最新最全的分支 |
功能分支 | feature-* | 新功能分支,某个功能点正在开发阶段 |
发布版本 | release-* | 发布定期要上线的功能 |
修复分支 | hotfix-* | 修复线上代码的 bug |
每一种角色所拥有的权限都不同,如下图:
我们需要做的是,为项目成员分配恰当的角色,以限制其权限。
Protected Branches
在对 Git 不熟悉的时候,时常苦恼于各个分支不受约束,任何开发人员都可以向任何分支直接推送任何提交,各种未经审查的代码、花样百出的 Bug 就这样流窜在预发布分支上。
其实我们可以通过 GitLab 的受保护分支(Protected Branches)功能解决该问题,该功能可用于:
Keep stable branches secure and force developers to use merge requests. By default, protected branches are designed to:
- prevent their creation, if not already created, from everybody except Masters
- prevent pushes from everybody except Masters
- prevent anyone from force pushing to the branch
- prevent anyone from deleting the branch
接下来我们就使用这项功能,锁定我们的受保护分支——主分支 master 和预发布分支 release-*,以阻止 Developer 直接向这两类分支中推送代码:
锁定后,Developer 推送代码将会报错:
Merge Requests
锁定受保护分支后,要么 Master 需要时刻、主动关注各特性分支的进度,要么 Developer 需要线下、口头向 Master 汇报其特性分支的进度,这两种做法都非常不便于 Master 管理每个预发布分支的合并,尤其在团队大、分支多的情况。
我们可以通过 GitLab 的发起合并请求(Merge Request)功能解决该问题,这样既可以让 Developer 更自如的掌控自己分支进度,在必要的时候才主动发起合并请求;又可以减轻 Master 的合并工作量和沟通成本,可谓一举两得。
新建 MR
第一步,按表单要求填写合并请求。注意,对于 Developer 而言:
- Source branch 是你的特性分支 feature-*;
- Tagget branch 只可能是预发布分支 release-*;
- Title 和 Description 要填写恰当的分支描述;
- Assignee 是该项目的 Master。
审查 MR
第二步,Master 收到合并请求后,进行代码审查。逐一查看 Commits 或 Changes 一栏提交的内容即可,对于需要改进的代码,可以直接在该行添加注释,非常方便。
如果对整个请求还有疑问的地方,还可以通过 Discussion 功能进行线上讨论。
处理 MR
关闭
对于完全不合格的垃圾代码、或者废弃的特性分支的合并请求,Master 点击右上角的 Close 按钮即可。合并请求将被关闭,相当于扔进回收站。
改进
对于分支内需改进的代码,Developer 直接修正并推送即可,合并请求将会自动包含最新的推送提交。
接受
Master 审查无误后,可以接受该次合并请求。点击 Accept Merge Request 按钮将自动合并分支,勾选 Remove source-branch 将同时删除该特性分支。
整个自动合并过程如果以命令形式手工执行的话,步骤如下:
最后需要注意的是,只有 Assignee 才能够接受合并请求,其它人只会被通知:
You don’t have permission to merge this MR
总结
GitLab 提供的上述功能非常实用,为项目的源码管理提供了有力的支持。