基于Jenkins的开发测试全流程持续集成实践

今年一直在公司实践CI，本文将近半年来的一些实践总结一下，可能不太完善或优美，但的确初步解决了我目前所在项目组的一些痛点。当然这仅是一家之言也不够完整，后续还会深入实践和引入Kubernetes进行容器编排，以及通过阿里云K8S服务进行高效的云上托管，希望对各位童鞋有一点用。

一、持续集成全流程介绍

　　今年一直在开发我司的一个核心业务系统，一个还未上线的产品开发阶段，其中后端采用ASP.NET Core + 一系列开源组件开发微服务并且部署在Linux Docker中，前端采用React + Flutter开发Web和App。采用了Jenkins作为CI工具，集成了一堆插件Plugin实现了初步的持续集成全流程。

　　下图就是我最近整理的一个目前的持续集成全流程图：

　　可以看出，在开发测试环境我有3个环境：

　　（1）DEV环境：用于dev分支的前后端开发联调，有单独的数据库

　　（2）MT环境：用于release分支（现阶段我直接用的master分支，产品上线后不可取）的测试进行集成测试，有单独的数据库

　　（3）DEV-AT环境：用于dev分支的自动化接口测试环境，即专门拿来跑自动化接口脚本的环境，有单独的数据库

　　针对CI服务器，在开发测试环境我有个2个节点：

　　（1）master节点：用于持续集成和部署等一般性构建任务

　　（2）slave-at节点：专门用于跑自动化接口测试脚本构建任务

　　推荐在Jenkins中为不同类型的构建任务设置不同的label，这样可以绑定不同类型的构建任务至不同的Node上执行，从而减少高峰时期master节点的负载压力。

二、ASP.NET Core CI流程部分

　　我的后端微服务是基于ASP.NET Core开发的，采用了容器化部署至Linux服务器，之前有过一篇详细的文章介绍过《基于Jenkins Pipeline的ASP.NET Core持续集成实践》。

　　在Jenkins中提供了Pipeline方便地进行构建流水线，在我的实践中主要是通过开发人员的每一次Check-In到git，触发一个Webhook到Jenkins中从而使持续集成构建任务开始执行：

　　从图中可以看出，其经历了中台微服务的编译和单元测试及 BFF（Backend for Frontend）服务的编译和单元测试来保障代码质量，当然前提是有足够的单元测试作为保护层，这也需要开发人员花时间为每个服务接口（或者高价值的部分）写单元测试！

　　如果构建任务中有一个Stage失败了，那么此构建任务则认为失败，会给开发团队和Leader发送邮件告警：

　　此外，我们还使用了一个用于大屏显示构建状态的插件—Build Monitor，在我们工作区后方的电视屏上会显示各个构建任务的实时状态，如果有任务失败了会变为红色：

　　并且，Build Monitor还会将推进不可靠代码的提交者名字（git账号名字）显示在屏幕中的构建任务里边，方便大家查看谁的锅：

三、ASP.NET Core CD流程部分

　　经过CI部分，就可以初步认为提交的代码已经经过了初步的验证，这时会进入部署部分的构建任务，在我的流程里会有开发联调环境的部署及接口自动化环境的部署。当然，除了API的部署也有Web的部署，我们可以将其写到一个统一的Pipeline中也可以分开两个Pipeline来写。

　　下图是我的一个API的部署构建任务，其中会经历中台微服务的部署及BFF服务的部署，当然也可以部署至多个服务器：

　　这里说一下，由于我目前并没有采用任何的容器编排工具，所以这里的发布就只是单纯的将release文件覆盖之后然后将docker暂停和重启。这样做的缺点是没有充分利用镜像的优点，无法实现版本的有效管理（比如回退）。

四、RobotFramework AT流程部分

　　对于一个产品来说，质量很重要，而保证质量的辅助手段就是充分的回归测试。自动化接口测试使得回归测试成为可以频繁触发，也就能及时发现提交的代码对已有接口功能的影响。我们的AT是根据重要的业务场景来写的，而且我们也觉得AT应该写在那些主要业务流程的接口上面，才能显示出它的价值，而且AT的编写也是不小的工作量。

　　我们使用的是RobotFramework，开发语言是Python。在开发人员提交代码并发布到开发联调环境时，便会自动触发AT环境的部署，部署无误后就会触发AT任务的执行，AT执行无误后才会自动Merge dev分支的代码至稳定的测试分支，之后测试再选择是否发布最新的更改至测试环境进行验证bug fix。

　　下图是基于RF的AT构建任务的执行结果：