CN108763065A - 一种移动应用灰度发布系统及方法 - Google Patents

Abstract

本发明公开了一种移动应用灰度发布系统及方法，包括：灰度发布模块、数据统计模块和AB测试模块；灰度发布模块，用于依据预设的流程逐量发布移动应用版本；数据统计模块，用于获取预设关键点数据，将预设关键点数据以预设的样式进行展示，并根据预设关键点数据判断移动应用版本是否出现故障；AB测试模块用于通过服务器分组的方式对不同的目标用户进行移动应用版本的功能测试。这样，对发布系统的功能进行了完善，通过对移动版本按照预设的流程逐量的发布，不仅保障了发布的准确性也使得当出现发布的移动应用版本故障时，可以及时的对移动应用版本进行补救。除此之外，还能够及时的发现漏洞和故障，有利于对移动应用版本的优化。

Description

一种移动应用灰度发布系统及方法

技术领域

本发明涉及软件发布领域，尤其涉及一种移动应用灰度发布系统及方法。

背景技术

随着移动设备的不断普及，移动设备已经深入到广大用户的生活当中，为了提高移动端用户群体的用户体验，适用性以及稳定性等，应用一般需要定期的发布新版本或者及时更新新的功能来满足客户需求。

现有技术中，对于新版本或者新功能的发布比较简单，并且是全量发布，直接面向的是所有的用户群体，如果发布不完善，会给产品带来极大的负面影响。除此之外，也无法及时发现线上的漏洞和故障，不易于应用的优化。

发明内容

有鉴于此，本发明实施例公开了一种移动应用灰度发布系统及方法，对发布系统的功能进行了完善，并且，通过对移动版本按照预设的流程逐量的发布，不仅保障了发布的准确性也使得当出现发布的移动应用版本故障时，可以及时的对移动应用版本进行补救。除此之外，还能够及时的发现漏洞和故障，有利于对移动应用版本的优化。

本发明公开了一种移动应用灰度发布系统，包括：灰度发布模块、数据统计模块和AB测试模块；

所述灰度发布模块，用于依据预设的流程逐量发布移动应用版本；

所述数据统计模块，用于获取预设关键点数据，将所述预设关键点数据以预设的样式进行展示，并根据所述预设关键点数据判断移动应用版本是否出现故障；

所述AB测试模块用于通过服务器分组的方式对不同的目标用户进行移动应用版本的功能测试。

可选的，所述灰度发布模块，包括：

发布审批模块，用于当接收到对所述移动应用版本进行发布的指令后，向预设的审批人员发送移动应用版本的审批单，并接收审批结果；

发布流程控制单元，用于在所述新版本审批通过的情况下，按照预设的发布流程逐量的发布所述移动应用版本。

可选的，所述预设的发布流程包括：

内灰阶段、外灰阶段和全景阶段；

在所述内灰阶段，确定内灰发布量，向第一目标用户逐量的发布所述移动应用版本，当接收到内灰停止指令时，停止发布，当接收到开启外灰阶段后开启外灰阶段；

在所述外灰阶段，确定外灰发布量，向第二目标用户逐量的发布所述移动应用版本，当接收到外灰停止指令时，停止发布，当接收到全量发布指令后开启全量阶段；

在所述全量阶段，向所有的目标用户逐量的发布所述移动应用版本，当接收到全量停止指令时，停止发布。

可选的，所述数据统计模块包括：

数据展示子模块，用于获取第一预设关键点数据，将所述第一预设关键点数据以预设的样式进行展示；

监控子模块，用于定期获取第二预设关键点数据，根据所述第二预设关键点数据判断移动应用版本是否出现故障。

可选的，所述数据展示子模块包括：

第一数据获取单元，用获取第一预设关键点数据；

样式转换单元，用于将第一预设关键点数据转换为预设的样式；

展示单元，用于调取转换为预设样式的目标时间段的数据，并展示。

可选的，所述数据监控子模块包括：

第二数据获取单元，用于定期的获取第二预设关键点数据；

监控指标更新单元，用于更新移动应用版本的监控指标的报警配置；

监控单元，用于依据采集的所述第二预设关键点数据和所述移动应用版本的监控指标的报警配置确定所述第二预设关键点数据是否出现异常，在出现异常的情况下对异常率进行累积；

报警单元，用于当任何一个监控指标的异常率达到预设的阈值的情况下，报警。

可选的，所述监控子模块还包括：

熔断单元，用于在移动应用版本逐步放量的过程中，若目标监控指标的异常率达到预设的阈值时，停止对移动应用版本的发布。

可选的，所述AB测试模块包括：

配置请求单元，用于在客户端不存在目标功能的缓存配置或者缓存配置的存储时间超过了设定的过期时间的情况下，向服务器发送配置请求；

分组单元，用于使服务器确定每个目标功能的目标人群；

下发配置单元，用于使服务器向每个目标人群发送相应的目标功能的配置。

可选的，还包括：

灰度发布模块，还包括：

记录子模块，用于将所述移动应用版本发布的过程通过快照的方式进行记录，以便用户查看发布的历史记录。

本发明还公开了一种移动应用灰度发布方法，包括：

依据预设的流程逐量发布移动应用版本；

在所述移动应用发布的过程中，获取预设关键点数据，将所述预设关键点数据以预设的样式进行展示，并根据所述预设关键点数据判断所述移动应用版本是否出现故障；

在所述移动应用发布的过程中，通过服务器分组的方式对移动应用版本的功能进行测试。

本发明实施例公开了一种移动应用灰度发布系统及方法，包括：灰度发布模块、数据统计模块和AB测试模块；灰度发布模块，用于依据预设的流程逐量发布移动应用版本；数据统计模块，用于获取预设关键点数据，将预设关键点数据以预设的样式进行展示，并根据预设关键点数据判断移动应用版本是否出现故障；AB测试模块用于通过服务器分组的方式对不同的目标用户进行移动应用版本的功能测试。这样，对发布系统的功能进行了完善，通过对移动版本按照预设的流程逐量的发布，不仅保障了发布的准确性也使得当出现发布的移动应用版本故障时，可以及时的对移动应用版本进行补救。除此之外，还能够及时的发现漏洞和故障，有利于对移动应用版本的优化。

并且，通过服务器分组解决线上多个实验之间的干扰问题。

进一步的，在移动应用版本发布之前对待发布的移动应用版本进行审批的方式，进一步保障了移动应用版发布的准确性。

附图说明

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

图1示出了本发明实施例提供的一种移动应用灰度发布系统的结构示意图；

图2示出了本发明实施例提供的一种审批流程示意图；

图3示出了本发明实施例提供的一种分组测试流程的示意图；

图4示出了本发明实施例提供的一种移动应用灰度发布方法的流程示意图。

具体实施方式

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

参考图1，示出了本发明实施例提供的一种移动应用灰度发布系统的结构示意图，在本实施例中，该系统包括：

灰度发布模块100、数据统计模块200和AB测试模块300；

灰度发布模块100，用于依据预设的流程逐量发布移动应用版本；

所述数据统计模块200，用于获取预设关键点数据，将所述预设关键点数据以预设的样式进行展示，并根据所述预设关键点数据判断移动应用版本是否出现故障；

AB测试模块300，用于通过服务器分组的方式对不同的目标用户进行移动应用版本的功能测试。

接下来对移动应用灰度发布系统的各个模块进行详细的介绍：

1、针对于灰度发布模块100：

本实施例中，为了防止发生错误发布的情况，本实施例中的灰度发布模块还可以实现：按照预设流程的发布以及发布的审批控制，具体的，灰度发布模块100包括：

发布审批模块，用于当接收到对所述移动应用版本进行发布的指令后，向预设的审批人员发送移动应用版本的审批单，并接收审批结果；

发布流程控制单元，用于在所述新版本审批通过的情况下，按照预设的发布流程逐量的发布所述移动应用版本。

举例说明：参考图2的审批流程，当申请人点击相应的操作之后，会由工作流自动创建审批单，其中，审批人员可以是预先设定的，也可以是在审批单生成后，技术人员或者根据预设的规则确定的。审批单生成后通知相关的负责人进行审批操作，其中，可以通过多种渠道向相关的负责人员发送审批单，例如可以通过邮件、短信、或者任何一种即时通信的方式；当审批完成后，发布审批模块可以接收审批人员反馈的审批结果。申请人可以根据相关的审批结果确定发布的移动应用版本是否正确，若正确的话，则对移动应用版本进行发布。

其中，审批的过程可以是所有的审批人员同步进行，也可以是按照预设的顺序进行的，例如在A审批完成后，再由B进行审批，依次类推直到所有的相关负责人审批完毕。

本实施例中，预设的发布流程可以包括：内灰阶段、外灰阶段以及全量阶段。

其中，在所述内灰阶段，确定内灰发布量，向第一目标用户逐量的发布所述移动应用版本，当接收到内灰停止指令时，停止发布，当接收到外灰测试指令后开启外灰测试；

在所述外灰测试阶段，确定外灰发布量，向第二目标用户逐量的发布所述移动应用版本，当接收到外灰停止指令时，停止发布，当接收到全量发布指令后开启全量测试；

在所述全量阶段，确定全量发布量，向所有的目标用户逐量的发布所述移动应用版本，当接收到全量停止指令时，停止发布。

可以理解的是，无论是内灰阶段、外灰阶段还是全量阶段，都可以限定发布的数量，并且在限定的数量范围内，逐量的发布。逐量发布可以理解为在一定的时间内，发布一定数量的移动应用版本，而不是一下子发布完设定的发布量。并且，在逐量发布的过程中，每个阶段都可以停止发布。但是发布的流程一定是在执行了内灰阶段后才可以执行外灰阶段，执行完外灰阶段后，才可以执行全量阶段，不可以逆向执行。也就是说，在执行内灰阶段时，只能停止发布或者继续执行外灰阶段；在执行外灰阶段时，只能是停止发布或者继续执行全量阶段，但是不能再去执行内灰阶段；在执行全量阶段时，只能执行停止全量发布，不可以返回执行外灰阶段和内灰阶段。

本实施例中，通过按照预设的流程的对移动应用的版本进行发布，可以避免直接跳过某个阶段直接放量的错误操作的发生。

其中，为了方便查看每次进行灰度发布的流程，记录灰度的关键节点的信息，并且按照预设的流程进行逐量发布，系统可以使用GrayControlDO类来进行灰度发布流程的控制。本实施例中，为了便于用户了解自己的发布操作是否有误，可以对用户的发布操作进行记录，这样用户可以方便的额调取发布过程中的历史记录，进而通过历史记录了解发布操作是否有误，具体的，灰度发布模块还包括：

记录子模块，用于将所述移动应用版本发布的过程通过快照的方式进行记录，以便用户查看发布的历史记录。

除此之外，灰度发布模块为移动应用灰度发布系统的基本功能，可以实现应用的打包、动态更新、移动应用版本包的灰度发布等基本功能。

举例说明：灰度发布模块中对应用包的操作包括：通过Button来创建新的应用包信息，通过点击批量灰度Button进去到相应应用包的灰度页面进行灰度操作，通过点击详情Button进入应用包相关信息的详情页面来查看相关包信息等。

2、针对数据统计模块200：

本实施例中，数据统计模块主要实现两个功能：数据展示和数据监控，具体的，数据统计模块200包括：

数据展示子模块，用于获取第一预设关键点数据，将所述第一预设关键点数据以预设的样式进行展示；

监控子模块，用于定期获取第二预设关键点数据，根据所述第二预设关键点数据判断移动应用版本是否出现故障。

其中，对于数据的获取可以采用在客户端预设关键点的方式，并通过雷达系统采集预设关键点数据。

举例说明：预设关键点数据可以包括：移动应用的日活数量、移动应用的Crash数量、线上版本的活跃数量等等。其中，第一预设关键点数据和第二预设关键点数据可以相同也可以不同。

本实施例中，初步得到的预设关键点数据形式较多、也不统一，不利于技术人员理解，为了方便技术人员理解采集到的数据，可以将预设关键点数据进一步加工后再进行展示，例如可以将离散的数据聚合成按照时间区间的方式呈现给用户，用户可以根据需求选择展示某个时间段的数据，具体的，数据展示子模块包括：

第一数据获取单元，用获取第一预设关键点数据；

样式转换单元，用于将第一预设关键点数据转换为预设的样式；

展示单元，用于调取转换为预设样式的目标时间段的数据，并展示。

但是，后端进行数据处理时，一般是将离散的数据进行聚合，然而这是个比较耗时的计算过程，在实际应用中如果在短时间内多次请求会造成系统的崩溃，因此每次请求数据的时候，系统对这个数据也添加了缓存操作，缓存的Key可以采用：时间+平台+版本号+功能名来命名，同时为了防止过多数据的缓存，系统会过滤掉超时时间超过预设的第一时间阈值的查询数据，以及时间跨度超过第二时间阈值的数据，以防止恶意的请求造成缓存资源的浪费。

本实施例中，通过数据展示子模块，开发人员或者产品经理可以根据展示的数据情况，了解到移动应用的线上运行情况和用户的反馈情况。

其中，对于监控子模块，具体的，包括：

第二数据获取单元，用于定期的获取第二预设关键点数据；

监控指标更新单元，用于更新移动应用版本的监控指标的报警配置；

监控单元，用于依据采集的所述第二预设关键点数据和所述移动应用版本的监控指标的报警配置确定所述第二预设关键点数据是否出现异常，在出现异常的情况下对异常率进行累积；

报警单元，用于当任何一个监控指标的异常率达到预设的阈值的情况下，报警。

本实施例中，第二预设关键点数据可以包括客户端预设关键点数据和Mtop预设关键点数据。

本实施例中，预设的监控指标可以表示为移动应用的某些功能，对监控指标的更新可以是对某些功能的报警配置的更新，通过报警配置对第二预设关键点数据进行监控，若出现于报警配置相同的异常情况，则更新异常率，当任何一个监控指标的异常率达到预设的阈值时，则向相关的人员进行报警。

并且，由于在内灰阶段、外灰阶段和全量阶段是对移动版本逐步放量的，在逐步放量的过程中，系统不可能一下子就让所有的用户全都更新完了，而是需要一段时间逐渐完成的，在这段时间内，若出现故障报警的情况，开发者还可以停止发布，及时的弥补出现的错误，具体的，所述监控子模块还包括：

熔断单元，用于在移动应用版本逐步放量的过程中，若目标监控指标的异常率达到预设的阈值时，停止对移动应用版本的发布。

除此之外，除了可以依据规则自动熔断外，用户还可以根据需求进行手动熔断。

3、针对AB测试模块300：

本实施例中，为了研究出最适合用户体验的方案，可以通过用户对移动应用的不同功能进行测试，具体的，AB测试模块300包括：

配置请求单元，用于在客户端不存在目标功能的缓存配置或者缓存配置的存储时间超过了设定的过期时间的情况下，向服务器发送配置请求；

分组单元，用于使服务器确定每个目标功能的目标人群；

下发配置单元，用于使服务器向每个目标人群发送相应的目标功能的配置。

本实施例中，参考图3的分组测试流程，客户端优先读取本地缓存配置进行分工，如果本地缓存不存在或者缓存的存储时间超过了设定的过期时间的时候，客户端向服务器发送请求进行分组请求，服务端接收到请求后线确定目标人群，之后将分组配置下发到客户端上，客户端在执行回调后将新的配置内容缓存到本地当中。

本实施例中，通过服务器分组解决线上多个实验之间的干扰问题，现有技术中，通常采用客户端分组的方式，但是客户端分组的方式，一个客户通常会参与多个功能的测试，在该种方式下，很难证明用户在参与测试之前各个功能的数据是没有影响的，但是若一个用户只能参与一个功能的测试，则可以解决这个问题，服务器根据功能确定目标人群。

本实施例中，随着互联网的不断发展，单个的服务器的服务器架构己经越来越难满足用户的正常需求和体验。当一个系统的用户量到达一定的数量级或者这个系统需要较高的稳定性需求或者安全需求的时候，单服务器系统会暴露出很多的问题。为了解决这样的问题，系统采用了分布式的方式。分布式系统是组织在网络之上的系统软件，具有较好的透明性和内聚性，尽管系统是分布在不同的物理空间之上，但是在用户看来却和单系统没有区别。其优点在于，具有良好的并行和高性能处理能力，具有较高的容错能力、稳定性以及安全性。更重要的，分布式系统具有很好的可扩张性，这为以后系统的迁移、备份、更改部分底层实现等提供了方便。

本实施例中，公开的移动应用发布系统包括：灰度发布模块、数据统计模块和AB测试模块；灰度发布模块，用于依据预设的流程逐量发布移动应用版本；数据统计模块，用于获取预设关键点数据，将预设关键点数据以预设的样式进行展示，并根据预设关键点数据判断移动应用版本是否出现故障；AB测试模块用于通过服务器分组的方式对不同的目标用户进行移动应用版本的功能测试。通过对移动版本按照预设的流程逐量的发布，不仅保障了发布的准确性也使得当出现发布的移动应用版本故障时，可以及时的对移动应用版本进行补救。除此之外，还能够及时的发现漏洞和故障，有利于对移动应用版本的优化。

参考图4示出了本发明实施例提供的一种移动应用灰度发布方法的流程示意图，在本实施例中，该方法包括：

S401：依据预设的流程逐量发布移动应用版本；

S402：在所述移动应用发布的过程中，获取预设关键点数据，将所述预设关键点数据以预设的样式进行展示，并根据所述预设关键点数据判断所述移动应用版本是否出现故障；

S403：在所述移动应用发布的过程中，通过服务器分组的方式对移动应用版本的功能进行测试。

可选的，所述依据预设的流程逐量发布移动应用版本，包括：

当接收到对所述移动应用版本进行发布的指令后，向预设的审批人员发送移动应用版本的审批单，并接收所述审批人员的审批结果；

在所述新版本审批通过的情况下，按照预设的发布流程逐量的发布所述移动应用版本。

其中，所述预设的发布流程包括：

内灰阶段、外灰阶段和全景阶段；

在所述内灰阶段，确定内灰发布量，向第一目标用户逐量的发布所述移动应用版本，当接收到内灰停止指令时，停止发布，当接收到开启外灰阶段后开启外灰阶段；

在所述外灰阶段，确定外灰发布量，向第二目标用户逐量的发布所述移动应用版本，当接收到外灰停止指令时，停止发布，当接收到全量发布指令后开启全量阶段；

在所述全量阶段，向所有的目标用户逐量的发布所述移动应用版本，当接收到全量停止指令时，停止发布。

可选的，获取预设关键点数据，将所述预设关键点数据以预设的样式进行展示，包括：

获取第一预设关键点数据；

将第一预设关键点数据转换为预设的样式；

调取转换为预设样式的目标时间段的数据，并展示。

可选的，获取预设关键点数据，并根据所述预设关键点数据判断所述移动应用版本是否出现故障，包括：

定期获取第二预设关键点数据；

更新移动应用版本的监控指标的报警配置；

依据采集的所述第二预设关键点数据和所述移动应用版本的监控指标的报警配置确定所述第二预设关键点数据是否出现异常，在出现异常的情况下对异常率进行累积；

当任何一个监控指标的异常率达到预设的阈值的情况下，报警。

可选的，在所述移动应用发布的过程中，通过服务器分组的方式对移动应用版本的功能进行测试，包括：

在客户端不存在目标功能的缓存配置或者缓存配置的存储时间超过了设定的过期时间的情况下，向服务器发送配置请求；

服务器确定每个目标功能的目标人群；

服务器向每个目标人群发送相应的目标功能的配置。

本实施例中，通过对移动版本按照预设的流程逐量的发布，不仅保障了发布的准确性也使得当出现发布的移动应用版本故障时，可以及时的对移动应用版本进行补救。除此之外，还能够及时的发现漏洞和故障，有利于对移动应用版本的优化。

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

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

Claims (10)

1.一种移动应用灰度发布系统，其特征在于，包括：灰度发布模块、数据统计模块和AB测试模块；

所述灰度发布模块，用于依据预设的流程逐量发布移动应用版本；

所述数据统计模块，用于获取预设关键点数据，将所述预设关键点数据以预设的样式进行展示，并根据所述预设关键点数据判断移动应用版本是否出现故障；

所述AB测试模块用于通过服务器分组的方式对不同的目标用户进行移动应用版本的功能测试。

2.根据权利要求1所述的系统，其特征在于，所述灰度发布模块，包括：

发布审批模块，用于当接收到对所述移动应用版本进行发布的指令后，向预设的审批人员发送移动应用版本的审批单，并接收审批结果；

发布流程控制单元，用于在所述新版本审批通过的情况下，按照预设的发布流程逐量的发布所述移动应用版本。

3.根据权利要求2所述的系统，其特征在于，所述预设的发布流程包括：

内灰阶段、外灰阶段和全景阶段；

在所述内灰阶段，确定内灰发布量，向第一目标用户逐量的发布所述移动应用版本，当接收到内灰停止指令时，停止发布，当接收到开启外灰阶段后开启外灰阶段；

在所述外灰阶段，确定外灰发布量，向第二目标用户逐量的发布所述移动应用版本，当接收到外灰停止指令时，停止发布，当接收到全量发布指令后开启全量阶段；

在所述全量阶段，向所有的目标用户逐量的发布所述移动应用版本，当接收到全量停止指令时，停止发布。

4.根据权利要求1所述的系统，其特征在于，所述数据统计模块包括：

数据展示子模块，用于获取第一预设关键点数据，将所述第一预设关键点数据以预设的样式进行展示；

监控子模块，用于定期获取第二预设关键点数据，根据所述第二预设关键点数据判断移动应用版本是否出现故障。

5.根据权利要求4所述的系统，其特征在于，所述数据展示子模块包括：

第一数据获取单元，用获取第一预设关键点数据；

样式转换单元，用于将第一预设关键点数据转换为预设的样式；

展示单元，用于调取转换为预设样式的目标时间段的数据，并展示。

6.根据权利要求4所述的系统，其特征在于，所述数据监控子模块包括：

第二数据获取单元，用于定期获取第二预设关键点数据；

监控指标更新单元，用于更新移动应用版本的监控指标的报警配置；

监控单元，用于依据采集的所述第二预设关键点数据和所述移动应用版本的监控指标的报警配置确定所述第二预设关键点数据是否出现异常，在出现异常的情况下对异常率进行累积；

报警单元，用于当任何一个监控指标的异常率达到预设的阈值的情况下，报警。

7.根据权利要求5所述的系统，其特征在于，所述监控子模块还包括：

熔断单元，用于在移动应用版本逐步放量的过程中，若目标监控指标的异常率达到预设的阈值时，停止对移动应用版本的发布。

8.根据权利要求1所述的系统，其特征在于，所述AB测试模块包括：

配置请求单元，用于在客户端不存在目标功能的缓存配置或者缓存配置的存储时间超过了设定的过期时间的情况下，向服务器发送配置请求；

分组单元，用于使服务器确定每个目标功能的目标人群；

下发配置单元，用于使服务器向每个目标人群发送相应的目标功能的配置。

9.根据权利要求1所述的系统，其特征在于，还包括：

灰度发布模块，还包括：

记录子模块，用于将所述移动应用版本发布的过程通过快照的方式进行记录，以便用户查看发布的历史记录。

10.一种移动应用灰度发布方法，其特征在于，包括：

依据预设的流程逐量发布移动应用版本；

在所述移动应用发布的过程中，获取预设关键点数据，将所述预设关键点数据以预设的样式进行展示，并根据所述预设关键点数据判断所述移动应用版本是否出现故障；

在所述移动应用发布的过程中，通过服务器分组的方式对移动应用版本的功能进行测试。