多人协同开发如何保证代码质量！看看这篇《理想中的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%实现理想中的开发流程，如果你有好的建议欢迎留言。