一种用于灰度发布的方法和装置与流程

本申请涉及计算机技术领域，具体涉及互联网技术领域，尤其涉及一种用于灰度发布的方法和装置。

背景技术：

灰度发布，是指在历史版本和灰度测试版本之间能够平滑过渡的一种版本发布方式，可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以减少灰度异常对用户的影响。

目前的灰度发布方法，可以先手动配置某一或某几个渠道的版本升级，充分验证稳定性后，再全量发布。灰度发布的核心量化指标是崩溃(crash)率等。一定时间后人工收集灰度发布的指标并分析灰度测试指标，如有集中的崩溃再修复后重新灰度，直到无明显问题，再全量发布。

然而，目前的灰度发布方法，通常需要消耗一定的运营维护、数据分析以及项目管理之类的人力资源，并且随着版本发布的日益频繁，人力资源的消耗会有所增加。此外通常因为缺少人工值守，不能在节假日前发布，并且还有一定的配置风险，比如因渠道配置错误所带来的灰度量过大等。

技术实现要素：

本申请的目的在于提出一种改进的一种用于灰度发布的方法和装置，来解决以上背景技术部分提到的技术问题。

第一方面，本申请提供了一种用于灰度发布的方法，所述方法包括：获取灰度测试安装包集合；接收对灰度测试参数的设定，所述设定包括调研版本数量；根据历史用户日志，确定发布渠道队列；根据所述设定，将所述灰度测试安装包同步至发布渠道队列。

在一些实施例中，所述根据所述设定，将所述灰度测试安装包同步至发布渠道队列包括：根据所述调研版本数量，从所述发布渠道队列中确定调研渠道；基于所述灰度测试安装包集合，将所述调研渠道的用户软件升级至调研版本；基于所述灰度测试安装包集合，将所述发布渠道队列中除所述调研渠道之外的测试渠道的用户软件升级至灰度测试版本。

在一些实施例中，所述根据调研版本数量，从所述发布渠道队列中确定调研渠道包括：根据调研版本数量，确定所述发布渠道队列中的游标历史池包括的渠道数量，将所述游标历史池包括的渠道确定为调研渠道；以及所述基于所述灰度测试安装包集合，将所述调研渠道的用户软件升级至调研版本包括：基于所述灰度测试安装包集合，预先在所述调研渠道内从前至后依次设置上一次升级的灰度测试版本的前一版本至前N版本，其中，N的数值等于所述调研版本数量，在所述测试渠道内设置上一次升级的灰度测试版本，将所述游标历史池向前推进单个渠道，得到所述调研版本。

在一些实施例中，所述基于所述灰度测试安装包集合，将所述发布渠道队列中除所述调研渠道之外的测试渠道的用户软件升级至灰度测试版本包括：基于所述灰度测试安装包集合，将响应于所述游标历史池向前推进单个渠道而退出的渠道中的用户软件跨越升级至灰度测试版本，其中，所述跨越升级跨越的版本数量为所述调研版本的数量加一；基于所述灰度测试安装包集合，将除所述退出的渠道之外的测试渠道升级单个版本至灰度测试版本。

在一些实施例中，所述设定包括灰度列表；以及所述根据所述设定，将所述灰度测试安装包同步至发布渠道队列包括：访问灰度列表中的第一个灰度，根据访问的当前灰度，确定发布渠道队列中各渠道待升级的用户软件的数量；根据所述各渠道待升级的用户软件的数量，确定所述各渠道待升级的用户软件；将所述灰度测试安装包同步至所述各渠道待升级的用户软件；从所述各渠道收集灰度测试指标；响应于预设观测时长内收集的灰度测试指标均符合正常阈值且所述灰度列表中存在下一个灰度，访问所述下一个灰度。

在一些实施例中，所述根据所述设定，将所述灰度测试安装包同步至发布渠道队列还包括：响应于预设观测时长内收集的灰度测试指标中存在不符合正常阈值的灰度测试指标，结束访问所述灰度列表；或响应于预设观测时长内收集的灰度测试指标均符合正常阈值且灰度列表中不存在下一个灰度，结束访问所述灰度列表。

在一些实施例中，所述方法还包括：从所述发布渠道队列收集灰度测试指标。

在一些实施例中，所述方法还包括：响应于从所述发布渠道队列收集的灰度测试指标符合预警阈值，呈现预警信息；和/或响应于从所述发布渠道队列收集的灰度测试指标符合终止阈值，呈现报警信息并终止灰度发布。

在一些实施例中，所述方法还包括：存储所述灰度测试对应的版本的灰度信息，所述灰度信息包括以下一项或多项：唯一标识号、灰度次数、灰度测试指标、应用程序版本号和渠道信息。

第二方面，本申请提供了一种用于灰度发布的装置，所述装置包括：获取单元，用于获取灰度测试安装包集合；接收单元，用于接收对灰度测试参数的设定，所述设定包括调研版本数量；确定单元，用于根据历史用户日志，确定发布渠道队列；同步单元，用于根据所述设定，将所述灰度测试安装包同步至发布渠道队列。

在一些实施例中，所述同步单元包括：调研渠道确定子单元，用于根据所述调研版本数量，从所述发布渠道队列中确定调研渠道；调研渠道升级子单元，用于基于所述灰度测试安装包集合，将所述调研渠道的用户软件升级至调研版本；测试渠道升级子单元，用于基于所述灰度测试安装包集合，将所述发布渠道队列中除所述调研渠道之外的测试渠道的用户软件升级至灰度测试版本。

在一些实施例中，所述调研渠道确定子单元进一步用于：根据调研版本数量，确定所述发布渠道队列中的游标历史池包括的渠道数量，将所述游标历史池包括的渠道确定为调研渠道；以及所述调研渠道升级子单元进一步用于：基于所述灰度测试安装包集合，预先在所述调研渠道内从前至后依次设置上一次升级的灰度测试版本的前一版本至前N版本，其中，N的数值等于所述调研版本数量，在所述测试渠道内设置上一次升级的灰度测试版本，将所述游标历史池向前推进单个渠道，得到所述调研版本。

在一些实施例中，所述测试渠道升级子单元进一步用于：基于所述灰度测试安装包集合，将响应于所述游标历史池向前推进单个渠道而退出的渠道中的用户软件跨越升级至灰度测试版本，其中，所述跨越升级跨越的版本数量为所述调研版本的数量加一；基于所述灰度测试安装包集合，将除所述退出的渠道之外的测试渠道升级单个版本至灰度测试版本。

在一些实施例中，所述接收单元接收的对灰度测试参数的设定包括灰度列表；以及所述同步单元进一步用于：访问灰度列表中的第一个灰度，根据访问的当前灰度，确定发布渠道队列中各渠道待升级的用户软件的数量；根据所述各渠道待升级的用户软件的数量，确定所述各渠道待升级的用户软件；将所述灰度测试安装包同步至所述各渠道待升级的用户软件；从所述各渠道收集灰度测试指标；响应于预设观测时长内收集的灰度测试指标均符合正常阈值且所述灰度列表中存在下一个灰度，访问所述下一个灰度。

在一些实施例中，所述同步单元进一步用于：响应于预设观测时长内收集的灰度测试指标中存在不符合正常阈值的灰度测试指标，结束访问所述灰度列表；或响应于预设观测时长内收集的灰度测试指标均符合正常阈值且灰度列表中不存在下一个灰度，结束访问所述灰度列表。

在一些实施例中，所述装置还包括：收集单元，用于从所述发布渠道队列收集灰度测试指标。

在一些实施例中，所述装置还包括：预警单元，用于响应于从所述发布渠道队列收集的灰度测试指标符合预警阈值，呈现预警信息；和/或报警单元，用于响应于从所述发布渠道队列收集的灰度测试指标符合终止阈值，呈现报警信息并终止灰度发布。

在一些实施例中，所述装置还包括：存储单元，用于存储所述灰度测试对应的版本的灰度信息，所述灰度信息包括以下一项或多项：唯一标识号、灰度次数、灰度测试指标、应用程序版本号和渠道信息。

本申请提供的用于灰度发布的方法和装置，首先获取灰度测试安装包集合，接收对灰度测试参数的设定，并且根据历史用户日志，确定发布渠道队列，最后根据设定将灰度测试安装包同步至发布渠道队列，从而实现了通过数据分析智能化配置发布渠道队列，减少了灰度发布过程中的人力资源投入，加快了版本发布效率，降低了人工配置发布渠道的错误风险，实现了新老版本的并行发布，避免了全量发布新版本时为了分析老版本数据而强制降级给用户带来的极差体验。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1是本申请可以应用于其中的示例性系统架构图；

图2是根据本申请的用于灰度发布的方法的一个实施例的示意性流程图；

图3是根据本申请的基于游标历史池实现灰度发布的方法的一个实施例的示意性流程图；

图4是根据本申请的基于游标历史池实现灰度发布的方法的一个应用场景的示意图；

图5是根据本申请的基于灰度列表实现灰度发布的方法的一个实施例的示意性流程图；

图6是根据本申请的用于灰度发布的装置的一个实施例的示例性结构图；

图7是根据本申请的基于游标历史池实现灰度发布的装置的一个实施例的示例性结构图；

图8是根据本申请的基于灰度列表实现灰度发布的装置的一个实施例的示例性结构图；

图9是适于用来实现本申请实施例的终端设备或服务器的计算机系统的结构示意图。

具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释相关发明，而非对该发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与有关发明相关的部分。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

图1示出了可以应用本申请的用于灰度发布的方法或用于灰度发布的装置的实施例的示例性系统架构100。

如图1所示，系统架构100可以包括终端设备101、102、103，网络104和服务器105、106。网络104用以在终端设备101、102、103和服务器105、106之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户110可以使用终端设备101、102、103通过网络104与服务器105、106交互，以接收或发送消息等。终端设备101、102、103上可以安装有各种客户端应用，例如视频播放类应用、搜索引擎类应用、购物类应用、即时通信工具、邮箱客户端、社交平台软件等。

终端设备101、102、103可以是具有显示屏并且支持交互功能的各种电子设备，包括但不限于智能手机、平板电脑、电子书阅读器、MP3播放器(Moving Picture Experts Group Audio Layer III，动态影像专家压缩标准音频层面3)、MP4(Moving Picture Experts Group Audio Layer IV，动态影像专家压缩标准音频层面4)播放器、膝上型便携计算机和台式计算机等等。

服务器105、106可以是提供各种服务的服务器，例如对终端设备101、102、103提供支持的后台服务器。后台服务器可以基于从终端收集的数据进行分析等处理，并将处理结果(例如灰度发布)反馈给终端设备。

需要说明的是，本申请中实施例所提供的用于灰度发布的方法一般由服务器105、106执行，相应地，用于灰度发布的装置一般设置于服务器105、106中。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

继续参考图2，示出了根据本申请的用于灰度发布的方法的一个实施例的流程200。该用于灰度发布的方法，包括以下步骤：

步骤201，获取灰度测试安装包集合。

在本实施例中，用于灰度发布的方法运行于其上的电子设备(例如图1中的服务器)可以接收其它电子设备(例如终端或服务器)上传的灰度测试安装包。这里的灰度测试安装包集合，可以包括各历史版本的安装包和当前灰度测试版本的安装包。

步骤202，接收对灰度测试参数的设定，设定包括调研版本数量。

在本实施例中，灰度测试参数是指在灰度测试时用于指示灰度发布操作的参数，至少可以包括调研版本数量(也即灰度测试时保留的历史版本数量)，还可以包括灰度量等。用户可以通过现有技术或未来发展的技术中的多种交互方式来提交对灰度测试参数的设定，本申请对此不做限定。

步骤203，根据历史用户日志，确定发布渠道队列。

在本实施例中，用于灰度发布的方法运行于其上的电子设备可以基于历史用户日志来确定向哪些用户进行灰度发布。进一步地，为了便于管理向哪些用户进行灰度发布，还可以建立发布渠道队列，并将可以用于灰度发布的用户分类至发布渠道队列中的各发布渠道中。

这里的历史用户日志，是指用户使用软件历史版本的数据以及用户对软件历史版本的反馈数据。

步骤204，根据设定，将灰度测试安装包同步至发布渠道队列。

在本实施例中，根据上述步骤202中接收的对灰度测试参数的设定，可以将灰度测试安装包同步至发布渠道队列。由于灰度测试参数中的设定中包括调研版本数量，则在将灰度测试安装包同步至发布渠道队列时，可以将发布渠道队列中的部分渠道的用户软件保留在当前灰度测试的历史版本，或者将发布渠道队列中的所有渠道的部分用户软件保留在当前灰度测试的历史版本。进一步地，若所述灰度测试参数还设定了灰度量，则可以根据灰度量将灰度测试安装包同步至发布渠道队列中的部分渠道，或者根据灰度量将灰度测试安装包同步至发布渠道队列中的所有渠道的部分用户。

在本申请的上述实施例中，通过获取灰度测试安装包的集合，接收对灰度测试参数的设定，并根据历史用户日志确定发布渠道队列，最后根据设定将灰度测试安装包同步至发布渠道队列，实现了通过数据分析智能化配置发布渠道队列，减少了灰度发布过程中的人力资源投入，加快了版本发布效率，降低了人工配置发布渠道的错误风险，实现了新老版本的并行发布，避免了全量发布新版本时为了分析老版本数据而强制降级给用户带来的极差体验。

在本实施例的一些可选实现方式中，上述的根据设定，将灰度测试安装包同步至发布渠道队列可以包括：根据设定中指示的调研版本数量，从发布渠道队列中确定调研渠道；基于灰度测试安装包集合，将调研渠道的用户软件升级至调研版本；基于灰度测试安装包集合，将发布渠道队列中除调研渠道之外的测试渠道的用户软件升级至灰度测试版本。

在本实现方式中，调研渠道的数量通常可以与调研版本数量相同，在调研渠道较多的情况下，调研渠道的数量也可以为调研版本数量的整数倍。在确定调研渠道之后，若发布的灰度测试版本在之前版本的基础上升级了一个版本，则对应灰度测试版本的调研版本也需要在之前调研版本的基础上升级一个版本，此时可以基于灰度测试安装包集合，将调研渠道的用户软件升级至调研版本；另外，为了满足当前灰度测试版本的数据观测量，可以将发布渠道队列中除调研渠道之外的测试渠道的用户软件升级至灰度测试版本。这里的调研版本，是指用户希望观测的历史版本，例如，调研版本可以为当前灰度测试版本的前1至前N版本，这里的N的数值与调研版本数量相同。

在本实现方式中，通过自动确定调研渠道，之后对调研渠道和除调研渠道之外的测试渠道分别进行升级，可以实现各版本占比的精准控制，降低人工配置发布渠道的错误风险，避免了全量发布新版本时为了分析老版本数据而强制降级给用户带来的极差体验。

在本实施例的一些可选实现方式中，上述用于灰度发布的方法还包括：从发布渠道队列收集灰度测试指标。

在本实现方式中，为了判定灰度发布是否成功，需要从发布渠道队列收集灰度测试指标来进行分析。

在本实施例的一些可选实现方式中，上述用于灰度发布的方法还包括：响应于从发布渠道队列收集的灰度测试指标符合预警阈值，呈现预警信息；和/或响应于从发布渠道队列收集的灰度测试指标符合终止阈值，呈现报警信息并终止灰度发布。

在本实现方式中，若从发布渠道队列收集的灰度测试指标符合预警阈值，则表明灰度发布出现问题，此时呈现的预警信息可以提醒责任人第一时间发现问题并对问题进行处理；若从发布渠道队列收集的灰度测试指标符合终止阈值，则表明灰度发布出现重大问题，需要终止灰度发布，并且通过报警信息第一时间通知责任人。

在本实施例的一些可选实现方式中，上述的方法还可以包括：存储灰度测试对应的版本的灰度信息，这些灰度信息包括以下一项或多项：唯一标识号、灰度次数、灰度测试指标、应用程序版本号和渠道信息。通过这些灰度信息，可以记录灰度发布的过程，以便在灰度发布异常时通过存储的灰度信息准确定位问题。

进一步参考图3，示出了根据本申请的基于游标历史池实现灰度发布的方法的一个实施例的流程300。该基于游标历史池实现灰度发布的方法，包括以下步骤：

步骤301，根据调研版本数量，确定发布渠道队列中的游标历史池包括的渠道数量。

在本实施例中，调研版本的数量通常可以根据需要观测的历史版本数量设定。发布渠道队列中设置的游标历史池，提供了在发布渠道队列中单次以一列或多列前进或向后浏览发布渠道，该游标历史池可以作为一个指针指定发布渠道队列中的位置，然后允许对游标历史池中的数据进行处理。该游标历史池中包括的渠道数量与调研版本的数量相同或为调研版本的数量的整数倍。

步骤302，将游标历史池包括的渠道确定为调研渠道。

在本实施例中，通过将游标历史池包括的渠道确定为调研渠道，可以基于这些调研渠道来保证在灰度发布时并行控制多个版本。

步骤303，基于灰度测试安装包集合，预先在调研渠道内从前至后依次设置上一次升级的灰度测试版本的前一版本至前N版本，在测试渠道内设置上一次升级的灰度测试版本。

在本实施例中，灰度测试安装包集合包括了用于升级各版本的安装包。因此，可以预先从灰度测试安装包集合中选择合适的安装包来对各渠道的用户软件版本进行设置，这里预先设置的上一次升级的调研版本和上一次升级的灰度测试版本，可以方便本次灰度发布时采用游标历史池实现调研版本。这里的N的数值等于调研版本的数量。

步骤304，将游标历史池向前推进单个渠道，得到调研版本。

在本实施例中，由于游标历史池前方的测试渠道中的用户软件为上一次升级的最新版本，因此可以通过将游标历史池向前推进单个渠道，从而将上一次升级的最新版本纳入游标历史池中成为本次升级的前一版本，上一次升级的前一版本无需升级便成为本次升级的前二版本，依次类推，上一次升级的前N-1版本无需升级便成为本次升级的前N版本。从而，游标历史池中包括的用户软件版本无需再升级便可以作为本次升级的前一版本至前N版本，也即可以作为本次升级的调研版本。

步骤305，基于灰度测试安装包集合，将响应于游标历史池向前推进单个渠道而退出的渠道中的用户软件跨越升级至灰度测试版本。

在本实施例中，在步骤304中游标历史池向前推进单个渠道后，由于游标历史池所包括的渠道数量与调研版本数量相同，因此上一次升级的前N版本退出了游标历史池进入测试渠道。该上一次升级的前N版本(也即本次灰度测试的前N+1版本)进入测试渠道后，需要跨越升级至灰度测试版本，跨越升级所跨越的版本数量为调研版本的数量加一，此时可以从灰度测试安装包集合中选取合适的升级安装包来进行跨越升级。

步骤306，基于灰度测试安装包集合，将除退出的渠道之外的测试渠道升级单个版本至灰度测试版本。

在本实施例中，除上述退出的渠道之外的测试渠道中的用户软件的版本为上一次升级的最新版本，因此可以通过升级单个版本而得到灰度测试版本。

本申请上述实施例提供的基于游标历史池实现灰度发布的方法，通过在发布渠道队列中向前推进游标历史池，从而实现了动态置换观测渠道，避免了单一渠道一直停留在历史版本，实现了并行管理，并且提高了多版本并行发布的发布效率。

请参考图4，图4示出了基于游标历史池实现灰度发布的方法的一个应用场景的示意图。

如图4所示，首先，在预先设置的V3版本的发布渠道队列410中，根据接收的对灰度测试参数的设定，可以确定渠道1-3为游标历史池包括的渠道，也即渠道1-3为调研渠道，调研渠道中的用户软件版本包括V3版本的前1版本V2、前2版本V1和前3版本V0，同时可以确定渠道4-10为测试渠道，测试渠道包括的用户软件的版本均为V3版本。

之后，在对发布渠道队列410进行灰度发布得到的发布渠道队列420中，游标历史池向前推进了1个渠道，从而得到游标历史池内的渠道10、渠道1和渠道2，此时游标历史池内的用户软件版本为V3、V2、V1，为测试渠道3-9中V4版本的调研版本。同时，渠道3为响应于游标历史池向前推进1个渠道而退出的渠道，对照发布渠道队列410可以看出，渠道3跨越升级的版本数量为调研版本数量3再加上1，也即跨越的版本数量为4个版本；渠道4-9从V3升级至V4，升级了单个版本。

之后，在对发布渠道队列420进行灰度发布得到的发布渠道队列430中，游标历史池向前推进1个渠道，从而得到游标历史池内的渠道9、渠道10和渠道1，此时游标历史池内的用户软件版本为V4、V3、V2，为测试渠道2-8中V5版本的调研版本。同时，渠道2为响应于游标历史池向前推进1个渠道而退出的渠道，对照发布渠道队列420可以看出，渠道2跨越升级的版本数量为调研版本数量3再加上1，也即跨越的版本数量为4个版本；渠道3-8从V4升级至V5，升级了单个版本。

依次类推，对发布渠道队列430进行灰度发布可以得到发布渠道队列440、对发布渠道队列440进行灰度发布可以得到发布渠道队列450、对发布渠道队列450进行灰度发布可以得到发布渠道队列460。

应当理解，上述应用场景仅为本申请的基于游标历史池实现灰度发布的方法的示例性应用场景，并不代表对本申请的限定，例如，发布渠道的队列并不限定于10个，可以为更多或更少数量的发布渠道，调研渠道的数量也并不限定于3个，可以为更多或更少数量的发布渠道。

本申请上述应用场景提供的基于游标历史池实现灰度发布的方法，保证了调研版本和灰度测试版本的并行，并且精准有效的控制了每个版本的占比，为后期进行数据分析和定位版本升级过程中的问题提供了解决方案，可以有效的排查是否因为产品功能的问题导致的观测数据变化。

进一步参考图5，示出了根据本申请的基于灰度列表实现灰度发布的方法的一个实施例的流程500。该基于灰度列表实现灰度发布的方法，包括以下步骤：

步骤501，访问灰度列表中的第一个灰度。

在本实施例中，为了在小比例的灰度发布成功后进行大比例的灰度发布，可以设置灰度列表中的灰度逐步增大，并且从灰度列表的第一个灰度开始访问，当基于灰度列表中的第一个灰度发布成功时，才继续推进访问灰度列表中的第二个灰度。

步骤502，根据访问的当前灰度，确定发布渠道队列中各渠道待升级的用户软件的数量。

在本实施例中，可以将当前灰度与各渠道的用户软件的数量相乘，并将对应各渠道得到的乘积分别作为各渠道待升级的用户软件的数量。

步骤503，根据各渠道待升级的用户软件的数量，确定各渠道待升级的用户软件。

在本实施例中，基于步骤502中确定的各渠道待升级的用户软件的数量，可以从各渠道中选取符合数量的待升级的用户软件，并将从各渠道中选取的用户软件确定为各渠道待升级的用户软件。在选取时，可以依据预设的选取规则选取符合数量的待升级的用户软件，也可以随机选取符合数量的待升级的用户软件。

步骤504，将灰度测试安装包同步至各渠道待升级的用户软件。

在本实施例中，基于步骤503中确定的各渠道待升级的用户软件，可以将灰度测试安装包同步至各渠道待升级的用户软件。

步骤505，从各渠道收集灰度测试指标。

在本实施例中，在将灰度测试安装包同步至各渠道待升级的用户软件之后，为了确定下一步是否可以继续灰度发布，需要从各渠道收集灰度测试指标以确定之前的灰度发布是否成功。

步骤506，判断预设观测时长内收集的灰度测试指标是否均符合正常阈值，若是，则执行步骤507，若否，则执行步骤508。

在本实施例中，正常阈值是用于判定灰度发布是否成功的标准。通过判断预设观测时长内收集的灰度测试指标是否均符合正常阈值，可以确定之前的灰度发布是否成功：若均符合，则灰度发布成功，若存在不符合正常阈值的灰度测试指标，则灰度发布不成功。

步骤507，判断灰度列表中是否存在下一个灰度，若是，则执行步骤509，若否，则执行步骤508。

在本实施例中，若基于步骤505中的判断结果可以确定灰度发布成功，也即意味着可以进行下一步灰度发布，由此可以执行步骤509；若基于步骤505中的判断结果可以确定灰度发布不成功，也即意味着不能进行下一步灰度发布，因此可以执行步骤508。

步骤508，结束访问灰度列表。

步骤509，访问下一个灰度，之后跳转至执行步骤502。

本申请上述实施例提供的基于灰度列表实现灰度发布的方法，通过采用灰度列表逐步扩大发布量，并在每一步发布时观测灰度测试指标，从而在灰度测试指标不符合正常阈值时停止下一步灰度发布，提高了灰度发布的可靠性和发布效率。

进一步参考图6，示出了根据本申请的用于灰度发布的装置的一个实施例的示例性结构图。

该用于灰度发布的装置实施例与图2中所示的方法实施例中方法所执行的操作步骤相对应，由此，上文针对方法所执行的操作步骤描述的操作和特征同样适用于该用于灰度发布的装置，在此不再赘述。

具体地，该用于灰度发布的装置600可以包括：获取单元610、接收单元620、确定单元630和同步单元640。

其中，获取单元610，用于获取灰度测试安装包集合。接收单元620，用于接收对灰度测试参数的设定，设定包括调研版本数量。确定单元630，用于根据历史用户日志，确定发布渠道队列。同步单元640，用于根据设定，将灰度测试安装包同步至发布渠道队列。

在本实施例的一些可选实现方式中，同步单元640可以包括：调研渠道确定子单元，用于根据调研版本数量，从发布渠道队列中确定调研渠道；调研渠道升级子单元，用于基于灰度测试安装包集合，将调研渠道的用户软件升级至调研版本；测试渠道升级子单元，用于基于灰度测试安装包集合，将发布渠道队列中除调研渠道之外的测试渠道的用户软件升级至灰度测试版本。

在本实施例的一些可选实现方式中，装置还包括：收集单元，用于从发布渠道队列收集灰度测试指标。

在本实施例的一些可选实现方式中，装置还包括：预警单元，用于响应于从发布渠道队列收集的灰度测试指标符合预警阈值，呈现预警信息；和/或报警单元，用于响应于从发布渠道队列收集的灰度测试指标符合终止阈值，呈现报警信息并终止灰度发布。

在本实施例的一些可选实现方式中，装置还包括：存储单元，用于存储灰度测试对应的版本的灰度信息，灰度信息包括以下一项或多项：唯一标识号、灰度次数、灰度测试指标、应用程序版本号和渠道信息。

进一步参考图7，示出了根据本申请的基于游标历史池实现灰度发布的装置的一个实施例的示例性结构图。

该基于游标历史池实现灰度发布的装置实施例与图3中所示的方法实施例中方法所执行的操作步骤相对应，由此，上文针对方法所执行的操作步骤描述的操作和特征同样适用于该基于游标历史池实现灰度发布的装置，在此不再赘述。

具体地，该基于游标历史池实现灰度发布的装置700可以包括调研渠道确定子单元710、调研渠道升级子单元720和测试渠道升级子单元730。

应当理解，该实施例中的调研渠道确定子单元710、调研渠道升级子单元720和测试渠道升级子单元730所执行的操作分别为图6所示的实施例的可选实现方式中的调研渠道确定子单元、调研渠道升级子单元和测试渠道升级子单元所执行的操作的进一步操作。

在这里，调研渠道确定子单元710进一步用于：根据调研版本数量，确定发布渠道队列中的游标历史池包括的渠道数量，将游标历史池包括的渠道确定为调研渠道。调研渠道升级子单元720进一步用于：基于灰度测试安装包集合，预先在调研渠道内从前至后依次设置上一次升级的灰度测试版本的前一版本至前N版本，其中，N的数值等于调研版本数量，在测试渠道内设置上一次升级的灰度测试版本，将游标历史池向前推进单个渠道，得到调研版本。测试渠道升级子单元730进一步用于：基于灰度测试安装包集合，将响应于游标历史池向前推进单个渠道而退出的渠道中的用户软件跨越升级至灰度测试版本，其中，跨越升级跨越的版本数量为调研版本的数量加一；基于灰度测试安装包集合，将除退出的渠道之外的测试渠道升级单个版本至灰度测试版本。

进一步参考图8，示出了根据本申请的基于灰度列表实现灰度发布的装置的一个实施例的示例性结构图。

该根据本申请的基于灰度列表实现灰度发布的装置实施例与图5中所示的方法实施例中方法所执行的操作步骤相对应，由此，上文针对方法所执行的操作步骤描述的操作和特征同样适用于该根据本申请的基于灰度列表实现灰度发布的装置，在此不再赘述。

具体地，该基于灰度列表实现灰度发布的装置800可以包括接收单元810和同步单元820。

应当理解，该实施例中的接收单元810和同步单元820所执行的操作分别为图6中的接收单元和同步单元所执行的操作的进一步操作。

在这里，接收单元810接收的对灰度测试参数的设定可以包括灰度列表；以及同步单元820进一步用于：访问灰度列表中的第一个灰度，根据访问的当前灰度，确定发布渠道队列中各渠道待升级的用户软件的数量；根据各渠道待升级的用户软件的数量，确定各渠道待升级的用户软件；将灰度测试安装包同步至各渠道待升级的用户软件；从各渠道收集灰度测试指标；响应于预设观测时长内收集的灰度测试指标均符合正常阈值且灰度列表中存在下一个灰度，访问下一个灰度。

在本实施例的一些可选实现方式中，同步单元进一步用于：响应于预设观测时长内收集的灰度测试指标中存在不符合正常阈值的灰度测试指标，结束访问灰度列表；或响应于预设观测时长内收集的灰度测试指标均符合正常阈值且灰度列表中不存在下一个灰度，结束访问灰度列表。

下面参考图9，其示出了适于用来实现本申请实施例的终端设备或服务器的计算机系统900的结构示意图。

如图9所示，计算机系统900包括中央处理单元(CPU)901，其可以根据存储在只读存储器(ROM)902中的

程序或者从存储部分908加载到随机访问存储器(RAM)903中的程序而执行各种适当的动作和处理。在RAM 903中，还存储有系统900操作所需的各种程序和数据。CPU 901、ROM 902以及RAM 903通过总线904彼此相连。输入/输出(I/O)接口905也连接至总线904。

以下部件连接至I/O接口905：包括键盘、鼠标等的输入部分906；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分907；包括硬盘等的存储部分908；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分909。通信部分909经由诸如因特网的网络执行通信处理。驱动器910也根据需要连接至I/O接口909。可拆卸介质911，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器910上，以便于从其上读出的计算机程序根据需要被安装入存储部分908。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括有形地包含在机器可读介质上的计算机程序，所述计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分909从网络上被下载和安装，和/或从可拆卸介质911被安装。在该计算机程序被中央处理单元(CPU)901执行时，执行本申请的方法中限定的上述功能。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个单元、程序段、或代码的一部分，所述单元、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元也可以设置在处理器中，例如，可以描述为：一种处理器包括获取单元、接收单元、确定单元和同步单元。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定，例如，获取单元还可以被描述为“获取灰度测试安装包集合的单元”。

作为另一方面，本申请还提供了一种非易失性计算机存储介质，该非易失性计算机存储介质可以是上述实施例中所述装置中所包含的非易失性计算机存储介质；也可以是单独存在，未装配入终端中的非易失性计算机存储介质。上述非易失性计算机存储介质存储有一个或者多个程序，当所述一个或者多个程序被一个设备执行时，使得所述设备：获取灰度测试安装包集合；接收对灰度测试参数的设定，设定包括调研版本数量；根据历史用户日志，确定发布渠道队列；根据设定，将灰度测试安装包同步至发布渠道队列。

以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本申请中所涉及的发明范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离所述发明构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本申请中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。