CN114661313A - 软件包发布、程序包生成方法、装置、设备及存储介质 - Google Patents

Abstract

本申请提供一种软件包发布方法、程序包生成方法、装置、设备及存储介质，根据应用的待发布软件包的源代码获取通用程序包，由于通用程序包是预先对应用不同版本的实现代码间的相同程序代码，按照程序代码依赖关系打包生成的程序包，所以安装通用程序包的过程实质上就是依次直接安装通用程序包中各程序的过程，也即在获取到通用程序包后，无需对通用程序包中各程序之间的依赖关系进行分析，便可以直接安装该通用程序包，可以提升软件包的发布效率。

Description

软件包发布、程序包生成方法、装置、设备及存储介质

技术领域

本申请涉及计算机技术领域，具体而言，涉及一种软件包发布、程序包生成方法、装置、设备及存储介质。

背景技术

随着互联网技术的迅速发展，各种应用程序层出不穷。为适应用户的各种新需求，需对应用程序进行更新。当需要对某一应用程序进行更新时，开发人员需要针对新版本应用程序编写对应的源代码。为减少开发工作的工作量，源代码中通常会直接调用开源的程序包，在完成源代码编写之后，需要从服务器中下载这些程序包，然后对各程序包的依赖关系进行分析，根据依赖关系依次安装各程序包后，再生成对应的待发布的软件包，然后将该软件包进行发布。由于每次生成待发布的软件包的过程中都需要对源代码中需调用的各程序包的依赖关系进行分析，然后根据该依赖关系依次安装各程序包，因此软件发布效率较低。

发明内容

本申请实施例的目的在于提供一种软件包发布、程序包生成方法、装置、设备及存储介质，用以解决现有技术中，由于在每次生成待发布的软件包的过程中都需要对源代码中需调用的各程序的依赖关系进行分析，然后根据该依赖关系依次安装各程序，导致软件发布效率较低的问题。

本申请实施例提供一种软件包发布方法，所述方法包括：

根据应用的待发布软件包的源代码获取目标程序包；所述目标程序包中包括通用程序包；所述通用程序包为：预先对所述应用不同版本的实现代码间的相同程序代码，按照程序代码依赖关系打包生成的程序包；

安装所述目标程序包，得到目标编译环境；

在所述目标编译环境中对所述源代码进行编译打包，得到所述待发布软件包；

将所述待发布软件包发布至目标环境中。

在上述实现过程中，根据应用的待发布软件包的源代码获取通用程序包，由于通用程序包是预先对应用不同版本的实现代码间的相同程序代码，按照程序代码依赖关系打包生成的程序包，所以安装通用程序包时可以自动依次安装通用程序包中各程序，也即在获取到通用程序包后，无需对通用程序包中各程序之间的依赖关系进行分析，便可以直接安装该通用程序包。也即，本申请实施例的方案可以直接安装通用程序包中的各程序，相比于现有方案中每次发布软件包的过程中都需要对源代码中需调用的各程序之间的依赖关系进行分析，然后再根据该依赖关系依次安装各程序而言，可以节省出分析依赖的时间，所以可以提升软件包的发布效率。

进一步地，所述源代码中包括通用程序包标识，所述根据待发布软件包的源代码获取目标程序包，包括：

根据所述通用程序包标识通过内网从第一服务器中下载与所述通用程序包标识对应的通用程序包。

在上述实现过程中，通过内网下载通用程序包，相比于通过外部网络进行下载而言，安全性更高，下载速度可控性更强，下载速度更快。

进一步地，所述通用程序包以镜像文件的形式存储在所述第一服务器中。

在上述实现过程中，通用程序包以镜像文件的形式存储在第一服务器中，镜像文件是一个单一的文件，便于开发人员下载和使用通用程序包。

进一步地，所述源代码中还包括非通用程序包标识，所述目标程序包还包括非通用程序包；所述根据待发布软件包的源代码获取目标程序包，包括：

根据所述非通用程序包标识从第二服务器中下载与所述非通用程序包标识对应的非通用程序包。

可理解，待发布软件包对应的源代码中除了需要调用通用程序包之外，可能还需要调用非通用程序包。在上述实现过程中，可以从第二服务器中下载源代码需调用的非通用程序包，从而获取到源代码中需调用的所有目标程序包。通过上述方案，使本方法可适用于新版本软件包的源代码需调用非通用程序包的场景，普适性更高。

进一步地，所述实现代码包括目标业务功能实现代码，所述目标业务功能实现代码为实现所述应用的目标业务功能的代码。

在上述实现过程中，由于通用程序包是预先针对应用不同版本的目标业务功能实现代码间的相同程序代码，按照程序代码依赖关系打包生成的通用程序包，所以通过上述实现过程，针对同一应用，可以从业务功能出发，为开发人员提供更多的可选择的对于不同业务功能的通用程序包，使开发人员可以根据待发布软件包所涉及的目标业务功能在源代码中调用对应的通用程序包。

进一步地，所述待发布软件包为所述应用的更新包。

在上述实现过程中，当需要对应用进行更新时，在根据源代码获取到通用程序包之后，可以直接安装该通用程序包，无需对通用程序包中的各程序之间的依赖关系进行分析。相比于现有方案中每次发布应用的更新包的过程中都需要对源代码中需调用的各程序之间的依赖关系进行分析，然后再根据该依赖关系依次安装各程序而言，可以节省出分析依赖的时间，提升软件更新时发布软件更新包的效率。

本申请实施例还提供一种程序包生成方法，包括：

获取同一应用不同版本的实现代码间的相同程序代码；

确定所述相同程序代码的程序代码依赖关系；

将所述相同程序代码按照所述程序代码依赖关系进行打包生成通用程序包。

上述过程提供了一种新的程序包生成方法，通过该方法，可以生成通用程序包。由于通用程序包是预先对同一应用不同版本的实现代码间的相同程序代码，按照程序代码依赖关系打包生成的通用程序包，所以后续在需要对该应用的版本进行更新时，就可以在新版本应用对应的源代码中直接调用该通用程序包。并且在获取到该通用程序包之后，无需对通用程序包中各程序代码之间的依赖关系进行分析，而是可以直接安装该通用程序包。相比于现有方案中由于没有预先生成通用程序包，所以每次发布软件包的过程中都需要对源代码中需调用的各程序包的依赖关系进行分析，然后再根据该依赖关系依次安装各程序包而言，可以节省出分析依赖的时间，所以可以提升软件包的发布效率。

进一步地，所述获取同一应用不同版本的实现代码间的相同程序代码，包括：

获取所述应用不同版本的目标业务功能实现代码间的相同程序代码；所述目标业务功能实现代码为实现所述应用的目标业务功能需要的代码。

在上述实现过程中，由于通用程序包是预先针对应用不同版本的目标业务功能实现代码间的相同程序代码，按照程序代码依赖关系打包生成的通用程序包。所以针对同一应用，可以为开发人员提供更多的可选择的通用程序包，使开发人员可以根据待发布软件包所涉及的目标业务功能在源代码中调用对应的通用程序包。

进一步地，在所述将所述相同程序代码按照所述依赖关系进行打包生成通用程序包之后，还包括：

将所述应用与所述通用程序包关联。

在上述实现过程中，将应用与通用程序包关联，当需要对该应用进行版本更新时，开发人员可以在源代码中直接调用与该应用关联的通用程序包，可以避免调用到其他不适用的程序包。

本申请实施例还提供了一种软件包发布装置，包括：

第一获取模块，用于根据应用的待发布软件包的源代码获取目标程序包；所述目标程序包中包括通用程序包；所述通用程序包为：预先对所述应用不同版本的实现代码间的相同程序代码，按照程序代码依赖关系打包生成的程序包；

安装模块，用于安装所述目标程序包，得到目标编译环境；

编译打包模块，用于在所述目标编译环境中对所述源代码进行编译打包，得到所述待发布软件包；

发布模块，用于将所述待发布软件包发布至目标环境中。

本申请实施例还提供了一种程序包生成装置，包括：

第二获取模块，用于获取同一应用不同版本的实现代码间的相同程序代码；

确定模块，用于确定所述相同程序代码的程序代码依赖关系；

打包模块，用于将所述相同程序代码按照所述程序代码依赖关系进行打包生成通用程序包。

本申请实施例还提供了一种电子设备，包括处理器和存储器，所述存储器中存储有计算机程序，所述处理器执行所述计算机程序，以实现上述任意一种方法。

本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被至少一个处理器执行时，以实现上述任意一种方法。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例一提供的软件包发布方法的流程示意图；

图2为本申请实施例二提供的程序包生成方法的流程示意图；

图3为本申请实施例三提供的软件包发布方法的流程示意图；

图4为本申请实施例四提供的软件包发布装置的结构示意图；

图5为本申请实施例五提供的程序包生成装置的结构示意图；

图6为本申请实施例六提供的电子设备的结构示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

需要说明的是，在本发明实施例中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本发明要求的保护范围之内。

在本发明的描述中，需要理解的是，步骤前的数字标号并不标识执行步骤的前后顺序，仅用于方便描述本发明及区别每一步骤，因此不能理解为对本发明的限制。

下面将提供多个实施例，来具体介绍软件包发布、程序包生成方法、装置、设备及存储介质，本申请所提供的软件包发布方法以及程序包生成方法可以应用于电子设备中，电子设备包括但不限于是PC(Personal Computer，个人电脑)、手机、平板电脑、笔记本电脑等。

实施例一：

为解决现有技术中，由于在每次生成待发布的软件包的过程中都需要对源代码中需调用的各程序的依赖关系进行分析，然后根据该依赖关系依次安装各程序，导致软件发布效率较低的问题，本申请实施例提供一种软件包发布方法，请参见图1所示，可以包括如下步骤：

S101：根据应用的待发布软件包的源代码获取目标程序包。

步骤S101中待发布软件包的源代码是指待发布软件包的开发代码，通常由开发人员编写，开发人员可以根据应用待发布软件包需要实现的功能编写对应的源代码。比如，开发人员在针对一款应用开发一款软件包(该软件包可以是该应用的更新包，也可以是该软件首次发布时对应的安装包)时，可以编写对应的程序代码，开发人员编写的程序代码也即是这里的源代码。

应当说明的是，可以通过在源代码中调用其他程序包的方式来减少开发工作的工作量。所以，步骤S101中的源代码中可以包含源代码需调用的目标程序包的程序包标识，根据该程序包标识便可获取到对应的目标程序包。

本实施例中的目标程序包包括通用程序包。本实施例中，通用程序包为：预先对该应用不同版本的实现代码间的相同程序代码，按照程序代码依赖关系打包生成的程序包。这里的程序代码依赖关系是指所述相同程序代码中各程序代码之间的依赖关系。

应用的实现代码是指实现应用的某一个功能、或者某几个功能、或者应用所有功能的代码。

为便于理解，这里对预先生成通用程序包的过程进行说明。

在第一种示例性的实施方式中，开发人员可以对该应用进行分析，直接编写该应用各版本都可以通用的程序代码，然后按照程序代码依赖关系对该程序代码打包得到通用程序包。

在第二种示例性的实施方式中，开发人员可以获取该应用的各历史版本的实现代码，提取出各历史版本的实现代码间的相同程序代码，然后对该相同程序代码按照程序代码依赖关系进行打包，生成通用程序包。由于需要获取该应用各历史版本的实现代码，所以这种方式适用于应用更新的场景。也即，当后续需要对该应用进行更新，对该应用的更新包进行发布时，可以根据源代码直接获取该通用程序包。

对于第二种示例性的实施方式，包括以下两种可选的实现方案：

第一种方案：应用的功能包括业务功能和基础功能，由于应用的基础功能通常不会变化，比如应用可打开、应用可关闭等；而应用的业务功能可能会发生变化，比如应用的“社交”功能，应用的“交易”功能等，所以实际应用中，通常并不会对应用的基础功能进行更新，往往只需要对业务功能进行更新，所以可以预先针对业务功能制作对应的通用程序包。

所以本方案中，可以从应用的目标业务功能的维度，针对预设的目标业务功能，获取该应用各历史版本中实现该目标业务功能的代码，得到各历史版本的目标业务功能实现代码。然后提取出各历史版本的目标业务功能实现代码间的相同程序代码，按照程序代码依赖关系进行打包，生成通用程序包。这样，针对该应用的每一目标业务功能，都可得到对应的通用程序包，也即，在本方案中，该应用可能对应多个通用程序包，通用程序包的数量由目标业务功能的数量决定。

应当说明的是，目标业务功能中可以包括一个业务功能，也可以包括多个业务功能。目标业务功能具体包括哪些业务功能，可以由开发人员根据实际应用情况灵活设置。开发人员可以选择将应用的多个业务功能作为一个目标业务功能，并设置对应的通用程序包，也可以选择将应用的一个业务功能作为一个目标业务功能。

比如，当该应用具有“社交”功能和“交易”功能时，开发人员可以选择将应用的“社交”功能和“交易”功能这两个业务功能作为一个目标业务功能。此时针对应用的“社交”功能和“交易”功能，可以得到一个通用程序包。后续在需要对应用的“社交”功能和“交易”功能同时进行更新时，便可以直接调用该通用程序包。

当然，开发人员也可以选择将应用的“社交”功能作为一个目标业务功能，“交易”功能作为另一个目标业务功能。此时针对应用的“社交”功能和“交易”功能，可以分别得到各自对应的通用程序包。后续在需要对应用的“社交”功能进行更新时，调用“社交”功能对应的通用程序即可，后续在需要对应用的“交易”功能进行更新时，调用“交易”功能对应的通用程序即可。

第二种方案：本方案中不进行业务功能的区分。也即，本方案中可以针对该应用的每一历史版本，获取该历史版本中实现该应用所有功能的代码，得到多个历史版本的实现代码。然后提取出各历史版本的实现代码间的相同程序代码，按照程序代码依赖关系进行打包，生成通用程序包。这样，针对该应用，可以得到一个通用程序包，后续在需要对该应用进行更新时，不管是何种更新，都可以直接调用该通用程序包。

下面对获取通用程序包的具体方式进行说明。

源代码中可以包括通用程序包标识，根据该通用程序包标识便可获取到与该通用程序包标识对应的通用程序包。

示例性的，本实施例中的通用程序包存储在第一服务器中，可以根据通用程序包标识通过内网从该第一服务器中下载对应的通用程序包，此时第一服务器是内部服务器。可以理解的是，这里的内网是指内部建立的局域网络，通过内网下载通用程序包，相比于通过外网进行下载而言，安全性更高，下载速度可控性更强，下载速度更快。

当然了，在其他的一些实施例中，通用程序包也可以存储在本地，此时直接根据源代码中的通用程序包标识在本地调用与该通用程序包标识对应的通用程序包即可。

在本实施例中，通用程序包可以以镜像文件的形式存储在第一服务器或本地中，镜像文件是一个单一的文件，便于下载和使用该通用程序包。

可以理解的是，该通用程序包也可以以其他的文件形式进行存储，比如以ZIP压缩文件的形式、或者以RAR压缩文件的形式进行存储。

应当说明的是，待发布软件包对应的源代码中除了需要调用通用程序包之外，可能还需要调用非通用程序包。此时，可以根据源代码中的非通用程序包标识获取对应的非通用程序包。具体的，可以根据该非通用程序包标识从第二服务器中下载与该非通用程序包标识对应的非通用程序包。

可以理解的是，这里的第二服务器可以与上面提及的第一服务器是同一个服务器，也即，可以是内部服务器。此时，可以根据该非通用程序包标识通过内网从内部服务器中下载对应的非通用程序包。这里的第二服务器也可以是外部服务器，比如可以是npm服务器。此时，可以根据该非通用程序包标识通过外网从该外部服务器中下载对应的非通用程序包。当然与上述通用程序包类似，非通用程序包也可以存储在本地，此时直接进行本地调用即可。

本实施例中非通用程序包是相对通用程序包这一概念而言的，源代码需调用的程序包中，除去通用程序包以外的其他所有程序包都是非通用程序包。

S102：安装目标程序包，得到目标编译环境。

步骤S102中的目标编译环境是指可以对源代码进行编译的环境。在获取得到目标程序包之后，需要将目标程序包安装在本地，这样才能对源代码进行正常编译。

对于通用程序包，其是预先对应用不同版本的实现代码间的相同程序代码，按照程序代码依赖关系打包生成的程序包。因此，安装通用程序包的过程实质上就是依次直接安装通用程序包中各程序的过程。所以在获取得到通用程序包后，无需对通用程序包中各程序之间的依赖关系进行分析，便可以直接安装该通用程序包，也即，可以直接安装通用程序包中的各程序。

若目标程序包中包括一个非通用程序包，则直接安装该非通用程序包即可。当目标程序包中包括多个非通用程序包，且各非通用程序包之间具有依赖关系时，在安装这些非通用程序包之前，需要先确定各非通用程序包之间的依赖关系，比如，可以根据源代码确定出各非通用程序包之间的依赖关系。这样，后续在安装这些非通用程序包时，才可以根据该依赖关系依次安装各非通用程序包，从而得到目标编译环境。

S103：在目标编译环境中对源代码进行编译打包，得到待发布软件包。

在步骤S103中，可以采用现有的编译打包方式对源代码进行编译打包，这里不再赘述具体过程。

S104：将待发布软件包发布至目标环境中。

本实施例中的目标环境可以是目标服务器，可以将待发布软件发布至目标服务器中供用户下载。

本实施例提供的软件包发布方法，通过应用的待发布软件包的源代码获取通用程序包，由于通用程序包是预先对应用不同版本的实现代码间的相同程序代码，按照程序代码依赖关系打包生成的程序包，所以安装通用程序包时可以自动依次安装通用程序包中各程序，所以在获取到通用程序包后，无需对通用程序包中各程序之间的依赖关系进行分析，便可以直接安装该通用程序包。也即，本实施例提供的软件包发布方法，可以直接安装通用程序包中的各程序，相比于现有方案中每次发布软件包的过程中都需要对源代码中需调用的各程序之间的依赖关系进行分析，然后再根据该依赖关系依次安装各程序而言，可以节省出分析依赖的时间，所以可以提升软件包的发布效率。

实施例二：

本申请实施例提供一种程序包生成方法，应用于电子设备，请参见图2所示，可以包括如下步骤：

S201：获取同一应用不同版本的实现代码间的相同程序代码。

在一些实施方式中，同一应用不同版本的实现代码间的相同程序代码可以是用户输入的，这里的用户通常是开发人员。通常情况下，开发人员都是基于电子设备进行软件的开发的，所以在另外一些实施方式中，电子设备本地或者云端服务器中可以对应用每一个版本对应的实现代码进行存储，此时可以直接从本地或云端服务器中获取该应用不同版本的实现代码，然后从中提取出各版本实现代码间的相同程序代码。

S202：确定相同程序代码的程序代码依赖关系。

本实施例中的相同程序代码包含多段程序代码，步骤S202中实质上是确定相同程序代码中各段程序代码之间的依赖关系，也即，是确定各段程序代码之间的调用被调用关系。

S203：将相同程序代码按照该程序代码依赖关系进行打包生成通用程序包。

本实施例中，应用的实现代码是指实现应用某一功能、或者多个功能、或者应用所有功能的代码。

应用的功能包括业务功能和基础功能，由于应用的基础功能通常不会变化，比如应用可打开、应用可关闭等；而应用的业务功能可能会发生变化，比如应用的“社交”功能，应用的“交易”功能等，所以实际应用中，通常并不会对应用的基础功能进行更新，往往只需要对业务功能进行更新，所以可以预先针对业务功能生成对应的通用程序包。

具体来说，在步骤S201中，可以从该应用的目标业务功能的维度，针对预设的目标业务功能，获取该应用各历史版本中实现该目标业务功能的代码，得到各历史版本的目标业务功能实现代码。然后，提取出各历史版本的目标业务功能实现代码间的相同程序代码，按照程序代码依赖关系进行打包，生成通用程序包。这样，在本实施方式中，针对该应用的每一目标业务功能，都可得到对应的通用程序包，也即，该应用可能对应多个通用程序包，通用程序包的数量由目标业务功能的数量决定。

应当说明的是，目标业务功能中可以包括一个业务功能，也可以包括多个业务功能。具体的，可以由开发人员根据实际应用情况灵活设置。开发人员可以为一个目标业务功能选择一个业务功能，也可以选择多个业务功能。

比如，当该应用具有“社交”功能和“交易”功能时，开发人员可以选择将应用的“社交”功能和“交易”功能这两个业务功能作为一个目标业务功能。此时，获取该应用不同版本的实现代码中实现“社交”功能和“交易”功能的目标业务功能实现代码，从不同版本的目标业务功能实现代码中提取出相同程序代码，然后确定该相同程序代码的程序代码依赖关系，将相同程序代码按照该依赖关系进行打包生成通用程序包，所以此时，针对“社交”功能和“交易”功能这两个业务功能，对应得到了一个通用程序包，后续在需要对应用的“社交”功能和“交易”功能同时进行更新时，便可以直接调用该通用程序包。

当然，开发人员也可以选择将应用的“社交”功能作为一个目标业务功能，“交易”功能作为另一个目标业务功能，此时针对应用的“社交”功能和“交易”功能，可以分别得到各自对应的通用程序包，后续在需要对应用的“社交”功能进行更新时，调用“社交”功能对应的通用程序即可，后续在需要对应用的“交易”功能进行更新时，调用“交易”功能对应的通用程序即可。

示例性的，在步骤S201中也可以不进行业务功能的区分。也即，可以针对该应用的每一历史版本，获取该历史版本中实现该应用所有功能的代码，得到多个历史版本的实现代码。然后，提取出各历史版本的实现代码间的相同程序代码，将相同程序代码按照程序代码依赖关系进行打包，生成通用程序包。这样，针对该应用，可以得到一个通用程序包，后续在需要对该应用进行更新时，不管是何种更新，都可以直接调用该通用程序包。

本实施例中，在得到通用程序包之后，可以将该通用程序包存储在本地，或者存储在云端服务器中，以便于后续在需要发布该应用的更新包时，可以调用通用程序包。这里的云端服务器可以是外部网络中的服务器，也可以是内部局域网中的服务器。

应当理解的是，为便于后续调用，还可以将应用与通用程序包进行关联。比如，可以针对应用和通用程序包生成对应的应用标识和通用程序包标识，建立应用标识与通用程序包标识之间的对应关系。当需要对该应用进行版本更新时，开发人员根据该关联关系，可以在源代码中直接调用与该应用关联的通用程序包，可以避免调用到其他不适用的程序包。

应当说明的是，当通用程序包是针对该应用某一目标业务功能生成的程序包时，可以将该应用、目标业务功能以及通用程序包进行关联。当需要对该应用的某一目标业务功能进行版本更新时，开发人员根据该关联关系，可以在源代码中直接调用与该应用的目标业务功能关联的通用程序包。

还应当说明的是，可以周期性的检测同一应用不同版本的实现代码间的相同程序代码是否有更新，当检测到相同程序代码对应的内容更新之后，确定更新后的相同程序代码的程序代码依赖关系，将更新后的相同程序代码按照该依赖关系进行打包生成新的通用程序包，同时可以删除对应的旧版通用程序包，以节省存储资源。

实施例三

为了更好的进行理解，本实施例结合具体的应用场景对软件包的发布方法进行具体的介绍，本实施例提供的软件包发布方法应用于电子设备，具体的，可以参见图3所示，包括如下步骤：

S301：获取待发布软件包的源代码。

源代码中包括源代码中需调用的通用程序包的通用程序包标识和需调用的非通用程序包的非通用程序包标识。

S302：根据源代码中的通用程序包标识通过内网在内部服务器中下载对应的通用程序包。

本实施例中通用程序包为预先对该应用不同版本的实现代码间的相同程序代码，按照程序代码依赖关系打包生成的程序包。

S303：根据源代码中的非通用程序包标识通过外网在外部服务器中下载对应的非通用程序包。

应当说明的是，步骤S303可以先于步骤S302执行，步骤S303和步骤S302也可以同时执行。

步骤S304中可以读取源代码根目录文件中的通用程序包标识和非通用程序包标识，根据读取的通用程序包标识和非通用程序包标识从内网和外网中分别下载对应的通用程序包和非通用程序包。

S304：安装通用程序包和非通用程序包，得到目标编译环境。

S305：在目标编译环境中对源代码进行编译打包，得到待发布软件包。

S306：将待发布软件包发布至目标服务器中。

S307：重启目标服务器。

实施例四：

本申请实施例提供一种软件包发布装置，请参见图4所示，包括：

第一获取模块401，用于根据应用的待发布软件包的源代码获取目标程序包；目标程序包中包括通用程序包；通用程序包为：预先对应用不同版本的实现代码间的相同程序代码，按照程序代码依赖关系打包生成的程序包。

安装模块402，用于安装目标程序包，得到目标编译环境。

编译打包模块403，用于在目标编译环境中对源代码进行编译打包，得到待发布软件包。

发布模块404，用于将待发布软件包发布至目标环境中。

在示例性的实施例中，源代码中可以包括通用程序包标识，第一获取模块401可以根据该通用程序包标识通过内网从该第一服务器中下载对应的通用程序包。

在示例性的实施例中，源代码中可以包括非通用程序包标识，目标程序包可以包括非通用程序包，第一获取模块401可以根据该非通用程序包标识从第二服务器中下载对应的非通用程序包。

在示例性的实施例中，通用程序包可以以镜像文件的形式存储在第一服务器中。

需要理解的是，出于描述简洁的考量，部分实施例一、实施例二和实施例三中描述过的内容在本实施例中不再赘述。

实施例五：

本申请实施例提供一种程序包生成装置，请参见图5所示，包括：

第二获取模块501，用于获取同一应用不同版本的实现代码间的相同程序代码。

确定模块502，用于确定所述相同程序代码的程序代码依赖关系。

打包模块503，用于将所述相同程序代码按照所述依赖关系进行打包生成通用程序包。

在示例性的实施例中，第二获取模块501可以接收用户输入的同一应用不同版本的实现代码间的相同程序代码。也可以从本地或云端服务器中获取该应用不同版本的实现代码，然后从中提取出各版本实现代码间的相同程序代码。

本实施例中，应用的实现代码是指实现应用某一功能、或者多个功能、或者应用所有功能的代码。应用的功能通常包括基础功能和业务功能，应用的基础功能是指应用基本不会变化的功能，比如应用可打开、应用可关闭等，无论哪一个版本的应用，都应当具备这些基础功能。而应用的业务功能是指可能会发生更新或变化的功能，比如应用的“社交”功能，应用的“交易”功能等。

由于应用的基础功能通常不会更新，而应用的业务功能可能会发生变化。示例性的，第二获取模块501可以获取同一应用不同版本的目标业务功能实现代码间的相同程序代码；目标业务功能实现代码为实现该应用的目标业务功能需要的代码。

具体来说，第二获取模块501可以从该应用的目标业务功能的维度，针对预设的目标业务功能，获取该应用各历史版本中实现该目标业务功能的代码，得到各历史版本的目标业务功能实现代码。然后，提取出各历史版本的目标业务功能实现代码间的相同程序代码，按照程序代码依赖关系进行打包，生成通用程序包。这样，在本实施方式中，针对该应用的每一目标业务功能，都可得到对应的通用程序包，也即，该应用可能对应多个通用程序包，通用程序包的数量由目标业务功能的数量决定。

应当说明的是，目标业务功能中可以包括一个业务功能，也可以包括多个业务功能。具体的，可以由开发人员根据实际应用情况灵活设置。开发人员可以为一个目标业务功能选择一个业务功能，也可以选择多个业务功能。

比如，当该应用具有“社交”功能和“交易”功能时，开发人员可以选择将应用的“社交”功能和“交易”功能这两个业务功能作为一个目标业务功能。此时，第二获取模块501获取该应用不同版本的实现代码中实现“社交”功能和“交易”功能的目标业务功能实现代码，从不同版本的目标业务功能实现代码中提取出相同程序代码，然后通过确定模块502确定该相同程序代码的程序代码依赖关系，最后通过打包模块503将相同程序代码按照该依赖关系进行打包生成通用程序包。所以此时，针对“社交”功能和“交易”功能这两个业务功能，对应得到了一个通用程序包，后续在需要对应用的“社交”功能和“交易”功能同时进行更新时，便可以直接调用该通用程序包。

当然，开发人员也可以选择将应用的“社交”功能作为一个目标业务功能，“交易”功能作为另一个目标业务功能，此时针对应用的“社交”功能和“交易”功能，可以分别得到各自对应的通用程序包，后续在需要对应用的“社交”功能进行更新时，调用“社交”功能对应的通用程序即可，后续在需要对应用的“交易”功能进行更新时，调用“交易”功能对应的通用程序即可。

在示例性的实施例中，第二获取模块501也可以不进行业务功能的区分，也即，针对该应用的每一历史版本，获取该历史版本中实现该应用所有功能的代码，得到多个历史版本的实现代码，然后提取出各历史版本的实现代码间的相同程序代码，将相同程序代码按照程序代码依赖关系进行打包，生成通用程序包。这样，针对该应用，可以得到一个通用程序包，后续在需要对该应用进行更新时，不管是何种更新，都可以直接调用该通用程序包。

在示例性的实施例中，程序包生成装置还可以包括存储模块，用于对该通用程序包进行存储。或者可以包括发送模块，用于将通用程序包发送至云端服务器进行存储。这里的云端服务器可以是外部网络中的服务器，也可以是内部局域网中的服务器。

在示例性的实施例中，程序包生成装置还可以包括关联模块，用于将应用与通用程序包进行关联。比如，可以针对应用和通用程序包生成对应的应用标识和通用程序包标识，建立应用标识与通用程序包标识之间的对应关系。当需要对该应用进行版本更新时，开发人员根据该关联关系，可以在源代码中直接调用与该应用关联的通用程序包，可以避免调用到其他不适用的程序包。

应当说明的是，当通用程序包是针对该应用某一目标业务功能生成的程序包时，关联模块还可以用于将该应用、目标业务功能以及通用程序包进行关联。当需要对该应用的某一目标业务功能进行版本更新时，开发人员根据该关联关系，可以在源代码中直接调用与该应用的目标业务功能关联的通用程序包。

需要理解的是，出于描述简洁的考量，部分实施例一、实施例二和实施例三中描述过的内容在本实施例中不再赘述。

实施例六：

基于同一发明构思，本申请实施例提供一种电子设备，请参见图6所示，包括处理器601和存储器602，所述存储器602中存储有计算机程序，所述处理器601执行所述计算机程序，以实现上述实施例一、或实施例二、或实施例三中方法的步骤，在此不再赘述。

可以理解，图6所示的结构仅为示意，设备还可包括比图6中所示更多或者更少的组件，或者具有与图6所示不同的配置。

处理器601可以是一种集成电路芯片，具有信号处理能力。上述处理器601可以是通用处理器，包括中央处理器(CPU)、网络处理器(NP)等；还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。其可以实现或者执行本申请实施例中公开的各种方法、步骤及逻辑框图。

存储器602可以包括但不限于随机存取存储器(RAM)，只读存储器(ROM)，可编程只读存储器(PROM)，可擦除只读存储器(EPROM)，电可擦除只读存储器(EEPROM)等。

本实施例还提供了一种计算机可读存储介质，如软盘、光盘、硬盘、闪存、U盘、安全数码(SD)卡、多媒体(MMC)卡等，在该计算机可读存储介质中存储有实现上述各个步骤的一个或者多个程序，这一个或者多个程序可被一个或者多个处理器执行，以实现上述各实施例中方法的各步骤，在此不再赘述。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。

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

Claims (13)

1.一种软件包发布方法，其特征在于，包括：

根据应用的待发布软件包的源代码获取目标程序包；所述目标程序包包括通用程序包；所述通用程序包为：预先对所述应用不同版本的实现代码间的相同程序代码，按照程序代码依赖关系打包生成的程序包；

安装所述目标程序包，得到目标编译环境；

在所述目标编译环境中对所述源代码进行编译打包，得到所述待发布软件包；

将所述待发布软件包发布至目标环境中。

2.如权利要求1所述的软件包发布方法，其特征在于，所述源代码中包括通用程序包标识，所述根据待发布软件包的源代码获取目标程序包，包括：

根据所述通用程序包标识通过内网从第一服务器中下载与所述通用程序包标识对应的通用程序包。

3.如权利要求2所述的软件包发布方法，其特征在于，所述通用程序包以镜像文件的形式存储在所述第一服务器中。

4.如权利要求1所述的软件包发布方法，其特征在于，所述源代码中还包括非通用程序包标识，所述目标程序包还包括非通用程序包；所述根据待发布软件包的源代码获取目标程序包，包括：

根据所述非通用程序包标识从第二服务器中下载与所述非通用程序包标识对应的非通用程序包。

5.如权利要求1-4任一项所述的软件包发布方法，其特征在于，所述实现代码包括目标业务功能实现代码，所述目标业务功能实现代码为实现所述应用的目标业务功能的代码。

6.如权利要求1-5任一项所述的软件包发布方法，其特征在于，所述待发布软件包为所述应用的更新包。

7.一种程序包生成方法，其特征在于，包括：

获取同一应用不同版本的实现代码间的相同程序代码；

确定所述相同程序代码的程序代码依赖关系；

将所述相同程序代码按照所述程序代码依赖关系进行打包生成通用程序包。

8.如权利要求7所述的程序包生成方法，其特征在于，所述获取同一应用不同版本的实现代码间的相同程序代码，包括：

获取所述应用不同版本的目标业务功能实现代码间的相同程序代码；所述目标业务功能实现代码为实现所述应用的目标业务功能需要的代码。

9.如权利要求7或8所述的程序包生成方法，其特征在于，在所述将所述相同程序代码按照所述依赖关系进行打包生成通用程序包之后，还包括：

将所述应用与所述通用程序包关联。

10.一种软件包发布装置，其特征在于，包括：

第一获取模块，用于根据应用的待发布软件包的源代码获取目标程序包；所述目标程序包中包括通用程序包；所述通用程序包为：预先对所述应用不同版本的实现代码间的相同程序代码，按照程序代码依赖关系打包生成的程序包；

安装模块，用于安装所述目标程序包，得到目标编译环境；

编译打包模块，用于在所述目标编译环境中对所述源代码进行编译打包，得到所述待发布软件包；

发布模块，用于将所述待发布软件包发布至目标环境中。

11.一种程序包生成装置，其特征在于，包括：

第二获取模块，用于获取同一应用不同版本的实现代码间的相同程序代码；

确定模块，用于确定所述相同程序代码的程序代码依赖关系；

打包模块，用于将所述相同程序代码按照所述程序代码依赖关系进行打包生成通用程序包。

12.一种电子设备，其特征在于，包括处理器和存储器，所述存储器中存储有计算机程序，所述处理器执行所述计算机程序，以实现如权利要求1-6中任一项或如权利要求7-9中任一项所述的方法。

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

Images