一、背景
前端即便是小团队，偶然也是会冒出多人单干问题。
- 编码格调不能保障对立
- git应用不标准，某些不标准的代码推送造成历史代码失落
- 新人对别人代码上下文不相熟改变产生bug
等等。
问题的防止要求到集体是不牢靠的，扩散精力到琐碎如缩进格局的细节也会升高生产力。
因而，思考应用自动化加上流程改良的计划，无效拦挡问题。
二、指标
标准流程
- 产品、我的项目的代码都设成爱护分支，禁止force push等危险操作
- git提交可控，如当抵触解决失误、无心笼罩多个文件，检查人员可能不便看进去，防止合入主分支
- 性能批改commit必须带上jira id，不便开发日后看git历史理解上下文、QA剖析
代码放弃优雅
编码格调对立
如文件排列规定统一
减少可维护性、可读性
如变量表意，没有大段无用代码，尽量应用新的稳固语法糖，缩小冗余代码
防止潜在bug
如相等判断应该应用全等符号，而不是仅仅比拟值
质量保证
防止低级谬误，如把编译不过、导致白屏的代码合并到主分支
保障单元测试笼罩的代码性能不被毁坏
三、流程
四：审核形式：Merge Request
代码合并到我的项目/产品主分支前肯定要通过merge request的形式进行合并。
- 把所有我的项目/产品分支设置为爱护分支，能禁止force push（️）这种危险操作。
- 能够增加一系列主动查看，让代码标准查看成为强制、常态、主动的。
- 人造给code review提供方便
- 对于高级继续集成计划，构建、实际的工夫老本很低
主动查看：流水线
把本地提交合并到近程骨干分支前，须要通过一系列查看。
为什么须要流水线
防止本地查看因为种种原因被跳过（如代码很急跳过查看，习惯不好不喜爱查看，环境配置不对导致本地查看不失效等等）
查看内容
查看不通过，如提交的批改新增了lint谬误，流水线会失败。
人工查看： Code Review
MR流水线通过后，须要通过其他人确认没有看出问题。能力由有权限的人进行合并。
Review根本规定
- 严格遵循MR/git/代码格调的标准
- 不容许谬误应用git导致提他人的代码 （比方一个非重命名提交几十个文件改变）
- Reviewer提出有潜在的bug，作者要提交新的修复commit才通过review
前置条件：自审
本人才是MR的最终负责人，防止谬误提交。
commit是否只蕴含无效提交
- 不蕴含他人的提交
如本次MR集体只提交了5个commit，就应该只有5个commit
如多出一个无用的merge commit，一般批改逻辑不该有这样的提交
change是不是都是合乎预期
- 能够很分明地看到文件改变数量，大量文件变动是不失常的
- 左侧变动导航能够分明看到改变了那些文件，是否蕴含本人未被动变动过的文件批改
- 流水线跑过后再请人review，防止来来回回浪费时间
这些都是一眼能扫出来的问题。
Code Review 利弊剖析
益处：
- 提前缩小问题
- 能够碰撞思维，让代码更加强壮优雅。
顾虑Q&A：
Q: 开发格调不一样，如果reviewer有集体爱好（如一个工夫转换工具叫做DateUtil还是DateTransfromer），很难花工夫去探讨、迁就
- A: 不要提集体爱好，次要按集体的倡议另外找工夫和所有人拉通，放在开发标准里。
- A: 强烈的倡议能够提gitlab issue，找工夫集中整顿issue，列为技术债指定人一一解决
- A: 对于没有写在标准文档里的，然而社区公认的不好实际，不予通过，如被废除的办法
Q: review他人代码会不会太消耗精力，看不出问题是否接受压力。
- A: 对于相熟的代码，很快就晓得干了什么
- A: 对于不相熟的代码，不明确的请对方阐明，能够减少本人对我的项目的根本理解。在工夫紧的状况下，能够不关怀逻辑，只查看一些准则问题。
- A: reviewer只是躲避危险，提出倡议。作者才是最终负责人。
Q: 一个人负责的我的项目，且非新人、合作伙伴、实习生，合并前须要code review吗？
- A: 合并到主分支里的代码须要，其余灵便变通。
五、提交MR步骤
如小明须要向产品分支feature-AAA奉献代码，对应jira工作JIRA-1001
基于最新feature-AAA分支
checkout一个新的本地分支xiaoming，更举荐以jira号命名JIRA-1001。集体分支名不能和主产品、我的项目分支命名相似，其余如果没有标准看集体习惯。git checkout feature-AAAgit pull --rebasegit checkout -b JIRA-1001- 在本地分支JIRA-1001上提交批改。
push到对应近程分支
git push --set-upstream origin JIRA-1001命令行可主动提醒创立merge-request链接
或点击gitlab网站上创立merge request。留神选对【待合并分支】和【待合入的分支】
点击流水线跑过后后立刻merge按钮，则跑过后会合并。默认近程分支会删除。
上述操作实现后，如果要在同一个本地分支上持续提交代码，确保在提merge request之前，本地代码和待合入的代码放弃同步。
git fetch origin feature-AAA （或罗唆 git fetch --all）git rebase origin feature-AAA 如果有抵触，先在本地解决了再push。防止反复提交、或提了MR后才发现有抵触，浪费时间。
MR格局要求
是否合并多个commit 为一个
- 对于很小变动的提交（比方所有MR都做的同一件事件，抉择压缩所有commit到一个）。放弃主分支变更历史清晰。
- 每个commit做了独立的事件，不squash
对于性能批改代码，变更历史须要蕴含jira id。
如果压缩commit：MR title带 jira id
不压缩：commit须要带jira id
保障主分支代码历史有变更根据。
问题
提交merge request后，合并之前又有人提交了新的代码怎么办？
点击rebase即可线上更新代码，如果没有抵触，则可持续流程
为什么同步了最新的代码提交merge request，过了一会儿又发现有抵触？
可能是其他人合入了与你的MR产生抵触的代码。
此时把近程分支删除，更新本地代码，解决抵触后从新提交。
//把近程分支删除git push origin JIRA-1001 --delete//更新本地代码git fetch origin feature-AAA （或罗唆 git fetch --all）git rebase origin feature-AAA
六、贴士
在本地IDE配置主动格式化代码，主动修复工具
配置保留时主动格式化。
简略的谬误能够也能够主动修复。
- 性能代码提交后运行主动修复命令。如果有主动修复造成的更改，再提交一个修复的commit。
七、更进一步的冀望
更多的补充查看
动态查看 / 代码扫描
- 如sonar，可能发现更多问题。
功能性测试
高级功能测试，保障运行正确
作用：开发确保页面可拜访，至多能拜访首页（或默认页面），防止低级谬误（如页面拦挡逻辑写错导致我的项目白屏）
测试撰写：前端开发
环境保护人：前端开发，集成到前端流水线
老本：较小。要为功能测试做配置，至多要搭建一个含有根本API拜访的mock server，须要破费一些工夫。
高级功能测试，保障前端性能
作用：从前端单方面保障所有根本稳固的页面交互正确，防止新代码合入改坏旧性能以及修复旧性能造成QA反复工作
测试撰写：QA撰写本人保护的测试用例，前端开发撰写一些白盒用例
环境保护人：前端开发，集成到前端流水线
老本：较大。须要搭建自动化同步更新后端接口+人工mock数据合并的mock server，要花费较多的工夫。保护起来能够变成开源我的项目。每个我的项目要独自筹备一些初始数据。
比较完善的功能测试，端到端
作用：还原实在的测试场景，测试稳固的重要性能，保障测试到的场景下所有链路性能失常。
比方测试某个页面时，能够期待几秒后截图，截图邮件发给QA，能够定期检查，截图是否合乎预期。甚至能够留一个底图做像素比对，类似度低于肯定水平时才发告警邮件。
版本开发实现，提交测试后，修复性代码合并前应该通过功能测试。
测试撰写：QA撰写本人保护的测试用例，前端开发撰写一些白盒用例
环境保护人：所有开发、运维。独自成一条流水线，不影响提测前代码合并。流水线失败也可能看到。
老本：很大。对于前端和测试只须要筹备本人的测试用例，对于前端所有的下层开发都要筹备一些初始数据，保障测试环境的稳固，运维须要筹备和重置测试环境，筹备流水线。每个我的项目要独自筹备一些初始数据。
可能存在的问题剖析
提测后，修复代码可能造成新的bug
解决方案：
人工形式：
提测后，相干分支除了通过流水线外，必须被其他人review 批准后才可合并。
review新人（对我的项目齐全不熟）、合作伙伴、实习生的代码，除了基本准则，肯定查看明确代码逻辑。
- 自动化的形式：跑功能测试后才可合并（期待将来搭建）
流水线有时比较慢，须要运维共事帮忙优化
解决方案：
- 优化CI配置，前置依赖下载给多个job应用。
- 配置缓存，至多缩小反复下载依赖的工夫。
更好地造成闭环
- 流程可视化，如在办公室设立一个专用大屏（投影，或者电视挂在墙上），流水线失败会显示挂掉的UI
- 主分支流水线失败及时告诉，用邮件、群机器人️、扩音器播音的形式揭示对应提交人
- 如果有自动化功能测试，功能测试失败会主动发邮件给QA