CN105335204A - 软件程序的灰度发布控制方法和灰度发布控制装置 - Google Patents

Abstract

根据本发明，提出了一种软件程序的灰度发布控制方法，包括：从软件程序的功能函数中确定该软件程序的核心函数；针对所确定的软件程序的所有核心函数，确定修改后的待发布的最新的软件程序相对于当前正在运行的软件程序的整体源码变化率；以及在所述整体源码变化率超过或等于预定的阈值的情况下，将所述最新的软件程序作为试用版本而将当前正在运行的软件程序作为稳定版本进行灰度分布。

Description

软件程序的灰度发布控制方法和灰度发布控制装置

技术领域

本发明涉及软件处理领域，具体涉及一种软件程序的灰度发布控制方法和灰度发布控制装置，能够通过对软件的灰度发布与否进行判定，并利用用户对灰度发布版本的反馈结果对灰度发布过程进行控制，从而减少软件发布的风险。

背景技术

当前随着移动互联网的快速发展，各种SaaS(软件即服务)软件厂商为了抢占宝贵的市场机会，都加快了SaaS系统软件发布和更新的速度。有些大的软件公司甚至开发了可每日发布的软件发布平台。但是随着软件发布时间的缩短和发布频率的增加，软件发布带来的风险也越来越明显。如果新发布的软件存在明显的技术问题，对公司带来的损失是非常严重的。

为了控制和减少软件发布的风险，一些互联网公司开始采用新的软件发布方式即灰度发布。在灰度发布中，同时发布稳定版本的软件和试用版本的软件，设定大部分的客户继续之前的稳定版本的软件，而只设定小部分的用户访问试用版本，这样即使试用版本的软件存在问题影响范围只是有限的小部分用户，从而有效减少了软件发布的风险。

例如，中国专利申请No：201110333921.6提供了一种灰度发布的处理方法及系统，如图1所示，它把稳定版本的软件和试用版本的软件分别放在不同的服务器上，在运行服务器前端添加了代理服务器，在代理服务器中安装了试用IP列表和客户访问判断模块。在用户A请求服务时，先在代理服务器中判断该A客户是否在试用IP列表中。如果在就把请求转发到试用版本中，如果不在试用IP列表中就把请求转发到稳定版本中。

但是这样的灰度发布存在以下三个问题：

(1)由于灰度发布过程中需要同时维护多个版本的软件，所以相比传统发布方式，灰度发布要花费软件人员更多的时间和精力，因此需要有一种方法，能够在软件系统每次更新之前判断是否真的需要做灰度发布；

(2)在一般的灰度发布过程中，试用用户占所有用户的比例以及试用用户列表都是随机选择和生成的，没有一个具体的数学模型去计算这样的参数值；

(3)传统的软件发布过程仅仅考虑软件厂商的自己的利益而没有真正考虑终端客户的感受，比如SaaS系统更换了软件的前端页面设计，将会影响到终端客户的使用方式和使用感受。所以应该考虑让终端客户也参与到SaaS系统的发布和更新过程中。

发明内容

为了解决现有技术的上述问题提出了本发明。因此，本发明的目的之一是提出一种软件程序的灰度发布控制方法和灰度发布控制装置，能够通过对软件的灰度发布与否进行判定，并利用用户对灰度发布版本的反馈结果对灰度发布过程进行控制，从而减少软件发布的风险。

为了实现上述目的，根据本发明，提出了一种软件程序的灰度发布控制方法，包括：从软件程序的功能函数中确定该软件程序的核心函数；针对所确定的软件程序的所有核心函数，确定修改后的待发布的最新的软件程序相对于当前正在运行的软件程序的整体源码变化率；以及在所述整体源码变化率超过或等于预定的阈值的情况下，将所述最新的软件程序作为试用版本而将当前正在运行的软件程序作为稳定版本进行灰度分布。

优选地，所述方法还包括：在对该软件程序进行灰度分布时，对于该软件程序中源码变化率较大的核心函数，根据运行日志信息确定其所对应的通常访问用户和通常访问时间，从而确定针对所述灰度发布的试用用户和试用时间。

优选地，所述核心函数是通过根据从软件运行服务器中获取的该软件程序的运行日志信息进行函数的调用频率分析而确定的。

优选地，所述核心函数是通过由程序开发者指定来确定的。

优选地，所述方法还包括：在进行灰度发布时，根据实时从试用版本的运行服务器中获取的作为日志记录的函数出错率和客户对新版本的使用反馈信息，判断是停用该试用版本还是将该试用版本采用为新的稳定版本。

优选地，所述软件程序包括软件即服务程序，即，SaaS软件程序。

另外，根据本发明，还提出了一种软件程序的灰度发布控制装置，包括：从软件程序的功能函数中确定该软件程序的核心函数的单元；针对所确定的软件程序的所有核心函数，确定修改后的待发布的最新的软件程序相对于当前正在运行的软件程序的整体源码变化率的单元；以及在所述整体源码变化率超过或等于预定的阈值的情况下，将所述最新的软件程序作为试用版本而将当前正在运行的软件程序作为稳定版本进行灰度分布的单元。

本发明能够根据系统的检测和用户的反馈来减少软件版本发布的风险，同时提高软件由试用版转化为稳定版本的效率。通过该系统的应用，软件试用人员能够通过简单易用的用户图形界面提供使用软件系统的反馈信息，以助于系统的改进。同时，软件开发人员能够及时得到系统和用户对程序代码功能、质量等的反馈，及时提高软件开发及修正的进度。

附图说明

通过参考以下组合附图对所采用的优选实施方式的详细描述，本发明的上述目的、优点和特征将变得更显而易见，其中：

图1是示出了传统发布和灰度发布的系统结构差别的图。

图2是示出了根据本发明的处于灰度发布系统中的灰度发布控制服务器的具体结构的框图。

图3是示出了根据本发明的灰度发布系统架构的一个示例的图。

图4是示出了根据本发明的灰度发布方法的主要流程的图。

图5是示出了根据本发明的灰度发布方法的过程001的具体处理的流程图。

图6是示出了根据本发明的灰度发布方法的过程002的具体处理的流程图。

图7是示出了灰度发布客户反馈GUI(图形用户界面)的一个示例的示意图。

图8是示出了根据本发明的灰度发布方法的过程003的具体处理的流程图。

具体实施方式

为使本发明的上述目的、特征和优点更加明显易懂，以下结合附图和具体实施例进一步详细描述本发明。需要说明的是，附图中的各结构只是示意性的而不是限定性的，以使本领域普通技术人员最佳地理解本发明的原理，其不一定按比例绘制。下面将结合附图对本发明的实施例进行详细说明。

本发明的特征是在原来开发服务器、运行服务器和代理服务器之外，添加了灰度发布控制器。如图2所示，该灰度发布控制服务器与开发服务器、运行服务器和代理服务器相连接，从开发服务器、运行服务器获取相关数据，并基于数据分析结果来设置代理服务器从而实现灰度发布的控制。

图2示出了根据本发明的处于灰度发布系统中的灰度发布控制服务器的具体结构。该灰度发布控制服务器主要包括4个模块：

1.运行分析模块

该运行分析模块与软件运行服务器(图2所示的运行服务器1和/或运行服务器2)连接，并从软件运行服务器中获取运行日志信息。由于软件的每一个功能和任务的都是基于程序中一个或者多个的功能函数来实现，而这些函数被调用一次就在运行日志中增加一条记录，记录包含了调用用户信息、函数名字、被调用时间以及执行结果等。

通过分析这些日志信息，我们可以统计出功能函数被调用的顺序和每个功能函数被调用的次数等。作为示例，可以将调用函数频率最高的前N个函数称为核心函数，其中N是用户可以设定的值。当然，选择核心函数的方式并不局限于此。

有些函数调用频率不高但是非常重要，如果出错的话软件发布风险非常高，对于这种核心函数系统提供了一种交互界面，自动显示出所有功能函数以及他们之间的调用关系，由开发者手动指定哪些是核心函数。

2.源码变化分析模块

程序员在修改和测试完最新的软件源码后会提交到源码管理服务器上，比如SVN或者github上。源码变化分析模块会连接到源码管理服务器上，自动分析核心功能函数所对应的源码变化率。如下是一种计算源码变化率的方法。

由于在运行日志中已经记录了每个功能函数的源码所在的文件比如java文件，通过查找对应的函数名可以找到功能函数的源码在java文件中的具体中具体行数。通过查找同一函数在不同版本代码中的位置来比较函数中每一行代码是否有改变，并计算改变的代码行数和原来总的行数比例得到每一个函数的变化比例Si。

Si＝(函数添加、删除、修改行数)/总代码函数

这里比如在版本V1中用户登录函数loginAction()在Login.java中的3～13行，而在最新版本V2中用户登录函数loginAction()在Login.java中的3～15行，在比较每一行后发现新添加了2行代码，则用户登录函数的变化是比例是20％。

该软件程序的整体源码的变化率S可以定义为所有核心函数的变化率Si均值：

S＝(S1*W1+S2*W2+..SN*WN)/N

N是核心函数的数量，Wi是每个函数的加权值，这里

Wi＝Ni/(N1+N2+…NN)

Ni日志中记录的第i个核心函数访问的次数。

然后，可以对整体源码变化率S和设定的变化率经验阈值(预定的阈值)。如果超出或等于经验阈值，说明系统的发布的风险比较高，则系统推荐使用灰度发布。如果变化率小于经验阈值则不推荐灰度发布。

如果计算结果是需要执行灰度发布，系统会继续统计日志信息来计算灰度发布所需要的一些参数信息，比如试用用户列表和试用时间。由于之前系统已经计算出那些变化率比较大的核心函数，所以只需要统计出那些源码变化率大的核心函数所对应的通常访问的用户和通常访问的时间，就可以计算出针对每次软件更新的最有效的试用用户和试用时间。

3.灰度发布控制模块

基于前两步模块的计算可以得出灰度发布的一些重要参数值，比如是否需要灰度发布、灰度发布的用户列表和灰度发布的时间。灰度发布控制模块主要控制发布的过程，以及在代理服务器中设定灰度发布的用户列表。

在灰度发布过程中也可以让终端用户参与进来，比如对新版本的界面的使用体验进行评分和添加意见。

在手动或用自动化工具部署完试用版本服务器之后就可以开启灰度发布，让客户同时访问稳定版本和试用版本。在灰度过程中自动开启反馈分析模块，实时从试用服务器中获取日志记录函数出错率和客户反馈。如果超出设定的阈值就自动关闭灰度发布，或把试用的用户比例调整为零。

如果没有自动关闭灰度发布，则在规定的时间点到达后停止灰度发布。

4.反馈分析模块

在灰度发布执行过程中或停止后，反馈分析模块主要对灰度发布中运行数据进行记录和统计分析。这里的运行数据主要包括2方面的数据：(1)运行日志中每个函数的运行结果；(2)用户的评价信息，用于分析用户是否对新版本的使用体验比较满意。

系统管理员基于分析结果判断是否采用试用版本，如果新的试用版本效果很好，管理员可以调整试用用户的比例为100％，重启灰度发布，这样试用版本将变成最新的稳定版本；如果新的试用版本效果较差，比如函数错误率超过50％，系统管理员需要通知开发工程师继续优化和改进源码，准备下一次灰度发布。

本发明的一个实施例如图3所示。图3是一个灰度发布控制器的架构图的示例，该灰度发布控制器包括：后端处理系统以及前端交互界面。后端处理系统与开发服务器或源码管理服务器、运行服务器之间有数据接口，与代理服务器之间存在命令接口。后端服务器内部包含四个程序模块：程序运行分析模块、代码变化分析模块、灰度发布管理模块、试用反馈分析模块。后端服务器内部包含一个数据库，用于保存数据分析结果、前端数据的展示以及保存用户交互的数据。

图4示出了根据本发明的灰度发布方法的主要流程

该流程包含四个：运行分析、源代码变化分析、灰度发布控制及反馈分析。

运行分析的作用是分析用户使用软件的日志、对不同方法的调用进行分析和排序，得出使用频率高的核心方法列表。同时，管理员也能通过GUI，方便手动设置虽然访问量低，但是代表了核心业务的核心函数。这些函数名称及用户请求ID都会被记录在运行日志数据结构中。

源码变化分析的作用是比较分析由开发者上传到代码托管服务器(SVN或Git)的代码与原始代码的差别，通过一系列的数学方法得出每个核心方法的源码改变率数值。然后通过和设置的阈值进行比较，系统能够自动推断当前最新版本的程序是否需要进行灰度发布。然后，会生成每个核心模块的用户列表和执行时间。

灰度发布控制的作用是配置灰度发布参数并管理整个灰度发布的循环流程。如果系统判断软件需要使用灰度发布，接下来，灰度发布控制模块将根据核心函数的使用率和改变率，设置相应的灰度发布参数值来管理整个灰度发布的循环流程。

反馈分析的作用是收集用户的软件版本使用反馈，分析用户对灰色发布版本的反馈并且判断试用版本是否运行顺利，用户是否对灰度发布满意。

如上所述，本发明提供了一种方法，能基于软件的开发数据和运行数据自动判断每次更新之后的软件是否需要执行灰度发布，并管理和执行灰度发布的过程，同时让终端用户也能参与到软件发布过程中，最后自动分析灰度发布的结果。

如下所示的表1展示了运行日志结构，其中包括：用户使用的应用程序名称、用户信息、用户的请求ID、调用的函数名及此函数涉及的代码行范围、调用代码所属的类名和文件名、代码调用时间、方法调用结果(成功/失败)。该日志用来计算和比较不同调用之间的S值，也即源码改变率数值。

表1

图5示出了根据本发明的灰度发布方法的过程001的具体处理。该过程由运行分析子过程和源代码变化分析子过程组成。每个软件系统由不同的函数组成。不同的函数组合顺序表明了不同的业务需求。通过这两个模块在步骤101分析系统的运行状态，得到函数的调用顺序，并在步骤102分析函数调用频率，得到核心函数列表，其中大于N次的方法被定义为核心函数。这些定义能够以图形化的方法展示在管理员GUI界面，因此管理员能够看到自动更新的记录，同时也能够手动标记他们认为的核心函数。

当开发人员更新程序源代码的时候，我们需要知道这些改变是怎样影响程序的运行环境和业务逻辑。因此当程序员把代码上传到代码仓库的时候，运行分析模块和源代码变化分析模块在步骤103中，能够自动比较新旧代码并判断核心方法是否被修改，并同时计算核心方法和修改频率平均值S。这里，S＝(S1*W1+S2*W2+..WN*SN)/N，Si＝(函数添加、删除、修改行数)/总代码函数。N是核心函数的数量，Wi是每个函数的加权值，这里Wi＝Ni/(N1+N2+…NN)，Ni是日志中记录的第i个核心函数访问的次数。通过比较运行日志结构中的类名，文件名及代码起始位置，就能够得出Si的值。

在步骤104中，如果上述的这些代码改变涉及到核心函数并且整体源码改变率高于事先设置的阈值，那么系统将会给管理员推荐使用灰度发布方法。否则，不使用灰度发布。

在步骤105中，根据运行日志结构中的用户信息及代码调用时间，系统能够计算出针对核心函数的记录，并形成测试用户列表。

图6示出了根据本发明的灰度发布方法的过程002的具体处理(灰度发布控制)。过程002通过设置灰度发布的各种参数来管理程序发布的流程。在步骤201中，主要的参数，比如“是否使用灰度发布”“试用时间”“试用用户清单”能够从过程001中计算出来。其它参数，比如“试用用户使用率”、“是否使用反馈信息”等，是管理员根据软件升级类型来定义的。在步骤202，将试用版本的软件发布到运行服务器，并在步骤203中允许步骤201中的试用用户进行使用。步骤204中，如果“是否使用反馈信息”参数设置为真，用户就可以在试用的时候加入自己的反馈意见(步骤205)。

在步骤206的运行过程中，该模块会实时分析运行日志和用户反馈。步骤207如果分析结果比较好，则“试用用户使用率”参数就增加。但是如果70％的试用失败或者得到10个错误，则试用版本将自动停止运行(步骤208)。这些阈值可以在GUI中手动设置。

图7示出了灰度发布客户反馈GUI的一个示例，在图例中，可以清楚地看到，用户在试用的过程中，对每个函数可以加入自己的反馈信息，勾选从“完美”到“非常坏”选择，也可以手动输入别的信息。但是，需要指出的是，本发明并不局限于此。

图8示出了根据本发明的灰度发布方法的过程003的具体处理(灰度发布反馈分析)。过程003运行于试用反馈分析模块。试用结束后，步骤301从运行日志结构中计算出每个核心函数的运行结果。根据这些结果，管理员能够基于如下两种标准在步骤302中判断试用结果：

a.每个核心函数是否运行顺利

b.是否大多数的用户在评论中表示对系统满意

如果判断结果是好的。则系统管理员在步骤303中将扩展用户试用列表并且最终把“试用用户使用率”更改为100％，也就意味着在步骤303中，试用版本变成了稳定版本。如果判断结果是坏的，在步骤304中，开发人员就需要为了下一次灰度发布继续改进代码。

以上列举了若干具体实施例来详细阐明本发明，这些个例仅说明本发明的原理及其实施方法之用，而非对本发明的限制，在不脱离本发明的精神和范围的情况下，本领域的技术人员还可以做出各种变形和改进。因此，本发明不应由上述实施例来限定，而应由所附权利要求及其等价物来限定。

Claims (7)

1.一种软件程序的灰度发布控制方法，包括：

从软件程序的功能函数中确定该软件程序的核心函数；

针对所确定的软件程序的所有核心函数，确定修改后的待发布的最新的软件程序相对于当前正在运行的软件程序的整体源码变化率；以及

在所述整体源码变化率超过或等于预定的阈值的情况下，将所述最新的软件程序作为试用版本而将当前正在运行的软件程序作为稳定版本进行灰度分布。

2.根据权利要求1所述的方法，还包括：

在对该软件程序进行灰度分布时，对于该软件程序中源码变化率较大的核心函数，根据运行日志信息确定其所对应的通常访问用户和通常访问时间，从而确定针对所述灰度发布的试用用户和试用时间。

3.根据权利要求1所述的方法，其中，

所述核心函数是通过根据从软件运行服务器中获取的该软件程序的运行日志信息进行函数的调用频率分析而确定的。

4.根据权利要求3所述的方法，其中，

所述核心函数是通过由程序开发者指定来确定的。

5.根据权利要求1所述的方法，还包括：

在进行灰度发布时，根据实时从试用版本的运行服务器中获取的作为日志记录的函数出错率和客户对新版本的使用反馈信息，判断是停用该试用版本还是将该试用版本采用为新的稳定版本。

6.根据权利要求1所述的方法，其中，

所述软件程序包括软件即服务程序，即，SaaS软件程序。

7.一种软件程序的灰度发布控制装置，包括：

从软件程序的功能函数中确定该软件程序的核心函数的单元；

针对所确定的软件程序的所有核心函数，确定修改后的待发布的最新的软件程序相对于当前正在运行的软件程序的整体源码变化率的单元；以及

在所述整体源码变化率超过或等于预定的阈值的情况下，将所述最新的软件程序作为试用版本而将当前正在运行的软件程序作为稳定版本进行灰度分布的单元。