CN117270886B - 一种微服务系统开发部署方法、设备及介质 - Google Patents

Abstract

本申请实施例公开了一种微服务系统开发部署方法、设备及介质。属于电数字数据处理技术领域。解决了现有技术中手动频繁打包和部署系统，使微服务系统开发部署效率较低的问题。获取提交至TFS库的源码数据；基于源码数据触发预置触发器，以对TFS库的源码数据进行拉取，并基于源码数据构建镜像；在镜像库中拉取带有第一标签的镜像，以启动多个Docker容器进行系统测试，并在测试完成后，对第一标签进行更新，并将带有更新后标签的镜像推送至预置镜像库存储；在预置镜像库中对带有更新后标签的镜像进行拉取，并将拉取的镜像转换为离线镜像压缩包，将离线镜像压缩包导入生产环境以完成微服务系统的部署。

Description

一种微服务系统开发部署方法、设备及介质

技术领域

本申请涉及电数字数据处理技术领域，尤其涉及一种微服务系统开发部署方法、设备及介质。

背景技术

随着互联网的快速发展，业务应用变得越来越复杂，处理的事情越来越多。过去的单体应用程序已无法满足日益增长的业务需求和技术要求，微服务架构系统应运而生，在开发、部署、运维以及发布的流程中发挥了积极有效的作用，显著的提高了应用系统的灵活性和扩展性。

基于SpringCloud框架的微服务系统，随着业务的扩展，版本的迭代，开发、测试和实施人员深深的体会到多个微服务运行带来的技术挑战。由于微服务的数量越来越多，开发人员和测试人员手动频繁的打包和部署系统，使微服务系统开发部署过程效率较低。

发明内容

本申请实施例提供了一种微服务系统开发部署方法、设备及介质，用于解决如下技术问题：基于SpringCloud框架的微服务系统，由于微服务的数量越来越多，开发人员和测试人员手动频繁的打包和部署系统，使微服务系统开发部署过程效率较低。

本申请实施例采用下述技术方案：

本申请实施例提供一种微服务系统开发部署方法。包括，获取提交至TFS（TaobaoFile System）库的源码数据；基于源码数据触发预置触发器，以触发Jenkins对TFS库的源码数据进行拉取，并基于源码数据构建镜像；其中，镜像设置有第一标签；基于预置测试步骤与预置Docker Compose编排工具，在镜像库中拉取带有第一标签的镜像，以启动多个Docker容器进行系统测试，并在测试完成后，对第一标签进行更新，并将带有更新后标签的镜像推送至预置镜像库存储；基于预置Docker Compose编排工具，在预置镜像库中对带有更新后标签的镜像进行拉取，并将拉取的镜像转换为离线镜像压缩包，将离线镜像压缩包导入生产环境以完成微服务系统的部署。

本申请实施例通过源码数据触发预置触发器，以触发Jenkins对TFS库的源码数据进行拉取，从而能够自动构建镜像，无需开发人员频繁进行打包。其次，本申请实施例通过在镜像库中拉取带有第一标签的镜像，以及在测试完成后，对第一标签进行更新，并将带有更新后标签的镜像推送至预置镜像库存储，从而使得系统自动确定出所需镜像，确保镜像拉取的准确性。解决了随着业务的扩展，版本的迭代，开发人员和测试人员手动频繁的打包，以致微服务系统开发效率较慢的问题。

在本申请的一种实现方式中，基于预置测试步骤与预置Docker Compose编排工具，在镜像库中拉取带有第一标签的镜像，以启动多个Docker容器进行系统测试，并在测试完成后，对第一标签进行更新，并将带有更新后标签的镜像推送至预置镜像库存储，具体包括：在程序自测阶段，通过预置Docker Compose编排工具在镜像库中拉取带有第一标签的镜像，以启动多个Docker容器进行系统自测；完成程序自测后，对带有第一标签的镜像设置上第二标签，并将带有第二标签的镜像推送至镜像库进行存储；在程序检测阶段，通过预置Docker Compose编排工具在镜像库中拉取带有第二标签的镜像，以启动多个Docker容器进行系统检测；完成系统检测后，对带有第二标签的镜像设置上第三标签，并将带有第三标签的镜像推送至镜像库进行存储。

在本申请的一种实现方式中，基于源码数据触发预置触发器，以触发Jenkins对TFS库的源码数据进行拉取之前，方法还包括：在Jenkins中配置微服务TFS库的源码信息；其中，源码信息包括源码地址、源码连接信息以及源码分支中的一项或多项；对TFS库对应的触发器进行配置与操作信息设置；其中，触发器的配置包括触发事件配置与筛选器的配置，筛选器的配置包括存储库设置、源码分支设置以及触发成员设置；操作信息配置包括操作类型配置、Jenkins地址配置、Jenkins登录信息配置以及Jenkins定义的构建对象配置。

在本申请的一种实现方式中，基于源码数据构建镜像，具体包括：基于SpringCloud框架的微服务系统，通过Maven打包插件spring-boot-maven-plugin进行打包；创建run.sh脚本微服务启动文件；创建微服务镜像Dockerfile构建文件。

在本申请的一种实现方式中，基于源码数据构建镜像之后，方法还包括：获取镜像对应的镜像信息；其中，镜像信息包括镜像名称与镜像信息对应的源码数据；将镜像名称与历史镜像信息列表进行比对，在历史镜像信息列表中不存在镜像名称的情况下，将镜像信息添加至历史镜像信息列表；在历史镜像信息列表中存在镜像名称的情况下，基于镜像信息的构建时间，对镜像信息进行相应处理；其中，相应处理包括删除处理与关联处理。

在本申请的一种实现方式中，基于镜像信息的构建时间，对镜像信息进行相应处理，具体包括：在历史镜像信息列表中存在镜像名称的情况下，将历史镜像信息列表中的历史镜像信息对应的源码数据与当前镜像信息对应的源码数据进行比对；若比对结果一致，则将当前镜像信息进行删除处理；若比对结果不一致，则按照镜像信息的构建时间，将名称相同的多个镜像信息进行关联处理。

在本申请的一种实现方式中，获取提交至TFS库的源码数据之后，方法还包括：基于源码数据生成当前源码配置文件；基于源码数据的源码信息，在TFS库中确定出历史源码配置文件；基于当前源码配置文件的生成时间，以及历史源码配置文件对应的生成时间，构建源码信息对应的配置文件时间节点表；其中，配置文件时间节点表中包括，不同生成时间的源码配置文件分别对应的存储地址链接。

在本申请的一种实现方式中，在测试完成后，对第一标签进行更新之后，方法还包括：在测试不通过的情况下，确定出进行测试的镜像所对应的镜像标签；将测试结果与镜像标签发送至相应的开发人员，以通过镜像标签确定出未通过的测试步骤。

本申请实施例提供一种微服务系统开发部署设备，包括：至少一个处理器；以及，与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够：获取提交至TFS库的源码数据；基于源码数据触发预置触发器，以触发Jenkins对TFS库的源码数据进行拉取，并基于源码数据构建镜像；其中，镜像设置有第一标签；基于预置测试步骤与预置Docker Compose编排工具，在镜像库中拉取带有第一标签的镜像，以启动多个Docker容器进行系统测试，并在测试完成后，对第一标签进行更新，并将带有更新后标签的镜像推送至预置镜像库存储；基于预置Docker Compose编排工具，在预置镜像库中对带有更新后标签的镜像进行拉取，并将拉取的镜像转换为离线镜像压缩包，将离线镜像压缩包导入生产环境以完成微服务系统的部署。

本申请实施例提供的一种非易失性计算机存储介质，存储有计算机可执行指令，计算机可执行指令设置为：获取提交至TFS库的源码数据；基于源码数据触发预置触发器，以触发Jenkins对TFS库的源码数据进行拉取，并基于源码数据构建镜像；其中，镜像设置有第一标签；基于预置测试步骤与预置Docker Compose编排工具，在镜像库中拉取带有第一标签的镜像，以启动多个Docker容器进行系统测试，并在测试完成后，对第一标签进行更新，并将带有更新后标签的镜像推送至预置镜像库存储；基于预置Docker Compose编排工具，在预置镜像库中对带有更新后标签的镜像进行拉取，并将拉取的镜像转换为离线镜像压缩包，将离线镜像压缩包导入生产环境以完成微服务系统的部署。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：本申请实施例通过源码数据触发预置触发器，以触发Jenkins对TFS库的源码数据进行拉取，从而能够自动构建镜像，无需开发人员频繁进行打包。其次，本申请实施例通过在镜像库中拉取带有第一标签的镜像，以及在测试完成后，对第一标签进行更新，并将带有更新后标签的镜像推送至预置镜像库存储，从而使得系统自动确定出所需镜像，确保镜像拉取的准确性。解决了随着业务的扩展，版本的迭代，开发人员和测试人员手动频繁的打包，以致微服务系统开发效率较慢的问题。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1为本申请实施例提供的一种微服务系统架构图；

图2为本申请实施例提供的一种微服务系统开发部署方法流程图；

图3为本申请实施例提供的一种Jenkins构建镜像第一示意图；

图4为本申请实施例提供的一种Jenkins构建镜像第二示意图；

图5为本申请实施例提供的一种自动化开发部署图；

图6为本申请实施例提供的一种微服务系统开发部署设备的结构示意图。

附图标记：

200微服务系统开发部署设备，201处理器，202存储器。

具体实施方式

本申请实施例提供一种微服务系统开发部署方法、设备及介质。

为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本说明书实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

下面通过附图对本申请实施例提出的技术方案进行详细的说明。

图1为本申请实施例提供的一种微服务系统架构图。如图1所示，基于SpringCloud框架的微服务系统包含：路由网关服务Gateway，安全认证服务Security，业务应用服务MES、库存管理服务WMS以及物流执行服务LES等。前端服务Nginx，分布式日志服务PlumeLog，分布式事务服务Seata，以及依赖的配置中心服务Nacos，数据缓存服务Redis等，每个服务放在一个Docker容器中运行。

图2为本申请实施例提供的一种微服务系统开发部署方法流程图。如图1所示，微服务系统开发部署方法包括如下步骤：

步骤101、获取提交至TFS库的源码数据。

在本申请的一个实施例中，基于源码数据生成当前源码配置文件。基于源码数据的源码信息，在TFS库中确定出历史源码配置文件。基于当前源码配置文件的生成时间，以及历史源码配置文件对应的生成时间，构建源码信息对应的配置文件时间节点表。其中，配置文件时间节点表中包括，不同生成时间的源码配置文件分别对应的存储地址链接。

具体地，开发人员对源码进行开发，并将其提交至TFS库f_dev分支。此时，根据TFS库中收到的当前源码数据生成当前源码配置文件。且，TFS库中将之前生成的源码配置文件均进行存储，以建立历史源码配置文件。将当前源码配置文件与历史源码配置文件进行比对，确定出具有相同源码信息的历史源码配置文件，其中，源码信息至少包括源码地址、源码连接信息以及源码分支中的一项。

进一步地，基于各配置文件生成的时间，将当前源码配置文件，以及与当前源码配置文件具有相同源码信息的历史源码配置文件进行排列，以根据排列顺序构建该源码信息对应的配置文件时间节点表。其中，该配置文件时间节点表中包括有按顺序排列的源码配置文件的存储地址链接，从而在对相同源码信息对应的多个源码配置文件进行查询时，直接在该配置文件时间节点表中进行查询即可，且通过该配置文件时间节点表也能快速获取不同版本的源码数据，从而对源码问题快速进行解决。

步骤102、基于源码数据触发预置触发器，以触发Jenkins对TFS库的源码数据进行拉取，并基于源码数据构建镜像。

在本申请的一个实施例中，基于Spring Cloud框架的微服务系统，通过Maven打包插件spring-boot-maven-plugin进行打包。创建run.sh脚本微服务启动文件，创建微服务镜像Dockerfile构建文件。

具体地，开发人员编写修改源码，提交到TFS库f_dev分支。基于Spring Cloud框架的微服务系统，例如以gateway后端微服务为例，采用Maven打包插件spring-boot-maven-plugin进行打包。创建一个run.sh脚本微服务启动文件，创建一个微服务镜像Dockerfile构建文件。

进一步地，Jenkins配置微服务的TFS库的源码地址及相关信息，Jenkins构建完镜像，自动推送于私有Harbor仓库存储。

在本申请的一个实施例中，在Jenkins中配置微服务TFS库的源码信息；其中，源码信息至少包括源码地址、源码连接信息以及源码分支中的一项。对TFS库对应的预置触发器进行配置与操作信息设置，其中，预置触发器的配置包括触发事件配置与筛选器的配置，筛选器的配置包括存储库设置、源码分支设置以及触发成员设置。操作信息配置包括操作类型配置、Jenkins地址配置、Jenkins登录信息配置以及Jenkins定义的构建对象配置。

具体地，以gateway后端微服务为例，触发器设置完后，开发人员提交源码到TFS库，自动触发触发器，触发Jenkins拉取源码，进而自动构建成dev标签镜像。其中，在对源码管理中，需要对源码地址、源码连接信息以及源码分支进行设置。在编辑服务挂钩订阅中，包括对预置触发器的设置与操作信息的设置，即，需要选择要触发的事件并配置所有筛选器，以及选择并配置要执行的操作。

图3为本申请实施例提供的一种Jenkins构建镜像第一示意图。如图3所示，在对触发器的配置中，需要选择该类型事件的触发器，以及对筛选器进行配置。即，触发器触发类型事件为源码修改提交触发，筛选器配置包括源码配置、源码分支配置以及触发人配置。

图4为本申请实施例提供的一种Jenkins构建镜像第二示意图。如图4所示，对操作信息的配置包括有操作类型配置、Jenkins地址配置、Jenkins登录信息配置以及Jenkins定义的构建对象配置等多种配置选项。

在本申请的一个实施例中，获取镜像对应的镜像信息；其中，镜像信息包括镜像名称与镜像信息对应的源码数据。将镜像名称与历史镜像信息列表进行比对，在历史镜像信息列表中不存在镜像名称的情况下，将镜像信息添加至历史镜像信息列表。在历史镜像信息列表中存在镜像名称的情况下，基于镜像信息的构建时间，对镜像信息进行相应处理；其中，相应处理包括删除处理与关联处理。

具体地，本申请实施例将源码提交源码到TFS库，自动触发Jenkins拉取源码构建镜像后，会对构建的镜像进行检测。首先获取镜像对应的镜像信息，例如，获取的镜像信息可以为镜像名称与镜像信息对应的源码数据。本申请实施例基于生成的镜像会进行存储，并建立历史镜像信息列表，该历史镜像信息列表中包括有多个历史镜像名称，以及多个历史镜像信息对应的生成时间。其次，将当前生成的镜像名称与历史镜像信息列表进行比对，若历史镜像信息列表中不存在当前镜像名称的情况下，将当前生成的镜像名称添加至该历史镜像信息列表，并对当前镜像进行存储。

在本申请的一个实施例中，在历史镜像信息列表中存在镜像名称的情况下，将历史镜像信息列表中的历史镜像信息对应的源码数据与当前镜像信息对应的源码数据进行比对。若比对结果一致，则将当前镜像信息进行删除处理。若比对结果不一致，则按照镜像信息的构建时间，将名称相同的多个镜像信息进行关联处理。

具体地，若历史镜像信息列表中存在当前镜像名称，则在TFS库中查找出相同名称的镜像名称所对应的源码数据，将当前镜像名称对应的源码数据与在TFS库中查找出的源码数据进行比对，若比对结果一致，则当前生成的镜像为重复生成，此时将当前生成的镜像进行删除处理。若比对结果不一致，则当前生成的镜像为修改源码数据生成的镜像，此时，将查找出的相同名称的历史镜像与当前镜像进行关联处理，从而可以通过一个镜像信息快速查找出相同名称的多个镜像信息，提高查找效率。

步骤103、基于预置测试步骤与预置Docker Compose编排工具，在镜像库中拉取带有第一标签的镜像，以启动多个Docker容器进行系统测试，并在测试完成后，对第一标签进行更新，并将带有更新后标签的镜像推送至预置镜像库存储。

在本申请的一个实施例中，在程序自测阶段，通过预置Docker Compose编排工具在镜像库中拉取带有第一标签的镜像，以启动多个Docker容器进行系统自测。完成程序自测后，对带有第一标签的镜像设置上第二标签，并将带有第二标签的镜像推送至镜像库进行存储。在程序检测阶段，通过预置Docker Compose编排工具在镜像库中拉取带有第二标签的镜像，以启动多个Docker容器进行系统检测。完成系统检测后，对带有第二标签的镜像设置上第三标签，并将带有第三标签的镜像推送至镜像库进行存储。

具体地，触发器设置完后，将源码提交至到TFS库，自动触发触发器，触发Jenkins拉取源码，进而自动构建成带有第一标签的镜像，即带有dev标签镜像。在程序自测阶段，通过Docker Compose编排工具从镜像库中拉取dev标签镜像，实现对多容器管理，完成程序自测后，将第一标签更新为第二标签，即更新为test标签镜像，并将其推送至私有Harbor仓库存储。在程序检测阶段，通过Docker Compose编排工具从镜像库中拉取test标签镜像，实现对多容器管理，完成系统专业测试后，将第二标签更新为第三标签，即更新为release标签镜像，并将其推送至私有Harbor仓库存储。

在本申请的一个实施例中，在测试不通过的情况下，确定出进行测试的镜像所对应的镜像标签。将测试结果与所述镜像标签发送至相应的开发人员，以通过所述镜像标签确定出未通过的测试步骤。

具体地，若在自测阶段显示测试不通过，则将第一标签，即dev标签发送至相应的开发人员，若在程序检测阶段显示测试不通过，则将第二标签，即test标签发送至相应的开发人员。开发人员可以通过接收到的标签确定出测试不通过的阶段，从而有针对性的对源码数据进行更改。

步骤104、基于预置Docker Compose编排工具，在预置镜像库中带有更新后标签的镜像进行拉取，并将拉取的镜像转换为离线镜像压缩包，将离线镜像压缩包导入生产环境以完成微服务系统的部署。

在本申请的一个实施例中，测试通过后，通过预置Docker Compose编排工具从镜像库中拉取测试完成的带有第三标签的镜像，即，带有release标签镜像，并打成离线镜像压缩包，并把离线镜像压缩包导入生产环境，完成微服务系统部署和发布。

图5为本申请实施例提供的一种自动化开发部署图。如图5所示，开发人员进行源码开发，并将开发后的源码提交至TFS库进行源码存储。此时，触发预置触发器，触发Jenkins对TFS库的源码数据进行拉取，并基于源码数据构建镜像，并将构建的镜像打上dev标签，推送至Harbor仓库存储。进入开发人员程序自测阶段，在镜像库中拉取带有dev标签的镜像，若测试通过，则将dev标签更改为test标签，并推送至Harbor仓库存储，若测试不通过，则对开发人员发送dev标签以及测试不通过通知。进入测试人员专业测试后，在镜像库中拉取带有test标签的镜像，若测试通过，则将test标签更改为release标签，并推送至Harbor仓库存储，若测试不通过，则对开发人员发送test标签以及测试不通过通知。全部测试通过后，从镜像库中拉取集成测试完的release标签镜像，并打成离线镜像压缩包，并把离线镜像压缩包导入生产环境，完成微服务系统部署和发布。

图6为本申请实施例提供的一种微服务系统开发部署设备的结构示意图。如图6所示，微服务系统开发部署设备200，包括：至少一个处理器201；以及，与至少一个处理器201通信连接的存储器202；其中，存储器202存储有可被至少一个处理器201执行的指令，指令被至少一个处理器201执行，以使至少一个处理器201能够：获取提交至TFS库的源码数据；基于源码数据触发预置触发器，以触发Jenkins对TFS库的源码数据进行拉取，并基于源码数据构建镜像；其中，镜像设置有第一标签；基于预置测试步骤与预置Docker Compose编排工具，在镜像库中拉取带有第一标签的镜像，以启动多个Docker容器进行系统测试，并在测试完成后，对第一标签进行更新，并将带有更新后标签的镜像推送至预置镜像库存储；基于预置Docker Compose编排工具，在预置镜像库中对带有更新后标签的镜像进行拉取，并将拉取的镜像转换为离线镜像压缩包，将离线镜像压缩包导入生产环境以完成微服务系统的部署。

本申请实施例还提供一种非易失性计算机存储介质，存储有计算机可执行指令，计算机可执行指令设置为：获取提交至TFS库的源码数据；基于源码数据触发预置触发器，以触发Jenkins对TFS库的源码数据进行拉取，并基于源码数据构建镜像；其中，镜像设置有第一标签；基于预置测试步骤与预置Docker Compose编排工具，在镜像库中拉取带有第一标签的镜像，以启动多个Docker容器进行系统测试，并在测试完成后，对第一标签进行更新，并将带有更新后标签的镜像推送至预置镜像库存储；基于预置Docker Compose编排工具，在预置镜像库中对带有更新后标签的镜像进行拉取，并将拉取的镜像转换为离线镜像压缩包，将离线镜像压缩包导入生产环境以完成微服务系统的部署。

本申请中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、设备、非易失性计算机存储介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请的实施例可以有各种更改和变化。而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (9)

1.一种微服务系统开发部署方法，其特征在于，所述方法包括：

获取提交至TFS库的源码数据；

基于所述源码数据触发预置触发器，以触发Jenkins对所述TFS库的源码数据进行拉取，并基于所述源码数据构建镜像；其中，所述镜像设置有第一标签；

基于预置测试步骤与预置Docker Compose编排工具，在镜像库中拉取带有所述第一标签的镜像，以启动多个Docker容器进行系统测试，并在测试完成后，对所述第一标签进行更新，并将带有更新后标签的镜像推送至预置镜像库存储；

基于所述预置Docker Compose编排工具，在所述预置镜像库中对带有所述更新后标签的镜像进行拉取，并将拉取的镜像转换为离线镜像压缩包，将所述离线镜像压缩包导入生产环境以完成微服务系统的部署；

所述基于预置测试步骤与预置Docker Compose编排工具，在镜像库中拉取带有所述第一标签的镜像，以启动多个Docker容器进行系统测试，并在测试完成后，对所述第一标签进行更新，并将带有更新后标签的镜像推送至预置镜像库存储，具体包括：

在程序自测阶段，通过所述预置Docker Compose编排工具在镜像库中拉取带有所述第一标签的镜像，以启动多个Docker容器进行系统自测；

完成程序自测后，对带有所述第一标签的镜像设置上第二标签，并将带有第二标签的镜像推送至镜像库进行存储；

在程序检测阶段，通过所述预置Docker Compose编排工具在所述镜像库中拉取带有所述第二标签的镜像，以启动多个Docker容器进行系统检测；

完成系统检测后，对带有所述第二标签的镜像设置上第三标签，并将带有所述第三标签的镜像推送至所述镜像库进行存储。

2.根据权利要求1所述的一种微服务系统开发部署方法，其特征在于，所述基于所述源码数据触发预置触发器，以触发Jenkins对所述TFS库的源码数据进行拉取之前，所述方法还包括：

在所述Jenkins中配置微服务TFS库的源码信息；其中，所述源码信息至少包括源码地址、源码连接信息以及源码分支中的一项；

对所述TFS库对应的预置触发器进行配置与操作信息设置；

其中，预置触发器的配置包括触发事件配置与筛选器的配置，所述筛选器的配置包括存储库设置、源码分支设置以及触发成员设置；

所述操作信息配置包括操作类型配置、Jenkins地址配置、Jenkins登录信息配置以及Jenkins定义的构建对象配置。

3.根据权利要求1所述的一种微服务系统开发部署方法，其特征在于，所述基于所述源码数据构建镜像，具体包括：

基于Spring Cloud框架的微服务系统，通过Maven打包插件spring-boot-maven-plugin进行打包；

创建run.sh脚本微服务启动文件；

创建微服务镜像Dockerfile构建文件。

4.根据权利要求1所述的一种微服务系统开发部署方法，其特征在于，所述基于所述源码数据构建镜像之后，所述方法还包括：

获取所述镜像对应的镜像信息；其中，所述镜像信息包括镜像名称与所述镜像信息对应的源码数据；

将所述镜像名称与历史镜像信息列表进行比对，在所述历史镜像信息列表中不存在所述镜像名称的情况下，将所述镜像信息添加至所述历史镜像信息列表；

在所述历史镜像信息列表中存在所述镜像名称的情况下，基于镜像信息的构建时间，对所述镜像信息进行相应处理；其中，所述相应处理包括删除处理与关联处理。

5.根据权利要求4所述的一种微服务系统开发部署方法，其特征在于，所述基于镜像信息的构建时间，对所述镜像信息进行相应处理，具体包括：

在所述历史镜像信息列表中存在所述镜像名称的情况下，将所述历史镜像信息列表中的历史镜像信息对应的源码数据，与当前镜像信息对应的源码数据进行比对；

若比对结果一致，则将当前镜像信息进行删除处理；

若比对结果不一致，则按照镜像信息的构建时间，将名称相同的多个镜像信息进行关联处理。

6.根据权利要求1所述的一种微服务系统开发部署方法，其特征在于，所述获取提交至TFS库的源码数据之后，所述方法还包括：

基于所述源码数据生成当前源码配置文件；

基于所述源码数据的源码信息，在所述TFS库中确定出历史源码配置文件；

基于所述当前源码配置文件的生成时间，以及历史源码配置文件对应的生成时间，构建所述源码信息对应的配置文件时间节点表；

其中，所述配置文件时间节点表中包括，不同生成时间的源码配置文件分别对应的存储地址链接。

7.根据权利要求1所述的一种微服务系统开发部署方法，其特征在于，所述在测试完成后，对所述第一标签进行更新之后，所述方法还包括：

在测试不通过的情况下，确定出进行测试的镜像所对应的镜像标签；

将测试结果与所述镜像标签发送至相应的开发人员，以通过所述镜像标签确定出未通过的测试步骤。

8.一种微服务系统开发部署设备，其特征在于，该设备包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发该设备执行权利要求1-7中的任一项所述的方法。

9.一种非易失性计算机存储介质，存储有计算机可执行指令，其特征在于，所述计算机可执行指令能够执行权利要求1-7任一项所述的方法。