CN106959872A - 应用上线方法和装置 - Google Patents

Abstract

本发明提供了一种应用上线方法和装置，其中，该方法包括：确定增量测试的待上线应用是否达到上线标准；如果达到所述上线标准，则将所述待上线应用推送到预设比例的前端集群；获取待上线应用在所述预设比例的前端集群中的反馈结果；根据所述反馈结果，确定所述待上线应用是否达到全量标准；如果达到所述全量标准，则将所述待上线应用推送到全部的前端集群中。通过本方案实现了从灰度到全量上线的目的，有效提高了项目管理的效率，降低了人工和管理成本。

Description

应用上线方法和装置

技术领域

本发明涉及互联网技术领域，特别涉及一种应用上线方法和装置。

背景技术

目前，在日常的项目进展中，从开发、测试到上线中的每一个环节都需要人为的干预。在开发环节中，开发人员需要手动提交代码；在测试环节中，测试人员需要部署相应的代码库及其相关的服务器资源；在上线环节中，需要运维人员在系统后台手动操作上线。由此可见，在整个项目的进展过程中，每个环节都是需要人为干预的，且每个环节都是断开的。

对于上线环节，虽然是需要人为干预的，但是还是存在自动上线的可能，通过自动上线可以有效提高项目进展的效率，可以提高管理和人工成本。

针对如何简单高效实现上线环节的自动化，目前尚未提出有效的解决方案。

发明内容

本发明实施例提供了一种应用上线方法，以达到应用自动化上线的目的，该方法包括：

确定增量测试的待上线应用是否达到上线标准；

如果达到所述上线标准，则将所述待上线应用推送到预设比例的前端集群；

获取待上线应用在所述预设比例的前端集群中的反馈结果；

根据所述反馈结果，确定所述待上线应用是否达到全量标准；

如果达到所述全量标准，则将所述待上线应用推送到全部的前端集群中。

在一个实施方式中，获取待上线应用在所述预设比例的前端集群中的反馈结果，包括：

获取所述待上线应用在所述预设比例的前端集群中预设灰度验证时间的反馈结果。

在一个实施方式中，所述预设灰度验证时间大于等于搜集所述预设灰度验证时间的反馈结果的时间，小于一个上线周期。

在一个实施方式中，所述反馈结果包括以下至少之一：用户的使用反馈结果、产品人员的反馈结果、测试人员的反馈结果。

在一个实施方式中，在根据所述反馈结果，确定所述待上线应用是否达到全量标准之后，所述方法还包括：

如果未达到所述全量标准，则将所述预设比例的前端集群回滚至上一次稳定可用状态。

在一个实施方式中，所述预设比例大于等于4％，小于50％。

在一个实施方式中，上述应用上线方法还包括：将所述待上线应用的上线状态信息以邮件和/或WEB页面的形式展现。

本发明实施例还提供了一种应用上线装置，以达到应用自动化上线的目的，该装置包括：

第一确定模块，用于确定增量测试的待上线应用是否达到上线标准；

第一推送模块，用于在确定达到所述上线标准的情况下，将所述待上线应用推送到预设比例的前端集群；

获取模块，用于获取待上线应用在所述预设比例的前端集群中的反馈结果；

第二确定模块，用于根据所述反馈结果，确定所述待上线应用是否达到全量标准；

第二推送模块，用于在确定达到所述全量标准的情况下，将所述待上线应用推送到全部的前端集群中。

在一个实施方式中，上述应用上线装置还包括：回滚模块，用于在在根据所述反馈结果，确定所述待上线应用是否达到全量标准之后，在确定未达到所述全量标准的情况下，将所述预设比例的前端集群回滚至上一次稳定可用状态。

在一个实施方式中，上述应用上线装置还包括：展现模块，将所述待上线应用的上线状态信息以邮件和/或WEB页面的形式展现。

在本发明实施例中，提供了一种应用上线方法，先是部分前端集群的灰度上线，在基于反馈结果确定可以全量上线后，再进行全线上线，因为考虑到了灰度上线后的反馈因素，从而实现了从灰度到全量上线的目的，有效提高了项目管理的效率，降低了人工和管理成本。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，并不构成对本发明的限定。在附图中：

图1是根据本发明实施例的应用上线方法的一种方法流程图；

图2是根据本发明实施例的基于用户动态反馈的自动上线构建系统示意图；

图3是根据本发明实施例的应用上线装置的一种结构框图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下面结合实施方式和附图，对本发明做进一步详细说明。在此，本发明的示意性实施方式及其说明用于解释本发明，但并不作为对本发明的限定。

为了提升项目进展的效率，降低管理和人工成本。可以减少项目进展过程中的人为因素，将整个项目进展自动化，从而使得每个项目环节流程化。尤其在上线环节，可以考虑用户动态反馈因素、产品人员反馈因素以及测试人员反馈因素，以自动化进行从灰度到全量的自动上线流程。通过该方式可以有效提高项目管理上的效率、降低人工和管理成本，同时可以将各个生产环节的信息透明化，及时反映项目状态。

具体的，如图1所示，在本例中提供了一种应用上线方法，可以包括以下步骤：

步骤101：确定增量测试的待上线应用是否达到上线标准；

具体的，可以是经过每日的增量测试的应用，在该应用达到项目上线标准的时候，就可以启动自动上线流程。

步骤102：如果达到所述上线标准，则将所述待上线应用推送到预设比例的前端集群；

考虑到将上线过程分为：灰度阶段和全量阶段，因此，在确定达到上线标准的情况下，可以先将项目推送到预设比例(例如：5％)的灰度前端集群。在此之后，可以经过预定时长的灰度验证时间(例如6个小时)。

然而值得注意的是，上述所列举的预设比例的取值和预设时长的取值，仅是一种示例性表述，在实现的时候，可以采用其它的数值。举例而言，预设比例可以根据项目的用户量进行动态调整，只要达到既能涵盖搜集到反馈验证效果，又避免影响大面积的用户的要求即可，例如，可以选择5％左右，但是最大不要超出50％。上预设时长也是可以动态调整的，在选择的时候，可以设置小于一个上线周期，不少于搜集灰度验证反馈结果的时间，数值的具体设定可以根据自身的项目情况、项目灰度时间和上线时间选定。

步骤103：获取待上线应用在所述预设比例的前端集群中的反馈结果；

具体的，系统可以通过内部机制检测线上真实用户的使用反馈、产品人员的反馈结果、测试人员的反馈结果等来决策如何执行如下操作。

即，获取灰度验证时间之后的反馈结果，基于这些反馈结果确定后续是进行回滚，还是进行全量上线。

然而，值得注意的是，上述所列举的反馈结果仅是为了一种示意性表述，在实际实现的时候，还可以包括其它的反馈结果类型，本申请对此不作限定。上述所列列举的前端集群的比例和灰度验证时间的具体取值也仅是一种示意性表述，在实际执行的时候，可以根据系统的处理能力和精度需求选取合适的取值。

步骤104：根据所述反馈结果，确定所述待上线应用是否达到全量标准；

步骤105：如果达到所述全量标准，则将所述待上线应用推送到全部的前端集群中。

即，如果确定该应用可以达到全量标准，那么就可以将该应用上线推广至所有的前端集群。如果未达到所述全量标准，那么可以将预设比例的前端集群回滚至上一次稳定可用状态。

进一步的，为了使得各个生成环节的信息透明化，并及时反馈项目的状态，可以通过邮件或者WEB方式，将项目当前的状态信息等展示给相应的测试和产品人员。

下面结合一个具体实施例对上述应用上线方法进行说明，然而值得注意的是，该具体实施例仅是为了更好地说明本申请，并不构成对本申请的不当限定。

在生产实践中，项目进展中的人为干预，带来的不一定是更高的产品质量，有时会影响产品的质量。同时，每个环节的运行状态信息不透明，无法实时的反应项目当前的状态，这也大大降低了产品质量，增大了项目故障排查的成本。在本例中，通过减少日常项目进展中的人为因素，将整个项目进展自动化，使每个项目环节流程化，尤其是上线环节。在本例中，提供了一种基于用户动态反馈的持续上线构建系统设计。

在软件开发的过程中，自动构建是重要的过程之一，构建系统会将整个产品解决方案完整地构建一遍，将生成的程序文件部署在一个稳定的可测集群环境中。随后，接着进行BVT(Build Verification Test)来对主功能进行冒烟测试(Smoke Test)，并将检测结果报告(Reporting)发送给相关Team Member的邮箱。

在经过每日的增量测试，在达到项目上线标准时，启动自动上线流程，这个自动上线流程可以分为两个阶段：灰度阶段与全量阶段。

如图2所示，在达到上线标准时，系统将项目推送到5％的灰度前端集群。在此之后，会经过长达6个小时候的灰度验证时间。系统将通过内部机制检测线上真实用户的使用反馈、产品与测试人员的使用反馈来决策下一步的具体执行动作。如果反馈效果没有达到全量标准，那么系统将回滚当前灰度集群的代码到上一次稳定可用状态。如果反馈效果可以达到全量标准，那么系统将会发布最新项目版本到100％前端机集群。同时，以上每个环节的信息都可以以邮件形式和WEB形式进行展现。

自动化项目构建系统可以采用PHP语言作为开发工具，运行于Linux+Nginx环境下，配合Crontab(计划任务)功能，每日定时将所有开发人员编写的代码自动地提交到Git(或者SVN)版本库，随后进行代码库的编译(检测)，推送代码到与开发环境隔离的测试服务器集群中。

随后，测试人员进行版本增量测试。在达到版本上线预期时，构建系统可以根据当前用户、产品人员与测试人员的反馈进行决策，进而以先灰度再全量的方式将测试环境的代码推送线上服务集群。

在灰度阶段，如上所述，构建系统会将上述的代码直接推送到线上服务器集群中的若干台。当然，可以设置只有白名单(部分)用户的请求会落到这些服务器上。

在上述的所有环节中，不论进展顺利与否，相关构建信息都可以通过PHPMailer组件以邮件形式发送给项目的所有相关人员，例如：项目经理、产品、测试、开发与其他业务方人员，从而实现自动化构建过程的透明化。其中，邮件的内容可以包括但不限于以下一种或多种：构建状态与产品基本信息、版本库的代码提交信息、测试方法信息以及产品构建的流程信息(附件)等等。一旦有项目构建失败的情况，可以根据邮件中的信息，相关负责人员可以及时修正，以提高产品质量，降低线上故障风险。

通过上述的应用上线方法，可以提高项目的管理效率、降低人工成本、实现项目状态的透明化、降低集成风险、提高产品质量、实现流程规范化。

基于同一发明构思，本发明实施例中还提供了一种应用上线装置，如下面的实施例所述。由于应用上线装置解决问题的原理与应用上线方法相似，因此应用上线装置的实施可以参见应用上线方法的实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。图3是本发明实施例的应用上线装置的一种结构框图，如图3所示，可以包括：第一确定模块301、第一推送模块302、获取模块303、第二确定模块304和第二推送模块305，下面对该结构进行说明。

第一确定模块301，用于确定增量测试的待上线应用是否达到上线标准；

第一推送模块302，用于在确定达到所述上线标准的情况下，将所述待上线应用推送到预设比例的前端集群；

获取模块303，用于获取待上线应用在所述预设比例的前端集群中的反馈结果；

第二确定模块304，用于根据所述反馈结果，确定所述待上线应用是否达到全量标准；

第二推送模块305，用于在确定达到所述全量标准的情况下，将所述待上线应用推送到全部的前端集群中。

在一个实施方式中，上述获取模块303具体可以用于获取所述待上线应用在所述预设比例的前端集群中预设灰度验证时间的反馈结果。

在一个实施方式中，所述预设灰度验证时间为6小时。

在一个实施方式中，所述反馈结果可以包括但不限于以下至少之一：用户的使用反馈结果、产品人员的反馈结果、测试人员的反馈结果。

在一个实施方式中，上述应用上线装置还可以包括：回滚模块，用于在在根据所述反馈结果，确定所述待上线应用是否达到全量标准之后，在确定未达到所述全量标准的情况下，将所述预设比例的前端集群回滚至上一次稳定可用状态。

在一个实施方式中，所述预设比例为5％。

在一个实施方式中，上述应用上述装置还可以包括：展现模块，将所述待上线应用的上线状态信息以邮件和/或WEB页面的形式展现。

在另外一个实施例中，还提供了一种软件，该软件用于执行上述实施例及优选实施方式中描述的技术方案。

在另外一个实施例中，还提供了一种存储介质，该存储介质中存储有上述软件，该存储介质包括但不限于：光盘、软盘、硬盘、可擦写存储器等。

从以上的描述中，可以看出，本发明实施例实现了如下技术效果：提供了一种应用上线方法，先是部分前端集群的灰度上线，在基于反馈结果确定可以全量上线后，再进行全量上线，因为考虑到了灰度上线后的反馈因素，从而实现了从灰度到全量上线的目的，有效提高了项目管理的效率，降低了人工和管理成本。

显然，本领域的技术人员应该明白，上述的本发明实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明实施例不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明实施例可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种应用上线方法，其特征在于，包括：

确定增量测试的待上线应用是否达到上线标准；

如果达到所述上线标准，则将所述待上线应用推送到预设比例的前端集群；

获取待上线应用在所述预设比例的前端集群中的反馈结果；

根据所述反馈结果，确定所述待上线应用是否达到全量标准；

如果达到所述全量标准，则将所述待上线应用推送到全部的前端集群中。

2.如权利要求1所述的方法，其特征在于，获取待上线应用在所述预设比例的前端集群中的反馈结果，包括：

获取所述待上线应用在所述预设比例的前端集群中预设灰度验证时间的反馈结果。

3.如权利要求2所述的方法，其特征在于，所述预设灰度验证时间大于等于搜集所述预设灰度验证时间的反馈结果的时间，小于一个上线周期。

4.如权利要求1所述的方法，其特征在于，所述反馈结果包括以下至少之一：用户的使用反馈结果、产品人员的反馈结果、测试人员的反馈结果。

5.如权利要求1所述的方法，其特征在于，在根据所述反馈结果，确定所述待上线应用是否达到全量标准之后，所述方法还包括：

如果未达到所述全量标准，则将所述预设比例的前端集群回滚至上一次稳定可用状态。

6.如权利要求1至5中任一项所述的方法，其特征在于，所述预设比例大于等于4％，小于50％。

7.如权利要求1至5中任一项所述的方法，其特征在于，还包括：

将所述待上线应用的上线状态信息以邮件和/或WEB页面的形式展现。

8.一种应用上线装置，其特征在于，包括：

第一确定模块，用于确定增量测试的待上线应用是否达到上线标准；

第一推送模块，用于在确定达到所述上线标准的情况下，将所述待上线应用推送到预设比例的前端集群；

获取模块，用于获取待上线应用在所述预设比例的前端集群中的反馈结果；

第二确定模块，用于根据所述反馈结果，确定所述待上线应用是否达到全量标准；

第二推送模块，用于在确定达到所述全量标准的情况下，将所述待上线应用推送到全部的前端集群中。

9.如权利要求8所述的装置，其特征在于，还包括：

回滚模块，用于在在根据所述反馈结果，确定所述待上线应用是否达到全量标准之后，在确定未达到所述全量标准的情况下，将所述预设比例的前端集群回滚至上一次稳定可用状态。

10.如权利要求8或9所述的装置，其特征在于，还包括：

展现模块，将所述待上线应用的上线状态信息以邮件和/或WEB页面的形式展现。