CN112817623A - 应用程序的发版方法、装置、移动终端及可读存储介质 - Google Patents

Abstract

本发明涉及应用程序发布技术领域，公开了一种应用程序的发版方法、装置、移动终端及可读存储介质。其中，该方法包括：获取目标应用程序的应用标识号；基于应用标识号确定目标应程序对应的至少一个待更新组件；基于至少一个待更新组件，触发目标应用程序的发版操作，得到触发结果；基于触发结果，发版目标应用程序。通过实施本发明，实现了目标应用程序的自动发版，避免了人为操作的不必要错误以及人为沟通不到位的问题，从而降低了目标应用程序的发版周期。

Description

应用程序的发版方法、装置、移动终端及可读存储介质

技术领域

本发明涉及应用程序发布技术领域，具体涉及一种应用程序的发版方法、装置、移动终端及可读存储介质。

背景技术

随着移动终端的应用程序越来越大，为了便于维护，一个大型应用程序会被拆分成多个子项目(组件)和一个主项目(app或者壳工程)，而主项目的功能实现主要依赖于多个子项目。

移动终端的应用程序的发版流程通常为分支拉取、组件构建、功能开发、需求提测、测试、合并开发分支、代码封板、测试回归、打发布包、发布应用市场，而每个阶段都需要依靠人为操作及沟通，极容易出现漏操作或沟通不到位的问题，从而导致应用程序的发版延期。

发明内容

有鉴于此，本发明实施例提供了一种应用程序的发版方法、装置、移动终端及可读存储介质，以解决人为漏操作或沟通不到位而导致发版延期的问题。

根据第一方面，本发明实施例提供了一种应用程序的发版方法，包括如下步骤：获取目标应用程序的应用标识号；基于所述应用标识号确定所述目标应程序对应的至少一个待更新组件；基于所述至少一个待更新组件，触发目标应用程序的发版操作，得到触发结果；基于所述触发结果，发版所述目标应用程序。

本发明实施例的应用程序的发版方法，通过获取目标应用程序的应用标识号，基于应用标识号可以确定目标应用程序对应的至少一个待更新组件，从而触发与至少一个待更新组件对应的发版操作，基于发版操作的触发结果进行目标应用程序的发版，从而实现了目标应用程序的自动发版，避免了人为操作的不必要错误以及人为沟通不到位的问题，从而降低了目标应用程序的发版周期。

结合第一方面，在第一方面的第一实施方式中，所述基于所述至少一个待更新组件，触发目标应用程序的发版操作，得到触发结果，包括：触发查询操作，确定所述至少一个待更新组件的需求信息；基于所述需求信息，触发所述至少一个待更新组件的特性分支创建操作，得到至少一个特性分支的创建结果；基于所述创建结果，触发所述至少一个待更新组件的组件构建操作，得到所述至少一个待更新组件的构建结果；基于所述构建结果，触发所述至少一个待更新组件的测试操作，得到所述至少一个待更新组件的测试结果。

本发明实施例的应用程序的发版方法，通过触发查询操作确定至少一个待更新组件的需求信息，基于需求信息触发至少一个待更新组件的特性分支创建操作，得到至少一个特性分支的创建结果，并基于创建结果触发至少一个待更新组件的组件构建操作，得到至少一个待更新组件的构建结果，基于构建结果触发至少一个待更新组件的测试操作，得到至少一个待更新组件的测试结果，从而实现了发版操作过程的自动触发，避免了沟通不到位而导致的失误，减少了目标应用程序的发版过程中的错误率，节省了发版时间。

结合第一方面第一实施方式，在第一方面的第二实施方式中，所述基于所述创建结果，触发所述至少一个待更新组件的组件构建操作，得到所述至少一个待更新组件的构建结果，包括：基于所述创建结果，生成中间件组件构建请求；基于所述中间件组件构建请求，触发安卓组件构建操作，确定构建结果。

结合第一方面第一实施方式，在第一方面的第三实施方式中，所述基于所述创建结果，触发所述至少一个待更新组件的组件构建操作，得到所述至少一个待更新组件的构建结果，包括：基于所述创建结果，生成组件构建请求；基于所述组件构建请求，触发IOS组件构建操作，确定构建结果。

本发明实施例的应用程序的发版方法，通过生成中间件组件构建请求，触发安卓组件的自动构建，或通过生成组件构建请求，触发IOS组件的自动构建，从而实现了组件构建的自动化，降低了发版系统组件构建的难度。

结合第一方面第一实施方式，在第一方面的第四实施方式中，所述基于所述构建结果，触发所述至少一个待更新组件的测试操作，得到所述至少一个待更新组件的测试结果，包括：对所述至少一个特性分支对应的待更新组件进行需求测试；当所述需求测试成功时，触发所述至少一个待更新组件的第一合并操作，将所述至少一个待更新组件合并至开发分支；对所述开发分支上的所述至少一个待更新组件进行集成测试；当所述集成测试成功时，触发发布分支的拉取操作，将所述至少一个待更新组件的发布至所述发布分支；对所述发布分支上的所述至少一个待更新组件进行回归测试；当所述回归测试成功时，触发所述至少一个待更新组件的第二合并操作，将所述至少一个待更新组件合并至主分支。

本发明实施例的应用程序的发版方法，通过自动触发各个组件分支上的待更新组件的测试，实现了组件分支的零沟通测试，避免了因组件过多而沟通不到位出现代码漏测试的问题，从而保证了组件测试的完整性。

结合第一方面第四实施方式，在第一方面的第五实施方式中，所述触发所述至少一个待更新组件的测试操作，包括：分配操作权限；基于所述操作权限，触发所述至少一个待更新组件的测试操作。

本发明实施例的应用程序的发版方法，通过分配操作权限，为不同角色分配不同额的操作权限，给予不同角色不同的操作界面，避免了使用者的误操作，从而降低了目标应用程序发版操作过程中的出错率。

结合第一方面第一实施方式，在第一方面的第六实施方式中，基于所述需求信息，触发所述至少一个待更新组件的特性分支创建操作，得到至少一个特性分支的创建结果，包括：触发所述至少一个待更新组件的需求信息的填充操作；基于所述填充操作，生成所述特性分支的创建表单；基于所述创建表单，触发所述特性分支创建操作，得到所述创建结果。

本发明实施例的应用程序的发版方法，通过触发待更新组件的需求信息的的填充操作，生成对应于待更新组件的特性分支的创建表单，并基于创建表单触发特性分支的创建操作，得到特性分支的创建结果，实现了对多组件的特性分支的自动构建，从而实现了对多组件的特性分支的统一管理。

根据第二方面，本发明实施例提供了一种应用程序的发版装置，包括：获取模块，用于获取目标应用程序的应用标识号；确定模块，用于基于所述应用标识号确定所述目标应程序对应的至少一个待更新组件；触发模块，用于基于所述至少一个待更新组件，触发目标应用程序的发版操作，得到触发结果；发版模块，用于基于所述触发结果，发版所述目标应用程序。

本发明实施例的应用程序的发版装置，通过获取目标应用程序的应用标识号，基于应用标识号可以确定目标应用程序对应的至少一个待更新组件，从而触发与至少一个待更新组件对应的发版操作，基于发版操作的触发结果进行目标应用程序的发版，从而实现了目标应用程序的自动发版，避免了人为操作的不必要错误以及人为沟通不到位的问题，从而降低了目标应用程序的发版周期。

根据第三方面，本发明实施例提供了一种电子设备，包括：存储器和处理器，所述存储器和所述处理器之间互相通信连接，所述存储器中存储有计算机指令，所述处理器通过执行所述计算机指令，从而执行第一方面或第一方面任一实施方式所述的应用程序的发版方法。

根据第四方面，本发明实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机指令，所述计算机指令用于使计算机执行第一方面或第一方面任一实施方式所述的应用程序的发版方法。

附图说明

为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是根据本发明实施例的应用程序的发版方法的流程图；

图2是根据本发明实施例的应用程序的发版方法的另一流程图；

图3是根据本发明实施例的应用程序的发版方法的另一流程图；

图4是根据本发明实施例的应用程序的发版装置的结构框图；

图5是本发明实施例提供的电子设备的硬件结构示意图。

具体实施方式

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

移动终端的应用程序的发版流程通常为分支拉取、组件构建、功能开发、需求提测、测试、合并开发分支、代码封板、测试回归、打发布包、发布应用市场，而每个阶段都需要依靠人为操作及沟通，极容易出现漏操作或沟通不到位的问题，从而导致应用程序的发版延期。

基于此，本发明技术方案通过自动化管理应用程序的发版流程，减少了应用程序发版流程中的人为操作，避免了人为操作失误而导致的发版延期。

根据本发明实施例，提供了一种应用程序的发版方法的实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

在本实施例中提供了一种应用程序的发版方法，可用于电子设备中的多项目发版管理系统，如手机、平板电脑、电脑等电子设备中的多项目发版管理系统，且电子设备的多项目发版管理系统依赖于jenkins、方舟管理系统、Gitlab、项目管理系统jira。其中，方舟管理系统中录入有待接入发版管理系统的组件或项目，发版管理系统可以通过网络请求从方舟管理系统中获取应用程序的相关信息，同时提供IOS端的组件构建及应用构建，发版系统通过网络请求调用方舟管理系统，并自动触发IOS端组件构建及应用构建，待组件构建及应用构建完成后，通过网络请求的方式将构建结果反馈至发版管理系统；Jenkins提供android端组件构建及应用构建，发版管理系统通过网络请求触发jenkins端的组件构建及应用构建，待组件构建及应用构建完成后，通过网络请求的方式将构建结果反馈至发版管理系统；Gitlab为代码仓库，其内存储有应用程序相关的组件代码，发版管理系统通过网络请求的方式与Gitlab进行交互，触发组件的分支创建、分支对比、分支合并等操作；项目管理系统jira用于提供组件的需求信息记录及需求信息的进度管控，发版管理系统在组件的分支创建阶段能够从项目管理系统jira获取需求信息。

图1是根据本发明实施例的应用程序的发版方法的流程图，如图1所示，该流程包括如下步骤：

S11，获取目标应用程序的应用标识号。

目标应用程序为待更新的应用程序，且应用标识号与应用程序一一对应，即每个应用程序均具有与其对应的应用标识号(应用ID)。发版管理系统的负责人员会将需要接入发版管理系统的应用程序录入至方舟管理系统，并在方舟管理系统中建立应用ID与其壳工程和组件的依赖关系。发版管理系统通过查询方舟管理系统获取应用程序列表，从应用程序列表中即可确定目标应用程序对应的应用ID。

S12，基于应用标识号确定目标应程序对应的至少一个待更新组件。

待更新组件为目标应用程序需要更新的功能模块所对应的组件。电子设备的发版管理系统通过目标应用程序的应用ID以及应用ID与其壳工程和组件的依赖关系，可以确定目标应用程序对应的壳工程和组件，进而确定与目标应用程序对应的至少一个待更新组件。

S13，基于至少一个待更新组件，触发目标应用程序的发版操作，得到触发结果。

基于待更新组件依次触发Ggitlab进行待更新组件的分支创建，触发Jenkins以及安卓管理系统进行待更新组件的组件构建，再触发待更新组件的组件测试。电子设备则可以根据发版操作的触发依次获取分支创建的触发结果、组件构建的触发结果以及组件测试的触发结果。

S14，基于触发结果，发版目标应用程序。

电子设备获取到分支创建成功的触发结果后，触发组件构建，在接收到组件构建成功的触发结果后，触发组件测试，并接收组件测试的触发结果。待接收到组件测试成功的触发结果后，将通过组件测试的待更新组件合并至最稳定的主分支上，将待更新组件打包至目标应用程序，并对已打包待更新组件的目标应用程序进行发版。

本发明实施例的应用程序的发版方法，通过获取目标应用程序的应用标识号，基于应用标识号可以确定目标应用程序对应的至少一个待更新组件，从而触发与至少一个待更新组件对应的发版操作，基于发版操作的触发结果进行目标应用程序的发版，从而实现了目标应用程序的自动发版，避免了人为操作的不必要错误以及人为沟通不到位的问题，从而降低了目标应用程序的发版周期。

在本实施例中提供了一种应用程序的发版方法，可用于电子设备，如手机、平板电脑、电脑等，图2是根据本发明实施例的应用程序的发版方法的流程图，如图2所示，该流程包括如下步骤：

S21，获取目标应用程序的应用标识号。详细说明参见上述实施例对应步骤S11的相关描述，此处不再赘述。

S22，基于应用标识号确定目标应程序对应的至少一个待更新组件。详细说明参见上述实施例对应步骤S12的相关描述，此处不再赘述。

S23，基于至少一个待更新组件，触发目标应用程序的发版操作，得到触发结果。

具体地，上述步骤S23可以包括如下步骤：

S231，触发查询操作，确定至少一个待更新组件的需求信息。

发版管理系统可以触发查询操作，从方舟管理系统获取应用ID以及应用ID对应的壳工程和至少一个待更新组件。当确定待更新组件后，发版管理系统可以在项目管理系统jira中获取对应于待更新组件的需求信息。

S232，基于需求信息，触发至少一个待更新组件的特性分支创建操作，得到至少一个特性分支的创建结果。

发版管理系统可以通过待更新组件的需求信息，通过网络请求的方式调用Gitlab的组件代码，触发组件代码创建对应于至少一个待更新组件的特性分支，Gitlab通过网络请求的方式将至少一个待更新组件的特性分支的创建结果反馈至电子设备的发版管理系统，如图3所示。

具体地，上述步骤S232可以包括如下步骤：

(1)触发至少一个待更新组件的需求信息的填充操作。

电子设备确定目标应用程序对应的至少一个待更新组件后，可以确定与至少一个待更新组件的需求信息对应的jira链接。研发人员可以将jira链接填入特性分支创建表单中，发版管理系统则可以根据该jira链接从项目管理系统中获取对应于至少一个待更新组件的需求信息，并基于该需求信息触发需求信息的自动填充操作。

(2)基于填充操作，生成特性分支的创建表单。

发版管理系统能够将至少一个待更新组件对应的需求信息自动填充至特性分支创建表单中，生成对应于至少一个待更新组件的特性分支的创建表单。

(3)基于创建表单，触发特性分支创建操作，得到创建结果。

发版管理系统可以根据特性分支的创建表单，通过网络请求的方式调用代码仓库Gitlab中的相关组件代码，触发Gitlab进行特性分支的创建。Gitlab完成特性分支创建后可以通过网络请求的方式将创建结果反馈至发版管理系统。

本实施例的应用程序的发版方法，通过触发待更新组件的需求信息的的填充操作，生成对应于待更新组件的特性分支的创建表单，并基于创建表单触发特性分支的创建操作，得到特性分支的创建结果，实现了对多组件的特性分支的自动构建，从而实现了对多组件的特性分支的统一管理。

S233，基于创建结果，触发至少一个待更新组件的组件构建操作，得到至少一个待更新组件的构建结果。

发版管理系统在接收到特性分支创建成功的创建结果后，研发人员可以在特性分支上根据需求信息进行组件的更新开发。电子设备可以响应于对组件的更新操作。在组件开发完成后，发版管理系统可以触发待更新组件的构建操作，以使Jenkins和方舟管理系统进行组件构建和应用构建。Jenkins和方舟管理系统可以通过网络请求将组件构建结果和应用构建结果反馈至发版管理系统。

具体地，对于安卓系统，上述步骤S233可以包括：

(1)基于创建结果，生成中间件组件构建请求。

对于安卓系统，Jenkins提供了用于安卓端组件构建及应用构建的中间件。该中间件负责接收发版管理系统发送的组件构建请求。发版管理系统在接收到创建结果以及组件开发完成结果时，发版管理系统可以生成中间件组件构建请求，并向中间件发送该中间件组件构建请求。

(2)基于中间件组件构建请求，触发安卓组件构建操作，确定构建结果。

发版管理系统可以基于生成的中间件组件构建请求触发Jenkins进行安卓端组件构建以及应用构建，以使中间件能够根据中间件组件构建请求的内容自动进行安卓端的组件构建以及应用构建。当中间件完成安卓端的组件构建以及应用构建时，可以将安卓端的组件构建以及应用构建的构建结果通过网络请求方式反馈至发版管理系统，如图3所示。

具体地，对于IOS系统，上述步骤S233可以包括：

(1)基于创建结果，生成组件构建请求。

对于IOS系统，方舟管理系统提供了IOS端的组件构建及应用构建。发版管理系统在接收到创建结果以及组件开发完成结果时，发版管理系统可以生成组件构建请求，并向方舟管理系统发送该组件构建请求。

(2)基于组件构建请求，触发IOS组件构建操作，确定构建结果。

发版管理系统可以基于生成的组件构建请求触发方舟管理系统进行IOS端的组件构建以及应用构建，以使方舟管理系统能够根据组件构建请求的内容自动进行IOS端的组件构建以及应用构建。当方舟管理系统完成IOS端的组件构建及应用构建时，可以将IOS端的组件构建及应用构建的构建结果通过网络请求方式反馈至发版管理系统，如图3所示。

本实施例的应用程序的发版方法，通过生成中间件组件构建请求，触发安卓组件的自动构建，或通过生成组件构建请求，触发IOS组件的自动构建，从而实现了组件构建的自动化，降低了发版系统组件构建的难度。

S234，基于构建结果，触发至少一个待更新组件的测试操作，得到至少一个待更新组件的测试结果。

发版管理系统在接收到组件构建以及应用构建的构建结果后，表示发版管理系统可以对组件进行的测试操作，此时发版管理系统触发至少一个待更新组件的测试操作，并获取至少一个待更新组件的测试结果。

具体地，研发人员开发完成组件后，可以在发版管理系统上填写一些必要信息(抄送人、提测内容、影响范围、提测类型)，然后点击提测按钮，发版管理系统则可以响应研发人员的提测请求，自动触发组件构建及应用构建，并生成组件测试的测试包，在组件构建以及应用构建完成后，发版管理系统可以按照研发人员填写的内容生成提测邮件，并将该提测邮件自动发送给测试人员。

测试人员在收到提测邮件后，直接下载测试包进行组件测试，如果测试包没有办法进行组件测试，测试人员则可以在发版管理系统上点击测试打回按钮，并填写打回原因。发版管理系统则可以根据测试人员填写的测试内容自动发送打回邮件。如果测试包没有问题，测试人员直接进行组件测试，待组件测试完成后，在发版管理系统上填写测试用例以及测试各端的情况，发版管理系统则可以自动根据测试内容生成测试邮件，并发送给研发人员，以使研发人员及时了解组件的开发情况。

具体地，上述步骤S234可以包括如下步骤：

(1)对至少一个特性分支对应的待更新组件进行需求测试。

特性(features)分支为研发人员根据需求信息在需求开发过程中使用的分支。一个版本的应用程序通常会包含多种需求信息，每个需求信息涉及的研发人员以及组件都不同，而且在组件的更新开发阶段，特性分支不太稳定，发版管理系统通过触发Gitlab创建特性分支以使研发人员在该特性分支上进行研发。发版管理系统触发对至少一个特性分支对应的待更新组件进行需求测试，以确定待更新组件是否满足组件更新需求。

(2)当需求测试成功时，触发至少一个待更新组件的第一合并操作，将至少一个待更新组件合并至开发分支。

当发版管理系统确定待更新组件满足组件更新需求时，即待更新组件的需求测试成功时，此时发版管理系统可以触发至少一个待更新组件的第一合并操作，将至少一个待更新组件合并至开发(develop)分支。

(3)对开发分支上的至少一个待更新组件进行集成测试。

develop分支上包含目标应用程序的最新组件的全部功能，用develop分支对待更新组件的功能进行集成测试，以确定待更新组件是否满足组件集成需求，避免各个待更新组件在集成的过程中出现组件功能冲突而影响目标应用程序的正常运行。

(4)当集成测试成功时，触发发布分支的拉取操作，将至少一个待更新组件的发布至发布分支。

当发版管理系统确定待更新组件满足组件集成需求时，即待更新组件的集成测试成功时，此时发版管理系统可以发布(release)分支的拉取操作，拉出一个release分支，并将至少一个待更新组件的发布至release分支。releases分支为封板分支，在目标应用程序发版之前，为了保证组件分支的稳定性，会拉出一个release分支，并对该分支进行权限保护，避免代码误合并。release分支所对应的组件信息与develop分支对应的组件信息相同，用于保存目标应用程序的当前版本，便于进行问题定位。

(5)对发布分支上的至少一个待更新组件进行回归测试。

当发版管理系统将至少一个待更新组件的发布至release分支后，在该release分支上对至少一个待更新组件做回归测试，以确定至少一个待更新组件满足回归需求，保证组件功能在目标应用程序中的正常运行。

(6)当回归测试成功时，触发至少一个待更新组件的第二合并操作，将至少一个待更新组件合并至主分支。

当发版管理系统确定至少一个待更新组件满足回归需求时，即待更新组件的回归测试成功时，表示待更新组件能够在目标应用程序中进行正常运行。此时发版管理系统可以触发将至少一个待更新组件合并至主(master)分支的第二合并操作，实现将至少一个待更新组件合并至master分支。master分支作为最稳定的分支，可以随时将至少一个待更新组件进行打包并发布市场。

本实施例的应用程序的发版方法，通过自动触发各个组件分支上的待更新组件的测试，实现了组件分支的零沟通测试，避免了因组件过多而沟通不到位出现代码漏测试的问题，从而保证了组件测试的完整性。

作为一个可选的实施方式，为了能够快速定位哪个阶段，哪个环节出现问题，可以对发版管理系统的各个阶段的状态进行详细划分，通过状态可快速的定位出错点在哪里，具体状态划分情况如下：

发版管理系统主要管理features分支和release分支两种类型的组件分支。

其中，对于features分支的状态划分为：

创建中：即features分支正在创建，features分支创建会涉及发版管理系统和Gitlab系统，并依赖网络请求，会出现不同的创建结果，分为创建中，创建失败和创建成功；

构建中：发版管理系统用于显示自动触发组件构建或应用构建的状态，分为构建中、成功和失败；

开发中：表示组件开发所需要的配置环境已经准备好，研发人员正在进行需求开发；

提测中：提测会触发组件构建、应用构建、邮件发送，因此需要三个状态来表示，分为提测中、提测成功和提测失败；

测试中：提测后即可针对features分支进行需求测试，而需求测试过程会分为测试中和测试完成两个阶段；

代码合并develop分支中：需求测试完成即可进行develop分支的代码合并进行集成测试，合并过程分为：合并中、合并失败、合并成功；

develop分支构建中：合并develop分支后，发版管理系统能够自动触发组件构建及应用构建，而组件构建及应用构建分为构建中、构建成功、构建失败；

已合并：表示特性分支功能集成完成。

对于releases分支的状态划分为：

分支创建中：即releases分支正在创建，releases分支会创建会涉及发版管理系统和Gitlab系统两个系统，并依赖网络请求，会出现不同的创建结果，分为创建中、创建失败和创建成功；

构建中：发版管理系统用于显示自动触发组件构建或应用构建的状态，分为构建中、成功和失败；

回归中：针对releases分支的回归测试，分为回归中和回归完成；

代码合并master分支中：回归测试完成后即可进行master分支的代码合并，合并过程分为：合并中、合并失败、合并成功；

master分支构建中：合并master分支后，发版管理系统能够自动触发应用构建，而应用构建有分为构建中、构建成功、构建失败；

已发版：表示应用已经打包完成，可以发版至应用市场。

可选地，上述应用程序的发版方法还可以包括：分配操作权限，基于操作权限，触发至少一个待更新组件的测试操作。

为了防止不同研发人员的误操作而导致目标应用程序发版流程出错，发版管理系统可以为不同的研发人员分配操作权限，给予不同的研发人员以不同的操作界面。

具体地，根据发版管理系统所能提供的操作以及研发人员的角色，可以对操作权限进行双维度的划分，并可根据发版管理系统的变化，动态调整操作权限的内容。首先根据发版管理系统可提供的操作，划分为查询全分支、查询关联分支、删除、提测、测试通过、回归完成、构建、特性分支合并、release分支合并，具体操作介绍如下：

查询全分支：表示可以查询全部的特性分支；

查询关联分支：表示可以查询与当前研发人员相关联的分支，关联指该用户是该分支的测试或研发；

删除：指从发版管理系统中删除分支；

提测：指研发人员在完成组件开发后，告知测试人员可以进行测试操作；

测试通过：测试完成后，通过操作界面通知研发人员已完成测试操作；

回归完成：release分支回归测试完成后，测试人员退出操作系统，更新回归状态的操作；

构建：发版管理系统提供组件构建及应用构建的操作；

特性分支合并：需求测试完成后，将代码合并到develop分支的操作；

release分支合并：回归测试完成后，将代码合并master分支的操作。

为了便于给不同的研发人员添加操作权限，发版管理系统可以增加研发人员的维度，为特定的研发人员提前分配好操作权限，当研发人员登录发版管理系统时，直接为研发人员指定好操作权限，研发人员即可获得其所具有的操作权限。

需要说明的是，当回归测试过程出现问题时，研发人员可以在特性分支进行问题修复。当问题修复完成时，通知需求测试人员进行功能验证，通过需求测试后，需求测试人员可以提交代码合并工单，申请将特性分支上的组件代码合并至release分支的操作权限。工单审批通过后，目标应用程序的发版负责人可以将该特性分支的研发人员添加至白名单，此时发版管理系统自动为处于白名单的研发人员添加代码合并权限。研发人员再此登录发版管理系统，点击合并按钮，发版管理系统则可以自动将特性分支上的组件代码合并到release分支。若合并成功，发版管理系统将特性分支上的组件代码同步合并到develop分支，以使develop分支和release分支保持组件功能一致；若合并失败，则需要研发人员在特性分支上继续进行问题修复。

本实施例的应用程序的发版方法，通过分配操作权限，为不同角色分配不同额的操作权限，给予不同角色不同的操作界面，避免了使用者的误操作，从而降低了目标应用程序发版操作过程中的出错率。

S24，基于触发结果，发版目标应用程序。详细说明参见上述实施例对应步骤S14的相关描述，此处不再赘述。

本实施例的应用程序的发版方法，通过触发查询操作确定至少一个待更新组件的需求信息，基于需求信息触发至少一个待更新组件的特性分支创建操作，得到至少一个特性分支的创建结果，并基于创建结果触发至少一个待更新组件的组件构建操作，得到至少一个待更新组件的构建结果，基于构建结果触发至少一个待更新组件的测试操作，得到至少一个待更新组件的测试结果，从而实现了发版操作过程的自动触发，避免了沟通不到位而导致的失误，减少了目标应用程序的发版过程中的错误率，节省了发版时间。

在本实施例中还提供了一种应用程序的发版装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

本实施例提供一种应用程序的发版装置，如图4所示，包括：

获取模块31，用于获取目标应用程序的应用标识号。详细说明参见上述实施例对应的相关描述，此处不再赘述。

确定模块32，用于基于应用标识号确定目标应程序对应的至少一个待更新组件。详细说明参见上述实施例对应的相关描述，此处不再赘述。

触发模块33，用于基于至少一个待更新组件，触发目标应用程序的发版操作，得到触发结果。详细说明参见上述实施例对应的相关描述，此处不再赘述。

发版模块34，用于基于触发结果，发版目标应用程序。详细说明参见上述实施例对应的相关描述，此处不再赘述。

本实施例的应用程序的发版装置，通过获取目标应用程序的应用标识号，基于应用标识号可以确定目标应用程序对应的至少一个待更新组件，从而触发与至少一个待更新组件对应的发版操作，基于发版操作的触发结果进行目标应用程序的发版，从而实现了目标应用程序的自动发版，避免了人为操作的不必要错误以及人为沟通不到位的问题，从而降低了目标应用程序的发版周期。

本实施例中的应用程序的发版装置是以功能单元的形式来呈现，这里的单元是指ASIC电路，执行一个或多个软件或固定程序的处理器和存储器，和/或其他可以提供上述功能的器件。

上述各个模块的更进一步的功能描述与上述对应实施例相同，在此不再赘述。

本发明实施例还提供一种电子设备，具有上述图4所示的应用程序的发版装置。

请参阅图5，图5是本发明可选实施例提供的一种电子设备的结构示意图，如图5所示，该电子设备可以包括：至少一个处理器501，例如CPU(Central Processing Unit，中央处理器)，至少一个通信接口503，存储器504，至少一个通信总线502。其中，通信总线502用于实现这些组件之间的连接通信。其中，通信接口503可以包括显示屏(Display)、键盘(Keyboard)，可选通信接口503还可以包括标准的有线接口、无线接口。存储器504可以是高速RAM存储器(Random Access Memory，易挥发性随机存取存储器)，也可以是非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。存储器504可选的还可以是至少一个位于远离前述处理器501的存储装置。其中处理器501可以结合图4所描述的装置，存储器504中存储应用程序，且处理器501调用存储器504中存储的程序代码，以用于执行上述任一方法步骤。

其中，通信总线502可以是外设部件互连标准(peripheral componentinterconnect，简称PCI)总线或扩展工业标准结构(extended industry standardarchitecture，简称EISA)总线等。通信总线502可以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

其中，存储器504可以包括易失性存储器(英文：volatile memory)，例如随机存取存储器(英文：random-access memory，缩写：RAM)；存储器也可以包括非易失性存储器(英文：non-volatile memory)，例如快闪存储器(英文：flash memory)，硬盘(英文：hard diskdrive，缩写：HDD)或固态硬盘(英文：solid-state drive，缩写：SSD)；存储器504还可以包括上述种类的存储器的组合。

其中，处理器501可以是中央处理器(英文：central processing unit，缩写：CPU)，网络处理器(英文：network processor，缩写：NP)或者CPU和NP的组合。

其中，处理器501还可以进一步包括硬件芯片。上述硬件芯片可以是专用集成电路(英文：application-specific integrated circuit，缩写：ASIC)，可编程逻辑器件(英文：programmable logic device，缩写：PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(英文：complex programmable logic device，缩写：CPLD)，现场可编程逻辑门阵列(英文：field-programmable gate array，缩写：FPGA)，通用阵列逻辑(英文：generic arraylogic,缩写：GAL)或其任意组合。

可选地，存储器504还用于存储程序指令。处理器501可以调用程序指令，实现如本申请图1和2实施例中所示的应用程序的发版方法。

本发明实施例还提供了一种非暂态计算机存储介质，所述计算机存储介质存储有计算机可执行指令，该计算机可执行指令可执行上述任意方法实施例中的应用程序的发版方法的处理方法。其中，所述存储介质可为磁碟、光盘、只读存储记忆体(Read-OnlyMemory，ROM)、随机存储记忆体(Random Access Memory，RAM)、快闪存储器(FlashMemory)、硬盘(Hard Disk Drive，缩写：HDD)或固态硬盘(Solid-State Drive，SSD)等；所述存储介质还可以包括上述种类的存储器的组合。

虽然结合附图描述了本发明的实施例，但是本领域技术人员可以在不脱离本发明的精神和范围的情况下做出各种修改和变型，这样的修改和变型均落入由所附权利要求所限定的范围之内。

Claims (10)

1.一种应用程序的发版方法，其特征在于，包括如下步骤：

获取目标应用程序的应用标识号；

基于所述应用标识号确定所述目标应程序对应的至少一个待更新组件；

基于所述至少一个待更新组件，触发目标应用程序的发版操作，得到触发结果；

基于所述触发结果，发版所述目标应用程序。

2.根据权利要求1所述的方法，其特征在于，所述基于所述至少一个待更新组件，触发目标应用程序的发版操作，得到触发结果，包括：

触发查询操作，确定所述至少一个待更新组件的需求信息；

基于所述需求信息，触发所述至少一个待更新组件的特性分支创建操作，得到至少一个特性分支的创建结果；

基于所述创建结果，触发所述至少一个待更新组件的组件构建操作，得到所述至少一个待更新组件的构建结果；

基于所述构建结果，触发所述至少一个待更新组件的测试操作，得到所述至少一个待更新组件的测试结果。

3.根据权利要求2所述的方法，其特征在于，所述基于所述创建结果，触发所述至少一个待更新组件的组件构建操作，得到所述至少一个待更新组件的构建结果，包括：

基于所述创建结果，生成中间件组件构建请求；

基于所述中间件组件构建请求，触发安卓组件构建操作，确定构建结果。

4.根据权利要求2所述的方法，其特征在于，所述基于所述创建结果，触发所述至少一个待更新组件的组件构建操作，得到所述至少一个待更新组件的构建结果，包括：

基于所述创建结果，生成组件构建请求；

基于所述组件构建请求，触发IOS组件构建操作，确定构建结果。

5.根据权利要求2所述的方法，其特征在于，所述基于所述构建结果，触发所述至少一个待更新组件的测试操作，得到所述至少一个待更新组件的测试结果，包括：

对所述至少一个特性分支对应的待更新组件进行需求测试；

当所述需求测试成功时，触发所述至少一个待更新组件的第一合并操作，将所述至少一个待更新组件合并至开发分支；

对所述开发分支上的所述至少一个待更新组件进行集成测试；

当所述集成测试成功时，触发发布分支的拉取操作，将所述至少一个待更新组件的发布至所述发布分支；

对所述发布分支上的所述至少一个待更新组件进行回归测试；

当所述回归测试成功时，触发所述至少一个待更新组件的第二合并操作，将所述至少一个待更新组件合并至主分支。

6.根据权利要求5所述的方法，其特征在于，所述触发所述至少一个待更新组件的测试操作，包括：

分配操作权限；

基于所述操作权限，触发所述至少一个待更新组件的测试操作。

7.根据权利要求2所述的方法，其特征在于，基于所述需求信息，触发所述至少一个待更新组件的特性分支创建操作，得到至少一个特性分支的创建结果，包括：

触发所述至少一个待更新组件的需求信息的填充操作；

基于所述填充操作，生成所述特性分支的创建表单；

基于所述创建表单，触发所述特性分支创建操作，得到所述创建结果。

8.一种应用程序的发版装置，其特征在于，包括：

获取模块，用于获取目标应用程序的应用标识号；

确定模块，用于基于所述应用标识号确定所述目标应程序对应的至少一个待更新组件；

触发模块，用于基于所述至少一个待更新组件，触发目标应用程序的发版操作，得到触发结果；

发版模块，用于基于所述触发结果，发版所述目标应用程序。

9.一种电子设备，其特征在于，包括：

存储器和处理器，所述存储器和所述处理器之间互相通信连接，所述存储器中存储有计算机指令，所述处理器通过执行所述计算机指令，从而执行权利要求1-7任一项所述的应用程序的发版方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机指令，所述计算机指令用于使计算机执行权利要求1-7任一项所述的应用程序的发版方法。

Images