CN111679854A - 软件产品的版本控制方法、装置和系统 - Google Patents

Abstract

本申请涉及一种软件产品的版本控制方法、装置和系统，在服务端对预定软件产品的不同产品类型和不同操作系统的版本配置管理及更新控制功能进行了统一设计与开发，并预先配置了预定软件产品的对应于不同产品类型和不同操作系统的版本信息，客户端相应可通过向服务端上送该预定软件产品的产品类型信息和操作系统信息，实现从服务端获得对应于其产品类型信息和操作系统信息的第一版本信息，并基于该第一版本信息与客户端中该预定软件产品自身的第二版本信息进行版本更新处理；从而，针对不同类型的软件产品实现了通用的版本配置管理及版本更新控制功能，无需由不同团队分别开发并各自维护，降低了版本管理及更新控制的代码开发量及维护成本。

Description

软件产品的版本控制方法、装置和系统

技术领域

本申请属于软件产品的版本管理技术领域，尤其涉及一种软件产品的版本控制方法、装置和系统。

背景技术

版本的配置管理和更新控制是手机银行一个非常重要的功能，影响手机银行版本的更新策略和用户体验。

目前，手机银行可能会有国内手机银行、海外手机银行、企业手机银行等多个不同类型的APP产品，然而，传统技术中，各个类型产品的版本配置管理及版本更新控制的功能实现分别由不同的团队开发并各自维护，存在代码重复开发、维护成本高昂等问题。

发明内容

有鉴于此，本申请提供了一种软件产品的版本控制方法、装置和系统，旨在针对不同类型的软件产品(如不同类型的手机银行app)实现通用的版本配置管理及版本更新控制功能，解决传统技术存在的上述问题。

具体技术方案如下：

一种软件产品的版本控制方法，应用于客户端；

所述方法包括：

获取客户端预定软件产品的产品类型信息及客户端操作系统信息；

发送所述产品类型信息及所述操作系统信息至服务端；服务端预先配置有所述预定软件产品的对应于不同产品类型和不同操作系统的版本信息；

接收服务端反馈的所述预定软件产品的对应于所述产品类型信息及客户端操作系统信息的第一版本信息；

基于所述第一版本信息和客户端所述预定软件产品当前的第二版本信息，对所述预定软件产品进行版本更新处理。

可选的，在获取客户端预定软件产品的产品类型信息及客户端操作系统信息时，还包括：

获取所述预定软件产品的登录用户的用户信息；

在发送所述产品类型信息及所述操作系统信息至服务端时，还包括：

发送所述用户信息至服务端；其中，服务端预先配置有所述预定软件产品的对应于不同产品类型、不同操作系统和不同用户的版本信息；

所述接收服务端反馈的所述预定软件产品的对应于所述产品类型信息及客户端操作系统信息的第一版本信息，包括：

接收服务端反馈的所述预定软件产品的对应于所述产品类型信息、所述客户端操作系统信息及所述用户信息的第一版本信息。

可选的，所述在发送所述产品类型信息及所述操作系统信息至服务端时发送所述用户信息至服务端，包括：

将所述产品类型信息、所述操作系统信息和所述用户信息按预定格式封装为一请求报文；

利用前后台交互接口的交互规范中提供的第一加密策略对所述用户信息在所述请求报文中对应的字段进行加密，得到加密处理后的请求报文；

利用前后台交互接口发送所述加密处理后的请求报文至服务端。

可选的，所述接收服务端反馈的所述预定软件产品的对应于所述产品类型信息及客户端操作系统信息的第一版本信息，包括：

接收服务端反馈的加密响应报文，所述加密响应报文为服务端基于所述前后台交互接口的交互规范中提供的第二加密策略对所述第一版本信息进行加密并将加密信息封装至响应报文后所得的结果；

利用所述前后台交互接口的交互规范中提供的第二解密策略对所述加密响应报文中的第一版本信息所在字段进行解密，得到所述第一版本信息。

可选的，所述第一版本信息包括第一版本号、版本更新内容及更新策略；所述第二版本信息包括第二版本号；

所述基于所述第一版本信息和客户端所述预定软件产品当前的第二版本信息，对所述预定软件产品进行版本更新处理，包括：

比较所述第一版本号和所述第二版本号；

若所述第一版本号不大于所述第二版本号，不更新所述预定软件产品的版本；

若所述第一版本号大于所述第一版本号，执行以下处理：

获取所述更新策略；

在所述更新策略为强制更新的情况下，基于所述版本更新内容对所述预定软件产品进行强制的版本更新；

在所述更新策略为提示更新的情况下，生成并展示版本更新提示，以基于用户选择确定是否更新所述预定软件产品的版本。

一种软件产品的版本控制方法，应用于服务端；

所述方法包括：

获取客户端上送的预定软件产品的产品类型信息及客户端操作系统信息；

从预先配置的所述预定软件产品的对应于不同产品类型和不同操作系统的版本信息中，确定对应于所述产品类型信息及客户端操作系统信息的第一版本信息；

反馈所述第一版本信息至客户端，以使客户端基于所述第一版本信息对所述预定软件产品进行版本更新处理。

可选的，在获取客户端上送的预定软件产品的产品类型信息及客户端操作系统信息时，还包括：

获取客户端上送的所述预定软件产品的登录用户的用户信息；

所述从预先配置的所述预定软件产品的对应于不同产品类型和不同操作系统的版本信息中，确定对应于所述产品类型信息及客户端操作系统信息的第一版本信息，包括：

从预先配置的所述预定软件产品的对应于不同产品类型、不同操作系统和不同用户的版本信息中，确定对应于所述产品类型信息、所述客户端操作系统信息和所述用户信息的第一版本信息。

可选的，所述在获取客户端上送的预定软件产品的产品类型信息及客户端操作系统信息时，获取客户端上送的所述预定软件产品的登录用户的用户信息，包括：

利用前后台交互接口接收客户端上送的加密请求报文；

利用前后台交互接口的交互规范中提供的第一解密策略对所述加密请求报文中用户信息所在的字段进行解密，得到解密后的请求报文；

从所述解密后的请求报文中提取所述产品类型信息、所述客户端操作系统信息和所述用户信息。

可选的，所述反馈所述第一版本信息至客户端，包括：

基于所述前后台交互接口的交互规范中提供的第二加密策略对所述第一版本信息进行加密，得到加密信息；

将加密信息封装至响应报文得到加密响应报文；

反馈所述加密响应报文至客户端。

可选的，还包括：

增添配置所述预定软件产品的新的产品类型的版本信息；

其中，所配置的版本信息至少包括所述新的产品类型的对应的产品类型信息、操作系统信息、版本更新内容及更新策略。

一种软件产品的版本控制装置，应用于客户端；

第一获取单元，用于获取客户端预定软件产品的产品类型信息及客户端操作系统信息；

发送单元，用于发送所述产品类型信息及所述操作系统信息至服务端；服务端预先配置有所述预定软件产品的对应于不同产品类型和不同操作系统的版本信息；

接收单元，用于接收服务端反馈的所述预定软件产品的对应于所述产品类型信息及客户端操作系统信息的第一版本信息；

更新处理单元，用于基于所述第一版本信息和客户端所述预定软件产品当前的第二版本信息，对所述预定软件产品进行版本更新处理。

一种软件产品的版本控制装置，应用于服务端；

所述装置包括：

第二获取单元，用于获取客户端上送的预定软件产品的产品类型信息及客户端操作系统信息；

确定单元，用于从预先配置的所述预定软件产品的对应于不同产品类型和不同操作系统的版本信息中，确定对应于所述产品类型信息及客户端操作系统信息的第一版本信息；

反馈单元，用于反馈所述第一版本信息至客户端，以使客户端基于所述第一版本信息对所述预定软件产品进行版本更新处理。

一种软件产品的版本控制系统，包括：

服务端设备及多个客户端设备；

其中，所述服务端设备用于执行如上任一项所述的应用于服务端的软件产品的版本控制方法，所述客户端设备用于执行如上任一项所述的应用于客户端的软件产品的版本控制方法。

由以上方案可知，本申请公开的软件产品的版本控制方法，在服务端对预定软件产品(如手机银行app)的不同产品类型和不同操作系统的版本配置管理及更新控制功能进行了统一设计与开发，并预先配置了预定软件产品的对应于不同产品类型和不同操作系统的版本信息(如版本号、版本更新内容、更新策略等)，与此相匹配的，客户端可通过向服务端上送其运行的该预定软件产品的产品类型信息和操作系统信息，实现从服务端请求并获取对应于其产品类型信息和操作系统信息的第一版本信息，并基于该第一版本信息与客户端中该预定软件产品自身的第二版本信息进行版本更新处理；从而，针对不同类型的软件产品实现了通用的版本配置管理及版本更新控制功能，无需由不同团队分别开发并各自维护，降低了版本管理及更新控制的代码开发量及维护成本。

附图说明

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

图1是本申请实施例提供的应用于客户端的软件产品的版本控制方法的一种流程示意图；

图2是本申请实施例提供的应用于客户端的软件产品的版本控制方法的另一种流程示意图；

图3是本申请实施例提供的手机银行和后台系统之间利用前后台交互接口进行的基于字段加密的交互逻辑示意图；

图4是本申请实施例提供的应用于服务端的软件产品的版本控制方法的一种流程示意图；

图5是本申请实施例提供的应用于服务端的软件产品的版本控制方法的另一种流程示意图；

图6是本申请实施例提供的应用于客户端的软件产品的版本控制装置的结构示意图；

图7是本申请实施例提供的应用于服务端的软件产品的版本控制装置的一种结构示意图；

图8是本申请实施例提供的应用于服务端的软件产品的版本控制装置的另一种结构示意图。

具体实施方式

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

发明人发现，针对手机银行app这一软件产品，由于现有技术中，对其各个类型产品的版本配置管理及版本更新控制的功能实现分别由不同的团队开发并各自维护，从而导致存在以下问题：

1)开发重复性高：以手机银行包括国内手机银行、海外手机银行、企业手机银行为例，三个手机银行的版本管理与更新控制的逻辑和流程相似，目前由不同团队各自开发，造成代码重复开发、人力资源浪费；

2)维护成本高昂：针对三个手机银行产品的版本管理及更新控制，生产环境上，维护人员要分别进行维护，造成工作内容重复、维护成本高。

为解决现有技术存在的上述问题，本申请公开了一种通用的、灵活的、可扩展的软件产品的版本控制方法、装置和系统，以下将通过多个实施例对该软件产品的版本控制方法、装置和系统进行详细说明。

在一可选实施例中，提供了一种应用于客户端的软件产品的版本控制方法，该方法具体可应用于智能手机或平板等终端设备构成的客户端中，如图1所示，该方法包括如下的处理步骤：

步骤101、获取客户端预定软件产品的产品类型信息及客户端操作系统信息。

其中，所述预定软件产品可以是但不限于手机银行app，手机银行app通常包括国内手机银行、海外手机银行、企业手机银行等多个不同类型的app产品。

另外，需要说明的是，即便是同一类型的app产品，也可以针对不同的客户端操作系统，而为其设计区别化的手机银行app产品形式，以使其从界面体验或功能实现等多个角度更加适配所对应的操作系统类型，如Android或IOS等。

鉴于此，本申请实施例中，为了克服因app类型不同以及操作系统不同而导致的开发重复性高及维护成本高等问题，在服务端对预定软件产品(如手机银行app)的不同产品类型和不同操作系统的版本配置管理及更新控制功能进行了统一设计与开发，并预先配置了预定软件产品的对应于不同产品类型和不同操作系统的版本信息，在服务端所配置的版本信息，如可以包括但不限于预定软件产品(如手机银行App)的对应于不同产品类型和不同操作系统的版本号、版本更新内容、更新策略等信息。也即，本质上来说，可在服务端配置该预定软件产品的app类型、适用的操作系统以及版本号、版本更新内容、更新策略等信息。

与此相匹配，客户端终端安装的该预定软件产品可在启动完成后，获取自身的产品类型信息及操作系统信息，如获取的自身产品类型信息为“企业手机银行”(或者“国内手机银行”、“国外手机银行”等)、操作系统信息为“Android”(或者“IOS”等)。

步骤102、发送所述产品类型信息及所述操作系统信息至服务端。

之后，客户端的所述预定软件产品可将启动完成后所获取的上述自身产品类型信息及操作系统信息上送至服务端。

步骤103、接收服务端反馈的所述预定软件产品的对应于所述产品类型信息及客户端操作系统信息的第一版本信息。

服务端获得客户端上送的产品类型信息及操作系统信息后，从预先配置的该预定软件产品如手机银行APP的版本信息中，查找与上送的产品类型信息及操作系统信息相匹配的第一版本信息并反馈至客户端，该第一版本信息可以包括但不限于版本号、版本更新内容及更新策略等信息。

相匹配的，客户端可接收到服务端反馈的第一版本信息，该第一版本信息与客户端的该预定软件产品的产品类型及客户端操作系统相匹配。

步骤104、基于所述第一版本信息和客户端所述预定软件产品当前的第二版本信息，对所述预定软件产品进行版本更新处理。

之后，客户端可基于接收的第一版本信息与客户端该预定软件产品当前自身的第二版本信息，实现对客户端该预定软件产品进行版本更新处理。

从服务端接收的第一版本信息可以包括但不限于第一版本号、版本更新内容及更新策略，该第一版本号即为服务端中所维护的对应于客户端产品类型信息及操作系统信息的该预定软件产品的最新版本号，所述更新策略可以包括但不限于强制更新和提示更新等不同类型；客户端中所述预定软件产品的当前第二版本信息包括第二版本号。

在此基础上，客户端基于第一版本信息和第二版本信息对其预定软件产品的更新处理过程可以包括：

1)比较所述第一版本号和所述第二版本号；

2)若所述第一版本号不大于所述第二版本号，不更新所述软件产品的版本；

第一版本号不大于第二版本号，即表示客户端中该预定软件产品的当前版本是最新的，从而无需执行版本更新流程。

3)若所述第一版本号大于所述第一版本号，执行以下处理：

反之，第一版本号大于第二版本号，则表示客户端中该预定软件产品的当前版本不是最新的，需执行版本更新流程。

31)获取所述更新策略；

32)在所述更新策略为强制更新的情况下，基于所述版本更新内容对所述预定软件产品进行强制的版本更新；

具体地，如果第一版本信息中携带的更新策略为强制更新，则可以直接基于第一版本信息中携带的版本更新内容对客户端该预定软件产品进行版本更新，或者，可选地，也可以在客户端弹框要求用户，必须更新到最新版本后才可使用该软件产品如手机银行，相应在用户操作弹框触发更新后再基于版本更新内容执行版本更新。

另外，可选地，也可在在第一版本信息中不携带版本更新内容，而是在确定需执行版本更新后，再从服务端请求具体的版本更新内容，本实施例对此不加限制。

33)在所述更新策略为提示更新的情况下，生成并展示版本更新提示，以基于用户选择确定是否更新所述软件产品的版本。

如果第一版本信息中携带的更新策略为提示更新，则可由客户端的该预定软件产品生成并展示版本更新提示，由用户选择是否需进行版本更新；以手机银行为例，手机银行弹框提示用户当前版本不是最新版本可进行版本更新，用户选择是，更新到最新版本，选择否，则不更新，可以继续使用当前版本的手机银行。

实施中，可在手机银行等预定软件产品增添编写Java/ObjectiveC代码，以实现从后台服务端请求最新版本号和版本更新策略等信息。

本实施例中，在服务端对预定软件产品(如手机银行App)的不同产品类型和不同操作系统的版本配置管理及更新控制功能进行了统一设计与开发，并预先配置了预定软件产品的对应于不同产品类型和不同操作系统的版本信息(如版本号、版本更新内容、更新策略等)，与此相匹配的，客户端可通过向服务端上送其运行的该预定软件产品的产品类型信息和操作系统信息，实现从服务端获得对应于其产品类型信息和操作系统信息的第一版本信息，并基于该第一版本信息与客户端中该预定软件产品自身的第二版本信息进行版本更新处理；从而，针对不同类型的软件产品实现了通用的版本配置管理及版本更新控制功能，无需由不同团队分别开发并各自维护，降低了版本管理及更新控制的代码开发量及维护成本。

在另一可选实施方式中，本申请实施例公开的应用于客户端的软件产品的版本控制方法，在获取客户端预定软件产品的产品类型信息及客户端操作系统信息时，还可以包括：获取所述预定软件产品的登录用户的用户信息；

相应地，在发送所述产品类型信息及所述操作系统信息至服务端时，还可以包括：发送所述用户信息至服务端；其中，服务端预先配置有所述预定软件产品的对应于不同产品类型、不同操作系统和不同用户的版本信息。

从而，参阅图2，上述的应用于客户端的软件产品的版本控制方法，可进一步通过以下的处理流程实现：

步骤201、获取客户端预定软件产品的产品类型信息、客户端操作系统信息及用户信息。

除了能够针对预定软件产品的不同产品类型及不同客户端操作系统，在服务端进行版本配置管理及更新控制逻辑与流程的统一设计与开发，本实施例中，还扩展了针对不同用户(具体可以理解为不同的用户类型，如普通用户、VIP用户、特殊用户等)，在后台服务端对其进行该预定软件产品如手机银行的版本信息管理及更新控制逻辑与流程的统一设计与开发，相对应地，在服务端预先配置了预定软件产品的对应于不同产品类型、不同操作系统和不同用户信息的版本信息(如版本号、版本更新内容、更新策略等)。

其中，本步骤201中，所获取的用户信息可以是但不限于用户手机号、身份证号、核心客户号中的任意一种或多种。

实施中，客户端可在用户首次登录手机银行等软件产品时，基于其登录信息提取用户的手机号、身份证号和/或核心客户号等用户信息并保存。

步骤202、发送所述产品类型信息、所述操作系统信息及用户信息至服务端；其中，服务端预先配置有所述预定软件产品的对应于不同产品类型、不同操作系统和不同用户的版本信息。

之后，客户端可将获取的自身手机银行等软件产品的产品类型信息(如企业手机银行)、操作系统信息(如IOS)以及用户信息(如用户的手机号、身份证号和/或核心客户号等)发送给服务端，以使得作为服务端进行版本信息查找的依据。

由于用户信息是涉敏的，从而，本实施中，在将用户信息进行上送时，优选地，可预先对用户信息进行加密。相应地，用户信息也可称之为用户敏感信息。

可选地，本实施例预先在客户端的手机银行等预定软件产品和服务端后台系统之间实现了一针对本申请的版本更新流程的专有前后台交互接口，该接口提供了前后台接口交互规范，且在所提供的交互规范中，约定了对用户信息进行加解密的加接密机制，如约定采用何种加解密方式加解密、对上送的请求报文中哪个字段(用户信息所在的字段)进行加解密等等。

在此基础上，本步骤202，具体可通过以下的处理过程实现：

1)将所述产品类型信息、所述操作系统信息和所述用户信息按预定格式封装为一请求报文；

2)利用前后台交互接口的交互规范中提供的第一加密策略对所述用户信息在所述请求报文中对应的字段进行加密，得到加密处理后的请求报文；

3)利用前后台交互接口发送所述加密处理后的请求报文至服务端。

可选地，作为一种实施方式，所述第一加密策略可以是：定位请求报文中用户信息所在的字段，并利用首次交互时根据用户信息(如手机号、身份证号和/或核心客户号等)生成的对称秘钥对用户信息在请求报文中所对应的字段进行加密，而其他字段如产品类型字段、操作系统字段则无需加密。

其中，所述“首次交互时”，是指用户在客户端设备上安装手机银行后，首次需向服务端后台系统上送请求报文以获得最新版本信息的时刻。在首次交互时，可基于用户信息生成用于加解密的对称秘钥，其中，每个用户有唯一不同的对称秘钥，后续由该交互接口维护该对称秘钥不变，直至用户更新其用户信息(如手机号码)时重新生成用于加解密的对称秘钥。

所述对称秘钥，可以是但不限于基于国密算法SM4等生成的秘钥。

作为另一种可选实施方式，所述第一加密策略还可以是：定位请求报文中用户信息所在的字段，并利用首次交互时生成的非对称秘钥对用户信息在请求报文中所对应的字段进行加密，而其他字段如产品类型字段、操作系统字段则无需加密。

此处，“首次交互时”的含义与上文中涉及的“首次交互时”同样，不再赘述。

步骤203、接收服务端反馈的所述预定软件产品的对应于所述产品类型信息、客户端操作系统信息及用户信息的第一版本信息。

相类似地，基于安全考虑，服务端在向客户端反馈第一版本信息时，可利用前后台交互接口的交互规范中提供的第二加密策略对所述第一版本信息进行加密。该第二加密策略，同样可以是基于对称秘钥或非对称秘钥的相应加密策略。

相对应地，本步骤中，客户端可接收服务端反馈的加密响应报文，所述加密响应报文为服务端基于所述前后台交互接口的交互规范中提供的第二加密策略对所述第一版本信息进行加密并将加密信息封装至响应报文后所得的结果；在接收到服务端的加密响应报文后，客户端可进一步利用所述前后台交互接口的交互规范中提供的第二解密策略对所述加密响应报文中的第一版本信息所在字段进行解密，得到所述第一版本信息。

所述的第二解密策略与所述第二加密策略相匹配，可以是基于对称秘钥或非对称秘钥的解密策略。

客户端手机银行和服务端后台系统之间，基于上述的前后台交互接口进行的基于字段加密的交互逻辑，具体可参阅图3所示。

以下以手机银行为例，提供本实施中利用非对称秘钥方式在前后台交互接口中对请求报文的相应字段信息(用户信息所在字段)或响应报文的相应字段信息(所述第一版本信息所在字段)进行加解密的一种实现流程。

在该示例中，客户端手机银行和服务端后台系统具体使用基于RSA算法的加解密处理，该加解密处理流程包括：

1)后台系统服务启动时，生成公钥和私钥：pub_key1和pri_key1；

其中，公钥pub_key1和私钥pri_key1都存储在后台数据库里，当然，不同客户端也会持有该公钥pub_key1。该公钥、私钥对只有一份，针对所有手机银行用户通用使用。

2)手机银行用户登录时，生成公钥和私钥：pub_key2和pri_key2；

该公钥pub_key2和私钥pri_key2都缓存在客户端手机银行本地，另外，服务端也持有不同客户端所对应的公钥pub_key2。该公钥pub_key2、私钥pri_key2对每个用户生成一份，不同用户的公钥、私钥对不同。

3)手机银行向服务端后台系统请求版本信息时，将手机银行app类型、操作系统信息及用户敏感信息封装在请求报文，并针对请求报文中的敏感信息(手机号、身份证号、核心客户号)字段，用后台系统公钥pub_key1加密，加密后的请求报文上送给后台系统；

4)后台系统使用私钥pri_key1解密，根据解密后的请求报文，从数据库查询对应的版本信息，用手机银行用户公钥pub_key2加密，加密后的信息放在响应报文里，返回给手机银行；

5)手机银行使用私钥pri_key2解密响应报文，得到版本信息。

步骤204、基于所述第一版本信息和客户端所述预定软件产品当前的第二版本信息，对所述预定软件产品进行版本更新处理。

该步骤204与上文实施中的步骤104相同，具体可参阅上文实施中对步骤104的相关说明或描述，不再赘述。

本实施例通过在服务端对预定软件产品(如手机银行App)的不同产品类型、不同客户端操作系统和不同用户信息的版本配置管理及更新控制逻辑与流程进行统一设计与开发，并预先配置预定软件产品的对应于不同产品类型、不同操作系统和不同用户信息的版本信息，可使得客户端预定软件产品如手机银行app基于上送其自身的产品类型信息、客户端操作系统信息和用户信息，从服务端请求对应于其自身相关信息的版本信息进行版本更新，从而实现了一种通用的、灵活的、可扩展的软件产品的版本控制方案。

与上述的应用于客户端的软件产品的版本控制方法相匹配，本申请实施例还公开了一种应用于服务端的软件产品的版本控制方法，具体地，该服务端可以是银行后台服务系统，简称后台系统。

参阅图4，该应用于服务端的软件产品的版本控制方法包括如下处理步骤：

步骤401、获取客户端上送的预定软件产品的产品类型信息及客户端操作系统信息。

具体地，比如，银行后台系统可获取手机银行app在其启动完成后所上送的手机银行app类型及客户端操作系统信息。

步骤402、从预先配置的所述预定软件产品的对应于不同产品类型和不同操作系统的版本信息中，确定对应于所述产品类型信息及客户端操作系统信息的第一版本信息。

本实施例中，预先在服务端对预定软件产品(如手机银行App)的不同产品类型和不同操作系统的版本配置管理及更新控制功能进行了统一设计与开发，并预先在服务端的后台系统配置了预定软件产品的对应于不同产品类型和不同操作系统的版本信息。

服务端的后台系统在获取到客户端上送的产品类型信息及操作系统信息后，从预先配置的预定软件产品的对应于不同产品类型和不同操作系统的版本信息中，查询对应于所上送信息的版本信息，即所述第一版本信息。

步骤403、反馈所述第一版本信息至客户端，以使客户端基于所述第一版本信息对所述预定软件产品进行版本更新处理。

之后，将查询所得的第一版本信息反馈至客户端，以便于客户端基于服务端反馈的第一版本信息及自身预定软件产品的当前第二版本信息对其预定软件产品进行版本更新处理。具体地，比如，银行后台系统将查询所得的对应于所上送的手机银行app类型及操作系统信息的手机银行最新版本信息反馈至手机银行app。

本实施例针对不同类型的软件产品实现了通用的版本配置管理及版本更新控制功能，无需由不同团队分别开发并各自维护，降低了版本管理及更新控制的代码开发量及维护成本。

与应用于客户端的软件产品的版本控制方法相匹配，在一可选实施例中，所述应用于服务端的软件产品的版本控制方法在获取客户端上送的预定软件产品的产品类型信息及客户端操作系统信息时，还可以包括：获取客户端上送的所述预定软件产品的登录用户的用户信息。

从而，参阅图5，该应用于服务端的软件产品的版本控制方法，还可以进一步通过以下的处理过程实现：

步骤501、获取客户端上送的预定软件产品的产品类型信息、客户端操作系统信息及用户信息。

可选地，由于用户信息涉密，服务端后台系统与客户端之间可基于加密方式进行用户信息的交互。

与客户端的加密处理过程相匹配，对于步骤501，服务端后台系统可通过以下处理实现：

利用前后台交互接口接收客户端上送的加密请求报文；

利用前后台交互接口的交互规范中提供的第一解密策略对所述加密请求报文中用户信息所在的字段进行解密，得到解密后的请求报文；

从所述解密后的请求报文中提取所述产品类型信息、所述客户端操作系统信息和所述用户信息。

所述第一解密策略与上文实施中的第一加密策略相匹配，可以是基于对称秘钥或非对称秘钥的解密策略。

步骤502、从预先配置的所述预定软件产品的对应于不同产品类型、不同操作系统和不同用户的版本信息中，确定对应于所述产品类型信息、所述客户端操作系统信息和所述用户信息的第一版本信息。

步骤503、反馈所述第一版本信息至客户端，以使客户端基于所述第一版本信息对所述预定软件产品进行版本更新处理。

类似地，基于安全考虑，服务端后台信息可对查询所得的第一版本信息进行加密基础上的版本信息反馈。

该加密过程可以包括：

基于所述前后台交互接口的交互规范中提供的第二加密策略对所述第一版本信息进行加密，得到加密信息；

将加密信息封装至响应报文得到加密响应报文；

反馈所述加密响应报文至客户端。

此处的第二加密策略与上文实施例中的第二解密策略相匹配，可以是基于对称秘钥或非对称秘钥的解密策略。

其中，客户端软件产品和服务端后台系统使用基于RSA算法的加解密流程，对请求报文的相应字段信息或响应报文的相应字段信息进行基于非对称秘钥的加解密处理流程，具体可参阅上文中提供的关于两套公私钥(pub_key1和pri_key1、pub_key2和pri_key2)的相关示例，此处不再赘述。

实施中，以手机银行为例，可预先在后台系统编写H5和Java代码，以实现通用的手机银行版本配置管理功能及更新控制功能，并提供接口给手机银行访问。如具体实现一后台系统版本配置模块、前后台交互接口，并针对前后台交互接口设计交互规范和接口字段加密方法，由此相应再实现一接口字段加密模块等。业务人员可在后台系统管理端的配置模块配置手机银行的版本更新信息，包括但不限于app类型(国内、海外、企业)、版本号、操作系统(Android、IOS)、更新策略(强制更新、提示更新)等等。手机银行启动时，调用交互接口访问后台系统配置的版本更新信息，且具体地可首先基于接口字段加密模块对用户敏感信息进行加密，并上送由app类型、操作系统及加密用户信息等各字段构成的请求报文至后台系统，后台系统相应返回对应所上送的APP类型、操作系统信息及用户信息的版本更新信息(即所述第一版本信息)给手机银行，以使后续银行基于后台系统反馈的版本信息及自身版本信息执行版本更新处理。

对应于上述的应用于客户端的软件产品的版本控制方法，本申请实施例还公开了一种应用于客户端的软件产品的版本控制装置，参阅图6，该装置包括：

第一获取单元601，用于获取客户端预定软件产品的产品类型信息及客户端操作系统信息；

发送单元602，用于发送所述产品类型信息及所述操作系统信息至服务端；服务端预先配置有所述预定软件产品的对应于不同产品类型和不同操作系统的版本信息；

接收单元603，用于接收服务端反馈的所述预定软件产品的对应于所述产品类型信息及客户端操作系统信息的第一版本信息；

更新处理单元604，用于基于所述第一版本信息和客户端所述预定软件产品当前的第二版本信息，对所述预定软件产品进行版本更新处理。

在本申请实施例的一可选实施方式中，第一获取单元601在获取客户端预定软件产品的产品类型信息及客户端操作系统信息时，还用于：获取所述预定软件产品的登录用户的用户信息；

发送单元602在发送所述产品类型信息及所述操作系统信息至服务端时，还包括：发送所述用户信息至服务端；其中，服务端预先配置有所述预定软件产品的对应于不同产品类型、不同操作系统和不同用户的版本信息；

接收单元603接收服务端反馈的所述预定软件产品的对应于所述产品类型信息及客户端操作系统信息的第一版本信息，具体包括：接收服务端反馈的所述预定软件产品的对应于所述产品类型信息、所述客户端操作系统信息及所述用户信息的第一版本信息。

在本申请实施例的一可选实施方式中，发送单元602具体用于：将所述产品类型信息、所述操作系统信息和所述用户信息按预定格式封装为一请求报文；利用前后台交互接口的交互规范中提供的第一加密策略对所述用户信息在所述请求报文中对应的字段进行加密，得到加密处理后的请求报文；利用前后台交互接口发送所述加密处理后的请求报文至服务端。

在本申请实施例的一可选实施方式中，接收单元603具体用于：接收服务端反馈的加密响应报文，所述加密响应报文为服务端基于所述前后台交互接口的交互规范中提供的第二加密策略对所述第一版本信息进行加密并将加密信息封装至响应报文后所得的结果；利用所述前后台交互接口的交互规范中提供的第二解密策略对所述加密响应报文中的第一版本信息所在字段进行解密，得到所述第一版本信息。

在本申请实施例的一可选实施方式中，所述第一版本信息包括第一版本号、版本更新内容及更新策略；所述第二版本信息包括第二版本号；

更新处理单元604具体用于：

比较所述第一版本号和所述第二版本号；

若所述第一版本号不大于所述第二版本号，不更新所述预定软件产品的版本；

若所述第一版本号大于所述第一版本号，执行以下处理：

获取所述更新策略；

在所述更新策略为强制更新的情况下，基于所述版本更新内容对所述预定软件产品进行强制的版本更新；

在所述更新策略为提示更新的情况下，生成并展示版本更新提示，以基于用户选择确定是否更新所述预定软件产品的版本。

对于本申请实施例公开的应用于客户端的软件产品的版本控制装置而言，由于其与上文相应实施例公开的应用于客户端的软件产品的版本控制方法相对应，所以描述的比较简单，相关相似之处请参见上文相应实施例中应用于客户端的软件产品的版本控制方法部分的说明即可，此处不再详述。

对应于上述的应用于服务端的软件产品的版本控制方法，本申请实施例还公开了一种应用于服务端的软件产品的版本控制装置，参阅图7，该装置包括：

第二获取单元701，用于获取客户端上送的预定软件产品的产品类型信息及客户端操作系统信息；

确定单元702，用于从预先配置的所述预定软件产品的对应于不同产品类型和不同操作系统的版本信息中，确定对应于所述产品类型信息及客户端操作系统信息的第一版本信息；

反馈单元703，用于反馈所述第一版本信息至客户端，以使客户端基于所述第一版本信息对所述预定软件产品进行版本更新处理。

在本申请实施例的一可选实施方式中，第二获取单元701在获取客户端上送的预定软件产品的产品类型信息及客户端操作系统信息时，还用于：获取客户端上送的所述预定软件产品的登录用户的用户信息；

确定单元702进一步用于：从预先配置的所述预定软件产品的对应于不同产品类型、不同操作系统和不同用户的版本信息中，确定对应于所述产品类型信息、所述客户端操作系统信息和所述用户信息的第一版本信息。

在本申请实施例的一可选实施方式中，第二获取单元701具体用于：利用前后台交互接口接收客户端上送的加密请求报文；利用前后台交互接口的交互规范中提供的第一解密策略对所述加密请求报文中用户信息所在的字段进行解密，得到解密后的请求报文；从所述解密后的请求报文中提取所述产品类型信息、所述客户端操作系统信息和所述用户信息。

在本申请实施例的一可选实施方式中，反馈单元703，具体用于：基于所述前后台交互接口的交互规范中提供的第二加密策略对所述第一版本信息进行加密，得到加密信息；将加密信息封装至响应报文得到加密响应报文；反馈所述加密响应报文至客户端。

在本申请实施例的一可选实施方式中，如图8所示，应用于服务端的所述装置还包括配置单元704，用于配置或增添配置所述预定软件产品的新的产品类型的版本信息；其中，所配置的版本信息至少包括所述新的产品类型的对应的产品类型信息、操作系统信息、版本更新内容及更新策略。

对于本申请实施例公开的应用于服务端的软件产品的版本控制装置而言，由于其与上文相应实施例公开的应用于服务端的软件产品的版本控制方法相对应，所以描述的比较简单，相关相似之处请参见上文相应实施例中应用于服务端的软件产品的版本控制方法部分的说明即可，此处不再详述。

另外，本申请实施例还公开了一种软件产品的版本控制系统，该系统包括：服务端设备及多个客户端设备；

服务端设备可以是但不限于银行后台系统所在的服务器(可以是一个或多个物理机，但逻辑上为一个)，客户端设备可以是但不限于智能手机、平板等移动终端。

其中，所述服务端设备用于执行如上文相应实施例提供的应用于服务端的软件产品的版本控制方法，所述客户端设备用于执行如上文相应实施例提供的应用于客户端的软件产品的版本控制方法。

综上所述，本申请提供的软件产品的版本控制方法、装置及系统，具备以下的技术效果：

1)更好的兼容性：同时兼容国内手机银行、海外手机银行、企业手机银行的版本管理功能；

2)提高代码复用率：将手机银行版本更新管理统一上收到后台系统进行开发，一套逻辑、一套代码，可极大提高代码复用率、节省人力资源；

3)更好的扩展性：若有新的APP产品要增加版本配置管理功能，只需后台系统的版本管理模块新增支持一种类型，即可进行新APP产品版本更新信息的配置管理。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

为了描述的方便，描述以上系统或装置时以功能分为各种模块或单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

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

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (13)

1.一种软件产品的版本控制方法，其特征在于，应用于客户端；

所述方法包括：

获取客户端预定软件产品的产品类型信息及客户端操作系统信息；

发送所述产品类型信息及所述操作系统信息至服务端；服务端预先配置有所述预定软件产品的对应于不同产品类型和不同操作系统的版本信息；

接收服务端反馈的所述预定软件产品的对应于所述产品类型信息及客户端操作系统信息的第一版本信息；

基于所述第一版本信息和客户端所述预定软件产品当前的第二版本信息，对所述预定软件产品进行版本更新处理。

2.根据权利要求1所述的方法，其特征在于，在获取客户端预定软件产品的产品类型信息及客户端操作系统信息时，还包括：

获取所述预定软件产品的登录用户的用户信息；

在发送所述产品类型信息及所述操作系统信息至服务端时，还包括：

发送所述用户信息至服务端；其中，服务端预先配置有所述预定软件产品的对应于不同产品类型、不同操作系统和不同用户的版本信息；

所述接收服务端反馈的所述预定软件产品的对应于所述产品类型信息及客户端操作系统信息的第一版本信息，包括：

接收服务端反馈的所述预定软件产品的对应于所述产品类型信息、所述客户端操作系统信息及所述用户信息的第一版本信息。

3.根据权利要求2所述的方法，其特征在于，所述在发送所述产品类型信息及所述操作系统信息至服务端时发送所述用户信息至服务端，包括：

将所述产品类型信息、所述操作系统信息和所述用户信息按预定格式封装为一请求报文；

利用前后台交互接口的交互规范中提供的第一加密策略对所述用户信息在所述请求报文中对应的字段进行加密，得到加密处理后的请求报文；

利用前后台交互接口发送所述加密处理后的请求报文至服务端。

4.根据权利要求3所述的方法，其特征在于，所述接收服务端反馈的所述预定软件产品的对应于所述产品类型信息及客户端操作系统信息的第一版本信息，包括：

接收服务端反馈的加密响应报文，所述加密响应报文为服务端基于所述前后台交互接口的交互规范中提供的第二加密策略对所述第一版本信息进行加密并将加密信息封装至响应报文后所得的结果；

利用所述前后台交互接口的交互规范中提供的第二解密策略对所述加密响应报文中的第一版本信息所在字段进行解密，得到所述第一版本信息。

5.根据权利要求1所述的方法，其特征在于，所述第一版本信息包括第一版本号、版本更新内容及更新策略；所述第二版本信息包括第二版本号；

所述基于所述第一版本信息和客户端所述预定软件产品当前的第二版本信息，对所述预定软件产品进行版本更新处理，包括：

比较所述第一版本号和所述第二版本号；

若所述第一版本号不大于所述第二版本号，不更新所述预定软件产品的版本；

若所述第一版本号大于所述第一版本号，执行以下处理：

获取所述更新策略；

在所述更新策略为强制更新的情况下，基于所述版本更新内容对所述预定软件产品进行强制的版本更新；

在所述更新策略为提示更新的情况下，生成并展示版本更新提示，以基于用户选择确定是否更新所述预定软件产品的版本。

6.一种软件产品的版本控制方法，其特征在于，应用于服务端；

所述方法包括：

获取客户端上送的预定软件产品的产品类型信息及客户端操作系统信息；

从预先配置的所述预定软件产品的对应于不同产品类型和不同操作系统的版本信息中，确定对应于所述产品类型信息及客户端操作系统信息的第一版本信息；

反馈所述第一版本信息至客户端，以使客户端基于所述第一版本信息对所述预定软件产品进行版本更新处理。

7.根据权利要求6所述的方法，其特征在于，在获取客户端上送的预定软件产品的产品类型信息及客户端操作系统信息时，还包括：

获取客户端上送的所述预定软件产品的登录用户的用户信息；

所述从预先配置的所述预定软件产品的对应于不同产品类型和不同操作系统的版本信息中，确定对应于所述产品类型信息及客户端操作系统信息的第一版本信息，包括：

从预先配置的所述预定软件产品的对应于不同产品类型、不同操作系统和不同用户的版本信息中，确定对应于所述产品类型信息、所述客户端操作系统信息和所述用户信息的第一版本信息。

8.根据权利要求7所述的方法，其特征在于，所述在获取客户端上送的预定软件产品的产品类型信息及客户端操作系统信息时，获取客户端上送的所述预定软件产品的登录用户的用户信息，包括：

利用前后台交互接口接收客户端上送的加密请求报文；

利用前后台交互接口的交互规范中提供的第一解密策略对所述加密请求报文中用户信息所在的字段进行解密，得到解密后的请求报文；

从所述解密后的请求报文中提取所述产品类型信息、所述客户端操作系统信息和所述用户信息。

9.根据权利要求8所述的方法，其特征在于，所述反馈所述第一版本信息至客户端，包括：

基于所述前后台交互接口的交互规范中提供的第二加密策略对所述第一版本信息进行加密，得到加密信息；

将加密信息封装至响应报文得到加密响应报文；

反馈所述加密响应报文至客户端。

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

增添配置所述预定软件产品的新的产品类型的版本信息；

其中，所配置的版本信息至少包括所述新的产品类型的对应的产品类型信息、操作系统信息、版本更新内容及更新策略。

11.一种软件产品的版本控制装置，其特征在于，应用于客户端；

第一获取单元，用于获取客户端预定软件产品的产品类型信息及客户端操作系统信息；

发送单元，用于发送所述产品类型信息及所述操作系统信息至服务端；服务端预先配置有所述预定软件产品的对应于不同产品类型和不同操作系统的版本信息；

接收单元，用于接收服务端反馈的所述预定软件产品的对应于所述产品类型信息及客户端操作系统信息的第一版本信息；

更新处理单元，用于基于所述第一版本信息和客户端所述预定软件产品当前的第二版本信息，对所述预定软件产品进行版本更新处理。

12.一种软件产品的版本控制装置，其特征在于，应用于服务端；

所述装置包括：

第二获取单元，用于获取客户端上送的预定软件产品的产品类型信息及客户端操作系统信息；

确定单元，用于从预先配置的所述预定软件产品的对应于不同产品类型和不同操作系统的版本信息中，确定对应于所述产品类型信息及客户端操作系统信息的第一版本信息；

反馈单元，用于反馈所述第一版本信息至客户端，以使客户端基于所述第一版本信息对所述预定软件产品进行版本更新处理。

13.一种软件产品的版本控制系统，其特征在于，包括：

服务端设备及多个客户端设备；

其中，所述服务端设备用于执行如权利要求6-10任一项所述的方法，所述客户端设备用于执行如权利要求1-5任一项所述的方法。

Images