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

234 阅读5分钟
原文链接: segmentfault.com

背景

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

clipboard.png

当然这其中有历史问题,因为我们是半路接管的欧美team的code,很多issue都是old code所遗留的。

clipboard.png

不逃避责任,其中也有一部分是我们后续提交的新代码造成的,通过项目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扼杀在萌芽中,把锅甩在最前面

clipboard.png

clipboard.png

clipboard.png

哇!!!太Cool了!

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

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

Jenkins需要一个plugin,叫做github pull request builder

它的作用是生成在Jenkins和Github之间生成webhook,似的PR可以自动触发Jenkins的Build

clipboard.png

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

clipboard.png

Jenkins还需要一个plugin,叫做SonarQube Scanner

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

clipboard.png

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

没听说的Sonar?没有现成的Sonar Server? 额,继续请devops吃饭吧...

clipboard.png

clipboard.png

Sonarqube里(注意是Sonarqube里,不是Jenkins里)也需要安装一个plugin,名字叫 Github

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

clipboard.png

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

clipboard.png

接下去就是配置Jenkins的project了

废话不多,只贴关键配置,红线部分很重要

clipboard.png

clipboard.png

Advanced里可以勾上这一条(虽然是Dangerous),因为我们Github是企业版,所以能提PR的人是有权限控制的,如果是用官网的github管理代码请慎用这个选项,建议使用黑白名单来控制触发的条件。
clipboard.png

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

clipboard.png

写在最后

Jenkins的安装,Sonar的安装啥的,教程我就不放link了,这种大路教程一搜一大堆(我个人建议你用docker安装)作为一个开发,我觉得这些基本的,能提升工作效率的工具还是要掌握一下的,并不是说只有devops才会用到这些工具,谁不喜欢偷懒呢,这些都是偷懒的好帮手。

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