基于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构建任务的执行结果：

　　下图是该任务的具体的输出信息，我们可以看到每个用例的执行情况：

　　由于我目前对这块了解不多，后续有机会了解多点后可以介绍一点我们在AT方面的实践和规范。

五、小结

　　本文介绍了我目前团队所在使用的持续集成全流程及一些重要插件的使用，虽然还很不完善，但初步解决了我所在团队在集成和发布上的一些痛点。随着后续对K8S的学习的深入，我会逐步引入K8S进行微服务的容器编排以及持续集成的K8S化改造，希望到时再进行分享。

作者：周旭龙

出处：https://edisonchou.cnblogs.com

本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文链接。