应用的构建方法及装置、存储介质及电子装置

技术领域

本申请涉及智慧家庭技术领域，具体而言，涉及一种应用的构建方法及装置、存储介质及电子装置。

背景技术

在工程化构建应用(Application，简称为App)时，App工程的所有文件都在版本控制工具下管理，比如git，将App的工程管理在一个仓库中。构建时，一般会采用该仓库的某个分支或tag的文件去编译打包。原始的App工程所包含的文件大致分为两类：一是源代码文件，二是配置及资源文件。基于模块化架构的App工程包含的文件也可分为两类：一是模块依赖文件，二是配置及资源文件。

上面提到原始的App工程，是指最基本的工程组织方式，该方式将源代码和配置及资源放在同一个库中管理。而对于大型App，一般同时有多个业务方、多个团队协同开发维护，这种原始的工程组织管理方式难以确保App安全稳定的迭代更新。这时往往基于功能和业务的差异，将App拆分成许多较小单元，即模块；各团队在各自的代码库中开发维护不同的模块；构建时，将各模块的指定版本整合起来进行编译打包。这就是上面所谓的基于模块化架构的App工程。可以拆分到模块的有源代码、资源和部分工程配置。

但无论是哪种工程组织管理方式，在构建App时都缺不了一套整体层面的配置及资源文件，这是无法拆分的。这种整体层面的配置及资源文件基本是App各异的、与模块无关的，每个App有自己特有的一套。基于模块化架构的App工程包含的两类文件中，模块依赖文件中注明App要整合哪些模块的哪个版本；配置及资源文件主要就是整体层面的配置及资源文件。构建前先通过工具，将模块依赖文件中指定的所有模块的文件获取到，然后再构建打包。

对于每一个App版本，其配置及资源文件与源代码文件同等重要，并且必须匹配。换句话说，如果版本A的配置及资源文件与版本B的源代码在一起构建，要么无法构建成功，要么容易产生运行时的错误或异常。但在开发实践中，一段时间内往往需要同时构建多个版本。例如，在版本V1.1.0开发新功能，在版本V1.0.1修复V1.0.0的问题。此时经常会遇到一个场景：这两个版本同时进入集成测试阶段，需要频繁地构建两个版本。假设V1.1.0修改了工程配置文件，而V1.0.1必须采用早前V1.0.0的工程配置文件，这样采用一个分支构建的弊端就产生了。为了解决这种版本冲突，实际中的做法是在构建每个版本前临时将配置文件改成需要的，或者采用某种分支策略，通过使用不同分支，来隔离各版本App工程配置及资源文件的差异。例如，假设构建V1.0.0版本时在V1.0.0分支，之后在基于V1.0.0的新分支V1.0.1上开发V1.0.1的版本，在基于V1.0.0的新分支V1.1.0上开发V1.1.0的功能。这样，如果要构建V1.0.1版本，那么直接在V1.0.1分支构建即可。如果要构建V1.1.0版本，则直接在V1.1.0分支构建即可。

但在多分支开发时，这些分支之间并不是完全独立的，因为还涉及到分支合并的问题。例如，V1.0.1开发完成后，其它正在开发的分支应当将其合并到自己分支，否则V1.0.1的变动尤其是配置及资源文件的变动就会丢失，而分支合并又会潜在冲突和解决冲突的事务。并且随着App的版本迭代，代码仓会累积大量的分支，这会带来存储、性能、维护成本等问题。

针对相关技术中，通过多分支构建多版本应用的构建效率较低的问题，目前尚未提出有效的解决方案。

因此，有必要对相关技术予以改良以克服相关技术中的所述缺陷。

发明内容

本发明实施例提供了一种应用的构建方法及装置、存储介质及电子装置，以至少解决通过多分支构建多版本应用的构建效率较低的问题。

根据本发明实施例的一方面，提供一种应用的构建方法，包括：通过应用构建工具获取构建请求，其中，所述构建请求用于请求构建第一版本的目标应用；通过所述构建请求获取所述目标应用对应的目标模块依赖文件、目标构建文件，其中，所述目标模块依赖文件用于指示构建所述目标应用所需的多个代码模块的版本；所述目标构建文件包括：目标工程文件、目标配置文件、目标资源文件；根据所述目标模块依赖文件、所述目标构建文件构建所述第一版本的目标应用。

在一个示例性的实施例中，通过所述构建请求获取所述目标应用对应的目标模块依赖文件、目标构建文件，包括：获取第一参考文件，其中，所述第一参考文件中记录有应用的版本与模块依赖文件和构建文件的版本的对应关系；通过所述第一参考文件确定与所述第一版本相对应的第二版本与第三版本，其中，所述第二版本为所述目标模块依赖文件的版本，所述第三版为所述目标构建文件的版本；获取所述第二版本的所述目标模块依赖文件；以及获取所述第三版本的所述目标构建文件。

在一个示例性的实施例中，获取所述第二版本的所述目标模块依赖文件，包括：获取第二参考文件，其中，所述第二参考文件中记录有不同版本的模块依赖文件；从所述第二参考文件中获取所述第二版本的所述目标模块依赖文件。

在一个示例性的实施例中，获取所述第三版本的所述目标构建文件，包括：获取第一文件库，其中，所述第一文件库中具有不同版本的构建文件；所述构建文件包括：工程文件、配置文件、资源文件；从所述第一文件库中获取所述第三版本的所述目标构建文件。

在一个示例性的实施例中，根据所述目标模块依赖文件、所述目标构建文件构建所述第一版本的目标应用，包括：根据所述目标模块依赖文件从代码库中获取构建所述目标应用所需的多个代码模块，其中，所述代码库中具有不同版本的代码模块；根据所述多个代码模块和所述目标构建文件构建所述第一版本的目标应用。

在一个示例性的实施例中，根据所述多个代码模块和所述目标构建文件构建所述第一版本的目标应用，包括：获取所述目标应用的构建标准；将所述多个代码模块和所述目标构建文件按照所述构建标准进行融合，并指示所述应用构建工具通过所述融合后的文件构建所述目标应用。

在一个示例性的实施例中，根据所述目标模块依赖文件、所述目标构建文件构建所述第一版本的目标应用之后，所述方法还包括：将所述目标模块依赖文件、所述目标构建文件存储至第二文件库中，其中，所述第二文件库用于存储不同版本的应用的模块依赖文件和构建文件。

根据本发明实施例的另一方面，还提供了一种应用的构建装置，包括：第一获取模块，用于通过应用构建工具获取构建请求，其中，所述构建请求用于请求构建第一版本的目标应用；第二获取模块，用于通过所述构建请求获取所述目标应用对应的目标模块依赖文件、目标构建文件，其中，所述目标模块依赖文件用于指示构建所述目标应用所需的多个代码模块的版本；所述目标构建文件包括：目标工程文件、目标配置文件、目标资源文件；构建模块，用于根据所述目标模块依赖文件、所述目标构建文件构建所述第一版本的目标应用。

在一个示例性的实施例中，第二获取模块，还用于获取第一参考文件，其中，所述第一参考文件中记录有应用的版本与模块依赖文件和构建文件的版本的对应关系；通过所述第一参考文件确定与所述第一版本相对应的第二版本与第三版本，其中，所述第二版本为所述目标模块依赖文件的版本，所述第三版为所述目标构建文件的版本；获取所述第二版本的所述目标模块依赖文件；以及获取所述第三版本的所述目标构建文件。

在一个示例性的实施例中，第二获取模块，还用于获取第二参考文件，其中，所述第二参考文件中记录有不同版本的模块依赖文件；从所述第二参考文件中获取所述第二版本的所述目标模块依赖文件。

在一个示例性的实施例中，第二获取模块，还用于获取第一文件库，其中，所述第一文件库中具有不同版本的构建文件；所述构建文件包括：工程文件、配置文件、资源文件；从所述第一文件库中获取所述第三版本的所述目标构建文件。

在一个示例性的实施例中，构建模块，还用于根据所述目标模块依赖文件从代码库中获取构建所述目标应用所需的多个代码模块，其中，所述代码库中具有不同版本的代码模块；根据所述多个代码模块和所述目标构建文件构建所述第一版本的目标应用。

在一个示例性的实施例中，构建模块，还用于获取所述目标应用的构建标准；将所述多个代码模块和所述目标构建文件按照所述构建标准进行融合，并指示所述应用构建工具通过所述融合后的文件构建所述目标应用。

在一个示例性的实施例中，所述装置还包括：存储模块，用于在根据所述目标模块依赖文件、所述目标构建文件构建所述第一版本的目标应用之后，将所述目标模块依赖文件、所述目标构建文件存储至第二文件库中，其中，所述第二文件库用于存储不同版本的应用的模块依赖文件和构建文件。

根据本发明实施例的又一方面，还提供了一种计算机可读的存储介质，该计算机可读的存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行上述应用的构建方法。

根据本发明实施例的又一方面，还提供了一种电子装置，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，上述处理器通过计算机程序执行上述应用的构建方法。

本发明，通过应用构建工具获取构建请求，其中，所述构建请求用于请求构建第一版本的目标应用，通过所述构建请求获取所述目标应用对应的目标模块依赖文件、目标构建文件，进而根据目标模块依赖文件、目标构建文件构建第一版本的目标应用。由于通过应用构建工具获取不同版本的应用构建请求，进而通过获取不同版本的应用对应的模块依赖文件和构建文件来构建不同版本的应用，解决了通过多分支构建多版本应用的构建效率较低的问题。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

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

图1是根据本申请实施例的一种应用的构建方法的硬件环境示意图；

图2是根据本发明实施例的应用的构建方法的流程图；

图3是根据本发明实施例的应用的构建方法的框架图；

图4是根据本发明实施例的应用的构建方法的时序图；

图5是根据本发明实施例的应用的构建装置的结构框图。

具体实施方式

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

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

根据本申请实施例的一个方面，提供了一种应用的构建方法。该应用的构建方法广泛应用于智慧家庭(Smart Home)、智能家居、智能家用设备生态、智慧住宅(IntelligenceHouse)生态等全屋智能数字化控制应用场景。可选地，在本实施例中，上述应用的构建方法可以应用于如图1所示的由终端设备102和服务器104所构成的硬件环境中。如图1所示，服务器104通过网络与终端设备102进行连接，可用于为终端或终端上安装的客户端提供服务(如应用服务等)，可在服务器上或独立于服务器设置数据库，用于为服务器104提供数据存储服务，可在服务器上或独立于服务器配置云计算和/或边缘计算服务，用于为服务器104提供数据运算服务。

上述网络可以包括但不限于以下至少之一：有线网络，无线网络。上述有线网络可以包括但不限于以下至少之一：广域网，城域网，局域网，上述无线网络可以包括但不限于以下至少之一：WIFI(Wireless Fidelity，无线保真)，蓝牙。终端设备102可以并不限定于为PC、手机、平板电脑、智能空调、智能烟机、智能冰箱、智能烤箱、智能炉灶、智能洗衣机、智能热水器、智能洗涤设备、智能洗碗机、智能投影设备、智能电视、智能晾衣架、智能窗帘、智能影音、智能插座、智能音响、智能音箱、智能新风设备、智能厨卫设备、智能卫浴设备、智能扫地机器人、智能擦窗机器人、智能拖地机器人、智能空气净化设备、智能蒸箱、智能微波炉、智能厨宝、智能净化器、智能饮水机、智能门锁等。

为了解决上述问题，在本实施例中提供了一种应用的构建方法，图2是根据本发明实施例的应用的构建方法的流程图，该流程包括如下步骤：

步骤S202，通过应用构建工具获取构建请求，其中，所述构建请求用于请求构建第一版本的目标应用；

步骤S204，通过所述构建请求获取所述目标应用对应的目标模块依赖文件、目标构建文件，其中，所述目标模块依赖文件用于指示构建所述目标应用所需的多个代码模块的版本；所述目标构建文件包括：目标工程文件、目标配置文件、目标资源文件；

在一个示例性的实施例中，上述步骤S204可以通过以下步骤S11-S13实现：

步骤S11：获取第一参考文件，其中，所述第一参考文件中记录有应用的版本与模块依赖文件和构建文件的版本的对应关系；

需要说明的是，第一参考文件可以存储在数据库中。第一参考文件记录着构建第一版本的目标应用需要何种版本的模块依赖文件和何种版本的构建文件。

步骤S12：通过所述第一参考文件确定与所述第一版本相对应的第二版本与第三版本，其中，所述第二版本为所述目标模块依赖文件的版本，所述第三版为所述目标构建文件的版本；

需要说明的是，在本实施例中，模块依赖文件和构建文件是一种泛指，目标模块依赖文件和目标构建文件是一种特指。即第二版本的模块依赖文件为模块依赖文件，第三版本的构建文件为目标构建文件。

步骤S13：获取所述第二版本的所述目标模块依赖文件；以及获取所述第三版本的所述目标构建文件。

在一个示例性的实施例中，获取所述第二版本的所述目标模块依赖文件，可以通过以下方式实现：获取第二参考文件，其中，所述第二参考文件中记录有不同版本的模块依赖文件；从所述第二参考文件中获取所述第二版本的所述目标模块依赖文件。

需要说明的是，第二参考文件可以存储在模块依赖文件库中，用于用来存放App不同版本的模块依赖文件，在该库中根据App版本功能及业务的需要进行更新迭代。

在一个示例性的实施例中，获取所述第三版本的所述目标构建文件，可以通过以下方式实现：获取第一文件库，其中，所述第一文件库中具有不同版本的构建文件；所述构建文件包括：工程文件、配置文件、资源文件；从所述第一文件库中获取所述第三版本的所述目标构建文件。

需要说明的是，第一文件库用来存放App的整体层面的工程文件、配置文件和资源文件，在该库中根据App版本功能及业务的需要进行更新迭代。

需要说明的是，在本实施例中，将App的工程配置及资源文件与源代码或模块依赖分开管理，分开进行版本控制，进而可以解决传统单分支和多分支构建多版本存在的问题。

步骤S206，根据所述目标模块依赖文件、所述目标构建文件构建所述第一版本的目标应用。

在一个示例性的实施例中，上述步骤S206可以通过以下方式实现：根据所述目标模块依赖文件从代码库中获取构建所述目标应用所需的多个代码模块，其中，所述代码库中具有不同版本的代码模块；根据所述多个代码模块和所述目标构建文件构建所述第一版本的目标应用。

需要说明的是，目标模块依赖文件中记录着目标应用所需的多个代码模块，以及多个代码模块中每个代码模块对应的版本。

在一个示例性的实施例中，根据所述多个代码模块和所述目标构建文件构建所述第一版本的目标应用，可以通过以下方式实现：获取所述目标应用的构建标准；将所述多个代码模块和所述目标构建文件按照所述构建标准进行融合，并指示所述应用构建工具通过所述融合后的文件构建所述目标应用。

作为一种可选的示例，可以通过构建标准将所述多个代码模块和所述目标构建文件进行重新组织，并且移到目录build中，进而应用构建工具开始构建目录build中的完整工程。

上述步骤，通过应用构建工具获取构建请求，其中，所述构建请求用于请求构建第一版本的目标应用，通过所述构建请求获取所述目标应用对应的目标模块依赖文件、目标构建文件，进而根据目标模块依赖文件、目标构建文件构建第一版本的目标应用。由于通过应用构建工具获取不同版本的应用构建请求，进而通过获取不同版本的应用对应的模块依赖文件和构建文件来构建不同版本的应用，解决了通过多分支构建多版本应用的构建效率较低的问题，避免了上述多分支开发会出现的问题。

在一个示例性的实施例中，根据所述目标模块依赖文件、所述目标构建文件构建所述第一版本的目标应用之后，还可以将所述目标模块依赖文件、所述目标构建文件存储至第二文件库中，其中，所述第二文件库用于存储不同版本的应用的模块依赖文件和构建文件。

需要说明的是，对于开发者来说，这个第二文件库是只读库，用来集成调试App和版本便利复原，即发开者可以通过第二文件库轻松、准确的获取到每个版本的应用的所有源码、工程配置和资源，进而根据这些文件可以对应用进行分析bug，解决问题。

显然，上述所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。为了更好的理解上述方法，以下结合实施例对上述过程进行说明，但不用于限定本发明实施例的技术方案，具体地：

在一个可选的实施例中，图3是根据本发明实施例的应用的构建方法的框架图，如图3所示，本申请需要四个库和构建流水线进行协作，四个库分别是：

1、App工程配置及资源库(相当于上述第一文件库)：用来存放App的整体层面的工程文件、配置文件和资源文件。在该库中根据App版本功能及业务的需要进行更新迭代，并且标记版本tag。

2、模块依赖文件库(相当于上述第二参考文件)：用来存放App的模块依赖记录文件。在该库中根据App版本功能及业务的需要进行更新迭代，并且标记版本tag。

3、版本库(相当于上述第一参考文件)：可以是一个数据库，也可以是一个代码库。用来记录App版本所要采用的App工程配置及资源库的版本和模块依赖文件库的版本。该库的tag与其对应的App版本一致。

4、App版本快照库(相当于上述第二文件库)：用来存放各App版本构建的核心文件，比如App工程配置及资源与模块依赖文件。对开发者来说，这个库是只读库，用来集成调试App和版本便利复原。该库的tag与其对应的App版本一致。

图4是根据本发明实施例的应用的构建方法的时序图，如图4所示，交互具体解释如下：

1.1.向构建流水线发起构建App版本A的操作。

1.2.构建流水线创建一个构建结果状态result，用为存储构建是否成功，并将其初始化为成功。

1.3.构建流水线获取版本库tag A的文件。

1.4.构建流水线检查获取版本库tag A是否成功。

1.5.如果获取版本库tag A失败，则设置构建状态result为失败，跳到1.15，构建流程结束。

1.6.如果获取版本库tag A成功，则获取版本库tag A中所指定的App工程配置及资源库的版本B。

1.6.构建流水线检查App工程配置及资源库的版本B是否获取成功。

1.7.如果App工程配置及资源库的版本B获取失败，则设置构建状态result为失败，跳到1.15，构建流程结束。

1.8.构建流水线获取版本库tag A所指定的模块依赖文件库的版本C。

1.9.构建流水线检查获取模块依赖文件库版本C是否成功。

1.10.如果获取模块依赖文件库版本C失败，则设置构建状态result为失败，跳到1.15，构建流程结束。

1.11.如果获取模块依赖文件库版本C成功，则将B和C的文件按照工程的标准结构进行重新组织，并且移到目录build中。

1.12.构建流水线开始构建目录build中的完整工程。

1.13.如果App构建成功，则将build目录中的核心文件写入App版本快照库，并且打tag A。

1.14.如果App构建失败，则设置构建状态result为失败。

1.15.构建流水线根据构建状态result的值，反馈构建成功或失败。

需要说明的是，本实施例将App工程配置及资源库与源代码或模块依赖分开管理，分开进行版本控制；在构建成功后将App版本的核心文件维护到快照库中，只作为记录，而非反过来基于其构建App版本。

通过上述技术方案，免去了通过多分支策略方案构建App时带来的诸多问题。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例的方法。

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

图5是根据本发明实施例的应用的构建装置的结构框图，该装置包括：

第一获取模块52，用于通过应用构建工具获取构建请求，其中，所述构建请求用于请求构建第一版本的目标应用；

第二获取模块54，用于通过所述构建请求获取所述目标应用对应的目标模块依赖文件、目标构建文件，其中，所述目标模块依赖文件用于指示构建所述目标应用所需的多个代码模块的版本；所述目标构建文件包括：目标工程文件、目标配置文件、目标资源文件；

构建模块56，用于根据所述目标模块依赖文件、所述目标构建文件构建所述第一版本的目标应用。

上述装置，通过应用构建工具获取构建请求，其中，所述构建请求用于请求构建第一版本的目标应用，通过所述构建请求获取所述目标应用对应的目标模块依赖文件、目标构建文件，进而根据目标模块依赖文件、目标构建文件构建第一版本的目标应用。由于通过应用构建工具获取不同版本的应用构建请求，进而通过获取不同版本的应用对应的模块依赖文件和构建文件来构建不同版本的应用，解决了通过多分支构建多版本应用的构建效率较低的问题。

在一个示例性的实施例中，第二获取模块54，还用于获取第一参考文件，其中，所述第一参考文件中记录有应用的版本与模块依赖文件和构建文件的版本的对应关系；通过所述第一参考文件确定与所述第一版本相对应的第二版本与第三版本，其中，所述第二版本为所述目标模块依赖文件的版本，所述第三版为所述目标构建文件的版本；获取所述第二版本的所述目标模块依赖文件；以及获取所述第三版本的所述目标构建文件。

在一个示例性的实施例中，第二获取模块54，还用于获取第二参考文件，其中，所述第二参考文件中记录有不同版本的模块依赖文件；从所述第二参考文件中获取所述第二版本的所述目标模块依赖文件。

在一个示例性的实施例中，第二获取模块54，还用于获取第一文件库，其中，所述第一文件库中具有不同版本的构建文件；所述构建文件包括：工程文件、配置文件、资源文件；从所述第一文件库中获取所述第三版本的所述目标构建文件。

在一个示例性的实施例中，构建模块56，还用于根据所述目标模块依赖文件从代码库中获取构建所述目标应用所需的多个代码模块，其中，所述代码库中具有不同版本的代码模块；根据所述多个代码模块和所述目标构建文件构建所述第一版本的目标应用。

在一个示例性的实施例中，构建模块，还用于获取所述目标应用的构建标准；将所述多个代码模块和所述目标构建文件按照所述构建标准进行融合，并指示所述应用构建工具通过所述融合后的文件构建所述目标应用。

在一个示例性的实施例中，上述装置还包括：存储模块，用于在根据所述目标模块依赖文件、所述目标构建文件构建所述第一版本的目标应用之后，将所述目标模块依赖文件、所述目标构建文件存储至第二文件库中，其中，所述第二文件库用于存储不同版本的应用的模块依赖文件和构建文件。

本发明的实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。

可选地，在本实施例中，上述存储介质可以被设置为存储用于执行以下步骤的计算机程序：

S1，通过应用构建工具获取构建请求，其中，所述构建请求用于请求构建第一版本的目标应用；

S2，通过所述构建请求获取所述目标应用对应的目标模块依赖文件、目标构建文件，其中，所述目标模块依赖文件用于指示构建所述目标应用所需的多个代码模块的版本；所述目标构建文件包括：目标工程文件、目标配置文件、目标资源文件；

S3，根据所述目标模块依赖文件、所述目标构建文件构建所述第一版本的目标应用。

在一个示例性实施例中，上述计算机可读存储介质可以包括但不限于：U盘、只读存储器(Read-Only Memory，简称为ROM)、随机存取存储器(Random Access Memory，简称为RAM)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。

本实施例中的具体示例可以参考上述实施例及示例性实施方式中所描述的示例，本实施例在此不再赘述。

本发明的实施例还提供了一种电子装置，包括存储器和处理器，该存储器中存储有计算机程序，该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。

可选地，在本实施例中，上述处理器可以被设置为通过计算机程序执行以下步骤：

S1，通过应用构建工具获取构建请求，其中，所述构建请求用于请求构建第一版本的目标应用；

S2，通过所述构建请求获取所述目标应用对应的目标模块依赖文件、目标构建文件，其中，所述目标模块依赖文件用于指示构建所述目标应用所需的多个代码模块的版本；所述目标构建文件包括：目标工程文件、目标配置文件、目标资源文件；

S3，根据所述目标模块依赖文件、所述目标构建文件构建所述第一版本的目标应用。

在一个示例性实施例中，上述电子装置还可以包括传输设备以及输入输出设备，其中，该传输设备和上述处理器连接，该输入输出设备和上述处理器连接。

本实施例中的具体示例可以参考上述实施例及示例性实施方式中所描述的示例，本实施例在此不再赘述。

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

以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。