CN117827221A - 部署程序代码的方法、装置、设备和存储介质 - Google Patents

Abstract

本申请公开了一种部署程序代码的方法、装置、设备和存储介质，属于互联网技术领域。方法包括：在全栈框架中，获取代码生成插件、代码部署插件、前端框架和后端框架，并获取输入的目标环境类型；通过代码生成插件，确定目标环境类型对应的目标前端环境参数，确定目标环境类型对应的目标后端环境参数；通过代码生成插件，基于前端框架和目标前端环境参数生成前端程序代码，基于后端框架和目标后端环境参数生成后端程序代码；通过代码部署插件，对前端程序代码和后端程序代码进行合并，将合并后的程序代码部署至服务器。采用本申请，可以防止由于前后端部署进程不一致或前后端配置的参数不匹配导致web应用运行出现错误。

Description

部署程序代码的方法、装置、设备和存储介质

技术领域

本申请涉及互联网技术领域，特别涉及一种部署程序代码的方法、装置、设备和存储介质。

背景技术

web(world wide web，全球广域网)应用是一种利用网络浏览器和网络技术在互联网上执行任务的应用，常见的订单系统、消费系统、电商购物系统、广告投放平台、运营管理系统、数据可视化平台和游戏运营平台等都是web应用。web应用包括前端和后端，在web应用开发完成或阶段性开发完成后进行上线运行或测试时需要进行部署。

相关技术采用前后端分离的模式开发和部署web应用，前端和后端分别使用对应的开发框架独立进行开发，然后，前端技术人员将开发完成的前端进行部署，后端技术人员将开发完成的后端进行部署。

前端和后端分离的模式，由于前端和后端分别部署，容易产生前端和后端部署进程不一致的情况，还可能出现前端和后端配置的参数不匹配的情况，这都会导致web应用运行出现错误。

发明内容

本申请实施例提供了一种部署程序代码的方法、装置、设备和存储介质，可以解决相关技术中存在的问题，所述技术方案如下：

第一方面，提供了一种部署程序代码的方法，所述方法包括：

在目标应用对应的全栈框架中，获取代码生成插件、代码部署插件、前端框架和后端框架，并获取输入的目标环境类型；

通过所述代码生成插件，基于环境类型与前端环境参数的对应关系，确定所述目标环境类型对应的目标前端环境参数，基于环境类型与后端环境参数的对应关系，确定所述目标环境类型对应的目标后端环境参数；

通过所述代码生成插件，基于所述前端框架和所述目标前端环境参数生成前端程序代码，基于所述后端框架和所述目标后端环境参数生成后端程序代码；

通过所述代码部署插件，对所述前端程序代码和所述后端程序代码进行合并，将合并后的程序代码部署至服务器。

在一种可能的实现方式中，所述环境类型与前端环境参数的对应关系记录于所述前端框架中；

所述环境类型与后端环境参数的对应关系记录于所述后端框架中。

在一种可能的实现方式中，所述基于所述前端框架和所述目标前端环境参数生成前端程序代码，包括：

获取所述前端框架对应的依赖函数；

将所述前端框架对应的依赖函数，添加到所述前端框架中，得到前端初始程序代码；

基于所述目标前端环境参数，对所述前端初始程序代码进行编译，生成前端程序代码。

在一种可能的实现方式中，所述基于所述后端框架和所述目标后端环境参数生成后端程序代码，包括：

获取所述后端框架对应的依赖函数；

将所述后端框架对应的依赖函数，添加到所述后端框架中，得到后端初始程序代码；

对所述后端初始程序代码加载所述目标后端环境参数，生成后端程序代码。

在一种可能的实现方式中，所述对所述前端程序代码和所述后端程序代码进行合并，将合并后的程序代码部署至服务器，包括：

将所述前端程序代码，添加到所述后端程序代码的主文件夹下的指定文件夹中；

将添加了所述前端程序代码后的后端程序代码，部署至服务器。

在一种可能的实现方式中，所述后端框架包括请求日志插件，所述请求日志插件用于当接收前端发送的请求消息，为所述请求消息分配请求标识，在对所述请求消息进行处理后存储处理过程的日志信息时，将所述请求标识与所述日志信息对应存储。

在一种可能的实现方式中，所述后端框架是在后端框架集合中选择得到后添加到所述全栈框架中的，所述后端框架集合至少包括第一后端框架和第二后端框架；

所述第一后端框架包括控制层、逻辑层和数据层，所述逻辑层包括至少一个逻辑模块，所述数据层包括至少一个数据库，所述控制层用于确定前端发送的请求消息对应的逻辑模块和数据库，所述逻辑模块用于解析所述请求消息对应的操作指令，并基于所述请求消息对应的数据库中存储的数据执行所述操作指令；

所述第二后端框架包括所述控制层和处理层，所述处理层包括至少一个逻辑模块和至少一个数据库，所述控制层用于确定前端发送的请求消息对应的逻辑模块，所述逻辑模块用于解析所述请求消息对应的操作指令，并基于所述逻辑模块绑定的数据库中存储的数据执行所述操作指令。

第二方面，提供了一种部署程序代码的装置，所述装置包括：

获取模块，用于在目标应用对应的全栈框架中，获取代码生成插件、代码部署插件、前端框架和后端框架，并获取输入的目标环境类型；

确定模块，用于通过所述代码生成插件，基于环境类型与前端环境参数的对应关系，确定所述目标环境类型对应的目标前端环境参数，基于环境类型与后端环境参数的对应关系，确定所述目标环境类型对应的目标后端环境参数；

生成模块，用于通过所述代码生成插件，基于所述前端框架和所述目标前端环境参数生成前端程序代码，基于所述后端框架和所述目标后端环境参数生成后端程序代码；

部署模块，用于通过所述代码部署插件，对所述前端程序代码和所述后端程序代码进行合并，将合并后的程序代码部署至服务器。

在一种可能的实现方式中，所述环境类型与前端环境参数的对应关系记录于所述前端框架中；

所述环境类型与后端环境参数的对应关系记录于所述后端框架中。

在一种可能的实现方式中，所述生成模块，用于：

获取所述前端框架对应的依赖函数；

将所述前端框架对应的依赖函数，添加到所述前端框架中，得到前端初始程序代码；

基于所述目标前端环境参数，对所述前端初始程序代码进行编译，生成前端程序代码。

在一种可能的实现方式中，所述生成模块，用于：

获取所述后端框架对应的依赖函数；

将所述后端框架对应的依赖函数，添加到所述后端框架中，得到后端初始程序代码；

对所述后端初始程序代码加载所述目标后端环境参数，生成后端程序代码。

在一种可能的实现方式中，所述部署模块，用于：

将所述前端程序代码，添加到所述后端程序代码的主文件夹下的指定文件夹中；

将添加了所述前端程序代码后的后端程序代码，部署至服务器。

在一种可能的实现方式中，所述后端框架包括请求日志插件，所述请求日志插件用于当接收前端发送的请求消息，为所述请求消息分配请求标识，在对所述请求消息进行处理后存储处理过程的日志信息时，将所述请求标识与所述日志信息对应存储。

在一种可能的实现方式中，所述后端框架是在后端框架集合中选择得到后添加到所述全栈框架中的，所述后端框架集合至少包括第一后端框架和第二后端框架；

所述第一后端框架用于控制层、逻辑层和数据层，所述逻辑层用于至少一个逻辑模块，所述数据层用于至少一个数据库，所述控制层用于确定前端发送的请求消息对应的逻辑模块和数据库，所述逻辑模块用于解析所述请求消息对应的操作指令，并基于所述请求消息对应的数据库中存储的数据执行所述操作指令；

所述第二后端框架用于所述控制层和处理层，所述处理层用于至少一个逻辑模块和至少一个数据库，所述控制层用于确定前端发送的请求消息对应的逻辑模块，所述逻辑模块用于解析所述请求消息对应的操作指令，并基于所述逻辑模块绑定的数据库中存储的数据执行所述操作指令。

第三方面，提供了一种计算机设备，所述计算机设备包括处理器和存储器，所述存储器中存储有至少一条指令，所述至少一条指令所述处理器加载并执行以实现如上述第一方面及其可能的实现方式的方法。

第四方面，提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令，所述至少一条指令由所述处理器加载并执行以实现如上述第一方面及其可能的实现方式的方法。

第五方面，提供了一种计算机程序产品，计算机程序产品包括计算机程序代码，在计算机程序代码被计算机设备执行时，计算机设备执行第一方面及其可能的实现方式的方法。

本申请实施例提供的技术方案带来的有益效果至少包括：

本申请实施例中，通过全栈框架部署程序代码，全栈框架中集成了前端框架和后端框架，用全栈框架进行前端和后端开发和部署，将前端程序代码与后端程序代码合并后，将合并的程序代码部署于服务器，因为是合并之后进行统一部署的，所以在部署时前端程序代码和后端程序代码部署进程完全一致，并且，前端环境参数和后端环境参数都是基于技术人员输入的目标环境类型在对应关系中查找得到的，所以，前端环境参数和后端环境参数都是与同一环境类型匹配的，故不会出现前端环境参数和后端环境参数不匹配的情况，从而，可以防止由于前后端部署进程不一致或前后端配置的参数不匹配导致web应用运行出现错误。

附图说明

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

图1是本申请实施例提供的一种全栈框架目录结构的示意图；

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

图3是本申请实施例提供的一种部署程序代码的方法流程图；

图4是本申请实施例提供的一种全栈框架的结构示意图；

图5是本申请实施例提供的一种项目选择窗口的示意图；

图6是本申请实施例提供的一种环境类型选择窗口的示意图；

图7是本申请实施例提供的一种前端框架的结构示意图；

图8是本申请实施例提供的一种基础路由的工作过程示意图；

图9是本申请实施例提供的一种缓存管理插件的工作过程示意图；

图10是本申请实施例提供的一种请求实例的工作过程示意图；

图11是本申请实施例提供的一种全局状态管理实例的工作过程示意图；

图12是本申请实施例提供的一种设置前端环境参数的方法流程图；

图13是本申请实施例提供的一种后端框架的结构示意图；

图14是本申请实施例提供的一种第一后端框架的结构示意图；

图15是本申请实施例提供的一种第二后端框架的结构示意图；

图16是本申请实施例提供的一种后端框架选择窗口的示意图；

图17是本申请实施例提供的一种对请求消息输出响应值的方法示意图；

图18是本申请实施例提供的一种设置后端环境参数的方法流程图；

图19是本申请实施例提供的一种部署程序代码的装置结构图；

图20是本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

下面对本实施例使用的一些名词进行解释：

前端框架：用于执行web应用基本功能的客户端程序代码、以及执行部署操作的相关数据的集合。

前端框架中的数据可以以多级目录的形式存储。

后端框架：用于执行web应用基本功能的服务端程序代码、以及执行部署操作的相关数据的集合。

后端框架中的数据可以以多级目录的形式存储。

依赖函数：前端框架和后端框架在执行过程中会调用的封装好的函数。

环境参数：在前端框架和后端框架中用来指定前端框架和后端框架运行环境的参数。环境参数存储于环境配置文件中。运行环境可以包括开发环境(development)、测试环境(test)和生产环境(porduction)等。

前端程序代码：通过代码生成插件对前端框架进行依赖函数添加、环境参数加载和编译得到的程序代码。相对于前端框架，前端程序代码具有更为完整的功能，具有更加独立的执行能力。

后端程序代码：通过代码生成插件对后端框架进行依赖函数添加和环境参数加载得到的程序代码。相对于后端框架，后端程序代码具有更为完整的功能，具有更加独立的执行能力。

代码生成插件：用于执行生成前端程序代码和后端程序代码的相关处理的插件。

依赖安装插件：用于执行为前端框架和后端框架安装依赖函数的相关处理的插件。

代码检查插件：用于检查代码规范的插件。

前端构建插件：用于对前端框架进行编译生成前端程序代码的插件。

代码部署插件：用于执行对程序代码的合并和上传的相关处理的插件。

项目配置文件：用于记录全栈框架当前配置的文件，如，记录前端框架和后端框架当前使用的依赖函数的名称和版本。

全栈框架：在web应用部署过程中进行主要处理的程序代码、以及部署所需的主要程序代码和相关数据的集合。全栈框架可以包括上述前端框架、后端框架、前端框架的依赖函数、后端框架的依赖函数、代码生成插件和代码部署插件，还可以包括一些参数信息等。

全栈框架中的各种数据可以以多级目录的形式存储。

例如，全栈框架目录可以如图1所示，全栈框架目录包含前端框架主目录(client)、后端框架主目录(server)、部署目录(output)、代码部署插件文件、代码生成插件文件、代码检查插件文件以及代码规范文件和项目配置文件(package.json)。

前端框架主目录中包含前端源代码目录(src)和前端环境配置目录(.env)，其中，前端源代码目录中包含路由目录(router)、全局状态管理目录(store)和页面代码目录(view)。

后端框架主目录中包含后端源代码目录(app)和后端环境配置目录(config)，其中，后端源代码目录中包括控制层目录(controller)、逻辑层目录(service)和数据层目录(model)。

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

本申请实施例提供了一种部署程序代码的方法，该方法的执行主体可以为计算机设备，该计算机设备可以是服务器或终端。该服务器可以是一个单独的服务器也可以是一个服务器组，如果是单独的服务器，该服务器可以负责下述方案中的所有处理，如果是服务器组，服务器组中的不同服务器分别可以负责下述方案中的不同处理，具体的处理分配情况可以由技术人员根据实际需求任意设置，此处不再赘述。该终端可以是台式计算机、笔记本电脑、智能手机、平板电脑等，但并不局限于此。本申请实施例以终端为执行主体进行方案详细说明，其他情况与之类似，不再赘述。

图2是本申请实施例提供的一种计算机设备的结构示意图，从硬件组成上来看，计算机设备的结构可以如图2所示，包括处理器210、存储器220和通信部件230。

处理器210可以是中央处理器(central processing unit，CPU)或系统级芯片(system on chip，SoC)等，处理器210可以用于执行部署程序代码涉及的各种指令等。

存储器220可以包括各种易失性存储器或非易失性存储器，如固态硬盘(solidstate disk，SSD)、动态随机存取存储器(dynamic random access memory，DRAM)内存等。存储器220可以用于存储部署程序代码过程中涉及到的初始数据、中间数据和结果数据，例如，前端框架模板和后端框架模板，环境参数，等等。

通信部件230可以是有线网络连接器、超宽带技术(ultra wide band，UWB)、无线保真(wireless fidelity，WiFi)模块、蓝牙模块、蜂巢网通信模块等。通信部件230可以用于与其他设备进行数据传输，其他设备可以是服务器、也可以是终端等。例如，将程序代码部署至服务器，等等。

在进行web应用的开发过程中，技术人员完成前端框架、后端框架以及一些配套的函数、插件等的代码编写之后，可能涉及到对web应用进行测试或上线运行等环节，这些环节都会涉及对web应用的程序代码(包括前端程序代码和后端程序代码)进行部署。部署过程中，可能涉及到参数的配置、函数的添加、编译、代码上传等操作。本申请实施例以web应用的部署为例进行方案说明，其他类型的应用也可以采用类似的处理方式，本申请实施例不再赘述。

web应用的前端框架和后端框架在开发完成后，需要部署到服务器，在后续的测试或者上线运行时启用，如图3所示，部署程序代码方法的处理流程可以包括如下的步骤：

301，在web应用对应的全栈框架中，获取代码部署插件、前端框架和后端框架。

其中，如图4所示，全栈框架包括前端框架、后端框架和基础功能插件，基础功能插件包括代码部署插件和代码生成插件，等等。

前端框架和后端框架可以预先进行设计，设计得到的前端框架和后端框架具体架构在后面会有详细说明。

技术人员需要对web应用进行部署时，可以在终端上运行用于部署web应用的应用程序。该应用程序可以具有图形化操作界面，在应用程序的主界面中，可以设置有部署选项。技术人员点击部署选项后，可以触发应用程序显示项目选择窗口，如图5所示，在项目选择窗口中可以显示有项目列表和确认控件，项目列表中包括各个web应用的选项。技术人员可以在其中进行浏览，找到想要部署的web应用，点击该web引用的选项，并点击确认控件。终端则会获取该web应用的全栈框架。其中，项目列表中的各web应用的全栈框架都已经由相关部门的技术人员编写完毕，并存储在该终端中。

终端获取全栈框架后可以进一步从中获取代码部署插件、前端框架和后端框架。

302，获取输入的目标环境类型。

其中，目标环境类型可以在环境类型中进行选择或者输入，环境类型包括开发环境、测试环境和生产环境等，在前端框架和后端框架处于不同环境类型时，对于框架中数据的调用权限不同。

在技术人员点击上述确认控件之后，应用程序可以显示代码部署界面，在代码部署界面中，可以设置有环境类型设置选项。技术人员点击环境类型设置选项后，可以触发应用程序显示环境类型选择窗口，如图6所示，在环境类型选择窗口中可以显示有环境类型列表和确认控件，环境类型列表中包括各个环境类型的选项。技术人员可以在其中进行浏览，找到想要使用的环境类型，点击该环境类型(如开发环境、测试环境和生产环境等)的选项，并点击确认控件。终端则会获取该环境类型(即上述目标环境类型)，进行存储。其中，环境类型列表中的各环境类型与对应的环境参数，已经存储在该终端中。

303，通过代码生成插件，基于环境类型与前端环境参数的对应关系，确定目标环境类型对应的目标前端环境参数，基于环境类型与后端环境参数的对应关系，确定目标环境类型对应的目标后端环境参数。

其中，前端环境参数可以用于指示前端框架对数据库的访问和修改权限等。后端环境参数可以用于指示后端框架数据库的访问和修改权限等。代码生成插件包括依赖安装插件、代码检查插件和前端构建插件。

技术人员可以预先设置每种环境类型对应的前端环境参数和后端环境参数。然后，建立环境类型与前端环境参数的对应关系，以及环境类型和后端环境参数的对应关系，两个对应关系可以分别以表的形式存储。再后，可以将环境类型与前端环境参数的对应关系添加到前端框架中，将环境类型与后端环境参数的对应关系添加到后端框架中。

上述代码部署界面中还可以包括启动部署控件。技术人员点击启动部署控件，则可以触发终端获取上述存储的目标环境类型，在前端框架中记录的对应关系中查找目标环境类型对应的目标前端环境参数，并在后端框架中记录的对应关系中查找目标环境类型对应的目标后端环境参数。这些处理可以由代码生成插件中的前端构建插件来执行。

304，通过代码生成插件，基于前端框架和目标前端环境参数生成前端程序代码，基于后端框架和目标后端环境参数生成后端程序代码。

首先，安装前端框架和后端框架的依赖函数。终端获取package.json文件中前端框架使用的依赖函数名称及版本等信息。获得需要安装的依赖函数名称及版本等信息后，将相应版本的依赖函数安装到前端框架中，得到前端初始程序代码。终端获取package.json文件中后端框架使用的依赖函数名称及版本等信息。获得需要安装的依赖函数名称及版本等信息后，将相应版本的依赖函数安装到后端框架中，得到后端初始程序代码。以上前端框架和后端框架的依赖函数安装，可以通过执行一次依赖安装插件全部完成。这些处理可以由依赖安装插件来执行，依赖安装插件可以为install:all插件。

然后，进行前端构建。前端构建插件对前端初始程序代码加载目标前端环境参数，对后端初始程序代码加载目标后端环境参数得到后端程序代码，将前端初始程序代码通过编译(或称构建打包)转换成可执行的前端程序代码。这些处理可以由前端构建插件来执行，前端构建插件可以为build.sh。

最后，检查代码的规范性。代码规范可以使用Typescript(一种程序语言的名称)规范等，在每次提交代码前使用代码检查插件检查代码的规范性。这些处理可以由代码检查插件来执行，代码检查插件可以为lint(一种代码检查插件)插件和stylelint(一种代码检查插件)插件等。

305，通过代码部署插件，对前端程序代码和后端程序代码进行合并，将合并后的程序代码部署至服务器。

在代码生成插件运行完毕后，终端可以运行代码部署插件，代码部署插件可以为deploy.sh。代码部署插件会自动将前端程序代码和后端程序代码进行合并，得到合并后的程序代码，然后根据预存的服务器地址，将合并后的程序代码上传至指定的服务器。

对前端程序代码与后端程序代码进行合并，以下给出了几种可行的合并方式：

方式一，将前端程序代码的主文件夹与后端程序代码的主文件夹合并到一个文件夹中。合并得到的文件夹中可以包括前端程序代码的主文件夹的所有下级文件夹、后端程序代码的主文件夹的下级文件夹、以及文件夹中的数据。

例如，前端程序代码的主文件夹为client文件夹，后端程序代码的主文件夹为server文件夹，创建output文件夹，将client文件夹下的所有文件夹和server文件夹下的所有文件夹连同文件夹中的数据放入output文件夹。

方式二，将前端程序代码的主文件夹，移动到后端程序代码的主文件夹中指定的下级文件夹中。

例如，前端程序代码的主文件夹为client文件夹，后端程序代码的主文件夹为server文件夹，将client文件夹移动到server文件夹中的public文件夹中，另外，将public文件夹中的首页入口文件(index.html)移动到server文件夹中的view文件夹，把server文件夹复制到全栈框架中的output文件夹。

以上部署程序代码的方法是全栈框架的基础功能，在部署完成后，后续对web应用进行更新或维护都可以基于全栈框架进行。技术人员可以对全栈框架中的前端框架或后端框架进行编辑，可以在其中增加代码或对其中的代码进行修改。在编辑完毕后，可以基于编辑后的全栈框架，重新执行上述流程，以完成更新后的web应用的部署。

本申请实施例提供一种前端框架，该前端框架是以VITE(virtual instrumenttest environment，虚拟仪器测试开发环境)(一种前端构建工具)+Vue3.2(一种web应用前端框架类型)+Typescript为基础设计的，如图7所示，前端框架的具体架构中可以包括以下内容：

(1)路由管理插件。

其中，路由管理插件用于设定访问路径，并将路径和前端框架中的组件映射起来，组件可以为列表组件、导航栏组件和搜索组件等。

前端框架中使用路由管理插件配置了基础路由，路由管理插件可以为vue-router，具体使用方法为：

在前端框架的开发过程中，首先通过路由管理插件设置基础路由，然后设置基础路由的跳转规则。

如图8所示，路由管理插件可以设置四种基础路由“/”、“/home”、“/detail/：id”和“404”。路由管理插件设置基础路由“/”对应的跳转规则为：跳转至“/”之后的字符串对应的页面。路由管理插件设置基础路由“/home”对应的跳转规则为：跳转至默认主页。路由管理插件设置基础路由“/detail/：id”对应的跳转规则为：跳转至id对应的文件夹中的页面，该页面为一个详情页面。路由管理插件设置基础路由“404”对应的跳转规则为：跳转至404空状态页面。

设置基础路由的跳转规则后，为每个基础路由设置meta标签(一种包含页面信息的数据标签)。在web应用运行过程中，当使用基础路由跳转至某页面时，使用路由钩子获取meta标签，读取meta标签中的页面信息，根据页面信息进行页面加载。路由钩子主要是在路由发生变化时进行一些特殊的处理而定义的函数，路由钩子可以使用beforeEach函数。

(2)缓存管理插件。

缓存管理插件用于防止重复渲染DOM(document object model，文档对象模型)结构，缓存插件可以为keep-alive缓存插件，如图9所示，具体使用方法为：

在前端框架的测试或上线运行过程中，在使用web应用通过路由进入某一页面时，终端在页面的app.vue(页面入口文件)读取meta标签，判断meta标签是否有缓存属性，若meta标签中存在缓存属性，则通过缓存管理插件直接读取缓存中的DOM结构，之后再进行页面渲染；若meta标签中不存在缓存属性，首先进行DOM结构渲染，再进行页面渲染。

(3)http(hyper text transfer protocol，超文本传输协议)请求库。

http请求库用于构建http请求消息，用于请求后端数据，http请求库可以采用axios，如图10所示，具体使用方法为：

在前端框架的开发过程中，通过预先创建的axios实例将请求导入至主页面(home页面)中，axios实例可以包含：请求方法(如：获取请求、删除请求、新建请求和修改请求等)、请求的域名(基本地址)、请求的超时时长、请求路径、请求头和请求参数。home页面接收到发送请求消息的指令后，通过异步函数发送请求消息至后端接口，异步函数可以采用async、await关键字声明的函数。在后续的开发中，可以对照前端框架内的axios实例创建新的axios实例用于发送请求消息。

(4)全局通用请求拦截器。

在前端框架的测试或上线运行过程中，全局通用请求拦截器可以在发送请求消息之前对请求消息进行修改，全局通用请求拦截器可以采用interceptors。具体使用方法为：

修改请求头的一些配置项，给请求的过程添加一些请求的图标，给请求消息添加参数，等等。

(5)全局状态管理插件。

在前端框架的测试或上线运行过程中，全局状态管理插件可以统一管理和维护前端框架内的各个数据状态，在需要多个位置更新同一个数据时使用，全局状态管理插件可以采用pinia。如图11所示，具体使用方法为：

将pinia实例导入全局状态管理目录(store)，详情页(detail页面)需要使用pinia实例中的数据时，读取全局状态管理目录中的数据状态，detail页面获得数据，detail页面对数据进行更新后，将数据传回全局状态管理目录，全局状态管理目录更新对应的数据状态。可以对照前端框架内的pinia实例创建新的pinia实例用于全局数据状态的管理。

(6)环境类型及对应的前端环境参数。

前面的实施例内容中已经阐述，环境类型可以包括开发环境、生产环境、测试环境，前端框架中存储有环境类型与前端环境参数的对应关系。

为前端框架设置环境参数的具体方法可以为：如图12所示，在web应用部署阶段，将技术人员选择的目标环境类型输入代码生成插件，代码生成插件获取目标环境类型传递给环境参数加载插件，环境参数加载插件基于目标环境类型在上述对应关系中查找对应的目标前端环境参数，加载到前端框架。环境参数加载插件可以为dotenv插件。

本申请实施例提供一种后端框架，该后端框架是以Egg(一种web应用后端框架类型)+Typescript为基础设计的，其中，Egg中引入egg-validate插件、egg-apigw-tracer插件和egg-view-nunjucks插件等常用插件。如图13所示，后端框架的具体架构中可以包括以下内容：

(1)第一后端框架和第二后端框架。

如图14所示，第一后端框架包括控制层(Controller)、逻辑层(Service)和数据层(Model)。逻辑层包括至少一个逻辑模块。数据层包括至少一个数据库。

控制层用于确定前端发送的请求消息对应的逻辑模块和数据库。

逻辑模块用于解析请求消息对应的操作指令，并基于请求消息对应的数据库中存储的数据执行操作指令。

第一后端框架可以采用egg-sequelize插件管理数据库。

如图15所示，第二后端框架包括控制层和处理层。处理层包括至少一个逻辑模块和至少一个数据库。

控制层用于确定前端发送的请求消息对应的逻辑模块。

逻辑模块用于解析请求消息对应的操作指令，并基于逻辑模块绑定的数据库中存储的数据执行操作指令。

第二后端框架可以采用egg-mysql或egg-redis插件管理数据库。

在后端框架的开发过程中，第一后端框架和第二后端框架可以根据web应用的具体使用需求进行选择。可以设置有后端框架选择栏，如图16所示，可以在其中对第一后端框架和第二后端框架进行选择。对于购物平台等功能复杂、较大规模的web应用可以选择第一后端框架。在增加或删除数据库时，不需要对逻辑模块进行大规模修改，减少技术人员工作量。对于人员信息管理系统等功能简单、较小规模的web应用可以选择第二后端框架。由于信息管理系统等web应用只涉及数据添加，删除、修改和查询等简单功能，所以采用第二后端框架将逻辑模块和调用的数据库直接进行绑定，能够减少技术人员需要编写的代码数量。

(2)请求日志插件。

上述第一后端框架和第二后端框架都可以包括请求日志插件。请求日志插件用于当接收前端发送的请求消息，为请求消息分配请求标识(requestid)，对请求消息进行处理后，处理过程中生成日志信息，将请求标识与日志信息对应存储至请求标识列表(list)。其中，根据请求标识和请求表示列表生成RESTful路由“/list/id”，通过RESTful路由确定对应的请求消息在处理的各个子过程的日志信息。请求日志插件包含http请求示踪器、错误处理插件和日志生成插件，具体使用方法为：

在后端框架的上线运行过程中，请求处理插件在接收到请求消息后，请求http请求示踪器为请求消息生成一个请求标识，后端框架对请求消息进行处理，日志生成插件为请求消息处理的各个子过程生成日志信息，并将日志信息与请求标识对应存储。在后端框架处理请求消息的每个子过程完成后，错误处理插件判断子过程是否输出报错信息，如果输出报错信息，日志生成插件捕获报错信息生成日志信息，将日志信息与请求标识对应存储。http请求示踪器可以为egg-apigw-tracer插件。

(3)基础控制器(BaseController)。

基础控制器处于控制层，用于根据请求消息对应的日志信息生成响应值。具体使用方法为：

在后端框架的测试或上线运行过程中，基础控制器中封装RESTful(representational state transfer，表述性状态转移)风格的回调函数，回调函数根据日志信息中存储的数据，生成RESTful风格的响应值，响应值可以由http状态码、提示信息、请求结果、请求标识符组成。如图17所示，控制层内的列表控制器(ListController)和账号控制器(UserController)等其他控制器可以引用这个基础控制器，使用基础控制器封装的RESTful风格的回调函数来生成响应值，生成响应值后，控制层输出响应值，将响应值发送至前端。回调函数可以为success函数。

(4)环境类型及对应的后端环境参数。

前面的实施例内容中已经阐述，环境类型可以包括开发环境、生产环境、测试环境，后端框架中存储有环境类型与后端环境参数的对应关系。

为后端框架设置环境参数的具体方法可以为：如图18所示，在web应用部署阶段，将技术人员选择的目标环境类型输入代码部署插件，代码部署插件基于目标环境类型在上述对应关系中查找对应的目标后端环境参数，加载到后端框架。

本申请实施例提供的部署程序代码的方法可以用于游戏运营平台的部署，处理流程与图3相似，在部署程序代码前需要对前端框架和后端框架进行游戏运营平台的相关设置：

在前端框架中，生成适合游戏运营平台的基础路由，使用缓存管理插件在本地存储需要重复渲染和加载的游戏运营平台页面。

在后端框架中，使用RESTful风格的响应值和路由，用于游戏运营平台的数据在不同页面的传递，方便大型游戏运营平台中不同页面的数据交流沟通，还能规范整个开发流程。为游戏运营平台的数据底层交互(游戏运营数据的增删查改)提供适合的后端框架。

采用本申请实施例提供的前端框架、后端框架以及部署程序代码的方法进行游戏运营平台的部署具有以下有益效果：

在本申请实施例中使用代码生成插件和代码部署插件对前后端进行部署，可以由一个开发人员或团队进行前后端开发、测试和部署，解决前后端独立开发、测试和部署时整体流程较慢的问题，简化部署流程让游戏运营平台中的小型项目快速部署上线，并避免相关技术中前后端部署进程不一致的问题。

本申请实施例中，通过全栈框架部署程序代码，全栈框架中集成了前端框架和后端框架，用全栈框架进行前端和后端开发和部署，将前端程序代码与后端程序代码合并后，将合并的程序代码部署于服务器，因为是合并之后进行统一部署的，所以在部署时前端程序代码和后端程序代码部署进程完全一致，并且，前端环境参数和后端环境参数都是基于技术人员输入的目标环境类型在对应关系中查找得到的，所以，前端环境参数和后端环境参数都是与同一环境类型匹配的，故不会出现前端环境参数和后端环境参数不匹配的情况，从而，可以防止由于前后端部署进程不一致或前后端配置的参数不匹配导致web应用运行出现错误。

上述所有可选技术方案，可以采用任意结合形成本公开的可选实施例，在此不再一一赘述。

基于相同的技术构思，本申请实施例还提供了一种部署程序代码的装置，如图19所示，该装置包括：

获取模块1910，用于在目标应用对应的全栈框架中，获取代码生成插件、代码部署插件、前端框架和后端框架，并获取输入的目标环境类型；

确定模块1920，用于通过代码生成插件，基于环境类型与前端环境参数的对应关系，确定目标环境类型对应的目标前端环境参数，基于环境类型与后端环境参数的对应关系，确定目标环境类型对应的目标后端环境参数；

生成模块1930，用于通过代码生成插件，基于前端框架和目标前端环境参数生成前端程序代码，基于后端框架和目标后端环境参数生成后端程序代码；

部署模块1940，用于通过代码部署插件，对前端程序代码和后端程序代码进行合并，将合并后的程序代码部署至服务器。

在一种可能的实现方式中，环境类型与前端环境参数的对应关系记录于前端框架中；

环境类型与后端环境参数的对应关系记录于后端框架中。

在一种可能的实现方式中，生成模块1930用于：

获取前端框架对应的依赖函数；

将前端框架对应的依赖函数，添加到前端框架中，得到前端初始程序代码；

基于目标前端环境参数，对前端初始程序代码进行编译，生成前端程序代码。

在一种可能的实现方式中，生成模块1930用于：

获取后端框架对应的依赖函数；

将后端框架对应的依赖函数，添加到后端框架中，得到后端初始程序代码；

对后端初始程序代码加载目标后端环境参数，生成后端程序代码。

在一种可能的实现方式中，部署模块1940用于：

将前端程序代码，添加到后端程序代码的主文件夹下的指定文件夹中；

将添加了前端程序代码后的后端程序代码，部署至服务器。

在一种可能的实现方式中，后端框架包括请求日志插件，请求日志插件用于当接收前端发送的请求消息，为请求消息分配请求标识，在对请求消息进行处理后存储处理过程的日志信息时，将请求标识与日志信息对应存储。

在一种可能的实现方式中，后端框架是在后端框架集合中选择得到后添加到全栈框架中的，后端框架集合至少包括第一后端框架和第二后端框架；

第一后端框架用于控制层、逻辑层和数据层，逻辑层用于至少一个逻辑模块，数据层用于至少一个数据库，控制层用于确定前端发送的请求消息对应的逻辑模块和数据库，逻辑模块用于解析请求消息对应的操作指令，并基于请求消息对应的数据库中存储的数据执行操作指令；

第二后端框架用于控制层和处理层，处理层用于至少一个逻辑模块和至少一个数据库，控制层用于确定前端发送的请求消息对应的逻辑模块，逻辑模块用于解析请求消息对应的操作指令，并基于逻辑模块绑定的数据库中存储的数据执行操作指令。

本申请实施例中，通过全栈框架部署程序代码，全栈框架中集成了前端框架和后端框架，用全栈框架进行前端和后端开发和部署，将前端程序代码与后端程序代码合并后，将合并的程序代码部署于服务器，因为是合并之后进行统一部署的，所以在部署时前端程序代码和后端程序代码部署进程完全一致，并且，前端环境参数和后端环境参数都是基于技术人员输入的目标环境类型在对应关系中查找得到的，所以，前端环境参数和后端环境参数都是与同一环境类型匹配的，故不会出现前端环境参数和后端环境参数不匹配的情况，从而，可以防止由于前后端部署进程不一致或前后端配置的参数不匹配导致web应用运行出现错误。

需要说明的是：上述实施例提供的部署程序代码的装置在部署程序代码时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的部署程序代码的装置与部署程序代码的方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

图20示出了本申请实施例提供的电子设备2000的结构框图。该电子设备可以是上述实施例中的各终端。该电子设备2000可以是便携式移动终端，比如：智能手机、平板电脑、MP3播放器(Moving Picture Experts Group Audio Layer III，动态影像专家压缩标准音频层面3)、MP4(Moving Picture Experts Group Audio Layer IV，动态影像专家压缩标准音频层面4)播放器、笔记本电脑或台式电脑。电子设备2000还可能被称为用户设备、便携式终端、膝上型终端、台式终端等其他名称。

通常，电子设备2000包括有：处理器2001和存储器2002。

处理器2001可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器2001可以采用DSP(Digital Signal Processing，数字信号处理)、FPGA(Field－Programmable Gate Array，现场可编程门阵列)、PLA(Programmable Logic Array，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器2001也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU(Central ProcessingUnit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器2001可以集成有GPU(Graphics Processing Unit，图像处理器)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器2001还可以包括AI(Artificial Intelligence，人工智能)处理器，该AI处理器用于处理有关机器学习的计算操作。

存储器2002可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器2002还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中，存储器2002中的非暂态的计算机可读存储介质用于存储至少一个指令，该至少一个指令用于被处理器2001所执行以实现本申请实施例提供的方法。

在一些实施例中，电子设备2000还可选包括有：外围设备接口2003和至少一个外围设备。处理器2001、存储器2002和外围设备接口2003之间可以通过总线或信号线相连。各个外围设备可以通过总线、信号线或电路板与外围设备接口2003相连。具体地，外围设备包括：射频电路2004、显示屏2005、摄像头组件2006、音频电路2007、定位组件2008和电源2009中的至少一种。

外围设备接口2003可被用于将I/O(Input/Output，输入/输出)相关的至少一个外围设备连接到处理器2001和存储器2002。在一些实施例中，处理器2001、存储器2002和外围设备接口2003被集成在同一芯片或电路板上；在一些其他实施例中，处理器2001、存储器2002和外围设备接口2003中的任意一个或两个可以在单独的芯片或电路板上实现，本实施例对此不加以限定。

射频电路2004用于接收和发射RF(Radio Frequency，射频)信号，也称电磁信号。射频电路2004通过电磁信号与通信网络以及其他通信设备进行通信。射频电路2004将电信号转换为电磁信号进行发送，或者，将接收到的电磁信号转换为电信号。可选地，射频电路2004包括：天线系统、RF收发器、一个或多个放大器、调谐器、振荡器、数字信号处理器、编解码芯片组、用户身份模块卡等等。射频电路2004可以通过至少一种无线通信协议来与其它终端进行通信。该无线通信协议包括但不限于：万维网、城域网、内联网、各代移动通信网络(2G、3G、4G及5G)、无线局域网和/或WiFi(Wireless Fidelity，无线保真)网络。在一些实施例中，射频电路2004还可以包括NFC(Near Field Communication，近距离无线通信)有关的电路，本申请对此不加以限定。

显示屏2005用于显示UI(User Interface，用户界面)。该UI可以包括图形、文本、图标、视频及其它们的任意组合。当显示屏2005是触摸显示屏时，显示屏2005还具有采集在显示屏2005的表面或表面上方的触摸信号的能力。该触摸信号可以作为控制信号输入至处理器2001进行处理。此时，显示屏2005还可以用于提供虚拟按钮和/或虚拟键盘，也称软按钮和/或软键盘。在一些实施例中，显示屏2005可以为一个，设置在电子设备2000的前面板；在另一些实施例中，显示屏2005可以为至少两个，分别设置在电子设备2000的不同表面或呈折叠设计；在另一些实施例中，显示屏2005可以是柔性显示屏，设置在电子设备2000的弯曲表面上或折叠面上。甚至，显示屏2005还可以设置成非矩形的不规则图形，也即异形屏。显示屏2005可以采用LCD(Liquid Crystal Display，液晶显示屏)、OLED(Organic Light-Emitting Diode，有机发光二极管)等材质制备。

摄像头组件2006用于采集图像或视频。可选地，摄像头组件2006包括前置摄像头和后置摄像头。通常，前置摄像头设置在终端的前面板，后置摄像头设置在终端的背面。在一些实施例中，后置摄像头为至少两个，分别为主摄像头、景深摄像头、广角摄像头、长焦摄像头中的任意一种，以实现主摄像头和景深摄像头融合实现背景虚化功能、主摄像头和广角摄像头融合实现全景拍摄以及VR(Virtual Reality，虚拟现实)拍摄功能或者其它融合拍摄功能。在一些实施例中，摄像头组件2006还可以包括闪光灯。闪光灯可以是单色温闪光灯，也可以是双色温闪光灯。双色温闪光灯是指暖光闪光灯和冷光闪光灯的组合，可以用于不同色温下的光线补偿。

音频电路2007可以包括麦克风和扬声器。麦克风用于采集用户及环境的声波，并将声波转换为电信号输入至处理器2001进行处理，或者输入至射频电路2004以实现语音通信。出于立体声采集或降噪的目的，麦克风可以为多个，分别设置在电子设备2000的不同部位。麦克风还可以是阵列麦克风或全向采集型麦克风。扬声器则用于将来自处理器2001或射频电路2004的电信号转换为声波。扬声器可以是传统的薄膜扬声器，也可以是压电陶瓷扬声器。当扬声器是压电陶瓷扬声器时，不仅可以将电信号转换为人类可听见的声波，也可以将电信号转换为人类听不见的声波以进行测距等用途。在一些实施例中，音频电路2007还可以包括耳机插孔。

定位组件2008用于定位电子设备2000的当前地理位置，以实现导航或LBS(Location Based Service，基于位置的服务)。定位组件2008可以是基于GPS(GlobalPositioning System，全球定位系统)或北斗系统的定位组件。

电源2009用于为电子设备2000中的各个组件进行供电。电源2009可以是交流电、直流电、一次性电池或可充电电池。当电源2009包括可充电电池时，该可充电电池可以是有线充电电池或无线充电电池。有线充电电池是通过有线线路充电的电池，无线充电电池是通过无线线圈充电的电池。该可充电电池还可以用于支持快充技术。

本领域技术人员可以理解，图20中示出的结构并不构成对电子设备2000的限定，可以包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。

需要说明的是，本申请所涉及的信息(包括但不限于用户设备信息、用户个人信息等)、数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)以及信号(包括但不限于用户终端与其他设备之间传输的信号等)，均为经用户授权或者经过各方充分授权的，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上仅为本申请的部分可能的实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种部署程序代码的方法，其特征在于，所述方法包括：

在目标应用对应的全栈框架中，获取代码生成插件、代码部署插件、前端框架和后端框架，并获取输入的目标环境类型；

通过所述代码生成插件，基于环境类型与前端环境参数的对应关系，确定所述目标环境类型对应的目标前端环境参数，基于环境类型与后端环境参数的对应关系，确定所述目标环境类型对应的目标后端环境参数；

通过所述代码生成插件，基于所述前端框架和所述目标前端环境参数生成前端程序代码，基于所述后端框架和所述目标后端环境参数生成后端程序代码；

通过所述代码部署插件，对所述前端程序代码和所述后端程序代码进行合并，将合并后的程序代码部署至服务器。

2.根据权利要求1所述的方法，其特征在于，所述环境类型与前端环境参数的对应关系记录于所述前端框架中；

所述环境类型与后端环境参数的对应关系记录于所述后端框架中。

3.根据权利要求1所述的方法，其特征在于，所述基于所述前端框架和所述目标前端环境参数生成前端程序代码，包括：

获取所述前端框架对应的依赖函数；

将所述前端框架对应的依赖函数，添加到所述前端框架中，得到前端初始程序代码；

基于所述目标前端环境参数，对所述前端初始程序代码进行编译，生成前端程序代码。

4.根据权利要求1所述的方法，其特征在于，所述基于所述后端框架和所述目标后端环境参数生成后端程序代码，包括：

获取所述后端框架对应的依赖函数；

将所述后端框架对应的依赖函数，添加到所述后端框架中，得到后端初始程序代码；

对所述后端初始程序代码加载所述目标后端环境参数，生成后端程序代码。

5.根据权利要求1所述的方法，其特征在于，所述对所述前端程序代码和所述后端程序代码进行合并，将合并后的程序代码部署至服务器，包括：

将所述前端程序代码，添加到所述后端程序代码的主文件夹下的指定文件夹中；

将添加了所述前端程序代码后的后端程序代码，部署至服务器。

6.根据权利要求1-5任一项所述的方法，其特征在于，所述后端框架包括请求日志插件，所述请求日志插件用于当接收前端发送的请求消息，为所述请求消息分配请求标识，在对所述请求消息进行处理后存储处理过程的日志信息时，将所述请求标识与所述日志信息对应存储。

7.根据权利要求1-5任一项所述的方法，其特征在于，所述后端框架是在后端框架集合中选择得到后添加到所述全栈框架中的，所述后端框架集合至少包括第一后端框架和第二后端框架；

所述第一后端框架包括控制层、逻辑层和数据层，所述逻辑层包括至少一个逻辑模块，所述数据层包括至少一个数据库，所述控制层用于确定前端发送的请求消息对应的逻辑模块和数据库，所述逻辑模块用于解析所述请求消息对应的操作指令，并基于所述请求消息对应的数据库中存储的数据执行所述操作指令；

所述第二后端框架包括所述控制层和处理层，所述处理层包括至少一个逻辑模块和至少一个数据库，所述控制层用于确定前端发送的请求消息对应的逻辑模块，所述逻辑模块用于解析所述请求消息对应的操作指令，并基于所述逻辑模块绑定的数据库中存储的数据执行所述操作指令。

8.一种部署程序代码的装置，其特征在于，所述装置包括：

获取模块，用于在目标应用对应的全栈框架中，获取代码生成插件、代码部署插件、前端框架和后端框架，并获取输入的目标环境类型；

确定模块，用于通过所述代码生成插件，基于环境类型与前端环境参数的对应关系，确定所述目标环境类型对应的目标前端环境参数，基于环境类型与后端环境参数的对应关系，确定所述目标环境类型对应的目标后端环境参数；

生成模块，用于通过所述代码生成插件，基于所述前端框架和所述目标前端环境参数生成前端程序代码，基于所述后端框架和所述目标后端环境参数生成后端程序代码；

部署模块，用于通过所述代码部署插件，对所述前端程序代码和所述后端程序代码进行合并，将合并后的程序代码部署至服务器。

9.一种计算机设备，其特征在于，所述计算机设备包括处理器和存储器，所述存储器中存储有至少一条指令，所述至少一条指令由所述处理器加载并执行以实现如权利要求1至权利要求7任一项所述的部署程序代码的方法所执行的操作。

10.一种计算机可读存储介质，其特征在于，所述存储介质中存储有至少一条指令，所述至少一条指令由处理器加载并执行以实现如权利要求1至权利要求7任一项所述的部署程序代码的方法所执行的操作。