具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请的一部分实施例，而不是全部的实施例，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

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

目前使用灰度系统进行灰度发布时，APS、发包渠道管理、版本管理平台、APM线上监控等系统之间没有打通，发版人员需要在各个系统之间线下手动进行配置操作。而且缺少灰度包线上数据汇总和监控提醒机制，难以及时针对线上问题以及各节点作出响应。

基于此，本申请提供了一种灰度发布系统，如图1所示，该系统包括：APS平台10、监控平台20、用户设备群30以及提醒平台40。

在本申请实施例中，APS平台用于目标应用程序待进行灰度发布的更新信息，并对更新信息进行打包得到应用安装包，对应用安装包进行测试，在测试通过的情况下，检测目标应用程序的当前版本在第一用户设备群中的状态信息；根据状态信息确定应用安装包的目标发布流程，基于目标发布流程对应用安装包进行发布。

其中，发布过程主要是通过发包渠道将应用安装包发送到用户设备群，其中，发包渠道包括：Android渠道和IOS渠道。用户设备群中的设备包括：计算机、笔记本电脑、智能手机以及便携式可穿戴设备等等。

在本申请实施例中，在将应用安装包发送到用户设备群之后，提醒平台会向监控平台发送提示信息，提示信息用于提示监控平台对用户设备群中产生的发布结果进行监控，并将发布结果发送至APS平台。提醒信息可以是通过预设的联系方式对该灰度版本的开发者进行提醒，例如通过自动发送短信、自动拨打电话、自动发送邮件等方式给开发者发送告警信息。

基于上述发布系统，本申请实施例提供了一种应用程序的灰度发布方法、装置、电子设备及存储介质。本发明实施例所提供的方法可以应用于任意需要的电子设备，例如，可以为服务器、终端等电子设备，在此不做具体限定，为描述方便，后续简称为电子设备。

根据本申请实施例的一方面，提供了一种应用程序的灰度发布方法的方法实施例。图2为本申请实施例提供的一种应用程序的灰度发布方法的流程图，如图2所示，该方法包括：

步骤S11，获取目标应用程序待进行灰度发布的目标版本的应用安装包。

在本申请实施例中，目标应用程序的目标版本的应用安装包是通过目标版本对应的更新信息生成的。更新信息包括：目标应用程序的界面、功能、漏洞补丁等等。

步骤S12，检测目标应用程序的当前版本在第一用户设备群中的状态信息。

在本申请实施例中，如图3所示，步骤S12，检测目标应用程序的当前版本在第一用户设备群中的状态信息，包括以下步骤A1-A3：

步骤A1，获取目标应用程度的当前版本在第一用户设备群中的运行数据。

在本申请实施例中，第一用户设备群是当前版本在进行灰度发布时所选择的用户设备群，运行数据包括：各个时间段用户设备登录目标应用程序产生的数据。

步骤A2，按照预设数据指标对运行数据进行统计，获取每个预设数据指标的目标值。

在本申请实施例中，预设数据指标包括：活跃数据指标、使用数据指标以及崩溃数据指标，其中活跃数据指标对应的目标值包括：日访问频率、周访问频率、浏览量，访问量，运行数据对应的目标值包括：平均使用时长。崩溃数据对应的目标值包括：崩溃次数以及闪退次数。

步骤A3，使用目标值与每个预设数据指标对应的阈值范围进行对比，得到状态信息，其中，状态信息包括：稳定状态和非稳定状态。

在本申请实施例中，将目标值与每个预设数据指标对应的阈值范围，能够确定每个预设数据指标子状态，然后根据每个子状态得到目标应用程序当前版本的状态信息。

作为一个示例，日访问频率大于第一预设频率，周访问频率大于第二预设频率，则活跃数据指标对应的子状态为活跃状态。平均使用时长大于预设使用时长，则确定使用数据指标对应的子状态为感兴趣状态。崩溃次数小于第一预设次数，且闪退次数小于第二预设次数则表示崩溃数据指标对应的子状态为正常运行状态，然后根据活跃状态、感兴趣状态以及正常运行状态，查询预设状态对应关系表，确定目标应用程序的当前版本在第一用户设备群中是稳定状态。

作为另一个示例，日访问频率小于第一预设频率，周访问频率小于第二预设频率，则活跃数据指标对应的子状态为疲倦状态。平均使用时长小于预设使用时长，则确定使用数据指标对应的子状态为非感兴趣状态。崩溃次数小于第一预设次数，且闪退次数小于第二预设次数则表示崩溃数据指标对应的子状态为正常运行状态，然后根据疲倦状态、非感兴趣状态以及正常运行状态，查询预设状态对应关系表，确定目标应用程序的当前版本在第一用户设备群中是非稳定状态。

步骤S13，根据状态信息确定应用安装包的目标发布流程。

在本申请实施例中，不同的状态信息对应不同的发布流程，因此可以从数据库中根据状态信息的状态标识查询状态信息对应的目标发布流程。

步骤S14，基于目标发布流程对应用安装包进行发布。

在本申请实施例中，在状态信息为非稳定状态的情况下，如图4所示，步骤S14，基于目标发布流程对应用安装包进行发布，包括以下步骤B1-B2：

步骤B1，中止当前版本在第一用户设备群的灰度发布流程。

步骤B2，向第一用户设备群发送应用安装包，以使第一用户设备群根据应用安装包将目标应用程序的版本更新为目标版本。

在本申请实施例中，在状态信息为非稳定状态的情况下，选择中止当前版本在第一用户设备群的灰度发布流程，并将应用安装包发送至第一用户设备群中的各个用户设备，以使各个用户设备使用应用安装包将目标应用程序由当前版本更新为目标版本。

本申请实施例在非稳定状态的情况下，通过中止当前发布当前版本在第一用户设备群的灰度发布流程，并向第一用户设备群发送应用安装包，以此及时的对第一用户设备群中目标应用程序进行更新，避免第一用户设备群中出现目标应用程序持续出现非稳定状态的情况。

在本申请实施例中，在状态信息为稳定状态的情况下，步骤S14，基于目标发布流程对应用安装包进行发布，如图5所示，包括以下步骤C1-C2：

步骤C1，确定应用安装包对应的发布类型，其中，发布类型包括：全量发布类型和灰度发布类型。

在本申请实施例中，由于状态信息是稳定状态，则表明目标应用程序在第一用户设备群中是被认可的，因此可以确定应用安装包的发布类型，其中，发布类型可以是工作人员预先设置的。发布类型包括：全量发布类型以及灰度发布类型。

步骤C2，根据发布类型执行相应的发布操作。

在本申请实施例中，步骤C2，根据发布类型执行相应的发布操作，包括以下步骤D1-D2：

步骤D1，在发布类型为全量发布的情况下，将携带有目标应用程序的设备确定为第二用户设备群。

步骤D2，向第二用户设备群全量下发应用安装包。

在本申请实施例中，如果发布类型为全量分发时，获取全部携带目标应用程序的设备，并将该类设备确定为第二用户设备群，并向第二用户设备群发送应用安装包，以使第二用户设备群中的每个设备根据目标应用安装包更新目标应用程序的版本。

需要说明的是，第二用户设备群包括或等于第一用户设备群。在目标应用程序当前版本是灰度下发的情况下，第二用户设备群包括第一用户设备群。如果目标应用程序当前版本是灰度下发的情况下，第二用户设备群等于第一用户设备群。

在本申请实施例中，步骤C2，根据发布类型执行相应的发布操作，包括以下步骤E1-E2：

步骤E1，在发布类型为灰度发布的情况下，获取灰度发布策略，其中，灰度发布策略携带目标设备标识以及预设发布结果，目标设备标识是用于表示接收应用安装包的设备对应的设备标识。

在本申请实施例中，灰度发布策略中包括：目标设备标识、发布时长以及预设发布结果等等，其中，目标设备标识用于筛选设备出用于接收应用安装包的设备，预设发布结果用于表示在目标应用程序更新为目标版本后各项预设数据指标达到的预期值。

在本申请实施例中，灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

步骤E2，向目标设备标识对应的第三用户设备群发送应用安装包。

本申请实施例在发布应用程序的新版本之前，检测当前版本在用户设备群中的状态信息，从而根据不同的状态信息选择不同的发布流程，整个过程无需发版人员在各个系统之间线下手动进行配置操作。实现了对应用程序的灰度版本进行自动化地灰度发布，能够提高灰度发布效率，降低灰度发布风险。

在本申请实施例中，在向目标设备标识对应的第三用户设备群发送应用安装包之后，方法还包括以下步骤E3-E4：

步骤E3，获取第三用户设备群反馈的发布结果，其中，发布结果是第三用户设备群使用应用安装包对目标应用程序的版本进行更新后得到的。

在本申请实施例中，第三用户设备群在使用应用安装包对目标应用程序的版本进行更新后，会产生相应的使用数据以及反馈信息，因此通过监控平台对使用数据以及反馈信息进行收集，将使用数据以及反馈信息确定为发布结果。

步骤E4，在发布结果满足预设发布结果的情况下，向携带有目标应用程序的第二用户设备群发送应用安装包。

在本申请实施例中，通过对反馈信息进行语义识别，确定第三用户设备群对目标版本的感兴趣程度，同时对使用数据中的浏览量、使用时长等数据与相应的阈值进行对比。如果感兴趣程度大于预设感兴趣程度，且各项使用数据均大于相应的预设阈值，则表示目标版本的达到预期效果，此时将灰度发布变更为全量发布，即将应用安装包发送至第二用户设备群。

在本申请实施例中，对反馈信息进行语义识别，确定第三用于设备群对目标版本的感兴趣程度，具体的实现过程如下：采用TFIDF(词频逆向文件频率)模型提取反馈信息中的多元词组。然后利用预设分析规则对多元词组进行筛选得到关键词组。本实施例所涉及的预设分析规则可以是：单一名词短语、多个名词短语、形容词、副词和名词短语连用等等。然后将关键词组与预设词典进行匹配，确定各个关键词组对应的目标权重，并计算目标权重的和值，根据和值确定感兴趣程度。其中，预设词典中包括：多个词组以及每次词组的权重，权重用于表示该词组的感兴趣程度。

本申请实施例通过采用上述技术方案，在灰度版本发布时，无需依赖于人工主动性，实现对目标应用的灰度版本进行自动化地灰度发布，能够提高灰度发布效率，降低灰度发布风险。

图5为本申请实施例提供的一种应用程序的灰度发布装置的框图，该装置可以通过软件、硬件或者两者的结合实现成为电子设备的部分或者全部。如图5所示，该装置包括：

获取模块51，用于获取目标应用程序待进行灰度发布的目标版本的应用安装包；

检测模块52，用于检测目标应用程序的当前版本在第一用户设备群中的状态信息；

确定模块53，用于根据状态信息确定应用安装包的目标发布流程；

执行模块54，用于基于目标发布流程对应用安装包进行发布。

在本申请实施例中，检测模块52，用于获取目标应用程度的当前版本在第一用户设备群中的运行数据；按照预设数据指标对运行数据进行统计，获取每个预设数据指标的目标值；使用目标值与每个预设数据指标对应的阈值范围进行对比，得到状态信息，其中，状态信息包括：稳定状态和非稳定状态。

在本申请实施例中，在状态信息为非稳定状态的情况下，执行模块54，用于中止当前版本在第一用户设备群的灰度发布流程；向第一用户设备群发送应用安装包，以使第一用户设备群根据应用安装包将目标应用程序的版本更新为目标版本。

在本申请实施例中，在状态信息为稳定状态的情况下，执行模块54，用于确定应用安装包对应的发布类型，其中，发布类型包括：全量发布类型和灰度发布类型；根据发布类型执行相应的发布操作。

在本申请实施例中，执行模块54，在发布类型为全量发布的情况下，将携带有目标应用程序的设备确定为第二用户设备群；向第二用户设备群全量下发应用安装包。

在本申请实施例中，执行模块54，在发布类型为灰度发布的情况下，获取灰度发布策略，其中，灰度发布策略携带目标设备标识以及预设发布结果，目标设备标识是用于表示接收应用安装包的设备对应的设备标识；向目标设备标识对应的第三用户设备群发送应用安装包。

本申请实施例装置还包括：监控模块，用于获取第三用户设备群反馈的发布结果，其中，发布结果是第三用户设备群使用应用安装包对目标应用程序的版本进行更新后得到的；在发布结果满足预设发布结果的情况下，向携带有目标应用程序的第二用户设备群发送应用安装包。

本申请实施例还提供一种电子设备，如图6所示，电子设备可以包括：处理器1501、通信接口1502、存储器1503和通信总线1504，其中，处理器1501，通信接口1502，存储器1503通过通信总线1504完成相互间的通信。

存储器1503，用于存放计算机程序；

处理器1501，用于执行存储器1503上所存放的计算机程序时，实现上述实施例的步骤。

上述终端提到的通信总线可以是外设部件互连标准(Peripheral ComponentInterconnect，简称PCI)总线或扩展工业标准结构(Extended Industry StandardArchitecture，简称EISA)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

通信接口用于上述终端与其他设备之间的通信。

存储器可以包括随机存取存储器(Random Access Memory，简称RAM)，也可以包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。

上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(Digital Signal Processing，简称DSP)、专用集成电路(Application SpecificIntegrated Circuit，简称ASIC)、现场可编程门阵列(Field－Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

在本申请提供的又一实施例中，还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述实施例中任一所述的一种应用程序的灰度发布方法。

在本申请提供的又一实施例中，还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述实施例中任一所述的一种应用程序的灰度发布方法。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘SolidState Disk)等。

以上所述仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本申请的保护范围内。

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