CN114003250A - 一种软件部署方法及装置 - Google Patents

Abstract

本申请提供一种软件部署方法及装置，涉及计算机软件技术，人工智能技术领域，能够在不依赖基线配置文件的情况下进行软件部署。该方法包括：获取目标软件的安装包，目标软件的安装包包括至少一个配置文件修改脚本；基于至少一个配置文件修改脚本，对部署环境中的配置文件进行修改，得到修改后的配置文件；判断修改后的配置文件的可靠性是否满足要求；若修改后的配置文件的可靠性满足要求，基于修改后的配置文件以及目标软件的安装包，安装目标软件。

Description

一种软件部署方法及装置

技术领域

本申请涉及计算机软件技术，人工智能技术领域，尤其涉及一种软件部署方法及装置。

背景技术

在软件项目开发的过程中，软件的需求变更是一个难以避免的问题，当软件需求改变时，为了保持软件各个配置成分的一致性，必须实行严格的产品控制，其中主要实行基线配置管理。

基线配置管理是基于基线配置文件的管理，即在软件开发、软件测试以及软件部署的过程中均基于基线配置文件进行。

其中，在软件部署的过程中，需要根据基线配置文件对软件部署的目标服务器进行配置，以使得软件在目标服务器上成功运行。现有技术提供的配置方案有以下两种：

方案一，直接将软件正式版本对应的基线配置文件覆盖到目标环境。但是，这种方案适用范围较窄，其原因在于：一方面，为了确保目标程序代码能够解析目标配置文件，需要严格要求基线配置文件，会增加软件开发及维护的成本；另一方面，软件的开发环境和软件的部署的目标环境会存在较多的差异，致使基线配置文件不能完全覆盖，需要手工部署。这种配置方案增加了维护成本，降低了软件部署的效率。

方案二，将软件正式版本对应的基线配置文件中的变量标识替换为目标环境客户化值后，再覆盖到目标环境。但是，这种方案的适用范围同样较窄，其原因在于：一方面，需要严格要求基线配置文件，增加了软件开发及维护的成本；另一方面，对基线配置文件的格式有严格要求，只适用于变量标识替换的情形，对于新增行、删除标识等操作是无法实现的。并且，复杂的可扩展标记语言(extensible markup language,XML)、Java脚本对象标识法(javascript object notation，JSON)文件无法采用此方案。

此外，在并行开发的过程中，如果软件的需求发生了变更，可能会出现有多个开发人员都需要对同一基线配置文件进行更改的情况，这样一来，会给软件部署带来困难。例如，在基于基线配置文件进行软件部署时，可能会出现以下情况：开发人员需要进行多次复核，确保基线配置文件统一后，再进行软件部署，这会大大增加软件开发和部署的成本；或者，针对不同开发人员修改的基线配置文件进行多次部署，这会降低软件部署的效率。

综上可以看出，基于基线配置文件的软件部署，在软件开发和长期运营的过程中，存在基线配置文件管理困难、部署成本高及部署效率低等问题，不能很好的满足用户的需求。

发明内容

本申请提供一种软件的部署方法及装置，能够在不依赖基线配置文件的情况下进行软件部署，提高了软件开发、部署的效率。

第一方面，本申请提供一种软件部署的方法，包括：获取目标软件的安装包，目标软件的安装包包括至少一个配置文件修改脚本；基于至少一个配置文件修改脚本，对部署环境中的配置文件进行修改，得到修改后的配置文件；判断修改后的配置文件的可靠性是否满足要求；若修改后的配置文件的可靠性满足要求，基于修改后的配置文件以及目标软件的安装包，安装目标软件。

基于上述技术方案，将配置文件修改脚本放入软件的安装包中，使目标软件在安装之前，能够根据配置文件修改脚本自动修改软件部署环境中的配置文件。这样一来，能够在未知基线配置文件的情况下进行软件部署，解决了基线配置文件管理困难的问题，提高了软件开发、部署的效率。此外，本申请提供的技术方案还可以对修改后的配置文件进行检验，确保修改后的配置文件的可靠性满足要求，使软件能够在部署环境中稳定运行。

可选的，在对部署环境中的配置文件进行修改之前，上述方法还包括：对配置文件进行备份，得到备份的配置文件；在判断修改后的配置文件的可靠性是否满足要求之后，上述方法还包括：若修改后的配置文件的可靠性不满足要求，基于备份的配置文件，对修改后的配置文件进行回滚操作。

可选的，判断修改后的配置文件的可靠性是否满足要求，包括：判断修改后的配置文件与备份的配置文件之间的编辑距离是否小于或等于第一阈值；和/或，在目标软件的安装包还包括基线配置文件的情况下，判断修改后的配置文件与基线配置文件之间的编辑距离是否小于或等于第二阈值。

可选的，若修改后的配置文件的可靠性不满足要求，上述方法还包括：基于修改后的配置文件以及备份的配置文件，确定配置文件修改脚本对配置文件进行修改的地方；发送告警信息，告警信息用于指示配置文件修改脚本对配置文件进行修改的地方。如此，在修改的配置文件的可靠性不满足要求的情况下，将修改后的配置文件和备份的配置文件进行对比，找到配置文件修改脚本对配置文件进行修改的地方，使得相关人员可以清晰的查找出问题所在，进而有针对性的解决问题，提高软件部署的效率。

可选的，目标软件的安装包用于安装第一版本号对应的目标软件；在获取目标软件的安装包之前，上述方法还包括：基于日志文件，检查是否已安装或者正在安装第一版本号对应的目标软件；获取目标软件的安装包，包括：在未安装或者未正在安装第一版本号对应的目标软件时，获取目标软件的安装包。基于上述技术方案，在获取软件安装包之前，基于日志文件，检查部署环境中是否正在进行部署操作；或者目标软件的第一版本号是否已在部署环境中部署过。如此，能够避免同一软件的同一版本号重复部署，以及避免部署环境中同时进行多个部署操作而导致部署混乱。

第二方面，本申请提供一种软件部署装置，包括：获取模块，用于获取目标软件的安装包，目标软件的安装包包括至少一个配置文件修改脚本；处理模块，用于基于至少一个配置文件修改脚本，对部署环境中的配置文件进行修改，得到修改后的配置文件；判断模块，用于判断修改后的配置文件的可靠性是否满足要求；安装模块，用于若修改后的配置文件的可靠性满足要求，基于修改后的配置文件以及目标软件的安装包，安装目标软件。

可选的，处理模块，还用于对配置文件进行备份，得到备份的配置文件；若修改后的配置文件的可靠性不满足要求，基于备份的配置文件，对修改后的配置文件进行回滚操作。

可选的，判断模块，具体用于判断修改后的配置文件与备份的配置文件之间的编辑距离是否小于或等于第一阈值；和/或，在目标软件的安装包还包括基线配置文件的情况下，判断修改后的配置文件与基线配置文件之间的编辑距离是否小于或等于第二阈值。

可选的，处理模块，还用于基于修改后的配置文件以及备份的配置文件，确定配置文件修改脚本对配置文件进行修改的地方；装置还包括通知模块，用于发送告警信息，告警信息用于指示配置文件修改脚本对配置文件进行修改的地方。

可选的，获取模块，还用于基于日志文件，检查是否已安装或者正在安装第一版本号对应的目标软件；在未安装或者未正在安装第一版本号对应的目标软件时，获取目标软件的安装包。

第三方面，本申请提供一种软件部署装置，包括：一个或多个处理器；处理器用于执行存储器中的计算机程序代码，计算机程序代码包括指令、使得软件部署装置执行上述第一方面所提供的任一种软件部署方法。

第四方面，本申请提供一种计算机可读存储介质，计算机可读存储介质中存储有指令，当该指令在计算机上运行时，使得计算机执行上述第一方面所提供的任一种软件部署方法。

第五方面，本申请提供一种包含指令的计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述第一方面所提供的任一种软件部署方法。

本申请中第二方面至第五方面的描述，可以参考第一方面的详细描述；并且，第二方面至第五方面的描述的有益效果，可以参考第一方面的有益效果分析，此处不再赘述。

附图说明

图1为本申请提供的一种软件部署系统的架构示意图；

图2为本申请提供的一种软件部署方法的流程图；

图3为本申请提供的另一种软件部署方法的流程图；

图4为本申请提供的又一种软件部署方法的流程图；

图5为本申请提供的一种软件部署装置的结构示意图；

图6为本申请提供的另一种软件部署装置的结构示意图。

具体实施方式

下面将结合附图对本申请提供的一种软件部署方法及装置进行详细的描述。

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。

本申请的说明书以及附图中的术语“第一”和“第二”等是用于区别不同的对象，或者用于区别对同一对象的不同处理，而不是用于描述对象的特定顺序。

此外，本申请的描述中所提到的术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选的还包括其他没有列出的步骤或单元，或可选的还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

需要说明的是，本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

在本申请的描述中，除非另有说明，“多个”的含义是指两个或两个以上。

如背景技术所述，软件在部署时，需要基于基线配置文件对部署环境中的配置文件进行修改，以使得软件在目标服务器上能够成功运行。其中，基线配置文件是指，根据预先设置的配置项确定的正式版本的配置文件。在软件开发、部署和运行过程中，软件版本的每一次修改和变更，都需要生成新的基线配置文件。

在软件开发和长期运营的过程中，难免会出现需求变动的情况，因此基于基线配置文件的软件部署，会存在基线配置文件管理困难、部署成本高及部署效率低等问题，不能很好的满足用户的需求。

针对上述技术问题，本申请实施例提供了一种软件部署方法及装置，具体包括：获取目标软件的安装包，目标软件的安装包包括至少一个配置文件修改脚本，配置文件修改脚本用于自动修改部署环境中的配置文件；基于至少一个配置文件修改脚本，对配置文件进行修改，得到修改后的配置文件；判断修改后的配置文件的可靠性是否满足要求；若修改后的配置文件的可靠性满足要求，基于修改后的配置文件以及目标软件的安装包，安装目标软件。

基于本申请实施例提供的技术方案，将配置文件修改脚本放入软件的安装包中，使目标软件在安装之前，能够根据配置文件修改脚本自动修改软件部署环境中的配置文件。这样一来，能够在未知基线配置文件的情况下进行软件部署，解决了基线配置文件管理困难的问题，提高了软件开发、部署的效率。此外，本申请提供的技术方案还可以对修改后的配置文件进行检验，确保修改后的配置文件的可靠性满足要求，使软件能够在部署环境中稳定运行。

通常，软件部署通常分为两种：手工部署和自动化部署。手工部署是指，部署人员需要手工将软件的正式版本(即软件正式投入使用的版本)覆盖到目标服务器对应的目录，并根据基线配置文件对目标服务器的部署环境中的配置文件进行人工的增加、删除、修改或查找等操作。自动化部署是指，通过软件自动化部署工具将软件的正式版本、基线配置文件等相关文件部署到目标服务器上。在本申请的一些实施例中，采用软件自动化部署工具进行软件部署。

参见图1，为本申请实施例适用的一种软件部署系统的架构示意图。如图1所示，该软件部署系统包括终端10和目标服务器20，终端10可以通过网络(有线网络或者无线网络)与目标服务器20之间建立连接。

其中，终端10为软件的开发人员所使用的设备。开发人员可以通过终端10登录目标服务器20，进而控制目标服务器20进行软件的安装和部署。

在一些实施例中，终端10上部署有软件自动化部署工具，该软件自动化部署工具可以接收目标服务器20发出的软件部署请求，根据该软件部署请求自动执行软件的部署操作。此外，在执行软件的部署操作之前，终端10还可以根据配置文件修改脚本修改目标服务器20的配置文件。

示例性的，终端10可以为手机、平板电脑、笔记本电脑、台式计算机、便携式计算机等，本申请实施例对此不做限定。

目标服务器20可以执行终端发出的修改软件部署环境的配置文件的操作指令，以实现目标软件的下载、安装和运行。

在一些实施例中，目标服务器20可以为搭建有前端工程的服务器；或者，目标服务器20可以为内容分发网络(content delivery network，CDN)服务器。

在一些实施例中，目标服务器20可以为一台服务器，或者，也可以为由多台服务器组成的服务器集群，本申请实施例对此不做限定。

下面结合说明书附图，对本申请提供的实施例进行具体介绍。

如图2所示，本申请实施例提供了一种软件配置方法，应用于图1所示的软件部署系统中的目标服务器20，该方法包括：

S101、获取目标软件的安装包，目标软件的安装包包括至少一个配置文件修改脚本。

其中，上述配置文件修改脚本是开发人员根据开发规范编写的脚本，其中包括依据行、关键字、模糊关键字、列、节点、XML、JSON等维度的操作。配置文件修改脚本用于自动对部署环境中的配置文件进行字符串的定位、替换、增加、删除等修改操作。

上述配置文件包括一个或多个配置项。配置项可以是：程序项目、网络协议(internet protocol，IP)地址或运行路径等。

目标软件为需要部署到目标服务器上的软件。由于目标软件的开发环境和目标服务器上的部署环境存在差异，因此，通过修改目标服务器的部署环境中的配置文件，可以使目标软件成功部署在目标服务器上。

可选的，在目标软件由多个开发人员并行开发的情况下，目标软件的安装包中可以包括一个或多个配置文件修改脚本，每个配置文件修改脚本用于修改对应的一个配置文件。

示例性的，假设每个开发人员均独立开发目标软件的一个功能模块，且各个功能模块之间无相互依赖关系，那么每个功能模块可以独立下发至目标服务器进行部署。在对该功能模块对应的配置文件进行修改时，每个开发人员仅需编写该功能模块对应部分的配置文件修改脚本，并将编写好的配置文件修改脚本独立下发，那么此时目标软件的安装包中可以只包含一个配置文件修改脚本。

例如，假设三个开发人员并行开发目标软件，其中开发人员A开发功能模块A1，开发人员B开发功能模块B1，开发人员C开发功能模块C1，且功能模块A1、B1、C1之间无相互依赖关系。为使目标软件的各个功能模块在目标服务器上能够成功运行，可能涉及到对目标服务器的配置文件进行修改，那么此时，开发人员A可以仅编写功能模块A1对应的一个配置文件修改脚本，并独立下发至目标服务器；开发人员B可以仅编写功能模块B1对应的一个配置文件修改脚本，并独立下发至目标服务器；开发人员C可以仅编写功能模块C1对应的一个配置文件修改脚本，并独立下发至目标服务器。

又一示例性的，假设每个开发人员均独立开发一个功能模块，但各个功能模块之间存在相互依赖关系，需要顺序执行，那么在对配置文件进行修改时，每个开发人员在完成该功能模块对应部分的配置文件修改脚本之后，还需将前一个或多个功能模块对应的配置文件修改脚本，按照执行顺序一起放入目标软件安装包中，那么此时目标软件安装包中需要包含多个配置文件修改脚本。

例如，假设三个开发人员并行开发目标软件，其中开发人员A开发功能模块A1，开发人员B开发功能模块B1，开发人员C开发功能模块C1，且功能模块A1、B1、C1之间存在相互依赖关系，需要按照A1-B1-C1的顺序执行。为使目标软件的各个功能模块在目标服务器上能够成功运行，可能涉及到对目标服务器的配置文件进行修改，那么此时，开发人员A可以仅编写功能模块A1对应的一个配置文件修改脚本，并独立下发至目标服务器；开发人员B在完成功能模块B1对应的一个配置文件修改脚本后，还需将功能模块A1对应的配置文件修改脚本排列在功能模块B1对应的配置文件修改脚本之前，将两个配置文件修改脚本下发至目标服务器；开发人员C在完成功能模块C1对应的配置文件修改脚本之后，还需要将功能模块A1对应的配置文件修改脚本和功能模块B1对应的配置文件修改脚本排列在配置文件A1对应的配置文件修改脚本之前，将三个配置文件修改脚本下发至目标服务器。

在一些实施例中，部署人员可以通过终端远程登录到目标服务器，并控制目标服务器从软件数据库中下载目标软件的安装包。从而，目标服务器可以获得目标软件的安装包。这样，终端通过部署在其上的软件自动化部署工具，自动控制目标服务器执行部署目标软件的操作，无需部署人员手动操作。

示例性的，响应于终端的携带的账户和密码的登录请求，目标服务器对登录请求中携带的账户和密码进行验证；在账号和密码通过验证的情况下，目标服务器允许终端登录该目标服务器，从而部署人员可以通过终端操作目标服务器。可选的，在远程登录时，终端和目标服务器之间可以采用安全壳(secure shell，SSH)协议。

在一些实施例中，目标软件的安装包用于安装第一版本号对应的目标软件。该第一版本号可以是目标软件的最新版本。基于此，可选的，在获取目标软件的安装包之前，还包括以下步骤：

步骤1、基于日志文件，检查是否已安装或者正在安装第一版本号对应的目标软件。

其中，上述日志文件，用于记录目标服务器的部署环境中的软件安装情况。示例性的，在软件开始安装时，可以在日志文件中记录开始标志，在软件安装完成时，可以在日志文件中记录结束标志。此外，日志文件还可以记录每一个在部署环境中安装的软件的版本型号。

如此，通过检查日志文件中记录的部署环境中安装的软件的版本型号，即可判断第一版本号对应的目标软件是否在部署环境中安装过；或者，通过检查日志文件中记录的第一版本号对应的目标软件的开始标志和结束标志是否完整，即可判断部署环境是否正在安装第一版本号对应的目标软件。

相应的，步骤S101可以具体实现为：在未安装或者未正在安装第一版本号对应的目标软件时，获取目标软件的安装包。

应理解，若部署环境中已经安装过第一版本号对应的目标软件，那么就不需要再重复安装，即，此时不需要获取目标软件的安装包。若部署环境中正在安装第一版本号对应的目标软件，那么此时再重复执行部署操作会导致部署环境的部署混乱，因此也不需要获取目标软件的安装包。

在一些实施例中，在部署人员通过终端远程登录目标服务器之后，还需要在目标服务器和目标软件之间进行双重认证。也即，验证目标服务器是否需要安装该目标软件，以及目标服务器是否有权限安装该目标软件。示例性的，目标软件的安装包和目标服务器均有标识信息，目标服务器通过识别目标软件的安装包的标识信息，来确定是否需要安装该目标软件；相应的，目标软件的安装包通过识别目标服务器的标识信息，来确定目标服务器是否有权限安装目标软件。

在双重认证之后，目标服务器执行以下步骤S102-S104。如此，通过在目标服务器和目标软件之间进行双重认证，可以避免目标软件部署错误，影响目标服务器的正常运行。

S102、基于至少一个配置文件修改脚本，对部署环境中的配置文件进行修改，得到修改后的配置文件。

示例性的，配置文件修改脚本可以包括以下函数：find(·)函数用于查找定位字符串、insert(·)插入函数用于将指定对象插入指定位置、replace(·)查找替换函数用于将文本中指定的字符串替换成其他字符串、delete(·)删除函数用于删除指定的字符串。

根据上述配置文件修改脚本可以完成诸如：字符串定位、字符串增加、字符串修改、字符串删除或字符串替换等操作，以实现对配置文件的修改，得到修改后的配置文件。

在一些实施例中，在对配置文件进行修改之前，上述方法还包括：对配置文件进行备份，得到备份的配置文件。

在一些实施例中，还可以在日志文件中记录配置文件修改脚本对配置文件的每一个修改操作。

应理解，配置文件修改脚本对配置文件进行的修改操作，进而根据修改后的配置文件进行目标软件部署，其目的在于：使得目标服务器上的目标软件的部署环境中的配置项与开发人员开发目标软件的开发环境中的配置项基本一致，从而保证目标软件可以安装在目标服务器上，并且保证目标服务器可以正常运行目标软件。

S103、判断修改后的配置文件的可靠性是否满足要求。

可选的，步骤S103可以采用以下实现方式中的至少一种：

实现方式一、通过判断修改后的配置文件与备份的配置文件之间的编辑距离是否小于或等于第一阈值，来确定修改后的配置文件的可靠性是否满足要求。

其中，在修改后的配置文件与备份的配置文件之间的编辑距离小于或等于第一阈值时，确定修改后的配置文件的可靠性满足要求。由于修改后的配置文件与备份的配置文件之间的编辑距离反映了修改后的配置文件与备份的配置文件之间的差异，因此，当配置文件修改脚本对配置文件的改动较小时，修改后的配置文件与备份的配置文件之间的边界距离小于或等于第一阈值，才能确定修改后的配置文件的可靠性满足要求。

第一阈值可以根据实验测试、模拟仿真、专家经验等方式来确定。

示例性的，可以根据以下公式(1)来确定修改后的配置文件与备份的配置文件之间的编辑距离。

其中，所述Lev表示表示编辑距离(Levenshtein Distance)算法，a表示备份的配置文件中的字符串，b表示修改后的配置文件中的字符串，Lev_a,b(i,j)表示字符串a中的第i个字符和字符串b中的第j个字符之间的距离。

当min(i，j)＝0时，即i或j有一个值为0，说明字符串a和字符串b中有一个为空串，那么从字符串a转换到字符串b只需要进行max(i，j)次单字符编辑操作，因此，编辑距离为max(i，j)，即i，j中的最大值。

实现方式二、在目标软件的安装包还包括基线配置文件的情况下，通过判断修改后的配置文件与基线配置文件之间的编辑距离是否小于或等于第二阈值，来确定修改后的配置文件的可靠性是否满足要求。

其中，在修改后的配置文件与基线配置文件之间的编辑距离小于或等于第二阈值时，确定修改后的配置文件的可靠性满足要求。由于，修改后的配置文件与基线配置文件之间的编辑距离反映了修改后的配置文件与基线配置文件之间的差异，且基线配置文件为正式版本的配置文件，因此修改后的配置文件与正式版本之间的差异越小越好。因此修改后的配置文件与基线配置文件之间的编辑距离小于或等于第二阈值时，才能确定修改后的配置文件的可靠性满足要求。

第二阈值可以根据实验测试、模拟仿真、专家经验等方式来确定。

示例性的，可以根据上述公式(1)来确定修改后的配置文件与基线配置文件之间的编辑距离。

其中，所述Lev表示表示编辑距离(Levenshtein Distance)算法，a表示修改后的配置文件中的字符串，b表示基线配置文件中的字符串，Lev_a,b(i,j)表示字符串a中的第i个字符和字符串b中的第j个字符之间的距离。

S104、若修改后的配置文件的可靠性满足要求，基于修改后的配置文件以及目标软件的安装包，安装目标软件。

在一些实施例中，在修改后的配置文件与备份文件之间的编辑距离小于或等于第一阈值，和/或修改后的配置文件与基线配置文件之间的编辑距离小于或等于第二阈值的情况下，确定修改后的配置文件的可靠性满足要求。

在一些实施例中，终端上部署有软件自动化部署工具，该软件自动化部署工具可以在目标服务器上自动执行目标软件的安装操作。在目标软件安装的过程中，终端可以查看软件在目标服务器上的安装进程，并通过控制软件自动化部署工具来控制安装操作的启动或停止。

基于图2所提供的技术方案，至少带来以下有益效果：将配置文件修改脚本放入软件的安装包中，使目标软件在安装之前，能够根据配置文件修改脚本自动修改软件部署环境中的配置文件。这样一来，能够在未知基线配置文件的情况下进行软件部署，解决了基线配置文件管理困难的问题，提高了软件开发、部署的效率。此外，本申请提供的技术方案还可以对修改后的配置文件进行检验，确保修改后的配置文件的可靠性满足要求，使软件能够在部署环境中稳定运行。

可选的，基于图2所示的实施例，如图3所示，在修改后的配置文件的可靠性不满足要求时，上述软件部署方法还可以包括以下步骤S105：

S105、若修改后的配置文件的可靠性不满足要求，基于备份的配置文件，对修改后的配置文件进行回滚操作。

在一些实施例中，在修改后的配置文件与备份文件之间的编辑距离大于第一阈值；或者，修改后的配置文件与基线配置文件之间的编辑距离大于第二阈值的情况下，确定修改后的配置文件的可靠性不满足要求。

其中，上述回滚操作是指，在程序或数据出现错误时，将程序或数据恢复至上一次正确状态的行为。在本申请实施例中，基于备份的配置文件，对修改后的配置文件进行回滚操作是指，用备份的配置文件覆盖(或替换)可靠性不满足要求的修改后的配置文件。

基于本申请实施例所提供的技术方案，至少带来以下有益效果：在修改后的配置文件的可靠性不满足要求时，基于备份的配置文件，对修改后的配置文件进行回滚操作，如此，通过回滚操作，可以将可靠性不满足要求的修改后的配置文件舍弃，然后基于备份配置文件，重新执行步骤S102-S103，直至得到可靠性满足要求的修改后的配置文件。

可选的，基于图3所示的实施例，如图4所示，在修改后的配置文件的可靠性不满足要求时，上述软件部署方法还可以包括以下步骤S106-S107：

S106、若修改后的配置文件的可靠性不满足要求，基于修改后的配置文件以及备份的配置文件，确定配置文件修改脚本对配置文件进行修改的地方。

作为一种可能的实现方式，可以采用最长公共子序列动态规划算法(longestcommon subsequence，LCS)，基于修改后的配置文件以及备份的配置文件，确定配置文件修改脚本对配置文件进行修改的地方。

示例性的，分别在修改后的配置文件中选取一段字符串text₁，在备份的配置文件中选取一段字符串text₂。假设字符串text₁的长度为m，字符串text₂的长度为n，创建一个m+1行n+1列的二维数组dp，其中dp[i][j]表示字符串text₁[0：i]和字符串text₂[0：j]的最长公共子序列的长度。

考虑动态规划的边界情况：当i＝0时，text1[0：i]为空，空字符串和任何字符串的最长公共子序列的长度都是0，因此对任意0≤j≤n，有dp[0][j]＝0；当j＝0时，text2[0：j]为空，同理可得，对任意0≤i≤n，有dp[i][0]＝0。因此动态规划的边界情况是：当i＝0或j＝0时，dp[i][j]＝0。

当i>0且j>0时，考虑dp[i][j]的计算：

当text₁[i-1]＝text₂[j-1]时，将这两个相同的字符称为公共字符，考虑text₁[0：i-1]和text₂[0：j-1]的最长公共子序列，再增加一个字符(即公共字符)即可得到text₁[0：i]和text₂[0：j]的最长公共子序列，因此dp[i][j]＝dp[i-1][j-1]+1。

当text₁[i-1]≠text₂[j-1]时，考虑以下两项：text₁[0：i-1]和text₂[0：j]的最长公共子序列；text₁[0：i]和text₂[0：j-1]的最长公共子序列。要得到text₁[0：i]和text₂[0：j]的最长公共子序列，应取两项中长度较大的一项，因此dp[i][j]＝max{dp[i-1][j]，dp[i][j-1]}。

由此可以得到如公式(2)所示的状态转移方程：

根据上述公式(2)最终计算的得到dp[m][n]即为字符串text₁和字符串text₂的最长公共子序列的长度。

根据字符串text₁和字符串text₂的最长公共子序列的长度，确定字符串text₁和字符串text₂的最长公共子序列，进而通过排除字符串text₁和字符串text₂的最长公共子序列，即可得到配置文件修改脚本对配置文件进行修改的地方。

S107、目标服务器向终端发送告警信息。

其中，上述告警信息用于指示配置文件修改脚本对配置文件进行修改的地方。

在一些实施例中，终端通过接收告警信息来获知配置文件修改脚本对配置文件进行修改的地方，进而检验配置文件修改脚本对配置文件进行修改的地方，查找出导致修改后的配置文件的可靠性不满足要求的问题。

在一些实施例中，在查找出导致修改后的配置文件的可靠性不满足要求的问题之后，还可以基于日志文件中记录的配置文件修改脚本对配置文件的每一个修改操作，进行回滚操作，以解决导致修改后的配置文件的可靠性不满足要求的问题。

基于本申请实施例所提供的技术方案，至少带来以下有益效果：在修改后的配置文件的可靠性不满足要求的情况下，基于修改后的配置文件以及备份的配置文件，确定配置文件修改脚本对配置文件进行修改的地方，以使得部署人员可以据此查找出导致修改后的配置文件的可靠性不满足要求的问题，进而有针对性的解决该问题，使目标软件能够成功部署在部署环境中。

需要说明的是，本申请实施例不限制步骤S105与步骤S106-S107之间的执行顺序。例如，可以先执行步骤S105，再执行步骤S106-S107；或者，先执行步骤S106-S107，再执行步骤S105；又或者，同时执行步骤S105与步骤S106-S107。

为便于理解，下面以三个开发人员分别负责目标软件的一个功能模块进行并行开发部署为例，对本申请实施例提供的一种软件部署方法进行进一步的介绍。

若目标软件的三个功能模块之间无相互依赖关系，那么每个开发人员所负责的功能模块对应的配置文件均可以单独下发至目标服务器，因此每个开发人员所执行的软件部署步骤相同，均为：

1、开发人员根据开发规范编写负责的功能模块对应的配置文件修改脚本；

2、测试人员对配置文件修改脚本进行测试，在测试成功后，将配置文件修改脚本放入第一版本号对应的目标软件的安装包中；

3、将第一版本号对应的目标软件的安装包下发至版本库，第一版本号对应的目标软件的安装包中包括配置文件修改脚本；

4、登录到目标服务器，从版本库中获取第一版本号对应的目标软件的安装包；

5、在目标服务器和目标软件之间进行双重认证，在目标服务器和目标软件认证成功的情况下，将当前目标服务器中的配置文件进行备份；

6、基于日志文件，检查目标服务器上是否已安装或者正在安装第一版本号对应的目标软件的；

7、在目标服务器上未安装或者未正在安装第一版本号对应的目标软件的情况下，根据配置文件修改脚本，对目标服务器中的配置文件进行字符串的定位、替换、增加、删除等修改操作，得到修改后的配置文件；配置文件修改脚本对配置文件的每一个修改操作均记录在日志文件中；

8、采用编辑距离算法，基于备份的配置文件或基线配置文件，判断修改后的配置文件的可靠性是否满足要求；

9、在所述修改后的配置文件的可靠性不满足要求的情况下，基于备份的配置文件，对修改后的配置文件进行回滚操作；或者，基于修改后的配置文件以及备份的配置文件，确定配置文件修改脚本对配置文件进行修改的地方，并向终端发送告警信息；

10、在修改后的配置文件的可靠性满足要求的情况下，基于修改后的配置文件以及目标软件的安装包，安装目标软件。

可以看出，上述主要从方法的角度对本申请实施例提供的方案进行了介绍。为了实现上述功能，本申请实施例提供了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的模块及算法步骤，本申请实施例能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

本申请实施例可以根据上述方法示例对网络节点进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。可选的，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

如图5所示，为本申请实施例提供的一种软件部署装置的结构示意图。该装置能够在不依赖基线配置文件的情况下进行软件部署，提高了软件开发、部署的效率。该软件部署装置300包括：获取模块301、处理模块302、判断模块303和安装模块304。在一些实施例中，该软件部署装置300还可以包括通知模块305.

获取模块301，用于获取目标软件的安装包，目标软件的安装包包括至少一个配置文件修改脚本。

处理模块302，用于基于至少一个配置文件修改脚本，对部署环境中的配置文件进行修改，得到修改后的配置文件。

判断模块303，用于判断修改后的配置文件的可靠性是否满足要求。

安装模块304，用于若修改后的配置文件的可靠性满足要求，基于修改后的配置文件以及目标软件的安装包，安装目标软件。

在一些实施例中，上述处理模块302，还用于对配置文件进行备份，得到备份的配置文件；若修改后的配置文件的可靠性不满足要求，基于备份的配置文件，对修改后的配置文件进行回滚操作。

在一些实施例中，上述判断模块303，具体用于判断修改后的配置文件与备份的配置文件之间的编辑距离是否小于或等于第一阈值；和/或，在目标软件的安装包还包括基线配置文件的情况下，判断修改后的配置文件与基线配置文件之间的编辑距离是否小于或等于第二阈值。

在一些实施例中，上述处理模块302，还用于基于修改后的配置文件以及备份的配置文件，确定配置文件修改脚本对配置文件进行修改的地方。上述通知模块305，用于发送告警信息，告警信息用于指示配置文件修改脚本对配置文件进行修改的地方。

在一些实施例中，上述获取模块301，还用于基于日志文件，检查是否已安装或者正在安装第一版本号对应的目标软件；在未安装或者未正在安装第一版本号对应的目标软件时，获取目标软件的安装包。

在采用硬件的形式实现上述集成的模块的功能的情况下，本发明实施例提供了上述实施例中所涉及的软件部署装置的另一种可能的结构示意图。如图6所示，该软件部署装置包括：处理器402，通信接口403，总线404。可选的，该软件部署装置还可以包括存储器401。

处理器402，可以是实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。该处理器402可以是中央处理器，通用处理器，数字信号处理器，专用集成电路，现场可编程门阵列或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。所述处理器402也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等。

通信接口403，用于与其他设备通过通信网络连接。该通信网络可以是以太网，无线接入网，无线局域网(wireless local area networks，WLAN)等。

存储器401，可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electrically erasable programmable read-only memory，EEPROM)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。

作为一种可能的实现方式，存储器401可以独立于处理器402存在，存储器401可以通过总线404与处理器402相连接，用于存储指令或者程序代码。处理器402调用并执行存储器401中存储的指令或程序代码时，能够实现本发明实施例提供的通信方法。

另一种可能的实现方式中，存储器401也可以和处理器402集成在一起。

总线404，可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将软件部署装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

本申请实施例还提供了一种计算机可读存储介质。上述方法实施例中的全部或者部分流程可以由计算机指令来指示相关的硬件完成，该程序可存储于上述计算机可读存储介质中，该程序在执行时，可包括如上述各方法实施例的流程。计算机可读存储介质可以是前述任一实施例的或内存。上述计算机可读存储介质也可以是上述软件部署装置的外部存储设备，例如上述软件部署装置上配备的插接式硬盘，智能存储卡(smart media card，SMC)，安全数字(secure digital，SD)卡，闪存卡(flash card)等。进一步地，上述计算机可读存储介质还可以既包括上述软件部署装置的内部存储单元也包括外部存储设备。上述计算机可读存储介质用于存储上述计算机程序以及上述软件部署装置所需的其他程序和数据。上述计算机可读存储介质还可以用于暂时地存储已经输出或者将要输出的数据。

本申请实施例还提供一种计算机程序产品，该计算机产品包含计算机程序，当该计算机程序产品在计算机上运行时，使得该计算机执行上述实施例中所提供的任一项软件部署方法。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应该以权利要求的保护范围为准。

Claims (11)

1.一种软件部署方法，其特征在于，所述方法包括：

获取目标软件的安装包，所述目标软件的安装包包括至少一个配置文件修改脚本；

基于所述至少一个配置文件修改脚本，对部署环境中的配置文件进行修改，得到修改后的配置文件；

判断所述修改后的配置文件的可靠性是否满足要求；

若所述修改后的配置文件的可靠性满足要求，基于所述修改后的配置文件以及所述目标软件的安装包，安装所述目标软件。

2.根据权利要求1所述的方法，其特征在于，在所述对部署环境中的配置文件进行修改之前，所述方法还包括：

对所述配置文件进行备份，得到备份的配置文件；

在所述判断所述修改后的配置文件的可靠性是否满足要求之后，所述方法还包括：

若所述修改后的配置文件的可靠性不满足要求，基于所述备份的配置文件，对所述修改后的配置文件进行回滚操作。

3.根据权利要求2所述的方法，其特征在于，所述判断所述修改后的配置文件的可靠性是否满足要求，包括：

判断所述修改后的配置文件与所述备份的配置文件之间的编辑距离是否小于或等于第一阈值；和/或，

在所述目标软件的安装包还包括基线配置文件的情况下，判断所述修改后的配置文件与所述基线配置文件之间的编辑距离是否小于或等于第二阈值。

4.根据权利要求2所述的方法，其特征在于，若所述修改后的配置文件的可靠性不满足要求，所述方法还包括：

基于所述修改后的配置文件以及所述备份的配置文件，确定所述配置文件修改脚本对所述配置文件进行修改的地方；

发送告警信息，所述告警信息用于指示所述配置文件修改脚本对所述配置文件进行修改的地方。

5.根据权利要求1至4任一项所述的方法，其特征在于，所述目标软件的安装包用于安装第一版本号对应的目标软件；

在所述获取目标软件的安装包之前，所述方法还包括：

基于日志文件，检查是否已安装或者正在安装所述第一版本号对应的目标软件；

所述获取目标软件的安装包，包括：

在未安装或者未正在安装所述第一版本号对应的目标软件时，获取所述目标软件的安装包。

6.一种软件部署装置，其特征在于，包括：

获取模块，用于获取目标软件的安装包，所述目标软件的安装包包括至少一个配置文件修改脚本；

处理模块，用于基于所述至少一个配置文件修改脚本，对部署环境中的配置文件进行修改，得到修改后的配置文件；

判断模块，用于判断所述修改后的配置文件的可靠性是否满足要求；

安装模块，用于若所述修改后的配置文件的可靠性满足要求，基于所述修改后的配置文件以及所述目标软件的安装包，安装所述目标软件。

7.根据权利要求6所述的装置，其特征在于，

所述处理模块，还用于对所述配置文件进行备份，得到备份的配置文件；若所述修改后的配置文件的可靠性不满足要求，基于所述备份的配置文件，对所述修改后的配置文件进行回滚操作。

8.根据权利要求7所述的装置，其特征在于，

所述判断模块，具体用于判断所述修改后的配置文件与所述备份的配置文件之间的编辑距离是否小于或等于第一阈值；和/或，

在所述目标软件的安装包还包括基线配置文件的情况下，判断所述修改后的配置文件与所述基线配置文件之间的编辑距离是否小于或等于第二阈值。

9.根据权利要求7所述的装置，其特征在于，

所述处理模块，还用于基于所述修改后的配置文件以及所述备份的配置文件，确定所述配置文件修改脚本对所述配置文件进行修改的地方；

所述装置还包括通知模块，用于发送告警信息，所述告警信息用于指示所述配置文件修改脚本对所述配置文件进行修改的地方。

10.根据权利要求6至9任一项所述的装置，其特征在于，所述目标软件的安装包用于安装第一版本号对应的目标软件；

所述获取模块，还用于基于日志文件，检查是否已安装或者正在安装所述第一版本号对应的目标软件；在未安装或者未正在安装所述第一版本号对应的目标软件时，获取所述目标软件的安装包。

11.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质包括计算机执行指令，当所述计算机执行指令在计算机上运行，使得计算机执行如权利要求1至5任一项所述的软件部署方法。

Images