CN117707600A - 一种应用发布方法、装置、电子设备及存储介质 - Google Patents

Abstract

本发明提供了一种应用发布方法、装置、电子设备及存储介质，响应于应用发布请求，确定待发布的目标应用服务之后，从代码仓库中获取目标应用服务对应的目标代码，调用预设代码检测工具对目标代码进行代码规范检查，检查通过之后对目标代码打包得到目标软件包。通过查询配置管理数据库，确定目标应用服务在测试环境中对应的多个第一应用服务器，将目标软件包分别部署在多个第一应用服务器，以对目标应用服务进行测试。响应于对目标应用服务测试通过，查询配置管理数据库，确定目标应用服务在目标环境中的多个第二应用服务器，从而将目标软件包分别部署在多个第二应用服务器，实现自动化应用发布，避免人工操作导致的错误，提高了应用发布效率。

Description

一种应用发布方法、装置、电子设备及存储介质

技术领域

本发明涉及计算机技术领域，更具体的，涉及一种应用发布方法、装置、电子设备及存储介质。

背景技术

从软件开发结束到应用发布涉及多个步骤，如检查代码规范、代码打包、将软件包部署到测试环境中的应用服务器、在测试环境执行功能测试、测试通过将软件包部署到预发布环境或生产环境等。

目前，一般通过人工手动执行应用发布的各个步骤，流程繁琐很容易出错。若待部署的应用服务器数量较多，对大量应用服务器进行手动部署效率低下，延长了应用发布时间。

发明内容

有鉴于此，本发明提供了一种应用发布方法、装置、电子设备及存储介质，实现自动化应用发布，避免人工操作导致的错误，提高了应用发布效率。

为了实现上述发明目的，本发明提供的具体技术方案如下：

第一方面，本发明实施例提供了一种应用发布方法，包括：

响应于应用发布请求，确定待发布的目标应用服务；

从代码仓库中获取所述目标应用服务对应的目标代码；

调用预设代码检测工具对所述目标代码进行代码规范检查，并获取检查结果；

若所述检查结果表示所述目标代码达到预设标准，对所述目标代码进行打包，得到目标软件包；

查询配置管理数据库，确定所述目标应用服务在测试环境中对应的多个第一应用服务器；

将所述目标软件包分别部署在所述多个第一应用服务器，以对所述目标应用服务进行测试；

响应于对所述目标应用服务测试通过，查询所述配置管理数据库，确定所述目标应用服务在目标环境中对应的多个第二应用服务器，所述目标环境为预发布环境或生产环境；

将所述目标软件包分别部署在所述多个第二应用服务器。

在一些实施例中，在得到目标软件包之后，还包括：

将所述目标软件包上传到Maven仓库中。

在一些实施例中，在所述目标应用服务发布之前，还包括：

将所述目标应用服务的开发信息和发布信息录入所述配置管理数据库；

所述开发信息至少包括所述目标应用服务所在的项目和所述目标应用服务的开发团队，所述发布信息至少包括所述目标应用服务在所述测试环境对应的第一Nginx服务器信息和所述多个第一应用服务器信息、所述目标应用服务在所述目标环境中对应的第二Nginx服务器信息和所述多个第二应用服务器信息。

在一些实施例中，所述查询配置管理数据库，确定所述目标应用服务在测试环境中对应的多个第一应用服务器，包括：

以所述目标应用服务所在的项目和所述目标应用服务作为查询条件，在所述配置管理数据库中查询所述目标应用服务在所述测试环境中对应的所述第一Nginx服务器和所述多个第一应用服务器。

在一些实施例中，所述将所述目标软件包分别部署在所述多个第一应用服务器，包括：

分别控制所述多个第一应用服务器获取所述目标软件包；

在所述第一Nginx服务器的负载均衡配置信息中删除所述多个第一应用服务器的IP地址；

分别控制所述多个第一应用服务器安装所述目标软件包，并在安装完成后启动所述目标应用服务；

将所述多个第一应用服务器的IP地址添加到所述第一Nginx服务器的负载均衡配置信息中，以使所述目标应用服务对外提供服务。

在一些实施例中，所述查询所述配置管理数据库，确定所述目标应用服务在目标环境中对应的多个第二应用服务器，包括：

根据预先配置的应用发布工作流，确定对所述目标应用服务测试通过之后发布所述目标应用服务的所述目标环境；

以所述目标应用服务所在的项目和所述目标应用服务作为查询条件，在所述配置管理数据库中查询所述目标应用服务在所述目标环境中对应的所述第二Nginx服务器和所述多个第二应用服务器。

在一些实施例中，若所述目标环境为预发布环境，在将所述目标软件包分别部署在所述多个第二应用服务器之后，还包括：

对所述目标应用服务进行预发布测试；

响应于对所述目标应用服务预发布测试通过，查询所述配置管理数据库，确定所述目标应用服务在生产环境中对应的第三Nginx服务器和多个第三应用服务器；

分别控制所述多个第三应用服务器获取所述目标软件包；

在所述第三Nginx服务器的负载均衡配置信息中删除所述多个第三应用服务器的IP地址；

分别控制所述多个第三应用服务器安装所述目标软件包，并在安装完成后启动所述目标应用服务；

将所述多个第三应用服务器的IP地址添加到所述第三Nginx服务器的负载均衡配置信息中，以使所述目标应用服务对外提供服务。

第二方面，本发明实施例提供了一种应用发布装置，包括：

应用确定单元，用于响应于应用发布请求，确定待发布的目标应用服务；

代码获取单元，用于从代码仓库中获取所述目标应用服务对应的目标代码；

代码检查单元，用于调用预设代码检测工具对所述目标代码进行代码规范检查，并获取检查结果；

代码打包单元，用于若所述检查结果表示所述目标代码达到预设标准，对所述目标代码进行打包，得到目标软件包；

第一查询单元，用于查询配置管理数据库，确定所述目标应用服务在测试环境中对应的多个第一应用服务器；

第一部署单元，用于将所述目标软件包分别部署在所述多个第一应用服务器，以对所述目标应用服务进行测试；

第二查询单元，用于响应于对所述目标应用服务测试通过，查询所述配置管理数据库，确定所述目标应用服务在目标环境中对应的多个第二应用服务器，所述目标环境为预发布环境或生产环境；

第二部署单元，用于将所述目标软件包分别部署在所述多个第二应用服务器。

第三方面，本发明实施例提供了一种电子设备，所述电子设备包括处理器以及存储器；

所述存储器用于存储程序代码，并将所述程序代码传输给所述处理器；

所述处理器用于根据所述程序代码中的指令执行如第一方面中任意一种实现方式描述的一种应用发布方法。

第四方面，本发明实施例提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如第一方面中任意一种实现方式描述的一种应用发布方法。

相对于现有技术，本发明的有益效果如下：

本发明公开的一种应用发布方法、装置、电子设备及存储介质，技术人员完成代码后需要将代码提交到代码仓库，实现对不同应用服务代码的统一管理，并通过配置管理数据库对不同应用服务的相关信息进行统一管理。响应于应用发布请求，确定待发布的目标应用服务之后，自动从代码仓库中获取目标应用服务对应的目标代码，调用预设代码检测工具对目标代码进行代码规范检查以实现自动检查代码规范。若扫描结果表示目标代码达到预设标准，对目标代码打包得到目标软件包。然后通过查询配置管理数据库，确定目标应用服务在测试环境中对应的多个第一应用服务器，将目标软件包分别部署在多个第一应用服务器，以对目标应用服务进行测试。响应于对目标应用服务测试通过，查询配置管理数据库，确定目标应用服务在目标环境中的多个第二应用服务器，从而将目标软件包分别部署在多个第二应用服务器，实现自动化应用发布，避免人工操作导致的错误，提高了应用发布效率。

附图说明

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

图1为本发明实施例公开的一种应用发布方法的流程示意图；

图2为本发明实施例公开的一种应用发布装置的结构示意图。

具体实施方式

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

为了更清楚地阐明本申请技术方案，下面对本申请涉及的相关概念进行解释。

(1)DevOps(Development Operations)是一组过程、方法与系统的统称，用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。它是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

(2)Jenkins是一个开源软件项目，是基于Java开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件项目可以进行持续集成。

(3)Vue是一款用于构建用户界面的JavaScript框架。它基于标准HTML、CSS和JavaScript构建，并提供了一套声明式的、组件化的编程模型，帮助开发者高效地开发用户界面。

(4)Spring Boot是由Pivotal团队提供的全新框架，其设计目的是用来简化新Spring应用的初始搭建以及开发过程。该框架使用了特定的方式来进行配置，从而使开发人员不再需要定义样板化的配置。通过这种方式，Spring Boot致力于在蓬勃发展的快速应用开发领域(rapid application development)成为领导者。

(5)Element UI是由饿了么前端团队推出的基于Vue封装的UI组件库。

(6)vue-element-admin是一个后台前端解决方案，它基于Vue和Element UI实现。

发明人经过研究发现：当前在应用发布的流程中存在如下痛点：

1)人工操作容易出错，同时有安全隐患。

各个技术团队的项目在代码编译打包、部署的方式上比较落后，很多项目都是写一个Shell脚本，然后把脚本放在各个服务器上，部署的时候由技术人员登录到每个服务器上去执行脚本，甚至有的项目连Shell脚本都没有，完全通过手工在本地开发电脑上打包，然后把软件包上传到服务器上执行命令启动，整个过程费时费力，也很容易出错。

2)代码质量不高。

低质量的代码会导致Bug的增加，降低系统的稳定性，同时低质量的代码通常可读性也很差，不易维护，所以会提高后续开发的难度，降低开发效率。

3)测试资源不足，测试不充分。

对于一些公司有上百个应用服务，每周都有服务要发布上线，经常有七八个服务同时发版，而测试人员只有几个人，想测试得排队，而且只能勉强把当前上线的新功能测试完，这样会导致测试不够充分，很多BUG都带到了生产环境，而生产环境的Bug要想修复，成本是很高的。

4)发布流程混乱、不规范。

目前发布规范没有约束力，比如规范要求代码要先经过测试后，才能发布到生产环境，但仍然存在代码未在测试环境进行测试就直接发布到生产环境的情况，从而引发了故障。

针对以上技术痛点，目前有一种解决方案是通过开源持续集成工具Jenkins来进行软件项目的发布管理，Jenkins可以为每个项目构建一个任务，在任务中通过一系列的工具插件和自定义的配置和脚本，来实现自动化的代码编译、打包、部署、也可以实现自动化的代码扫描以及接口测试。但是，针对项目特别多、服务也特别多的情况，每个服务都要创建一个Jenkins的任务，且每个任务的配置和流程也都是一样的，如果后续我们想对项目发布流水线做任何调整，需要改上百个任务。另外，与项目相关的基本信息，比如项目的代码仓库地址，秘钥，项目部署的服务器IP端口，部署成功后通知邮件的收件人等等，分散在各个任务的配置里，不便于统一维护管理。这些问题在项目比较少的时候还不是很明显，但在维护的项目特别多的情况下就衍生了上述运维成本高的问题，所以用Jenkins来管理项目发布并不适合。

为了解决上述技术问题，本发明提供的一种应用发布方法、装置、电子设备及存储介质，技术人员完成代码后需要将代码提交到代码仓库，实现对不同应用服务代码的统一管理，并通过配置管理数据库对不同应用服务的相关信息进行统一管理。在此基础上，响应于应用发布请求，构建一条项目发布流水线来实现自动化的从代码仓库获取代码、代码规范检查、代码打包、软件包部署以及自动化测试，在测试通过再自动发布到目标环境，实现自动化应用发布，避免人工操作导致的错误，提高了应用发布效率。

本发明提供的一种应用发布方法可以通过计算机程序来实现，如通过安装在电子设备中的应用程序来实现，电子设备可以是服务器或服务器集群。

示例性的，本发明提供的一种应用发布方法采用DevOps平台，平台采用前后端分离的架构，前端采用了基于Vue和Element UI的框架vue-element-admin，后端基于Java语言，选择的框架是Spring boot。DevOps平台打通开发和运维，将应用发布涉及的各个环节所对应的工具和系统组合起来，进行有效运转，规范应用发布流程，提高部署效率，降低人工出错的概率，提高代码质量，也能降低测试人力成本。

请参阅图1，本实施例公开的一种应用发布方法，具体包括以下步骤：

S101：响应于应用发布请求，确定待发布的目标应用服务；

用户可以通过可视化界面输入目标应用服务，发起应用发布请求。

示例性的，用户通过可视化界面输入标题，通过下拉列表选择项目、发布类型、服务信息，然后通过点击可视化界面中的确认发起应用发布请求。其中，标题用于用管理员或上级审核人员可读的形式表示本次发布的应用服务，即目标应用服务；项目为目标应用服务所在的项目；发布类型包括上线申请等类型；服务信息包括服务名称、服务类型、版本号、分支列表。

需要说明的是，服务名称和标题都表示目标应用服务，区别在于标题用管理员或上级审核人员可读的形式表示本次发布的应用服务。如目标应用服务的服务名称为“考勤SaaS对接适配服务”，标题为“生产-考勤适合配服务20231206”，目标应用服务的服务所在的项目为“考勤重构”，发布类型为“上线申请”，服务类型为“后端服务”，版本号为“1.0.133”，分支列表为“release-20231206-notice”。

还需要说明的是，可视化界面之所以能够以下拉列表的形式提供多种项目以及多种项目下的服务，供用户选择目标应用服务的相关信息，是因为用户在目标应用服务发布之前，将目标应用服务的相关信息录入配置管理数据库(Configuration ManagementDatabase,CMDB)，前端调用配置管理数据库，使配置管理数据库存储的目标应用服务的相关信息能够显示在前端可视化界面的下拉列表。

配置管理数据库是一个逻辑数据库，包含了配置项全生命周期的信息以及配置项之间的关系(包括物理关系、实时通信关系、非实时通信关系和依赖关系)。存储与管理企业IT架构中设备的各种配置信息，它与所有服务支持和服务交付流程都紧密相联，支持这些流程的运转、发挥配置信息的价值，同时依赖于相关流程保证数据的准确性。

S102：从代码仓库中获取所述目标应用服务对应的目标代码；

需要说明的是，技术人员在完成目标应用服务对应的目标代码之后，将目标代码提交到代码仓库中。

示例性的，代码仓库可以为GitLab，GitLab是一个用于仓库管理系统的开源项目，使用Git作为代码管理工具，并在此基础上搭建起来的Web服务。

以代码仓库为GitLab为例，根据配置管理数据库中存储的目标应用服务的目标代码对应的代码仓库地址或目标应用所在项目的代码仓库地址，通过GitLab的SDK插件来获取GitLab中目标应用服务对应的目标代码。

S103：调用预设代码检测工具对所述目标代码进行代码规范检查，并获取检查结果；

预设代码检测工具可以为SonarQube、Klocwork、codigger等。

以预设代码检测工具为SonarQube为例，SonarQube是管理代码质量一个开放平台，可以快速的定位代码中潜在的或者明显的错误。在使用时，通过调用SonarQube提供的web api接口，将目标代码发送到SonarQube进行代码规范检查，并获取检查结果。

S104：若所述检查结果表示所述目标代码达到预设标准，对所述目标代码进行打包，得到目标软件包；

示例性的，可以通过人工判断检查结果是否表示目标代码达到预设标准，若检查结果表示目标代码达到预设标准，则人工在可视化界面中确认，触发对目标代码的打包操作；若检查结果表示目标代码未达到预设标准，人工在可视化界面中进行操作，通过邮件、即时通信工具等方式将检查结果反馈给技术人员，以使技术人员对目标代码进行修改，修改之后可以再次发起应用发布请求。

示例性的，通过运行预先生成的检查结果解析脚本，对检查结果进行解析，得到至少一个指标值，通过将指标值与预设标准中的指标阈值进行比较，确定目标代码是否达到预设标准，若检查结果表示目标代码达到预设标准，自动触发对目标代码的打包操作；若检查结果表示目标代码未达到预设标准，自动通过邮件、即时通信工具等方式将检查结果反馈给技术人员，以使技术人员对目标代码进行修改，修改之后可以再次发起应用发布请求。

具体的，可以通过Java的SSH插件来执行Linux的shell命令，来调用Maven工具对目标代码进行打包，得到目标软件包，并通过Maven工具的depoly命令将目标软件包上传到Maven仓库。其中，SSH为安全外壳协议(SecureShell)，是一种加密的网络传输协议，可在不安全的网络中网络服务提供安全的传输环境。

S105：查询配置管理数据库，确定所述目标应用服务在测试环境中对应的多个第一应用服务器；

需要说明的是，在目标应用服务发布之前，将目标应用服务的相关信息，如开发信息和发布信息录入配置管理数据库。

其中：

开发信息至少包括目标应用服务所在的项目和目标应用服务的开发团队，开发团队包括开发目标应用服务的技术人员信息，如工号、姓名、部门、电话、邮箱等，便于S104中若目标代码的检查结果表示目标代码未达到预设标准，利用目标应用服务对应的技术人员信息，自动通过邮件、即时通信工具等方式将检查结果反馈给技术人员。

发布信息至少包括目标应用服务在测试环境对应的第一Nginx服务器和多个第一应用服务器、目标应用服务在目标环境中对应的第二Nginx服务器和多个第二应用服务器，服务器信息包括IP端口，发布信息还可以包括目标应用服务发布成功后邮件通知的收件人邮箱等。

在此基础上，以目标应用服务所在的项目和目标应用服务作为查询条件，在配置管理数据库中查询目标应用服务在测试环境中对应的第一Nginx服务器和多个第一应用服务器。

S106：将所述目标软件包分别部署在所述多个第一应用服务器，以对所述目标应用服务进行测试；

示例性的，基于SSH协议和Ansible运维框架来与各项目的服务器集群通信，实现DevOps平台对各个服务器的统一运维管理，包括免密登录的实现、基础运维的远程控制，不需要人工登录服务器去执行，避免了人工操作失误，降低了人力运维成本，也提高了安全性。对应于本步骤，则通过免密登录多个第一应用服务器，远程控制多个第一应用服务器部署目标软件包，具体的部署过程以下通过具体示例进行介绍，这里不再赘述。

将目标软件包分别部署在多个第一应用服务器之后，即可在测试环境对目标应用服务进行测试，示例性的，通过Java的SSH插件来登录到Jmeter服务器上运行提前编写好的自动化测试脚本来对部署好的第一应用服务器上的目标应用服务进行自动化测试。

Jmeter是Apache组织基于Java开发的压力测试工具，Jmeter服务器用于运行Jmeter。

S107：响应于对所述目标应用服务测试通过，查询所述配置管理数据库，确定所述目标应用服务在目标环境中对应的多个第二应用服务器，所述目标环境为预发布环境或生产环境；

为了避免在代码未在测试环境进行测试就直接发布到生产环境的情况，响应于对目标应用服务测试通过，才能查询配置管理数据库，确定目标应用服务在目标环境中对应的多个第二应用服务器，从而将目标软件包分别部署在多个第二应用服务器。

根据实际应用场景，目标环境可以为预发布环境(MGR)，还可以为生产环境(PROD)，也就是说，目标应用服务在测试环境测试通过之后可以先发布到预发布环境进行测试，测试通过之后再正式发布到生产环境，目标应用服务在测试环境测试通过之后也可以直接正式发布到生产环境。

具体的，以目标应用服务所在的项目和目标应用服务作为查询条件，在配置管理数据库中查询目标应用服务在目标环境中对应的第二Nginx服务器和多个第二应用服务器。

S108：将所述目标软件包分别部署在所述多个第二应用服务器。

需要说明的是，若目标环境为生产环境，将目标软件包分别部署在多个第二应用服务器，若部署成功则目标应用服务发布完成。若目标环境为预发布环境，则将目标软件包分别部署在多个第二应用服务器之后，需要在预发布环境对目标应用服务进行测试，测试成功再将目标应用服务发布到生产环境，若在生产环境发布成功则目标应用服务发布完成。

可以理解的是，整个发布过程按照先测试环境(TEST)、再到预发布环境(MGR)，最后是生产环境(PROD)的顺序，是能保证目标应用服务上线后稳定运行的最佳方式，避免操作人员绕过测试环境，不经测试就发布到生产环境的行为。

优选的，上述应用发布流程可以设置一个或多个需要人工确认的环节，需要人工确认的环节，比如测试团队通过测试，才能继续部署到预发布环境，或者部门负责人确认之后，才能发布到生产，这些人工卡点，可以通过对接工作流平台来实现审批，保障生产运维的规范、安全和稳定。

示例性的，上述S107：响应于对所述目标应用服务测试通过，一种可选的实现方式为：响应于预设审核人员发送的对所述目标应用服务测试通过的确定指令。具体的，预设审核人员在确认目标应用服务测试通过之后，在相应环节的可视化界面中点击确定，发送对目标应用服务测试通过的确定指令。

可见，本实施例公开的本发明公开的一种应用发布方法，技术人员完成代码后需要将代码提交到代码仓库，实现对不同应用服务代码的统一管理，并通过配置管理数据库对不同应用服务的相关信息进行统一管理。响应于应用发布请求，确定待发布的目标应用服务之后，自动从代码仓库中获取目标应用服务对应的目标代码，调用预设代码检测工具对目标代码进行代码规范检查以实现自动检查代码规范。若扫描结果表示目标代码达到预设标准，对目标代码打包得到目标软件包。然后通过查询配置管理数据库，确定目标应用服务在测试环境中对应的多个第一应用服务器，将目标软件包分别部署在多个第一应用服务器，以对目标应用服务进行测试。响应于对目标应用服务测试通过，查询配置管理数据库，确定目标应用服务在目标环境中的多个第二应用服务器，从而将目标软件包分别部署在多个第二应用服务器，实现自动化应用发布，避免人工操作导致的错误，提高了应用发布效率。

上述实施例中S106：将所述目标软件包分别部署在所述多个第一应用服务器，一种可选的实现方式包括以下步骤：

A1：分别控制所述多个第一应用服务器获取所述目标软件包；

具体的，通过Java的SSH插件登录多个第一应用服务器，访问Maven仓库获取目标软件包。

A2：在所述第一Nginx服务器的负载均衡配置信息中删除所述多个第一应用服务器的IP地址；

Nginx是一个高性能的HTTP和反向代理web服务器，按照预先设定的负载均衡策略规则将访问请求分配到多个应用服务器。

通过Java的SSH插件登录第一Nginx服务器，执行shell命令来更改第一Nginx服务器的负载均衡配置信息，在第一Nginx服务器的负载均衡配置信息中删除多个第一应用服务器的IP地址，使访问请求不会被分配到多个第一应用服务器。

A3：分别控制所述多个第一应用服务器安装所述目标软件包，并在安装完成后启动所述目标应用服务；

需要说明的是，若多个第一应用服务器上部署有所述目标应用服务对应的旧版本应用服务，需要先将原有的旧版本应用服务关闭。再分别控制多个第一应用服务器安装目标软件包，使目标软件包替换掉原有的旧版本应用服务软件包，并在安装完成后启动目标应用服务。

A4：将所述多个第一应用服务器的IP地址添加到所述第一Nginx服务器的负载均衡配置信息中，以使所述目标应用服务对外提供服务。

启动目标应用服务之后，第一应用服务器还不会接收到访问请求，需要将多个第一应用服务器的IP地址重新添加到第一Nginx服务器的负载均衡配置信息中，第一Nginx服务器才会将访问请求分配到第一应用服务器，使目标应用服务对外提供服务。

响应于对目标应用服务测试通过，根据预先配置的应用发布工作量，确定对目标应用服务测试通过之后发布目标应用服务的目标环境，从而将目标软件包分别部署在目标应用服务在目标环境中对应的第二Nginx服务器和多个第二应用服务器。

上述实施例中S108：将所述目标软件包分别部署在所述多个第二应用服务器，一种可选的实现方式包括以下步骤：

B1：分别控制所述多个第二应用服务器获取所述目标软件包；

B2：在所述第二Nginx服务器的负载均衡配置信息中删除所述多个第二应用服务器的IP地址；

B3：分别控制所述多个第二应用服务器安装所述目标软件包，并在安装完成后启动所述目标应用服务；

B4：将所述多个第二应用服务器的IP地址添加到所述第二Nginx服务器的负载均衡配置信息中，以使所述目标应用服务对外提供服务。

上述步骤B1～B4的原理与上述A1～A4的原理相同，这里不再赘述。

若目标环境为生产环境，将目标软件包成功部署在多个第二应用服务器，则目标应用服务发布完成。

若目标环境为预发布环境，在S108之后，还包括以下步骤：

C1：对所述目标应用服务进行预发布测试；

示例性的，通过Java的SSH插件来登录到Jmeter服务器上运行提前编写好的自动化预发布测试脚本来对部署好的第二应用服务器上的目标应用服务进行自动化测试。

C2：响应于对所述目标应用服务预发布测试通过，查询所述配置管理数据库，确定所述目标应用服务在生产环境中对应的第三Nginx服务器和多个第三应用服务器；

具体的，以所述目标应用服务所在的项目和所述目标应用服务作为查询条件，在所述配置管理数据库中查询所述目标应用服务在生产环境中对应的第三Nginx服务器和多个第三应用服务器。

C3：分别控制所述多个第三应用服务器获取所述目标软件包；

C4：在所述第三Nginx服务器的负载均衡配置信息中删除所述多个第三应用服务器的IP地址；

C5：分别控制所述多个第三应用服务器安装所述目标软件包，并在安装完成后启动所述目标应用服务；

C6：将所述多个第三应用服务器的IP地址添加到所述第三Nginx服务器的负载均衡配置信息中，以使所述目标应用服务对外提供服务。

上述步骤C3～C6的原理与上述A1～A4的原理相同，这里不再赘述。

基于上述实施例公开的一种应用发布方法，本实施例对应公开了一种应用发布装置，请参阅图2，本实施公开的应用发布装置包括：

应用确定单元201，用于响应于应用发布请求，确定待发布的目标应用服务；

代码获取单元202，用于从代码仓库中获取所述目标应用服务对应的目标代码；

代码检查单元203，用于调用预设代码检测工具对所述目标代码进行代码规范检查，并获取检查结果；

代码打包单元204，用于若所述检查结果表示所述目标代码达到预设标准，对所述目标代码进行打包，得到目标软件包；

第一查询单元205，用于查询配置管理数据库，确定所述目标应用服务在测试环境中对应的多个第一应用服务器；

第一部署单元206，用于将所述目标软件包分别部署在所述多个第一应用服务器，以对所述目标应用服务进行测试；

第二查询单元207，用于响应于对所述目标应用服务测试通过，查询所述配置管理数据库，确定所述目标应用服务在目标环境中对应的多个第二应用服务器，所述目标环境为预发布环境或生产环境；

第二部署单元208，用于将所述目标软件包分别部署在所述多个第二应用服务器。

在一些实施例中，所述应用发布装置还包括：

软件包上传单元，用于在得到目标软件包之后，将所述目标软件包上传到Maven仓库中。

在一些实施例中，所述应用发布装置还包括：

信息录入单元，用于在所述目标应用服务发布之前，将所述目标应用服务的开发信息和发布信息录入所述配置管理数据库；所述开发信息至少包括所述目标应用服务所在的项目和所述目标应用服务的开发团队，所述发布信息至少包括所述目标应用服务在所述测试环境对应的第一Nginx服务器信息和所述多个第一应用服务器信息、所述目标应用服务在所述目标环境中对应的第二Nginx服务器信息和所述多个第二应用服务器信息。

在一些实施例中，所述第一查询单元205，具体用于以所述目标应用服务所在的项目和所述目标应用服务作为查询条件，在所述配置管理数据库中查询所述目标应用服务在所述测试环境中对应的所述第一Nginx服务器和所述多个第一应用服务器。

在一些实施例中，所述第一部署单元206，具体用于分别控制所述多个第一应用服务器获取所述目标软件包；在所述第一Nginx服务器的负载均衡配置信息中删除所述多个第一应用服务器的IP地址；分别控制所述多个第一应用服务器安装所述目标软件包，并在安装完成后启动所述目标应用服务；将所述多个第一应用服务器的IP地址添加到所述第一Nginx服务器的负载均衡配置信息中，以使所述目标应用服务对外提供服务。

在一些实施例中，所述第二查询单元207，具体用于响应于预设审核人员发送的对所述目标应用服务测试通过的确定指令。

在一些实施例中，所述第二查询单元207，具体用于根据预先配置的应用发布工作流，确定对所述目标应用服务测试通过之后发布所述目标应用服务的所述目标环境；以所述目标应用服务所在的项目和所述目标应用服务作为查询条件，在所述配置管理数据库中查询所述目标应用服务在所述目标环境中对应的所述第二Nginx服务器和所述多个第二应用服务器。

在一些实施例中，若所述目标环境为预发布环境，所述应用发布装置还包括：

预发布测试单元，用于对所述目标应用服务进行预发布测试；

第三查询单元，用于响应于对所述目标应用服务预发布测试通过，查询所述配置管理数据库，确定所述目标应用服务在生产环境中对应的第三Nginx服务器和多个第三应用服务器；

第三部署单元，用于分别控制所述多个第三应用服务器获取所述目标软件包；在所述第三Nginx服务器的负载均衡配置信息中删除所述多个第三应用服务器的IP地址；分别控制所述多个第三应用服务器安装所述目标软件包，并在安装完成后启动所述目标应用服务；将所述多个第三应用服务器的IP地址添加到所述第三Nginx服务器的负载均衡配置信息中，以使所述目标应用服务对外提供服务。

本实施例公开的一种应用发布装置，技术人员完成代码后需要将代码提交到代码仓库，实现对不同应用服务代码的统一管理，并通过配置管理数据库对不同应用服务的相关信息进行统一管理。响应于应用发布请求，确定待发布的目标应用服务之后，自动从代码仓库中获取目标应用服务对应的目标代码，调用预设代码检测工具对目标代码进行代码规范检查以实现自动检查代码规范。若扫描结果表示目标代码达到预设标准，对目标代码打包得到目标软件包。然后通过查询配置管理数据库，确定目标应用服务在测试环境中对应的多个第一应用服务器，将目标软件包分别部署在多个第一应用服务器，以对目标应用服务进行测试。响应于对目标应用服务测试通过，查询配置管理数据库，确定目标应用服务在目标环境中的多个第二应用服务器，从而将目标软件包分别部署在多个第二应用服务器，实现自动化应用发布，避免人工操作导致的错误，提高了应用发布效率。

本发明实施例还提供了一种电子设备，所述电子设备包括处理器以及存储器；

所述存储器用于存储程序代码，并将所述程序代码传输给所述处理器；

所述处理器用于根据所述程序代码中的指令执行如上述实施例中任意一种实现方式描述的一种应用发布方法。

本发明实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上述实施例中任意一种实现方式描述的一种应用发布方法。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

上述各个实施例之间可任意组合，对所公开的实施例的上述说明，本说明书中各实施例中记载的特征可以相互替换或者组合，使本领域专业技术人员能够实现或使用本申请。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种应用发布方法，其特征在于，包括：

响应于应用发布请求，确定待发布的目标应用服务；

从代码仓库中获取所述目标应用服务对应的目标代码；

调用预设代码检测工具对所述目标代码进行代码规范检查，并获取检查结果；

若所述检查结果表示所述目标代码达到预设标准，对所述目标代码进行打包，得到目标软件包；

查询配置管理数据库，确定所述目标应用服务在测试环境中对应的多个第一应用服务器；

将所述目标软件包分别部署在所述多个第一应用服务器，以对所述目标应用服务进行测试；

响应于对所述目标应用服务测试通过，查询所述配置管理数据库，确定所述目标应用服务在目标环境中对应的多个第二应用服务器，所述目标环境为预发布环境或生产环境；

将所述目标软件包分别部署在所述多个第二应用服务器。

2.根据权利要求1所述的应用发布方法，其特征在于，在得到目标软件包之后，还包括：

将所述目标软件包上传到Maven仓库中。

3.根据权利要求1所述的应用发布方法，其特征在于，在所述目标应用服务发布之前，还包括：

将所述目标应用服务的开发信息和发布信息录入所述配置管理数据库；

所述开发信息至少包括所述目标应用服务所在的项目和所述目标应用服务的开发团队，所述发布信息至少包括所述目标应用服务在所述测试环境对应的第一Nginx服务器信息和所述多个第一应用服务器信息、所述目标应用服务在所述目标环境中对应的第二Nginx服务器信息和所述多个第二应用服务器信息。

4.根据权利要求3所述的应用发布方法，其特征在于，所述查询配置管理数据库，确定所述目标应用服务在测试环境中对应的多个第一应用服务器，包括：

以所述目标应用服务所在的项目和所述目标应用服务作为查询条件，在所述配置管理数据库中查询所述目标应用服务在所述测试环境中对应的所述第一Nginx服务器和所述多个第一应用服务器。

5.根据权利要求3所述的应用发布方法，其特征在于，所述将所述目标软件包分别部署在所述多个第一应用服务器，包括：

分别控制所述多个第一应用服务器获取所述目标软件包；

在所述第一Nginx服务器的负载均衡配置信息中删除所述多个第一应用服务器的IP地址；

分别控制所述多个第一应用服务器安装所述目标软件包，并在安装完成后启动所述目标应用服务；

将所述多个第一应用服务器的IP地址添加到所述第一Nginx服务器的负载均衡配置信息中，以使所述目标应用服务对外提供服务。

6.根据权利要求3所述的应用发布方法，其特征在于，所述查询所述配置管理数据库，确定所述目标应用服务在目标环境中对应的多个第二应用服务器，包括：

根据预先配置的应用发布工作流，确定对所述目标应用服务测试通过之后发布所述目标应用服务的所述目标环境；

以所述目标应用服务所在的项目和所述目标应用服务作为查询条件，在所述配置管理数据库中查询所述目标应用服务在所述目标环境中对应的所述第二Nginx服务器和所述多个第二应用服务器。

7.根据权利要求1或6所述的应用发布方法，其特征在于，若所述目标环境为预发布环境，在将所述目标软件包分别部署在所述多个第二应用服务器之后，还包括：

对所述目标应用服务进行预发布测试；

响应于对所述目标应用服务预发布测试通过，查询所述配置管理数据库，确定所述目标应用服务在生产环境中对应的第三Nginx服务器和多个第三应用服务器；

分别控制所述多个第三应用服务器获取所述目标软件包；

在所述第三Nginx服务器的负载均衡配置信息中删除所述多个第三应用服务器的IP地址；

分别控制所述多个第三应用服务器安装所述目标软件包，并在安装完成后启动所述目标应用服务；

将所述多个第三应用服务器的IP地址添加到所述第三Nginx服务器的负载均衡配置信息中，以使所述目标应用服务对外提供服务。

8.一种应用发布装置，其特征在于，包括：

应用确定单元，用于响应于应用发布请求，确定待发布的目标应用服务；

代码获取单元，用于从代码仓库中获取所述目标应用服务对应的目标代码；

代码检查单元，用于调用预设代码检测工具对所述目标代码进行代码规范检查，并获取检查结果；

代码打包单元，用于若所述检查结果表示所述目标代码达到预设标准，对所述目标代码进行打包，得到目标软件包；

第一查询单元，用于查询配置管理数据库，确定所述目标应用服务在测试环境中对应的多个第一应用服务器；

第一部署单元，用于将所述目标软件包分别部署在所述多个第一应用服务器，以对所述目标应用服务进行测试；

第二查询单元，用于响应于对所述目标应用服务测试通过，查询所述配置管理数据库，确定所述目标应用服务在目标环境中对应的多个第二应用服务器，所述目标环境为预发布环境或生产环境；

第二部署单元，用于将所述目标软件包分别部署在所述多个第二应用服务器。

9.一种电子设备，其特征在于，所述电子设备包括处理器以及存储器；

所述存储器用于存储程序代码，并将所述程序代码传输给所述处理器；

所述处理器用于根据所述程序代码中的指令执行如权利要求1-7中任一项所述的一种应用发布方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1-7中任一项所述的一种应用发布方法。