多人协同开发如何保证代码质量！看看这篇《理想中的Jenkins+Sonar+Github代码质量管理》

背景

前阵子老美的Audit要求各个开发组截图各自repository的Sonar Analysis Report，我跑去Sonarqube一看。。。好家伙！全是红灯，简直惨不忍睹

固然这其中有历史问题，由于咱们是半路接管的欧美team的code，不少issue都是old code所遗留的。

不逃避责任，其中也有一部分是咱们后续提交的新代码形成的，经过项目2年来的日积月累，issue多的有点积重难返，sonarqube虽然在每次jenkins build都会生成report，可是咱们却没有把它做为build成功失败的一个硬指标。只要build成功经过QA测试就行了嘛！管他娘的sonar quality gate

结果

为了出一份体面漂亮的report给audit，我不得不马不停蹄的checkout -b quick_fix_sonar_issues, 花了一成天的功夫把block和critical的issue降到了阈值如下。

临阵磨枪的我体会到了如下3个痛点

1. 有些Sonar能检测出来的issue，确实能规避一些产品上的潜在bug
2. 有些同事在code中犯的错误真的很低级，可是人工code review中很难被发现，不是个人锅，我如今却在为同事擦屁股。
3. 虽然快速fix了issue，可是code的owner并非我，我有可能为了迎合sonar的rule而产生了潜在的新的issue，而和owner去一一check又增长了不少沟通成本，另外owner颇有可能已经离职了

思考

囧则思变！如何改进咱们的开发流程？在代码开发阶段就能让Sonar分析出问题？强制owner必须解决完issue才能提交代码？
嗯！是时候对目前存在弊端的开发流程进行改进了！

老的开发流程

先介绍下目前的基础设施：

• 经过GitHub来管理source
• 经过Github Pull Request来实现Code Review（之前用gerrit可是我以UI太丑为由号召开发们拒绝使用）
• 经过Jenkins来实现持续集成
• 经过Sonarqube来实现代码分析（形同虚设）

老的流程：

1. 当一个新feature来临时
2. owner从master（受保护的）分支checkout 一个feature_dev_branch作开发
3. 开发完成后，提交pull request（PR）请求合并到master
4. 技术leader对PR进行code review并approve后，feature_dev_branch合并到master。
5. Merge触发触发Jenkins自动build，Jenkins触发Sonarqube scan产生report（仅仅生成report）
6. Build成功则进行package的deploy以及后续Automation Testing等流程
7. 交付QA测试

改进后的开发流程：

1. 当一个新feature来临时
2. owner从master （受保护的）分支checkout 一个feature_dev_branch作开发
3. 开发完成后，提交pull request（PR）请求合并到master
4. PR自动触发Jenkins，Jenkins触发Sonar分析本次提交的new code
5. Sonar将report和issue以comments的方式写到Github PR里，并做为硬性的check point
6. Owner对PR进行反复commit直至经过Sonar的分析
7. 技术leader对PR进行code review并approve后，feature_dev_branch合并到master。
8. Merge触发触发Jenkins自动build，Jenkins触发Sonarqube scan产生report（仅仅生成report）
9. Build成功则进行package的deploy以及后续Automation Testing等流程
10. 交付QA测试

加了3步，使得new code经过sonar检测成为一个硬性指标，把issue扼杀在萌芽中，把锅甩在最前面

哇！！！太Cool了！

跟我一步步完成Jenkins和Sonar的配置

什么？你居然不知道Jenkins是个啥？！那你操个哪门子的心去优化开发流程，好好搬你的砖，写你的bug！
咳咳！建议你转发本文给负责devops的同事，请他吃饭让他帮忙配置

Jenkins须要一个plugin，叫作github pull request builder

它的做用是生成在Jenkins和Github之间生成webhook，似的PR能够自动触发Jenkins的Build

稍微配置下这个插件，画红线的地方很重要

Jenkins还须要一个plugin，叫作SonarQube Scanner

它的做用是让Jenkins去触发Sonar的分析

稍微配置下这个插件，画红线的地方很重要

没据说的Sonar？没有现成的Sonar Server? 额，继续请devops吃饭吧...

Sonarqube里（注意是Sonarqube里，不是Jenkins里）也须要安装一个plugin，名字叫 Github

它的做用是 当Sonar检测完毕后，把生成的report和issue的分析以comments的方式写回到Github的PR中

稍微配置下这个插件，画红线的地方很重要

接下去就是配置Jenkins的project了

废话很少，只贴关键配置，红线部分很重要

Advanced里能够勾上这一条（虽然是Dangerous），由于咱们Github是企业版，因此能提PR的人是有权限控制的，若是是用官网的github管理代码请慎用这个选项，建议使用黑白名单来控制触发的条件。

如下是Sonar的配置，很重要，注意analysis mode只能选择preview，preview mode不会真正的在Sonar上生成report哦。

写在最后

Jenkins的安装，Sonar的安装啥的，教程我就不放link了，这种大路教程一搜一大堆（我我的建议你用docker安装）
做为一个开发，我以为这些基本的，能提高工做效率的工具仍是要掌握一下的，并非说只有devops才会用到这些工具，谁不喜欢偷懒呢，这些都是偷懒的好帮手。

截止发稿时，这个流程还存在一些些小bug，好比preview mode的sonar分析不能跟sonar中quality gate进行结合，sonar js不能分析parse有问题的js文件等等，还显得不够完美，咱们也在经过其它的workaround来100%实现理想中的开发流程，若是你有好的建议欢迎留言。