当前位置: 首页>大数据>正文

Code Quality and Security

code scan

使用sonar来检测我们代码是否存在security和隐含的bug以及code coverage。针对不是一开始就引入sonar,历史代码已经存在了的情况,可以关注新code的质量,毕竟不能再差下去了。我们可以在上一次分析的结果上打上一个tag,表明下次我分析的每个数据都是基于上次的结果。好处:
1. 清晰的到这个阶段我新增了多少代码,产生了多少新的bug和vulnerabilities。具体可以应用在每个sprint。当一个sprint结束了,我将其扫描的最后一个结果做个release tag,然后接下来的sprint里每次扫描的baseline都是和上个sprint比较。
2. 针对bug和vulerabilities,sonar定了5个级别,重点关注的是blocker和critical issue。确保每个sprint这些issues一定是fix的。
3. code coverage。针对新的code,coverage不少于50%,可以作为一个quality gate。如果新的code的coverage低于这个值,那么整个项目的coverage只会越来越低。在配置扫描的规则中可以去除一些pojo这种class(通过sonar.extensions设置),这种写UT没有必要,但是会影响coverage的数值。

Code Quality and Security,第1张

4. 扫描的rule可以自定义,自行在业界公认的issue上面删除或者修改的级别。
5. baseline的设置可以根据不同的project,设置不同的tag。针对那种交叉、release不同步的项目。
6. 目前新的社区版是7.9,尽量采用7.4以上的版本(这个版本有较大的调整)。(当然专业版和开发板还提供了根据不同的branch或者pr进行扫描也是挺不错的,不好的就是要钱)
7. 扫描频率。如果项目代码不是很大,可以per commit进行扫描,如果项目编译需要很长时间,建议定期扫描,将扫描结果发送相关人(github有api可以抓取一个阶段提交代码的人)

Code Quality and Security,第2张
40A882E5-2931-473C-B265-3BDDD32FA9AC.png

上述描述的是integrator可以设置的部分,那么developer可以做些什么呢?
IDEA里面有个插件 sonarlint ,可以在里面配置sonarqube的相关信息(server url,user,passwd)我们可以把soanrqube上的profile rule同步到这个插件里,这样开发在本地开发完扫描下代码,就可以提前检查自己的代码是否存在问题。

Test

Test首先对case进行分级,哪些case是UT的,哪些是gatekeeper的。

  1. 针对gatekeeper的case,每次部署环境的时候(QA,PP等)都会自动跑,生成report。一旦发现有case fail,code freeze。如果case都绿了,那么QA可以上去进一步验证feature。如何设置gatekeeper,或者如何给case分类,采用的是注解,外加maven profile的方式进行归类(注解的方式有个好处就是可以将类划分好几个category,便于统计)。
  2. 针对UT,需要保证UT 100%通过,筛选出重要的UT,不重要的剔除。可以通过surefire-plugin,surefire-report来查看UT情况。
  3. rerun policy。设置一些retry机制,排除环境的影响。surefire插件中包含surefire和failsafe,可以比较结果进行rerun。
Code Quality and Security,第3张
26C23D09-CDAE-4D24-AACF-655F94531BC0.png

error和failure都统计为fail。

  1. 针对反复出现不稳定的case,可以标记为unstable,等到retro的时候进行复盘,再归类,目的是消灭这部分分类case。
  2. case支持最快捷的手动rerun,可以写脚本。目前都是用的k8s的方式,一行kube命令就可以拉起所有的case。
Code Quality and Security,第4张
6D87028D-41B9-4DE7-9B56-974024E08B5C.png
  1. 收集case数据的好处可以看出case的历史趋势,对于Service的case很好分类判断,但是对于UIcase,有时会出现automation hang的问题,分析的时候可以借助于JProfiler,youkit。或者将selenium的maxSession调大。
  2. 配置zabbix,对机器性能的检测(CPU,IO,memory等)设置风险点,发送alert邮件。当然如果发现机器上的服务不可用,也可以在zabbix里写脚本当其检测到服务不可用时,自动重启。
  3. 将test加入到开发日常编译的过程中,开发提出pr的时候,需要先跑一下所有的case(可以通过pipeline),case 过了,才允许merge代码。
  4. jenkins pipeline三条线【PR pipeline(dev on demand), Master pipeline (schedule 4 hours, 和PR大部分一样,case更全面),nightly build(部署环境,专注于image) 】
  5. 目前做到部分是case既可以用maven跑,也可以在容器里执行。(容器里执行,需要容器化,还要考虑各个service之间的依赖顺序)

Delivery Tool

  1. 提供一种脚本可以一键部署应用。通过传入的参数来选择性的部署(infra,middle,product,upgrade...),采用的是go编写。
  2. 提供revert VM脚本,(ansible)。定制linux templete(jdk,linux内核,python,maven,git,jq...以及机器之间的免密登录)。

https://www.xamrdz.com/bigdata/78g1993964.html

相关文章: