73

背景

前阵子老美的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%实现理想中的开发流程,如果你有好的建议欢迎留言。

wll123 · 7月12日

要用中文就用中文 要用英文就用英文 不是一门技术不是一个专业术语 也特么用英文表示 显得自己很牛逼?用英文很装逼?很高大上?

+1 回复

1

外企文化而已。。。不要这么敏感嘛。。。

熊丸子 作者 · 7月12日
1

喷的这位同志真是豆腐心啊,用个英文而已,就上升到装逼的高度,各人有个人的写作习惯,自己看不惯就开喷,火气真大啊

samsara0511 · 7月13日
0

@samsara0511 😄谢谢支持哈,如果内容上有啥建议请尽管喷,我也不怕互怼,至于写作习惯吧,我也不收sf稿费是吧,爱看不看吧

熊丸子 作者 · 6 天前
AZmake · 7月12日

我一直都是本地跑Sonar,自己测;
你用的是GitHub的api,要是自己的gitlab那不得老实翻文档了

回复

1

https://gitlab.talanlabs.com/... 了解一下,作者是从github plugin fork的。我们之前也是要求每个dev在自己机器上装了一堆xxxlint plugin,但是这个全靠个人自觉,并不能强制要求,收效甚微,质量问题不少。所以才打出这套组合拳,目的就是硬性的提高多人协作的代码质量,希望对你的团队也有所帮助

熊丸子 作者 · 7月12日
原罪 · 5 天前

gitlab表示不服,ci/cd,devops已经都内置了

回复

0

好久不用gitlab了,刚才登上去一看,果然多了一整套解决方案,非常不错。

熊丸子 作者 · 4 天前
载入中...