CN116820519A - App发布控制方法、装置、介质及设备 - Google Patents

Abstract

本申请提供了一种APP发布控制方法、装置、介质及设备，其中方法包括：为APP待发布新版本配置处理事项检查单插件，生成包括多个处理节点的处理事项检查单；监控各个处理节点的状态信息；针对进行中状态的处理节点，响应于事项处理操作，变更处理节点的状态为已完成状态，其中，所述事项处理操作，是根据进行中状态的处理节点的操作方式信息，进行事项确认、转发、脚本调用中的至少一项操作；当所有处理节点状态均为已完成状态时，确定完成所述处理事项检查单，以指示进行APP新版本的发布。本申请可降低APP发布过程中的风险，例如，本申请针对数字医疗APP发布前进行控制，从而降低发布风险。

Description

APP发布控制方法、装置、介质及设备

技术领域

本申请涉及计算机应用软件技术领域和数字医疗领域，尤其是涉及到一种APP发布控制方法、装置、介质及设备。

背景技术

APP应用因为不可分割性，导致无法像后端服务一样分割成多个应用，彼此独立。例如，随着互联网技术的发展以及智能终端的普及，传统医疗模式逐步向数字医疗转换，例如，随着数字医疗的发展，各种数字医疗相关APP或小程序应运而生，例如，该类数字医疗平台可向用户提供挂号、体检、咨询、购药等相关服务。

由于APP发布时间统一，但是发布过程中多团队之间的沟通协调成本太大；而且，人为的互通存在信息错误，导致发布风险提升，严重可能导致无法顺利发布。例如，在针对数字医疗APP新版本发布之前，研发团队各成员需要完成本人部分的工作(代码更新、界面优化、方案确认等)，如果通过各部门各成员之间线下梳理各个环节的实施，非常耗费人力和时间，而且可能存在环节确认不准确或环节缺失等问题。可见，APP从研发到发布的流程就会因为多人的参与而变得杂乱，风险不可控。而由于数字医疗APP很大程度上依赖于用户使用感受，因此，如何快速、准确地进行APP版本更新，降低发布过程中的风险，以改善用户体验显得尤为重要。

发明内容

有鉴于此，本申请提供了一种APP发布控制方法、装置、介质及设备，主要目的在于降低APP发布过程中的风险，例如，针对数字医疗APP发布进行风险控制。

依据本申请的一个方面，提供了一种APP发布控制方法，包括：

为APP待发布新版本配置处理事项检查单插件，生成包括多个处理节点的处理事项检查单；

监控各个处理节点的状态信息；

针对进行中状态的处理节点，响应于事项处理操作，变更处理节点的状态为已完成状态，其中，所述事项处理操作，是根据进行中状态的处理节点的操作方式信息，进行事项确认、转发、脚本调用中的至少一项操作；

当所有处理节点状态均为已完成状态时，确定完成所述处理事项检查单，以指示进行APP新版本的发布。

在一种实现方式中，还包括：

根据各个处理节点的处理事项之间的依赖关系，确定各个处理节点之间的扭转方式，所述扭转方式包括串行扭转方式和/或并行扭转方式；

对于串行扭转方式的多个处理节点，进行串行的事项处理操作；对于并行扭转方式的多个处理节点，进行并行的事项处理操作。

在一种实现方式中，所述根据各个处理节点的处理事项之间的依赖关系，确定各个处理节点之间的扭转方式，包括：

当第二处理节点处理事项不依赖于第一处理节点处理事项的处理结果时，确定第一处理节点和第二处理节点之间的扭转方式为串行扭转方式；

当第二处理节点处理事项依赖于第一处理节点处理事项的处理结果时，确定第一处理节点和第二处理节点之间的扭转方式为并行扭转方式。

在一种实现方式中，还包括：

配置所述处理节点进一步包括多个子节点，当所述处理节点所包含的多个子节点的状态均为已完成状态时，确定所述处理节点的状态为已完成状态。

在一种实现方式中，还包括：

根据各个子节点的处理事项之间的依赖关系，确定各个子节点之间的扭转方式，所述扭转方式包括串行扭转方式和/或并行扭转方式；

对于串行扭转方式的多个子节点，进行串行的事项处理操作；对于并行扭转方式的多个子节点，进行并行的事项处理操作。

在一种实现方式中，所述根据各个子节点的处理事项之间的依赖关系，确定各个子节点之间的扭转方式，包括：

当第二子节点处理事项不依赖于第一子节点处理事项的处理结果时，确定第一子节点和第二子节点之间的扭转方式为串行扭转方式；

当第二子节点处理事项依赖于第一子节点处理事项的处理结果时，确定第一子节点和第二子节点之间的扭转方式为并行扭转方式。

在一种实现方式中，

还包括：配置处理节点属性信息，所述属性信息包括完成时间信息、操作人员信息、状态信息、操作方式信息中的至少一项；

在所述变更处理节点的状态为已完成状态之后，还包括：根据所述处理事项检查单，确定已完成处理节点的下一处理节点；将所述下一处理节点的状态信息从待完成状态更新为进行中状态。

依据本申请的一个方面，提供了一种APP发布控制装置，包括：

检查单生成单元，用于为APP待发布新版本配置处理事项检查单插件，生成包括多个处理节点的处理事项检查单；

节点监控单元，用于监控各个处理节点的状态信息；

节点操作单元，用于针对进行中状态的处理节点，响应于事项处理操作，变更处理节点的状态为已完成状态，其中，所述事项处理操作，是根据进行中状态的处理节点的操作方式信息，进行事项确认、转发、脚本调用中的至少一项操作；

发布指示单元，用于当所有处理节点状态均为已完成状态时，确定完成所述处理事项检查单，以指示进行APP新版本的发布。

依据本申请的一个方面，提供了一种存储介质，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行上述APP发布控制方法。

依据本申请的一个方面，提供了一种计算机设备，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行上述APP发布控制方法。

借由上述技术方案，本申请提供的一种APP发布控制方法、装置、介质及设备，通过一个检查单插件，生成包括多个处理节点的处理事项检查单，通过监控处理节点的状态，当所有处理节点状态均为已完成状态时，确定完成处理事项检查单，以指示进行APP新版本的发布。整个APP发布之前的准备工作无需人工接入，而是基于工作流引擎实现检查单插件，通过检查单(checklist)控制APP发布过程中的各个处理节点，当所有节点的状态均完成时，即可启动新版本APP发布。整个自动化控制过程可大大提高处理效率，且避免人为处理带来的风险。在一种实现方式中，checkList控制每个节点的扭转，节省了线下人工检查，推动流程的沟通时间和人力成本；避免了可能出现人为错误，节点操作遗留等问题。

例如，由于数字医疗APP很大程度上依赖于用户使用感受，因此，如何快速、准确地进行APP版本更新，以改善用户体验显得尤为重要。在数字医疗APP发布之前，通过本申请方案，由APP研发管理人员梳理处理节点及节点之间的扭转方式，通过检查单插件生成处理实事项检查单，之后，按照检查单上处理节点的流程进行串行或并行扭转，待所有处理节点状态均为已完成时，确定数字医疗APP新版本准备工作完毕，可进行版本发布。可见，采用本申请实施例方案，可针对数字医疗APP实现自动化处理流程，提高版本更新的效率，由此可改善用户体验。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1示出了本申请实施例提供的一种APP发布控制方法应用场景示意图

图2示出了本申请实施例提供的一种APP发布控制方法流程图；

图3示出了本申请实施例提供的一种APP发布控制方法实例示意图；

图4示出了本申请实施例提供的一种APP发布控制装置结构示意图；

图5示出了本申请实施例提供的一种计算机设备结构示意图；

图6示出了本申请实施例提供的另一种计算机设备结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

在当前APP发布控制方面，发布人员手动维护发布表格；发布人员需要记住每一个时间节点；到时间点了需要线下提醒相应人员操作，并且要一直去询问操作人员，获取操作结果。每个时间节点，都需要检查发布表格，确认没有任务遗漏。发布前发现遗漏可能会引起发无法按时上线。发布后发现遗漏，很可能导致线上故障。整个发布过程，发布人员需要一直在提醒，反复沟通获取结果，检查发布事项。非常消耗人力，效率低下。

针对上述问题，本申请实施例提出一种APP发布控制方法，摒弃APP发布过程中人为控制节点的方式，而是基于工作流引擎驱动一个checklist(检查单)，通过该checklist监控APP发布过程中的各个处理节点，各个处理节点并行或串行方式执行，当所有节点的状态均完成时，确定APP发布准备工作即完成，期间无需人员线下记录时间点，也无需协调其他人员进行处理，并且避免了人为遗忘等情况造成的风险，整个自动化控制过程可大大提高处理效率。

请参见图1，示出了本申请实施例提供的一种APP发布控制方法的实施场景示意图，其中，用户侧可以为用户使用的智能终端侧，智能终端例如是手机、电脑等终端，该终端上安装或使用有数字医疗客户端，例如数字医疗APP或小程序；网络侧为数字医疗客户端对应的服务端，在该服务端，进行数据存储、处理、对接客户端的请求等。

需要说明的是，本申请实施例可应用于数字医疗领域。例如，随着数字医疗的发展，各种数字医疗相关APP应运而生，例如，在线问诊平台向用户提供挂号、体检、咨询、购药等相关服务，用户需要向网络侧发送网络请求从而进行在线挂号或购药等。本申请实施例针对各类APP，包括但不限于数字医疗相关APP。本申请实施例中的数据包括但不限于医疗数据，如个人健康档案、处方、检查报告等数据。

参见图2，示出了本申请实施例提供的一种APP发布控制方法流程图。

该APP发布控制方法包括如下步骤S201-S204。

S201：为APP待发布新版本配置处理事项检查单插件，生成包括多个处理节点的处理事项检查单。

在APP当前版本发布之后，即可启动生成APP待发布新版本的处理事项检查单(checklist)。具体实现中，可通过基于工作流引擎(例如Activiti)驱动检查单插件，生成处理实现检查单。checklist可以理解为通过自动化技术实现的流程管理工具，在checklist上配置有多个处理节点，这些处理节点的执行顺序逻辑是在生成checklist时即根据实际设计需求而确定的，例如，处理节点之间包括顺序执行或并行执行的执行顺序逻辑。

为了生成checklist，需要对待发布新版本的处理节点进行规划和梳理。一般情况下，APP下一个版本会对已发布版本进行部分功能升级、优化等，可能涉及功能模块的新增或变更，以及UI界面更新等，因此，需要根据实际设计需求，配置处理节点。例如，处理节点可能包括文件配置、更新创建、用例创建等。

S202：监控各个处理节点的状态信息。

为了对整个checklist的执行情况进行监控，需要关注处理节点的状态信息。处理节点的状态信息，可包括如下几项：

1、完成时间信息：节点完成时间；

2、协调人信息：操作人；

3、状态信息：待完成状态、进行中状态、已完成状态；

4、操作信息：具体操作方式，例如，确认、转发或脚本调用(文件上传)等操作。

其中，“进行中状态”的处理节点，当前checklist执行到的节点，如果该节点被执行完成，则状态会更新为“已完成状态”，然后，自动跳转到下一个待执行节点。

因此在一种实现方式中，上述方法还包括如下步骤：配置处理节点属性信息，属性信息包括完成时间信息、操作人员信息、状态信息、操作方式信息中的至少一项；在变更处理节点的状态为已完成状态之后，还包括：根据处理事项检查单，确定已完成处理节点的下一处理节点；将下一处理节点的状态信息从待完成状态更新为进行中状态。

S203：针对进行中状态的处理节点，响应于事项处理操作，变更处理节点的状态为已完成状态，其中，事项处理操作，是根据进行中状态的处理节点的操作方式信息，进行事项确认、转发、脚本调用中的至少一项操作。

在整个checklist中，可对“进行中状态”的处理节点进行操作。如果进行中状态的处理节点被操作人执行了事项处理操作，则自动将状态更新为已完成状态。例如，针对当前进行中的节点，操作人进行了事项确认、转发、脚本调用中的至少一项操作，完成了该节点任务，则将该节点状态更新为已完成状态，并自动跳转到checklist中该节点的下一个处理节点。

需要说明的是，如果某些处理节点的执行逻辑是并行的，则可能存在多个进行中状态的处理节点。

S204：当所有处理节点状态均为已完成状态时，确定完成处理事项检查单，以指示进行APP新版本的发布。

通过对各个处理节点状态信息的监控，可确认整个checklist的处理情况，当监控到所有处理节点的状态均为已完成状态时，即可确定整个checklist已被执行完成，因此，此时可确定完成了待发布新版本APP的所有工作，即可启动新版本的发布了。

可见，通过本申请实施例提供的APP发布控制方法，整个APP发布之前的准备工作无需人工接入，而是基于工作流引擎实现检查单插件，通过该checklist控制APP发布过程中的各个处理节点，当所有节点的状态均完成时，即可启动新版本APP发布。整个自动化控制过程可大大提高处理效率，且避免人为处理带来的风险。

例如，由于数字医疗APP很大程度上依赖于用户使用感受，因此，如何快速、准确地进行APP版本更新，以改善用户体验显得尤为重要。在数字医疗APP发布之前，通过本申请方案，由APP研发管理人员梳理处理节点及节点之间的扭转方式，通过检查单插件生成处理实事项检查单，之后，按照检查单上处理节点的流程进行串行或并行扭转，待所有处理节点状态均为已完成时，确定数字医疗APP新版本准备工作完毕，可进行版本发布。可见，采用本申请实施例方案，可针对数字医疗APP实现自动化处理流程，提高版本更新的效率，由此可改善用户体验。

在一种实现方式中，上述APP发布控制方法还包括如下步骤：

(1)根据各个处理节点的处理事项之间的依赖关系，确定各个处理节点之间的扭转方式，扭转方式包括串行扭转方式和/或并行扭转方式。

其中，

当第二处理节点处理事项不依赖于第一处理节点处理事项的处理结果时，确定第一处理节点和第二处理节点之间的扭转方式为串行扭转方式；

当第二处理节点处理事项依赖于第一处理节点处理事项的处理结果时，确定第一处理节点和第二处理节点之间的扭转方式为并行扭转方式。

(2)对于串行扭转方式的多个处理节点，进行串行的事项处理操作；对于并行扭转方式的多个处理节点，进行并行的事项处理操作。

例如，假设checklist上包括处理节点A、B，而根据实际设计要求，处理节点B必须在处理节点A完成后才可以启动，那么此时可以确认处理节点B依赖于处理节点A的处理结果，即，处理节点B与处理节点A具有依赖关系，即二者是串行的扭转方式；而如果处理节点B无需在处理节点A完成后才可以启动，那么此时可以确认处理节点B不依赖于处理节点A的处理结果，即，处理节点B与处理节点A不具有依赖关系，即二者是并行的扭转方式。例如，假设处理节点A是“工程师上传更新脚本”、处理节点B是“界面主管确认”，那么，需要在工程师进行脚本上传之后，再由主管确认，因此，此例子中认为处理节点B与处理节点A具有依赖关系，属于串行的扭转方式。再比如，假设处理节点A是“工程师A上传脚本1”、处理节点B是“工程师乙上传脚本2”，那么，两份脚本上传无需区分先后顺序，因此，此例子中认为处理节点B与处理节点A不具有依赖关系，属于并行的扭转方式。

在一种实现方式中，某个(些)处理节点还进一步包括子节点，例如，某个组件更新任务中可能涉及多个脚本上传及确认等流程，因此，在该“组件更新”处理节点下，可能包括多个子节点。因此，在上述APP发布控制方法中，还可以包括如下步骤：配置处理节点进一步包括多个子节点，当处理节点所包含的多个子节点的状态均为已完成状态时，确定处理节点的状态为已完成状态。可以理解，一个处理节点的状态，需要通过其所包含的所有子节点的状态来体现，当其中有未完成的子节点，该处理节点的状态也是未完成，只有所有子节点的状态均为已完成时，该处理节点才是已完成状态。

在此基础上，上述APP发布控制方法中，还可以包括如下步骤：

(A)根据各个子节点的处理事项之间的依赖关系，确定各个子节点之间的扭转方式，所述扭转方式包括串行扭转方式和/或并行扭转方式。

其中，

当第二子节点处理事项不依赖于第一子节点处理事项的处理结果时，确定第一子节点和第二子节点之间的扭转方式为串行扭转方式；

当第二子节点处理事项依赖于第一子节点处理事项的处理结果时，确定第一子节点和第二子节点之间的扭转方式为并行扭转方式。

(B)对于串行扭转方式的多个子节点，进行串行的事项处理操作；对于并行扭转方式的多个子节点，进行并行的事项处理操作。

上述有关根据子节点之间依赖关系确定并行或串行扭转方式，可参见上述对处理节点扭转方式的说明和例子进行理解。

下面以一个具体例子对本申请实施例提供的APP发布控制方法进行示例性说明。

参见图3，示出了本申请实施例提供的一种APP发布控制方法实例示意图。该例子checklist中，包括左侧的两个处理节点：初始化节点、需求冻结节点，进一步，右侧示出了处理节点的子节点，其中，初始化节点进一步包括的子节点有：生成新版本featurelist、灰度配置完成确认、首页clone、热更新创建、用例创建，需求冻结节点进一步包括的子节点有：填写featurelist截至时间、完成featurelist的填写。

对该例子涉及的主要逻辑和处理方式说明如下：

1)App在一个版本发布后，自动生成下一个待发布版本的checkList，checkList的每个节点组成如下：

扭转方式：

串行(例：如图3，左侧节点“需求冻结”必须是“初始化”节点完成后才能开始)；

并行(例：如图3，右侧节点“首页clone”和“热更新创建”没有执行的先后顺序)。

完成时间：节点完成时间。

协调人：操作人。

状态：待完成，进行中，已完成。

操作：发邮件，确认等。

2)checklist的扭转

整个流程例如采用JFlow的工作流引擎，从数据库调用各节点及配置，调用各配置执行方法完成节点，引擎在执行如下处理方式：

串行：只有前一个节点完成，下一个节点才会开启；

例：如图3，只有串行节点“迭代初始化”完成后，下一个串行节点“需求冻结”才能打开，方便协调人操作响应。

并行：多个节点同时打开，操作人可以在这些节点上操作响应；

例：如图3，并行节点(生成新版本featureList，灰度配置完成确认，首页clone，热更新创建...)都是可以操作响应的.

3)状态变更

只有进行中的节点可以操作，

操作方式有多种：1、发邮件，系统在节点打开后自动邮件给对应的人员，例如，引用mail.jar实现邮件发送，同时引入沟通工具等及时发消息，避免邮件被忽略；2、确认，部分节点是需要操作人员响应的，此类节点只有操作人员在节点点击确认；3、部分功能可以直接调用外部自动化脚本完成，例如图3的“热更新创建”，直接调用运维的脚本，自动完成节点。

确认类型进一步可分为两种：1、多个操作人中只要有一个确认响应，则节点由进行中变为已完成；2、多个操作人都要确认响应，节点才能有进行中变为已完成。

4)技术运用

例如，可采用Activiti工作流引擎驱动整个流程，以及，通过数据库获取每个节点的配置。另外，可支持节点事务回滚、观察者模式，监控各节点状态，当任意节点被响应式，及时作出处理。整个流程支持各业务团队脚本接入。例如图3的灰度配置节点，可直接对接的运维团队的脚本，无需人工介入。

可见，上述例子中，通过线上发布流程的checkList，状态清晰明了，所有人员都能实时查看，而现有的线下发布流程，仅发布人自己维护了一个线下进度表格，其他对于发布进度完全不了解，本申请方案可实现所有人员共享各个节点状态，并及时处理自己对应的事项，提高处理效率；此外，CheckList控制每个节点的扭转，节省了线下人工检查，推动流程的沟通时间和人力成本；避免了可能出现人为错误，节点操作遗留等问题。

参见图4，示出了本申请实施例提供的一种APP发布控制装置结构示意图。该APP发布控制装置包括：

检查单生成单元401，用于为APP待发布新版本配置处理事项检查单插件，生成包括多个处理节点的处理事项检查单；

节点监控单元402，用于监控各个处理节点的状态信息；

节点操作单元403，用于针对进行中状态的处理节点，响应于事项处理操作，变更处理节点的状态为已完成状态，其中，所述事项处理操作，是根据进行中状态的处理节点的操作方式信息，进行事项确认、转发、脚本调用中的至少一项操作；

发布指示单元404，用于当所有处理节点状态均为已完成状态时，确定完成所述处理事项检查单，以指示进行APP新版本的发布。

在一种实现方式中，节点操作单元403还用于：

根据各个处理节点的处理事项之间的依赖关系，确定各个处理节点之间的扭转方式，所述扭转方式包括串行扭转方式和/或并行扭转方式；

对于串行扭转方式的多个处理节点，进行串行的事项处理操作；对于并行扭转方式的多个处理节点，进行并行的事项处理操作。

在一种实现方式中，节点操作单元403具体用于：

当第二处理节点处理事项不依赖于第一处理节点处理事项的处理结果时，确定第一处理节点和第二处理节点之间的扭转方式为串行扭转方式；

当第二处理节点处理事项依赖于第一处理节点处理事项的处理结果时，确定第一处理节点和第二处理节点之间的扭转方式为并行扭转方式。

在一种实现方式中，检查单生成单元401还用于：

配置所述处理节点进一步包括多个子节点，当所述处理节点所包含的多个子节点的状态均为已完成状态时，确定所述处理节点的状态为已完成状态。

在一种实现方式中，节点操作单元403还用于：

根据各个子节点的处理事项之间的依赖关系，确定各个子节点之间的扭转方式，所述扭转方式包括串行扭转方式和/或并行扭转方式；

对于串行扭转方式的多个子节点，进行串行的事项处理操作；对于并行扭转方式的多个子节点，进行并行的事项处理操作。

在一种实现方式中，节点操作单元403具体用于：

当第二子节点处理事项不依赖于第一子节点处理事项的处理结果时，确定第一子节点和第二子节点之间的扭转方式为串行扭转方式；

当第二子节点处理事项依赖于第一子节点处理事项的处理结果时，确定第一子节点和第二子节点之间的扭转方式为并行扭转方式。

在一种实现方式中，

检查单生成单元401还用于：配置处理节点属性信息，所述属性信息包括完成时间信息、操作人员信息、状态信息、操作方式信息中的至少一项；

节点操作单元403还用于：根据所述处理事项检查单，确定已完成处理节点的下一处理节点；将所述下一处理节点的状态信息从待完成状态更新为进行中状态。

关于APP发布控制装置的具体限定可以参见上文中对于APP发布控制装置方法的限定，在此不再赘述。上述APP发布控制装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务端，其内部结构图可以如图5所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性和/或易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部的客户端通过网络连接通信。该计算机程序被处理器执行时以实现一种APP发布控制装置方法服务端侧的功能或步骤。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是客户端，其内部结构图可以如图6所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部服务器通过网络连接通信。该计算机程序被处理器执行时以实现一种APP发布控制装置方法客户端侧的功能或步骤。

在一个实施例中，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现以下步骤：

为APP待发布新版本配置处理事项检查单插件，生成包括多个处理节点的处理事项检查单；

监控各个处理节点的状态信息；

针对进行中状态的处理节点，响应于事项处理操作，变更处理节点的状态为已完成状态，其中，所述事项处理操作，是根据进行中状态的处理节点的操作方式信息，进行事项确认、转发、脚本调用中的至少一项操作；

当所有处理节点状态均为已完成状态时，确定完成所述处理事项检查单，以指示进行APP新版本的发布。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：

为APP待发布新版本配置处理事项检查单插件，生成包括多个处理节点的处理事项检查单；

监控各个处理节点的状态信息；

针对进行中状态的处理节点，响应于事项处理操作，变更处理节点的状态为已完成状态，其中，所述事项处理操作，是根据进行中状态的处理节点的操作方式信息，进行事项确认、转发、脚本调用中的至少一项操作；

当所有处理节点状态均为已完成状态时，确定完成所述处理事项检查单，以指示进行APP新版本的发布。

需要说明的是，上述关于计算机可读存储介质或计算机设备所能实现的功能或步骤，可对应参阅前述方法实施例中，服务端侧以及客户端侧的相关描述，为避免重复，这里不再一一描述。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。

以上所述实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围，均应包含在本发明的保护范围内。

Claims (10)

1.一种APP发布控制方法，其特征在于，包括：

为APP待发布新版本配置处理事项检查单插件，生成包括多个处理节点的处理事项检查单；

监控各个处理节点的状态信息；

针对进行中状态的处理节点，响应于事项处理操作，变更处理节点的状态为已完成状态，其中，所述事项处理操作，是根据进行中状态的处理节点的操作方式信息，进行事项确认、转发、脚本调用中的至少一项操作；

当所有处理节点状态均为已完成状态时，确定完成所述处理事项检查单，以指示进行APP新版本的发布。

2.根据权利要求1所述的方法，其特征在于，还包括：

根据各个处理节点的处理事项之间的依赖关系，确定各个处理节点之间的扭转方式，所述扭转方式包括串行扭转方式和/或并行扭转方式；

对于串行扭转方式的多个处理节点，进行串行的事项处理操作；对于并行扭转方式的多个处理节点，进行并行的事项处理操作。

3.根据权利要求2所述的方法，其特征在于，所述根据各个处理节点的处理事项之间的依赖关系，确定各个处理节点之间的扭转方式，包括：

当第二处理节点处理事项不依赖于第一处理节点处理事项的处理结果时，确定第一处理节点和第二处理节点之间的扭转方式为串行扭转方式；

当第二处理节点处理事项依赖于第一处理节点处理事项的处理结果时，确定第一处理节点和第二处理节点之间的扭转方式为并行扭转方式。

4.根据权利要求1所述的方法，其特征在于，还包括：

配置所述处理节点进一步包括多个子节点，当所述处理节点所包含的多个子节点的状态均为已完成状态时，确定所述处理节点的状态为已完成状态。

5.根据权利要求4所述的方法，其特征在于，还包括：

根据各个子节点的处理事项之间的依赖关系，确定各个子节点之间的扭转方式，所述扭转方式包括串行扭转方式和/或并行扭转方式；

对于串行扭转方式的多个子节点，进行串行的事项处理操作；对于并行扭转方式的多个子节点，进行并行的事项处理操作。

6.根据权利要求5所述的方法，其特征在于，所述根据各个子节点的处理事项之间的依赖关系，确定各个子节点之间的扭转方式，包括：

当第二子节点处理事项不依赖于第一子节点处理事项的处理结果时，确定第一子节点和第二子节点之间的扭转方式为串行扭转方式；

当第二子节点处理事项依赖于第一子节点处理事项的处理结果时，确定第一子节点和第二子节点之间的扭转方式为并行扭转方式。

7.根据权利要求1-6任一项所述的方法，其特征在于，

还包括：配置处理节点属性信息，所述属性信息包括完成时间信息、操作人员信息、状态信息、操作方式信息中的至少一项；

在所述变更处理节点的状态为已完成状态之后，还包括：根据所述处理事项检查单，确定已完成处理节点的下一处理节点；将所述下一处理节点的状态信息从待完成状态更新为进行中状态。

8.一种APP发布控制装置，其特征在于，包括：

检查单生成单元，用于为APP待发布新版本配置处理事项检查单插件，生成包括多个处理节点的处理事项检查单；

节点监控单元，用于监控各个处理节点的状态信息；

节点操作单元，用于针对进行中状态的处理节点，响应于事项处理操作，变更处理节点的状态为已完成状态，其中，所述事项处理操作，是根据进行中状态的处理节点的操作方式信息，进行事项确认、转发、脚本调用中的至少一项操作；

发布指示单元，用于当所有处理节点状态均为已完成状态时，确定完成所述处理事项检查单，以指示进行APP新版本的发布。

9.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述方法的步骤。

10.一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至7任一项所述方法的步骤。