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的数值。
4. 扫描的rule可以自定义，自行在业界公认的issue上面删除或者修改的级别。
5. baseline的设置可以根据不同的project，设置不同的tag。针对那种交叉、release不同步的项目。
6. 目前新的社区版是7.9，尽量采用7.4以上的版本（这个版本有较大的调整）。（当然专业版和开发板还提供了根据不同的branch或者pr进行扫描也是挺不错的，不好的就是要钱）
7. 扫描频率。如果项目代码不是很大，可以per commit进行扫描，如果项目编译需要很长时间，建议定期扫描，将扫描结果发送相关人（github有api可以抓取一个阶段提交代码的人）
40A882E5-2931-473C-B265-3BDDD32FA9AC.png
上述描述的是integrator可以设置的部分，那么developer可以做些什么呢？
IDEA里面有个插件 sonarlint ，可以在里面配置sonarqube的相关信息（server url，user，passwd）我们可以把soanrqube上的profile rule同步到这个插件里，这样开发在本地开发完扫描下代码，就可以提前检查自己的代码是否存在问题。
Test
Test首先对case进行分级，哪些case是UT的，哪些是gatekeeper的。
- 针对gatekeeper的case，每次部署环境的时候（QA，PP等）都会自动跑，生成report。一旦发现有case fail，code freeze。如果case都绿了，那么QA可以上去进一步验证feature。如何设置gatekeeper，或者如何给case分类，采用的是注解，外加maven profile的方式进行归类（注解的方式有个好处就是可以将类划分好几个category，便于统计）。
- 针对UT，需要保证UT 100%通过，筛选出重要的UT，不重要的剔除。可以通过surefire-plugin，surefire-report来查看UT情况。
- rerun policy。设置一些retry机制，排除环境的影响。surefire插件中包含surefire和failsafe，可以比较结果进行rerun。
26C23D09-CDAE-4D24-AACF-655F94531BC0.png
error和failure都统计为fail。
- 针对反复出现不稳定的case，可以标记为unstable，等到retro的时候进行复盘，再归类，目的是消灭这部分分类case。
- case支持最快捷的手动rerun，可以写脚本。目前都是用的k8s的方式，一行kube命令就可以拉起所有的case。
6D87028D-41B9-4DE7-9B56-974024E08B5C.png
- 收集case数据的好处可以看出case的历史趋势，对于Service的case很好分类判断，但是对于UIcase，有时会出现automation hang的问题，分析的时候可以借助于JProfiler，youkit。或者将selenium的maxSession调大。
- 配置zabbix，对机器性能的检测（CPU，IO，memory等）设置风险点，发送alert邮件。当然如果发现机器上的服务不可用，也可以在zabbix里写脚本当其检测到服务不可用时，自动重启。
- 将test加入到开发日常编译的过程中，开发提出pr的时候，需要先跑一下所有的case（可以通过pipeline），case 过了，才允许merge代码。
- jenkins pipeline三条线【PR pipeline（dev on demand), Master pipeline (schedule 4 hours, 和PR大部分一样，case更全面)，nightly build（部署环境，专注于image） 】
- 目前做到部分是case既可以用maven跑，也可以在容器里执行。（容器里执行，需要容器化，还要考虑各个service之间的依赖顺序）
Delivery Tool
- 提供一种脚本可以一键部署应用。通过传入的参数来选择性的部署（infra，middle，product，upgrade...），采用的是go编写。
- 提供revert VM脚本，（ansible）。定制linux templete（jdk，linux内核，python，maven，git，jq...以及机器之间的免密登录）。
网友评论