代码质量之如何强制性管控代码质量

lsekfe

　一、背景
　　今天我们在该篇文章中描述下：如何使用gerrit+jenkins+sonar进行代码质量管控.主要是利用sonarqube分析代码的能力来管控。
　　一般流程是开发者只需要提交代码，然后会自动触发 CI/CD，根据编译结果来判断代码是否能被merge进去.而代码的质量却无法被管控到. 那么我们如何来进行管控呢？总体上是采用以下的流程：gerrit提交代码-->触发jenkins job--->编译后上传sonar报告-->shell脚本调用sonar的API，得到关键的质量数据后判断是否满足条件--->jenkins将执行结果返回给gerrit-->根据jenkins的返回结果判断是否merge代码
　　二、具体实现
　　在这个简单的流程中，最基本的是gerrit和jenkins的集成以及如何上传sonarqube报告. 当然本文不是讲解该如何集成，本文主要是讲解: shell脚本应该如何写.
　　整个shell脚本大概可以分为以下三步：
　　1、判断sonar报告已经上传成功，保证是这次提交对应的sonar报告。
　　2、curl命令去调用api，得到关键质量数据。
　　3、根据质量数据返回不同的值，返回1表示质量不过关，jenkins job也会失败，同时jenkins会给gerrit返回-1操作；返回0表示质量过关，jenkins job会是成功状态，jenkins 会给gerrit返回+1操作。
　　后面考虑将第一步抽离出来，因为可能各个team关注的质量指标不同，但是各个脚本都需要执行第一步.于是就有了两个脚本：sonarCheckStatus.sh、sonarCheckQuality.sh;
　　第一步sonarCheckStatus.sh的具体实现如下：

1. #!/bin/bash
   
2. 　　
   
3. 　　#set -ox
   
4. 　　
   
5. 　　projectName=$1
   
6. 　　url="$SONAR_address"
   
7. 　　
   
8. 　　function getStatus(){
   
9. 　　    urls=$url'api/ce/component?component='$projectName;
   
10. 　　    flag=12;
    
11. 　　    while [ $flag -gt 5  ]
    
12. 　　    do
    
13. 　　        result=`curl -k -X GET $urls`;
    
14. 　　        #if sonar project is private
    
15. 　　        #result=`curl -k -u $username:$password -X GET $urls`;
    
16. 　　        analyze=`echo $result | awk -F : '{print $11}' | awk -F '"' '{print $2}' `;
    
17. 　　        if [ "$analyze" == "SUCCESS" ];then
    
18. 　　          echo "sonarqube report analyze successfully!!!!! Please execute check script"  
    
19. 　　          break;
    
20. 　　        fi
    
21. 　　        echo "report is analyzing!!! sleep 20 seconds and scanning again"
    
22. 　　    sleep 20;
    
23. 　　    ((flag--));
    
24. 　　    done
    
25. 　　  if [ $flag -le 5 ];then
    
26. 　　    echo "Don't get the analysis result, please adjust the value of flag or check url & projectName"
    
27. 　　    return 1;
    
28. 　　  fi
    
29. 　　}
    
30. 　　
    
31. 　　getStatus

复制代码

这个脚本主要是考虑到一般sonarqube分析项目时都不会超过两分钟，因此每次调用sonar的api来判断报告是否更新，如果更新了，就返回0，如果sonar还在分析报告，就睡眠20秒后继续调用该API，再继续判断，如果120秒都没成功，脚本就返回-1，jenkins job就失败了.
　　第二步sonarCoverageCheck.sh脚本也是类似的思想，但是相比于第一步更加复杂。
　　三、其他
　　1.为什么使用shell脚本，而不是[url=]python[/url]脚本？
　　因为最开始的考虑是所有的linux系统都可以直接使用shell脚本，而python脚本需要手动安装python，出于最小影响的考虑，选择用shell.但是后来发现其实现在的系统会自动安装Python2.7.大家选择自己会的语言即可。
　　2.sonarqube的报告一直处于pending状态，导致脚本一直返回-1，代码一直无法merge进去。
　　这个问题是由于sonarqube本身导致的，sonarqube的任务执行是单队列的形式，当有任务阻塞的时候，会block住其他的任务.而代码无法merge是因为jenkins给gerrit返回了-1，开发同学看到-1后不会同意合并代码到主分支.(在gerrit上也可以设置：只要jenkins返回了-1，就不准任何人merge代码)。
　　3.脚本应该放在哪里
　　脚本放在jenkins job中，是通过脚本返回1或0来管控jenkins job的状态，从而给gerrit返回对应的状态码。
　　4.流程的优缺点
　　优点是：该流程在整体上满足质量管控的需求，可以对关键质量数据进行卡点. 而且不需要太多额外的依赖。
　　缺点是：由于是通过sonarqube的能力来管控质量，因此需要依赖sonarqube的状态，当sonar出现异常时，该流程无法正常运行. 而且，需要额外的成本来完成并管理shell脚本。