CI消息通知的设计方案
一.需求
CI主要依赖gerrit，jenkins，gitlab，sonar四块。
-
开发人员提交代码到gerrit，自动触发jenkins的验证；
-
提醒相关的开发进行code review，并且能够接收审核的结果；
-
代码由gerrit自动push至gitlab，而不是开发手动push到gitlab，再一次触发jenkins的打包以及部署。
-
在部署前，还需要进行静态代码检测。并且将sonar检测的指标值告知给开发人员。
-
测试人员在部署测试环境和预发环境的时候，也需要及时收到构建成功或失败的消息提醒。
二. 总体流程
开发视角.png
开发人员涉及的消息提醒相对多一点
- 首先是代码提交后，需要提醒同事去评审；其次是同事评审完毕，收到评审的结果，以便及时修改或合并到gitlab中。
- CI环境又分为V验证环境和DEV开发环境，他们的编译对象不同：前者是用来验证gerrit仓库中当前提交的代码，后者是用来验证gitlab仓库中合并后的代码；他们的工作内容不同：后者包括了前者的所有步骤，还需要衔接发布部署CD的工作。
测试人员就只是接收Jenkins的CI结果
- 成功就接收成功的提醒
- 失败就需要知道具体哪个step出现了错误
测试人员不需要接收V验证环境和DEV开发环境的消息提醒；同理，开发人员不接收测试环境和预发环境的消息提醒。
code review无论是审核通过+1/+2或审核不通过-1/-2，消息均只通知代码提交者，而不是发送给项目相关的所有开发人员。
三、示例
这里以订单服务作为示例，演示从代码提交到发布到线上的整个流程中，会接收到的所有消息通知。
1、提醒相关同事进行代码审核
code review.png
2、jenkins进行自动校验
构建通过.png
3、code review 审核不通过
不通过的提醒.png
4、code review审核通过
通过的提醒.png
审核通过后，代码提交者需要commit，将代码push到gitlab仓库。
image.png
点击"SUBMIT"，推送代码至gitlab，将自动触发jenkins的Job执行。
image.png
5、DEV开发环境构建结果通知
image.png
将收到两条通知，一个是sonar的指标结果，一个是Job构建结果。
sonar指标.png
jenkins构建成功.png
四、IM实现思路
同一个工程在整个CI流程的不同环节中，接收人应不一样。如果是将所有的消息发送到一个群里，体验不是很好，而且没有针对性，也就需要@到具体人。
也就是说，同一个工程具备多个标签。
给项目打标签.png
多个标签通过分号隔开.png
在整个CI流程中，sonar/gerrit/gitlab/jenkins的webhook，回调消息体都有项目名称字段。我们根据项目名，查询其拥有的标签。
多个标签通过分号隔开，标签值就是接收企业微信的标签。
建议标签的命名规则是：
【CI的来源】- 【业务组】- 【小组】
比如：
- jenkins-platform-java
- jenkins-platform-android
- jenkins-platform-h5
- jenkins-platform-php
- sonar-platform-java
- gerrit-platform-java
企业微信的标签组管理.png
在接收到sonar、gerrit、gitlab的回调后，解析出消息体中的项目名，查询得到标签，然后发送消息给对一个的标签组。
// 根据projectKey查询所属的业务组
String group = ProjectInfoService.getTag(projectKey, ProjectInfoService.SONAR);
// 发送企业微信消息
// SONAR_MSG为消息模板，paramMap为消息模板对应的key、value。
WxchatMessageUtil.sendByGroup(MessageFormatUtil.parseTemplate(SONAR_MSG, paramMap), group);
