基于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

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

原文地址:https://www.cnblogs.com/edisonchou/p/edc_ci_practise_introduction.html

时间: 2024-11-05 13:34:41

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

基于Jenkins Pipeline的ASP.NET Core持续集成实践

原文:基于Jenkins Pipeline的ASP.NET Core持续集成实践 最近在公司实践持续集成,使用到了Jenkins的Pipeline来提高团队基于ASP.NET Core API服务的集成与部署,因此这里总结一下. 一.关于持续集成与Jenkins Pipeline 1.1 持续集成相关概念 互联网软件的开发和发布,已经形成了一套标准流程,最重要的组成部分就是持续集成(Continuous integration,简称 CI) . 持续集成指的是,频繁地 (一天多次) 将代码集成到

基于 Jenkins+Docker+Git 的CI流程初探

在如今的互联网时代,随着软件开发复杂度的不断提高,软件开发和发布管理也越来越重要.目前已经形成一套标准的流程,最重要的组成部分就是持续集成(Continuous Integration,CI)及持续部署.交付(CD).在此,我们来以一个案例初步了解 CI 流程.那么什么是 CI 呢?简单来讲,CI 就是将传统的代码合并.构建.部署.测试都集成在一起,不断地执行这个过程,并对结果进行反馈. CI 流程设计图: 工作流程: 1. 开发人员提交代码到Git版本仓库:2. Jenkins人工/定时触发项

React16组件化+测试+全流程 实战“在线账本”项目

第1章 课程介绍介绍了整个课程的背景知识,项目简介,学习流程,可以掌握的知识点,以及学习方法和前置知识 第2章 设计稿:从蓝图开始从原型图出发,分析整个应用的需求和功能点,最后规定了文件结构和代码规范. 第3章 首页:庖丁解牛使用 React 理念开发首页的功能,通过组件拆分-展示型组件开发的流程开发所有的展示型组件,并且学习 PropTyps 验证 React组件的属性. 第4章 首页:乐高积木继续 React 理念的开发 ,通过 展示型组件组合 - state和数据流分析 -添加 state

HUDSON(Java开发的一种持续集成工具)

Hudson是Jenkins的前身,是基于Java开发的一种持续集成工具,用于监控程序重复的工作,包括: 1.持续的软件版本发布/测试项目. 2.监控外部调用执行的工作. Hudson的特性 1.易于安装-只要把hudson.war部署到servlet容器,不需要数据库支持. 2.易于配置-所有配置都是通过其提供的web界面实现. 3.集成RSS/E-mail/IM-通过RSS发布构建结果或当构建失败时通过e-mail实时通知. 4.生成JUnit/TestNG测试报告. 5.分布式构建支持-H

Jenkins在Windows系统dotnet平台持续集成

        之前写过一篇文章是在CentOS上构建.net自动化编译环境, 今天这篇是针对于Windows平台的环境.        Jenkins是一个开源软件项目,旨在提供一个开放易用的软件平台,使软件的持续集成变成可能.Jenkins是基于Java开发的一种持续集成工具,用于监控持续重复的工作, Jenkins是由Sun的前员工开发的,它的根基是Java,但也可以用在非Java的项目里,比如PHP.Ruby on Rails..NET.持续集成相关的工具有很多.它提供了Web界面,用户

使用jenkins配置.net mvc网站进行持续集成二

上一篇使用jenkins配置.net mvc网站进行持续集成一只是简单介绍了jenkins构建站点到本地服务器,这一篇,就来讲解如何部署站点到指定的服务器上面. 1.IIS远程发布配置 1.在服务器管理器中安装“管理服务”(若已存在则无须再安装) 1.1 服务器管理----->角色----->web 服务器IIS 1.2 点击右下角 “添加角色服务”,弹出选择“选择角色服务”对话框. 1.3 选中“管理服务” 点击“下一步”----->点击“安装”.安装完成后,重新打开“服务器管理器”在

持续集成实践

持续集成实践(一)- 引子 本系列文章包含: [独孤九剑]持续集成实践(一)- 引子 [独孤九剑]持续集成实践(二)– MSBuild语法入门 [独孤九剑]持续集成实践(三)- Jenkins安装与配置(Jenkins+MSBuild+GitHub) 1.概念描述(了解的话直接跳到第2部分) 1.1.我的理解 持续集成(Continuous Integration),以自动化方式实现“从开发阶段性完毕到部署上线之前”这一阶段的工作.当然也可做到简单部署,复杂的要涉及到持续部署阶段. 1.2.理论

[独孤九剑]持续集成实践(一)- 引子

本系列文章包含: [独孤九剑]持续集成实践(一)- 引子 [独孤九剑]持续集成实践(二)– MSBuild语法入门 [独孤九剑]持续集成实践(三)- Jenkins安装与配置(Jenkins+MSBuild+GitHub) 1.概念描述(了解的话直接跳到第2部分) 1.1.我的理解 持续集成(Continuous Integration),以自动化方式实现“从开发阶段性完毕到部署上线之前”这一阶段的工作.当然也可做到简单部署,复杂的要涉及到持续部署阶段. 1.2.理论层面的描述 下面为摘抄各网站

[独孤九剑]持续集成实践 – MSBuild语法入门

本系列文章包含: [独孤九剑]持续集成实践(一)- 引子 [独孤九剑]持续集成实践(二)– MSBuild语法入门 [独孤九剑]持续集成实践(三)- Jenkins安装与配置(Jenkins+MSBuild+GitHub) 本文是转发“用MSBuild和Jenkins搭建持续集成环境”,由于该文内容十分清晰,我就不再画蛇添足的再写一篇了.只是其中会夹杂一些个人的理解,如果各位看官介意,请移步至原文. 1.开始 在这篇文章中,我们会从头开始,一步步完成一个属于我们自己的MSBuild脚本.在它完成