CN115840572A - 一种版本包的部署管理方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请公开一种版本包的部署管理方法、装置、电子设备及存储介质，属于版本检验技术领域，方法包括：响应于部署关系设置操作，建立业务系统与至少两个部署单元之间的对应关系，建立每个部署单元与应用用户和至少一个投产主机之间的对应关系，基于业务系统的系统信息、部署单元的单元信息和应用用户的用户信息，生成部署单元的版本包存储路径，将版本包存储路径发送给这至少一个投产主机，使这至少一个投产主机加载部署单元的版本包，然后，向这至少一个投产主机分别发送版本包部署指令，以在这至少一个投产主机上部署版本包。这样，借助于版本检验管理工具半自动化地执行版本检验工作时需进行的一系列繁琐的前序工作，所以可提升版本检验的效率。

Description

一种版本包的部署管理方法、装置、电子设备及存储介质

技术领域

本申请涉及版本检验技术领域，尤其涉及一种版本包的部署管理方法、装置、电子设备及存储介质。

背景技术

一般地，业务系统在投产上线之前需在测试环境进行模拟投产，以检验当前版本是否具备上线条件，这个过程叫做版本检验。

相关技术中，测试环境的版本检验工作有很大的不确定性，并且，由于业务场景复杂，测试环境和生产环境都具备很大的灵活性，测试环境与生产环境在某些前置系统的差异，导致在测试环境进行版本检验时需要手动进行一系列繁琐的前序工作，极大地影响了版本检验的效率。

发明内容

本申请实施例提供一种版本包的部署管理方法、装置、电子设备及存储介质，用以解决相关技术中存在的版本检验的效率低的问题。

第一方面，本申请实施例提供一种版本包的部署管理方法，包括：

响应于部署关系设置操作，建立业务系统与至少两个部署单元之间的对应关系，并建立每个部署单元与应用用户和至少一个投产主机之间的对应关系；

基于所述业务系统的系统信息、所述部署单元的单元信息和所述应用用户的用户信息，生成所述部署单元的版本包存储路径；

将所述版本包存储路径发送给所述至少一个投产主机，使所述至少一个投产主机加载所述部署单元的版本包；

向所述至少一个投产主机分别发送版本包部署指令，以在所述至少一个投产主机上部署所述版本包。

在一些实施例中，根据以下步骤向每个投产主机发送版本包部署指令：

按照设定的部署指令发送次序，依次向所述投产主机发送部署指令；

若确定当前部署指令未成功执行，则进行告警处理。

在一些实施例中，在向所述投产主机发送任一部署指令之前，还包括：

基于所述投产主机的操作系统，将所述部署指令转换成所述操作系统能识别的指令形式。

在一些实施例中，还包括：

响应于用户信息设置操作，新建业务用户；

响应于权限设置操作，为所述业务用户设置所述业务系统中的权限。

在一些实施例中，还包括：

响应于针对所述业务用户的查看请求，展示所述业务用户的用户信息和权限；

若检测到用户信息更新操作，则基于所述用户信息更新操作更新所述业务用户的用户信息；

若检测到权限更新操作，则基于所述权限更新操作，增加、删除或修改所述业务用户对所述业务系统的权限。

在一些实施例中，还包括：

响应于部署信息查看请求，展示基本部署信息和部署关系信息，所述基本部署信息包括所述业务系统的系统信息、各部署单元的单元信息和各应用用户的用户信息，所述部署关系信息包括所述业务系统与至少两个部署单元之间的对应关系，以及每个部署单元与应用用户和至少一个投产主机之间的对应关系；

若检测到基本部署信息更新操作，则基于所述基本部署信息更新操作，更新所述业务系统的系统信息、各部署单元的单元信息和各应用用户的用户信息中的至少一种；

若检测到部署关系更新操作，则基于所述部署关系更新操作，更新所述业务系统与至少两个部署单元之间的对应关系，和/或，每个部署单元与应用用户和至少一个投产主机之间的对应关系。

在一些实施例中，还包括：

记录每次设置操作和更新操作，得到一条操作日志；

保存所述操作日志。

第二方面，本申请实施例提供一种版本包的部署管理装置，包括：

建立模块，用于响应于部署关系设置操作，建立业务系统与至少两个部署单元之间的对应关系，并建立每个部署单元与应用用户和至少一个投产主机之间的对应关系；

生成模块，用于基于所述业务系统的系统信息、所述部署单元的单元信息和所述应用用户的用户信息，生成所述部署单元的版本包存储路径；

发送模块，用于将所述版本包存储路径发送给所述至少一个投产主机，使所述至少一个投产主机加载所述部署单元的版本包；

部署模块，用于向所述至少一个投产主机分别发送版本包部署指令，以在所述至少一个投产主机上部署所述版本包。

在一些实施例中，所述部署模块具体用于根据以下步骤向每个投产主机发送版本包部署指令：

按照设定的部署指令发送次序，依次向所述投产主机发送部署指令；

若确定当前部署指令未成功执行，则进行告警处理。

在一些实施例中，所述部署模块还用于：

在向所述投产主机发送任一部署指令之前，基于所述投产主机的操作系统，将所述部署指令转换成所述操作系统能识别的指令形式。

在一些实施例中，还包括用户管理模块，用于：

响应于用户信息设置操作，新建业务用户；

响应于权限设置操作，为所述业务用户设置所述业务系统中的权限。

在一些实施例中，所述用户管理模块，还用于：

响应于针对所述业务用户的查看请求，展示所述业务用户的用户信息和权限；

若检测到用户信息更新操作，则基于所述用户信息更新操作更新所述业务用户的用户信息；

若检测到权限更新操作，则基于所述权限更新操作，增加、删除或修改所述业务用户对所述业务系统的权限。

在一些实施例中，还包括系统管理模块，用于：

响应于部署信息查看请求，展示基本部署信息和部署关系信息，所述基本部署信息包括所述业务系统的系统信息、各部署单元的单元信息和各应用用户的用户信息，所述部署关系信息包括所述业务系统与至少两个部署单元之间的对应关系，以及每个部署单元与应用用户和至少一个投产主机之间的对应关系；

若检测到基本部署信息更新操作，则基于所述基本部署信息更新操作，更新所述业务系统的系统信息、各部署单元的单元信息和各应用用户的用户信息中的至少一种；

若检测到部署关系更新操作，则基于所述部署关系更新操作，更新所述业务系统与至少两个部署单元之间的对应关系，和/或，每个部署单元与应用用户和至少一个投产主机之间的对应关系。

在一些实施例中，还包括日志管理模块，用于：

记录每次设置操作和更新操作，得到一条操作日志；

保存所述操作日志。

第三方面，本申请实施例提供一种电子设备，包括：至少一个处理器，以及与所述至少一个处理器通信连接的存储器，其中：

存储器存储有可被至少一个处理器执行的指令，该指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述任一版本包的部署管理方法。

第四方面，本申请实施例提供一种存储介质，当所述存储介质中的指令由电子设备的处理器执行时，所述电子设备能够执行上述任一版本包的部署管理方法。

第五方面，本申请实施例提供一种计算机程序产品，当计算机程序产品在被电子设备调用执行时，使得所述电子设备执行上述任一版本包的部署管理方法。

本申请实施例中，版本检验管理工具响应于部署关系设置操作，建立业务系统与至少两个部署单元之间的对应关系，并建立每个部署单元与应用用户和至少一个投产主机之间的对应关系，基于业务系统的系统信息、这个部署单元的单元信息和应用用户的用户信息，生成部署单元的版本包存储路径，将版本包存储路径发送给这至少一个投产主机，使这至少一个投产主机加载部署单元的版本包，然后，向这至少一个投产主机分别发送版本包部署指令，以在这至少一个投产主机上部署版本包。这样，借助于版本检验管理工具可半自动化地执行版本检验工作时需进行的一系列繁琐的前序工作，所以可提升版本检验的效率。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提供的一种版本包的部署管理方法的应用场景示意图；

图2为本申请实施例提供的一种用户基本信息的页面示意图；

图3为本申请实施例提供的一种用户权限分配的页面示意图；

图4为本申请实施例提供的一种用户权限管理的页面示意图；

图5为本申请实施例提供的一种系统纳管的页面示意图；

图6-图9为本申请实施例提供的系统查询及维护时的相关页面示意图；

图10为本申请实施例提供的一条日志的记录信息示意图；

图11为本申请实施例提供的一种版本包的部署管理方法的流程图；

图12为本申请实施例提供的一种业务系统与部署单元、应用用户、以及投产主机之间的关系示意图；

图13为本申请实施例提供的一种版本包的部署管理装置的结构示意图；

图14为本申请实施例提供的一种用于实现版本包的部署管理方法的电子设备的硬件结构示意图。

具体实施方式

为了解决相关技术中存在的版本检验的效率低的问题，本申请实施例提供了一种版本包的部署管理方法、装置、电子设备及存储介质。

以下结合说明书附图对本申请的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本申请，并不用于限定本申请，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。并且，本申请的实施例中，对数据的获取、存储、使用、处理等均符合国家法律法规的相关规定。

为了便于理解本申请，本申请涉及的技术术语中：

业务系统，提供某种业务服务的系统，一个业务系统通常是比较庞大的，可以包括多个部署单元，每个部署单元可看作是一个独立的业务模块，可独立开发版本包，独立升级版本包。一般地，每个部署单元对应一个应用用户和至少一个投产主机，应用用户是操作系统级的用户，投产主机是将部署部署单元的设备。

版本检验，业务服务在投产上线之前，根据预先编写好的脚本在测试环境中进行的版本增量更新，新增功能点验证，以此来检验当前版本是否具备上线条件的过程。版本检验的目的是测试本次版本的正确性、脚本的功能是否完备、是否具备回退等功能。

系统纳管，版本检验管理内绑定业务系统、部署单元、投产主机、以及应用用户之间的关系。

版本包，具备新功能点的代码打出的可执行文件。

版本机，统一保存版本包的服务器。

Puppet，一种开源的集群管理工具。

相关技术中，测试环境的版本检验工作有很大的不确定性，并且，由于业务场景复杂，测试环境和生产环境都有很大的灵活性，测试环境与生产环境在某些前置系统的差异如业务系统、部署单元、投产主机、以及应用用户之间的关系在生产环境中是自然拥有的，但是在测试环境中是没有的、需要配置，这些差异导致在测试环境进行版本检验工作时需要手动进行一系列繁琐的前序工作，极大地影响了版本检验的效率。因此，一套成熟完整的版本检验管理工具具有一定的现实意义。

图1为本申请实施例提供的一种版本包的部署管理方法的应用场景图，包括业务服务器、多个投产主机和版本机，其中：

业务服务器，用于安装版本检验管理工具和Puppet服务端，版本检验管理工具用于执行本申请实施例中的方法，以对版本检验过程进行管理，Puppet服务端用于与各投产主机中的Puppet客户端进行通信，以管理各投产主机；

每个投产主机，用于从版本机加载应当部署到自身的部署单元的版本包，基于与版本检验管理工具的交互部署版本包，并基于自身安装的Puppet客户端与Puppet服务端进行通信，执行Puppet服务端发送的控制指令；

版本机，用于保存各部署单元的版本包。

本申请实施例中，将业务系统在测试环境进行版本检验测试的主要流程概括为以下几个步骤：

第一步、基本信息纳管：包括业务系统中英文，部署单元名称，部署单元类型，服务器操作系统类型等基本信息的导入，其中，部署单元类型如应用、数据库、web页面等，操作系统类型如linux、unix等；

第二步、系统纳管：包括业务系统，部署单元，投产主机，应用用户之间建立关联；

第三步、主机纳管：包括投产主机进行puppet纳管(指在业务服务器上安装puppet服务端，在投产主机上安装puppet客户端)，进行免密登陆配置；

第四步、版本机路径创建：基于业务系统的名称、一个部署单元的名称+类型，以及对应应用用户的用户信息，拼接成这个部署单元的版本包的唯一存储路径。

第五步、人工基于存储路径上传部署单元的版本包到版本机；

第六步、按照业务系统维度管理用户权限。

通过以上几个步骤，设计并实现了基于CS架构的版本检验管理工具。具备以下功能：

1、用户管理

1.1用户信息管理包含查询用户、新建用户(用户信息包括用户名、登陆名和所属机构)、修改用户、删除用户以及重置密码。用户基本信息以表格的形式展示，如图2所示。

新增用户的用户状态分为正常和锁定两种状态，同时包含用户角色和用户组分配管理功能，如图3所示。

针对用户从角色和组两个维度对用户权限进行进一步的隔离，便于更方便的进行版本检查的管理工作。

1.2用户权限管理：管理每个用户的系统权限和菜单权限。

如4所示，为本申请实施例提供的一种用户权限管理的页面示意图。

2、系统管理

2.1系统纳管

系统纳管主要是建立业务系统、部署单元、投产主机以及应用用户之间的关联。这里，可采用关系型数据库对上述关联关系进行抽象存储，并根据相关信息建立适当的索引，便于数据的管理和查询。

对使用者而言，只需要在界面上填写或上传资源对应关系excel文件即可完成资源的自动关联。详细页面如图5所示。

本工具支持页面填写和文件批量导入两种方式，可以更高效的完成资源关系的建立，在进行纳管过程中，还可自动为当前系统在版本机上创建对应的版本目录，并同步版本到该目录下。

2.2系统查询及维护

系统查询及维护主要是对已纳管业务系统、部署单元及投产主机进行管理。

对业务系统、部署单元及投产主机进行基本信息的修改，包括系统名称，部署单元名称，部署单元类型，所属数据中心，投产主机名等的修改。

同时支持对已纳管分区进行重新纳管，同步时钟，同步证书等操作。这些操作都是进行版本检验的必要前序条件，是为了保证成功获取版本包。

图6-图9为系统查询及维护时的相关页面示意图。

3、日志管理

为了实现对所有操作的可追溯性，本工具设计了日志管理功能，对整个版本检验前序工作进行最小单元的拆分，每个单元单独记录一条日志，包括业务系统、部署单元等的基本信息，同时包括执行时间、执行状态、执行人和执行结果，如图10所示。实现了每一步的可控、可追溯。

另外，日志可采用关系型数据库进行存储，每条日志对应独立的id，并建立索引便于查询。

下面结合具体实施例对本申请实施例的方案进行说明。

版本检验即为用户验收测试(User Acceptance Test，UAT)环境应用验证，目的是为了验证待投产版本包是否可以在生产环境进行投产。具体流程主要如下：

1、技术人员需要使用版本检验工具进模拟投产，版本检验工具上需要维护业务系统和业务用户的关系(例如：admin用户被赋予对业务系统a和业务系统b的权限)，只有被赋予权限后，业务系统才对业务用户可见、业务用户才有权限进行版本验证后续操作(admin用户可以对业务系统a和业务系统b进行版本检验)，同时可以处理权限变更场景，即admin用户不再负责业务系统a和业务b系统，换成负责业务系统c。

2、技术人员首先需要使用版本检验工具进行相关信息录入，包含：业务系统、部署单元、投产主机及应用用户之间的关联关系，使用这些信息可以在版本机上确认每个部署单元唯一的版本包存储路径。如不录入这些信息，无法进行后续的版本检验操作。

3、版本检验工具使用业务系统的名称、每个部署单元的名称+类型、以及应用用户的用户信息，拼接成这个部署单元的唯一版本包存储路径，然后，可由技术人员手动将版本包上传到版本机的该路径下，再由版本检验工具向部署单元对应的每个投产主机下发puppet指令，以触发投产主机去拉去版本机上对应目录下的版本包。

4、在拉取成功后，技术人员使用版本检验工具向投产主机下发部署相关命令，投产主机接收到部署相关命令后，执行主要包含十二步标准部署流程，大致包括：拉取版本包，解压缩，备份，应用停止，应用启动，健康检查，交易验证等。

图11为本申请实施例提供的一种版本包的部署管理方法的流程图，该方法可表现为版本检验工具，安装于图1的业务服务器中，且该方法包括以下步骤。

在步骤1101中，响应于部署关系设置操作，建立业务系统与至少两个部署单元之间的对应关系，并建立每个部署单元与应用用户和至少一个投产主机之间的对应关系。

一般地，一个业务系统会包括多个部署单元，每个部署单元对应一个操作系统级的应用用户，每个部署单元可单独设置其所被部署到的投产主机，所以一个部署单元可对应至少一个投产主机，且不同部署单元可部署到相同的投产主机上，也可以部署到不同的投产主机上，具体如何部署根据实际业务场景进行设置即可。

参见图12，为本申请实施例提供的一种业务系统与部署单元、应用用户、以及投产主机之间的关系示意图，业务系统A包括部署单元1、部署单元2和部署单元3，其中，部署单元1对应应用用户1、部署单元2对应应用用户2，部署单元3对应应用用户3，并且，部署单元1对应投产主机1和投产主机2，部署单元2对应投产主机2和投产主机3，部署单元3对应投产主机4。

需要说明的是，在实际业务环境中，业务系统与部署单元、应用用户、以及投产主机之间的关系是天然具有的，但在测试环境中，这些关系需要进行设置。

在步骤1102中，基于业务系统的系统信息、部署单元的单元信息和应用用户的用户信息，生成部署单元的版本包存储路径。

这里，需先生成部署单元的版本包在版本机上的存储路径，之后，再将版本包存放到该存储路径下。

比如，用预设前缀+业务系统的名称+部署单元的名称及类型+应用用户的用户名，作为部署单元的版本包存储路径。

在步骤1103中，将版本包存储路径发送给这至少一个投产主机，使这至少一个投产主机加载部署单元的版本包。

在步骤1104中，向这至少一个投产主机分别发送版本包部署指令，以在这至少一个投产主机上部署版本包。

具体实施时，可根据以下步骤向每个投产主机发送版本包部署指令：

按照设定的部署指令发送次序，依次向投产主机发送部署指令，若确定当前部署指令未成功执行，则进行告警处理。

并且，在向投产主机发送任一部署指令之前，还可以基于投产主机的操作系统，将部署指令转换成操作系统能识别的指令形式，以保证投产主机能够正确执行部署指令。

在一些实施例中，版本检验工具还具有新建用户的功能，具体地，响应于用户信息设置操作，新建业务用户，响应于权限设置操作，为业务用户设置业务系统中的权限。

并且，可查询用户信息和权限，对其进行修改。具体地，响应于针对业务用户的查看请求，展示业务用户的用户信息和权限，若检测到用户信息更新操作，则基于用户信息更新操作更新业务用户的用户信息；若检测到权限更新操作，则基于权限更新操作，增加、删除或修改业务用户对业务系统的权限。

在一些实施例中，版本检验工具还可以响应于部署信息查看请求，展示基本部署信息和部署关系信息，其中，基本部署信息包括业务系统的系统信息、各部署单元的单元信息和各应用用户的用户信息，部署关系信息包括业务系统与至少两个部署单元之间的对应关系，以及每个部署单元与应用用户和至少一个投产主机之间的对应关系，之后，若检测到基本部署信息更新操作，则基于可基本部署信息更新操作，更新业务系统的系统信息、各部署单元的单元信息和各应用用户的用户信息中的至少一种；若检测到部署关系更新操作，则可基于部署关系更新操作，更新业务系统与这至少两个部署单元之间的对应关系，和/或，每个部署单元与应用用户和至少一个投产主机之间的对应关系。

在一些实施例中，版本检验工具还可以记录每次设置操作和更新操作，得到一条操作日志，保存操作日志，以方便后续进行操作溯源。

当本申请实施例中提供的方法以软件或硬件或软硬件结合实现的时候，电子设备中可以包括多个功能模块，每个功能模块可以包括软件、硬件或其结合。

基于相同的技术构思，本申请实施例还提供一种版本包的部署管理装置，版本包的部署管理装置解决问题的原理与上述版本包的部署管理方法相似，因此版本包的部署管理装置的实施可参见版本包的部署管理方法的实施，重复之处不再赘述。图13为本申请实施例提供的一种版本包的部署管理装置的结构示意图，包括建立模块1301、生成模块1302、发送模块1303、部署模块1304。

建立模块1301，用于响应于部署关系设置操作，建立业务系统与至少两个部署单元之间的对应关系，并建立每个部署单元与应用用户和至少一个投产主机之间的对应关系；

生成模块1302，用于基于所述业务系统的系统信息、所述部署单元的单元信息和所述应用用户的用户信息，生成所述部署单元的版本包存储路径；

发送模块1303，用于将所述版本包存储路径发送给所述至少一个投产主机，使所述至少一个投产主机加载所述部署单元的版本包；

部署模块1304，用于向所述至少一个投产主机分别发送版本包部署指令，以在所述至少一个投产主机上部署所述版本包。

在一些实施例中，所述部署模块1304具体用于根据以下步骤向每个投产主机发送版本包部署指令：

按照设定的部署指令发送次序，依次向所述投产主机发送部署指令；

若确定当前部署指令未成功执行，则进行告警处理。

在一些实施例中，所述部署模块1304还用于：

在向所述投产主机发送任一部署指令之前，基于所述投产主机的操作系统，将所述部署指令转换成所述操作系统能识别的指令形式。

在一些实施例中，还包括用户管理模块1305，用于：

响应于用户信息设置操作，新建业务用户；

响应于权限设置操作，为所述业务用户设置所述业务系统中的权限。

在一些实施例中，所述用户管理模块1305，还用于：

响应于针对所述业务用户的查看请求，展示所述业务用户的用户信息和权限；

若检测到用户信息更新操作，则基于所述用户信息更新操作更新所述业务用户的用户信息；

若检测到权限更新操作，则基于所述权限更新操作，增加、删除或修改所述业务用户对所述业务系统的权限。

在一些实施例中，还包括系统管理模块1306，用于：

响应于部署信息查看请求，展示基本部署信息和部署关系信息，所述基本部署信息包括所述业务系统的系统信息、各部署单元的单元信息和各应用用户的用户信息，所述部署关系信息包括所述业务系统与至少两个部署单元之间的对应关系，以及每个部署单元与应用用户和至少一个投产主机之间的对应关系；

若检测到基本部署信息更新操作，则基于所述基本部署信息更新操作，更新所述业务系统的系统信息、各部署单元的单元信息和各应用用户的用户信息中的至少一种；

若检测到部署关系更新操作，则基于所述部署关系更新操作，更新所述业务系统与至少两个部署单元之间的对应关系，和/或，每个部署单元与应用用户和至少一个投产主机之间的对应关系。

在一些实施例中，还包括日志管理模块1307，用于：

记录每次设置操作和更新操作，得到一条操作日志；

保存所述操作日志。

本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，另外，本申请各实施例中的各功能模块可以集成在一个处理器中，也可以是单独物理存在，也可以两个或两个以上模块集成在一个模块中。各个模块相互之间的耦合可以是通过一些接口实现，这些接口通常是电性通信接口，但是也不排除可能是机械接口或其它的形式接口。因此，作为分离部件说明的模块可以是或者也可以不是物理上分开的，既可以位于一个地方，也可以分布到同一个或不同设备的不同位置上。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

在介绍了本申请示例性实施方式的版本包的部署管理方法和装置之后，接下来，介绍根据本申请的另一示例性实施方式的电子设备。

在一些可能的实施方式中，本申请的电子设备可以至少包括至少一个处理器、以及至少一个存储器。其中，存储器存储有程序代码，当程序代码被处理器执行时，使得处理器执行本说明书上述描述的根据本申请各种示例性实施方式的方法。

下面参照图14来描述根据本申请的这种实施方式实现的电子设备140。图14显示的电子设备140仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图14所示，电子设备140以通用电子设备的形式表现。电子设备140的组件可以包括但不限于：上述至少一个处理器141、上述至少一个存储器142、连接不同系统组件(包括存储器142和处理器141)的总线143。

总线143表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器、外围总线、处理器或者使用多种总线结构中的任意总线结构的局域总线。

存储器142可以包括易失性存储器形式的可读介质，例如随机存取存储器(RAM)1421和/或高速缓存存储器1422，还可以进一步包括只读存储器(ROM)1423。

存储器142还可以包括具有一组(至少一个)程序模块1424的程序/实用工具1425，这样的程序模块1424包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

电子设备140也可以与一个或多个外部设备144(例如键盘、指向设备等)通信，还可与一个或者多个使得用户能与电子设备140交互的设备通信，和/或与使得该电子设备140能与一个或多个其它电子设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口145进行。并且，电子设备140还可以通过网络适配器146与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器146通过总线143与用于电子设备140的其它模块通信。应当理解，尽管图中未示出，可以结合电子设备140使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理器、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

在示例性实施例中，还提供了一种包括指令的计算机可读存储介质，例如包括指令的存储器142，上述指令可由处理器141执行以完成上述版本包的部署管理方法。可选地，存储介质可以是非临时性计算机可读存储介质，例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

在示例性实施例中，还提供一种计算机程序产品，当计算机程序产品在被电子设备调用执行时，使得所述电子设备执行本申请提供的任一示例性方法。

并且，计算机程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、RAM、ROM、可擦式可编程只读存储器(Erasable Programmable Read-Only Memory，EPROM)、闪存、光纤、光盘只读存储器(Compact Disk Read Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

本申请实施例中用于版本包的部署管理的程序产品可以采用CD-ROM并包括程序代码，并可以在计算设备上运行。然而，本申请的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、射频(Radio Frequency，RF)等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本申请操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络如局域网(Local AreaNetwork，LAN)或广域网(Wide Area Network，WAN)连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了装置的若干单元或子单元，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之，上文描述的一个单元的特征和功能可以进一步划分为由多个单元来具体化。

此外，尽管在附图中以特定顺序描述了本申请方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、装置(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也包含这些改动和变型在内。

Claims (17)

1.一种版本包的部署管理方法，其特征在于，包括：

响应于部署关系设置操作，建立业务系统与至少两个部署单元之间的对应关系，并建立每个部署单元与应用用户和至少一个投产主机之间的对应关系；

基于所述业务系统的系统信息、所述部署单元的单元信息和所述应用用户的用户信息，生成所述部署单元的版本包存储路径；

将所述版本包存储路径发送给所述至少一个投产主机，使所述至少一个投产主机加载所述部署单元的版本包；

向所述至少一个投产主机分别发送版本包部署指令，以在所述至少一个投产主机上部署所述版本包。

2.如权利要求1所述的方法，其特征在于，根据以下步骤向每个投产主机发送版本包部署指令：

按照设定的部署指令发送次序，依次向所述投产主机发送部署指令；

若确定当前部署指令未成功执行，则进行告警处理。

3.如权利要求2所述的方法，其特征在于，在向所述投产主机发送任一部署指令之前，还包括：

基于所述投产主机的操作系统，将所述部署指令转换成所述操作系统能识别的指令形式。

4.如权利要求1所述的方法，其特征在于，还包括：

响应于用户信息设置操作，新建业务用户；

响应于权限设置操作，为所述业务用户设置所述业务系统中的权限。

5.如权利要求4所述的方法，其特征在于，还包括：

响应于针对所述业务用户的查看请求，展示所述业务用户的用户信息和权限；

若检测到用户信息更新操作，则基于所述用户信息更新操作更新所述业务用户的用户信息；

若检测到权限更新操作，则基于所述权限更新操作，增加、删除或修改所述业务用户对所述业务系统的权限。

6.如权利要求1所述的方法，其特征在于，还包括：

响应于部署信息查看请求，展示基本部署信息和部署关系信息，所述基本部署信息包括所述业务系统的系统信息、各部署单元的单元信息和各应用用户的用户信息，所述部署关系信息包括所述业务系统与至少两个部署单元之间的对应关系，以及每个部署单元与应用用户和至少一个投产主机之间的对应关系；

若检测到基本部署信息更新操作，则基于所述基本部署信息更新操作，更新所述业务系统的系统信息、各部署单元的单元信息和各应用用户的用户信息中的至少一种；

若检测到部署关系更新操作，则基于所述部署关系更新操作，更新所述业务系统与至少两个部署单元之间的对应关系，和/或，每个部署单元与应用用户和至少一个投产主机之间的对应关系。

7.如权利要求1-6任一所述的方法，其特征在于，还包括：

记录每次设置操作和更新操作，得到一条操作日志；

保存所述操作日志。

8.一种版本包的部署管理装置，其特征在于，包括：

建立模块，用于响应于部署关系设置操作，建立业务系统与至少两个部署单元之间的对应关系，并建立每个部署单元与应用用户和至少一个投产主机之间的对应关系；

生成模块，用于基于所述业务系统的系统信息、所述部署单元的单元信息和所述应用用户的用户信息，生成所述部署单元的版本包存储路径；

发送模块，用于将所述版本包存储路径发送给所述至少一个投产主机，使所述至少一个投产主机加载所述部署单元的版本包；

部署模块，用于向所述至少一个投产主机分别发送版本包部署指令，以在所述至少一个投产主机上部署所述版本包。

9.如权利要求8所述的装置，其特征在于，所述部署模块具体用于根据以下步骤向每个投产主机发送版本包部署指令：

按照设定的部署指令发送次序，依次向所述投产主机发送部署指令；

若确定当前部署指令未成功执行，则进行告警处理。

10.如权利要求9所述的装置，其特征在于，所述部署模块还用于：

在向所述投产主机发送任一部署指令之前，基于所述投产主机的操作系统，将所述部署指令转换成所述操作系统能识别的指令形式。

11.如权利要求8所述的装置，其特征在于，还包括用户管理模块，用于：

响应于用户信息设置操作，新建业务用户；

响应于权限设置操作，为所述业务用户设置所述业务系统中的权限。

12.如权利要求11所述的装置，其特征在于，所述用户管理模块，还用于：

响应于针对所述业务用户的查看请求，展示所述业务用户的用户信息和权限；

若检测到用户信息更新操作，则基于所述用户信息更新操作更新所述业务用户的用户信息；

若检测到权限更新操作，则基于所述权限更新操作，增加、删除或修改所述业务用户对所述业务系统的权限。

13.如权利要求8所述的装置，其特征在于，还包括系统管理模块，用于：

响应于部署信息查看请求，展示基本部署信息和部署关系信息，所述基本部署信息包括所述业务系统的系统信息、各部署单元的单元信息和各应用用户的用户信息，所述部署关系信息包括所述业务系统与至少两个部署单元之间的对应关系，以及每个部署单元与应用用户和至少一个投产主机之间的对应关系；

若检测到基本部署信息更新操作，则基于所述基本部署信息更新操作，更新所述业务系统的系统信息、各部署单元的单元信息和各应用用户的用户信息中的至少一种；

若检测到部署关系更新操作，则基于所述部署关系更新操作，更新所述业务系统与至少两个部署单元之间的对应关系，和/或，每个部署单元与应用用户和至少一个投产主机之间的对应关系。

14.如权利要求8-13任一所述的装置，其特征在于，还包括日志管理模块，用于：

记录每次设置操作和更新操作，得到一条操作日志；

保存所述操作日志。

15.一种电子设备，其特征在于，包括：至少一个处理器，以及与所述至少一个处理器通信连接的存储器，其中：

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1-7任一所述的方法。

16.一种存储介质，其特征在于，当所述存储介质中的指令由电子设备的处理器执行时，所述电子设备能够执行如权利要求1-7任一所述的方法。

17.一种计算机程序产品，其特征在于，当计算机程序产品在被电子设备调用执行时，使得所述电子设备执行如权利要求1-7任一所述的方法。

Images