代码部署方法及装置与流程

本申请涉及软件开发技术领域，尤其涉及一种代码部署方法及装置。

背景技术：

目前，业务系统根据实际业务及需求的发展，会包含一个或多个存在同质化业务需求的子系统。相关技术中，针对同质化的业务，一般需要分别为业务系统下的每一子系统部署一套相应的实现代码，由于需要针对同一业务系统下的各子系统开发和部署多套代码，造成代码开发成本的上升，且不利于代码的后续维护。

技术实现要素：

有鉴于此，本申请提供一种代码部署方法及装置。

为实现上述目的，本申请提供技术方案如下：

根据本申请的第一方面，提出了一种代码部署方法，包括：

获得业务系统下的目标子系统对应的环境标识；

基于配置文件，确定与所述环境标识对应的代码模块；

从所述业务系统对应的原始代码文件中，抽取与确定的所述代码模块对应的目标代码文件；

将所述目标代码文件安装到所述目标子系统。

根据本申请的第二方面，提出了一种代码部署装置，包括：

获得单元，用于获得业务系统下的目标子系统对应的环境标识；

确定单元，用于基于配置文件，确定与所述环境标识对应的代码模块；

抽取单元，用于从所述业务系统对应的原始代码文件中，抽取与确定的所述代码模块对应的目标代码文件；

安装单元，用于将所述目标代码文件安装到所述目标子系统。

由以上技术方案可见，在业务系统包括一个或多个子系统的情况下，在部署代码的过程中，本申请实施例通过获得待部署代码的目标子系统的环境标识，并基于配置文件，确定所述环境标识对应的代码模块；接着，从所述业务系统对应的原始代码文件中，抽取与确定的所述代码模块对应的目标代码文件；最终，将所述目标代码文件安装到所述目标子系统上。可见，本申请实施例针对同一个业务系统，开发与该业务系统对应的一套原始代码文件，在部署代码时，根据环境标识从上述原始代码文件抽取每一子系统所需要部署的目标代码文件，以完成部署。本申请实施例通过开发一套原始代码文件，即可实现在多个子系统分别部署代码的目的，降低代码开发成本。并且后续仅需要维护一套代码，而不需要针对每一子系统分别维护一套代码，在一定程度上提升代码的维护效率。

附图说明

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

图2是本申请一示例性实施例提供的一种代码框架的结构示意图；

图3是本申请一示例性实施例提供的一种代码部署方法的场景图；

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

图5是本申请一示例性实施例提供的一种代码部署装置的框图。

具体实施方式

通常，根据业务系统所需实现的各种功能，需要开发相应的功能实现代码并部署到该业务系统上。例如，对于一种互联网金融平台，其需要实现的功能(或业务)可包括：会员、账务、资产等，需要分别开发相应功能的实现代码。当前，随着各类业务系统的业务发展，会产生一个或多个存在同质化业务需求的子业务系统(以下简称为“子系统”)，所谓“同质化”是指这些子业务系统在某些业务上存在一些共性或具备近似的实现过程。例如，对于一种互联网金融平台，可能随着业务发展，业务会分布在多个域(如：主站、国际、网商等)，其中每个“域”对应于一个子系统。在相关技术中，针对业务系统中某一种同质化的业务，一般需要分别为业务系统下的每一子系统部署一套相应的实现代码，例如：若互联网金融平台的业务分布在主站、国际、网商等多个域，则针对“会员”这一业务，需要分别在主站、国际、网商等多个域部署一套用于实现各个域的“会员”业务的实现代码。可见，随着子系统数量的增加，开发者需要针对同一业务系统下的各子系统开发和部署多套代码，这在一定程度上造成代码开发成本的上升，并且，后期需要维护多套代码，导致代码维护过程耗时耗力。为解决上述问题，提出了本申请实施例的如下方案。

图1是本申请一示例性实施例提供的一种代码部署方法的流程图，参图1所示，本实施例中，该代码部署方法可以应用在用于将代码部署到各个子系统上的电子设备(该设备可安装有相应的代码部署工具)上，该代码部署方法包括下述步骤101～104，其中：

在步骤101中，获得业务系统下的目标子系统对应的环境标识。

其中，预先为业务系统下的每一个子系统分别定义一个环境标识，该环境标识在所述业务系统中是唯一的，并用于标识每个子系统。例如，对于某一互联网金融平台，若包括子系统a、b，则可以定义子系统a的环境标识为“xxx”，定义子系统b的环境标识为“yyy”。本申请实施例中，上述“目标子系统”为需要部署代码的子系统。

在将代码部署到目标子系统之前，需要针对业务系统按照预设的代码框架开发一套原始代码文件，其中，所述原始代码文件可包含所述业务系统下的各个子系统所需部署的代码文件。关于原始代码文件所采用的代码框架，将在下文进行详细介绍。

本申请一实施例中，所述步骤101可具体通过下述过程来实现：

在代码打包时，从标识传入命令中读取目标子系统对应的环境标识。

例如，开发者可以通过软件配置管理(softwareconfigurationmanagement，scm)工具(如：maven)发起打包命令，如：mvnpackage。其中，在打包时，可以通过标识传入命令，传入所需部署的子系统对应的环境标识app，标识传入命令例如为：mvn–dapp＝xxx。当然，在可行的其他实施例中，所述环境标识也可以被携带在代码打包命令中。

在步骤102中，基于配置文件，确定与所述环境标识对应的代码模块。

本申请实施例中，对于业务系统下各个子系统而言，其实现代码的差异性主要体现在：

1、各子系统所依赖的文件包(如：jar包等)存在差异。例如：不同子系统依赖于不同版本的jar包。

2、所需实现的接口及实现接口过程中所采用的模型存在差异。例如：不同子系统的“会员接口”返回的会员id不一致，“网商子系统”返回的会员id为：iproleid，“国际子系统”返回的会员id为：userid。

虽然，各个子系统在代码实现上存在上述差异，但由于存在同质化的业务需求，各个子系统总体的业务实现流程相似或基本一致。

鉴于各个子系统总体的业务实现流程基本一致，本申请实施例中，开发者开发出一套可以被多个子系统所公用的代码框架，开发者可以依据这一代码框架编写原始代码文件。如图2所示，该代码框架按照实现功能可以划分成多个功能层，每一功能层还可以包括一个或多个组件(component)，其中，每个组件可以代表一个代码模块。举例而言，功能层可包括：test层、core层、service层等。其中，各个组件之间可以存在一定的依赖关系(图中箭头表示依赖和被依赖的关系)。本申请实施例中，所述代码框架可以为java代码框架等。

本申请一实施例中，所述代码框架可包括adapter层10和一个或多个integration层，每一个子系统对应于一个integration层，以通过该integration层中的代码文件来实现相应子系统的业务。在示例性的实施例中，假设某业务系统下包含子系统a、b，则子系统a可对应于integration层21，子系统b可对应于integration层22。本文为便于描述，可将代码框架中除adapter层及integration层之外的其余功能层定义为“公共功能层”，另外，将存在于integration层的代码文件定义为“integration层代码文件”，将存在于adapter层的代码文件定义为“adapter层代码文件”，将存在于公共功能层的代码文件定义为“公共功能层代码文件”。

本申请实施例中，所述adapter层代码文件用于定义所述目标子系统使用的对象，所述integration层代码文件用于按照所述目标子系统的业务逻辑实现所述对象。所述对象包括：接口interface、和/或模型、和/或接口interface中包含的入参和出参。其中，所述模型是指入参和出参所使用的对象，例如：接口为：“custview”，其对应的入参是：“vcauthorityscenerequest.java”，出参是：“vcauthorityrulecheckresult.java”，则该接口所使用的模型可包括：“vcauthorityrulecheckview.java”，“authorityrulecheckclient.java”，等等。

举例而言：

在adapter层代码文件(如pom.xml文件)中，可为子系统a定义接口interface1，为子系统b定义接口interface2，其中：定义接口的代码格式例如为：

[修饰符]interface接口名[extends父接口名列表]{

[public][static][final]常量；

[public][abstract]方法；

}

在adapter层定义上述接口后，可在子系统a对应的integration层21，通过代码文件实现上述接口interface1；可在子系统b对应的integration层22，通过代码文件实现上述接口interface2。例如，在类中实现接口可以使用关键字implements，其基本格式如下：

[修饰符]class<类名>[extends父类名][implements接口列表]{

}

本申请实施例中，所述adapter层代码文件定义的对象可以为各个子系统通用的对象(如接口interface、和/或模型、和/或参数等)。从而可以将通用的对象提供给所述代码框架中的其他各功能层来调用。例如，不同子系统的“会员接口”返回的会员id不一致，“网商子系统”返回的会员id为：iproleid，“国际子系统”返回的会员id为：customerid。在adapter层，可定义统一的会员id为userid。

在adapter层，若为不同子系统定义通用接口及通用接口使用的通用模型时，在各个子系统对应的integration层，可以采用子系统所独有的实现逻辑来实现上述通用接口的功能。这样，代码框架中的其它代码模块只需要感知或调用userid即可，这在一定程度上可以简化代码。

本申请实施例中，可以预先通过配置文件(如pom.xml)来定义不同子系统的依赖文件包及代码模块，所述依赖文件包用以构建所述代码模块。所述配置文件中的代码内容例如为：

假设子系统a的环境标识为“ifcvoucherfront”，系统b的环境标识为“fcvoucherfront”，则，基于以上示例的配置文件内容可以看出：

当环境标识app为：“ifcvoucherfront”时，可通过“<dependency>”和“</dependency>”之间的代码内容确定子系统a需要使用的依赖文件包的目录、名称、版本号等信息，可通过“<modules>”和“</modules>”之间的代码内容确定子系统a需要利用上述依赖文件包构建的代码模块，如：app/common/service/adaptor/pom-ap.xml、app/common/service/integration/ap。当环境标识app为：“fcvoucherfront”时，可通过“<dependency>”和“</dependency>”之间的代码内容确定子系统b需要使用的依赖文件包的目录、名称、版本号等信息，可通过“<modules>”和“</modules>”之间的代码内容确定子系统b需要利用上述依赖文件包构建的代码模块，如：app/common/service/adaptor/pom-bk.xml、app/common/service/integration/bk。

在步骤103中，从所述业务系统对应的原始代码文件中，抽取与确定的所述代码模块对应的目标代码文件。

本申请一实施例中，所述步骤103可以具体包括：

步骤1031：从原始代码文件中，抽取与所述环境标识对应的adapter层代码文件和公共功能层代码文件。

承上述例子，当环境标识app为：“ifcvoucherfront”时，需要抽取的adapter层代码文件为：adaptor/pom-ap.xml(可在pom-ap.xml中定义子系统a使用的各个对象)；当环境标识app为：“fcvoucherfront”时，需要抽取的adapter层代码文件为：adaptor/pom-bk.xml(可在pom-bk.xml中定义子系统b使用的各个对象)。

步骤1032：从原始代码文件中，抽取与所述环境标识对应的integration层代码文件。

承上述例子，当环境标识app为：“ifcvoucherfront”时，需要抽取的adapter层代码文件为：存在于adapter层21下的代码文件；当环境标识app为：“fcvoucherfront”时，需要抽取的adapter层代码文件为：存在于adapter层22下的代码文件。

步骤1033：将抽取的adapter层代码文件、公共功能层代码文件和integration层代码文件打包成目标代码文件。

在步骤104中，将所述目标代码文件安装到所述目标子系统。

本申请实施例中，对于不同的子系统而言，在部署代码时，根据业务实现的差异，相应地从原始代码文件中抽取出与自身业务相匹配的一些代码模块进行代码部署。从所述业务系统对应的原始代码文件中，抽取与确定的所述代码模块对应的目标代码文后，将所述目标代码文件安装到所述目标子系统前，所述方法还可以包括：

获得与所述环境标识对应的测试用例，并利用所述测试用例对所述目标代码文件进行测试。

鉴于各子系统的差异性，可以分别为每一个子系统编写测试用例，并将测试用例通过环境标识进行标记，从而在测试过程中，只需要输入环境标识便可以自动获取到相应的测试用例并完成测试，测试效率较高，无需人工查找测试用例，同时便于管理测试用例。

图3是本申请一示例性实施例提供的一种代码部署方法的场景图，如图3所示，开发者通过上述通用的代码框架并结合各个子系统的业务差异，编写出原始代码文件并上传到代码库中。当需要将代码部署到业务系统下各个子系统时，可以在打包时传入需要部署代码的子系统的环境标识app，使得代码部署设备从上述代码库中抽取出与该环境标识app相匹配的目标代码文件，并部署到指定的子系统设备(服务器)上。

本申请实施例中，在业务系统包括一个或多个子系统(如：子系统a、b)的情况下，在部署代码的过程中，本申请实施例通过获得待部署代码的目标子系统的环境标识(如：ifcvoucherfront)，并基于配置文件pom.xml，确定所述环境标识对应的代码模块；接着，从所述业务系统对应的原始代码文件中，抽取与确定的所述代码模块对应的目标代码文件；最终，将所述目标代码文件安装到所述目标子系统上。可见，本申请实施例针对同一个业务系统，开发与该业务系统对应的一套原始代码文件，在部署代码时，根据环境标识从上述原始代码文件抽取每一子系统所需要部署的目标代码文件，以完成部署。本申请实施例采用通用的代码框架(如图2所示)开发一套原始代码文件，即可实现在多个子系统分别部署代码的目的，降低代码开发成本。同时在后续维护代码时，只需要维护一套原始代码文件，而无需针对每一个子系统分别维护一套代码文件，大大提升代码的后续维护效率。此外，当业务系统不断衍生出新的子系统时，仅需要在上述代码框架中，增加相应的integration层代码文件，即可实现新增子系统的代码部署，增强了业务系统的扩展兼容性。

图4是本申请一示例性实施例提供的一种电子设备的结构示意图。该电子设备可以代码部署设备(如安装有代码管理工具的设备)，请参考图4，在硬件层面，该电子设备包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成用于代码部署装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图5，在本申请一实施例中，一种代码部署装置，包括：

获得单元201，用于获得业务系统下的目标子系统对应的环境标识；

确定单元202，用于基于配置文件，确定与所述环境标识对应的代码模块；

抽取单元203，用于从所述业务系统对应的原始代码文件中，抽取与确定的所述代码模块对应的目标代码文件；

安装单元204，用于将所述目标代码文件安装到所述目标子系统。

本申请一实施例中，所述代码模块包括adapter层代码文件和integration层代码文件，所述adapter层代码文件用于定义所述目标子系统使用的对象，所述integration层代码文件用于按照所述目标子系统的业务逻辑实现所述对象。

本申请一实施例中，所述adapter层代码文件定义的对象为各个子系统通用的对象。

本申请一实施例中，所述对象包括接口、和/或模型、和/或接口中包含的入参和出参。

本申请一实施例中，所述确定单元202具体用于：

基于配置文件，确定与所述环境标识对应的依赖文件包和代码模块，所述依赖文件包用以构建所述代码模块。

本申请一实施例中，所述抽取单元203可以具体包括：

第一抽取子单元，用于从原始代码文件中，抽取与所述环境标识对应的adapter层代码文件和公共功能层代码文件；所述原始代码文件包含所述业务系统下的各个子系统的代码文件；

第二抽取子单元，用于从原始代码文件中，抽取与所述环境标识对应的integration层代码文件；

打包单元，用于将抽取的adapter层代码文件、公共功能层代码文件和integration层代码文件打包成目标代码文件。

本申请一实施例中，所述获得单元201可以具体用于：

在代码打包时，从标识传入命令中读取目标子系统对应的环境标识。

本申请一实施例中，所述装置还可以包括：

测试单元，用于获得与所述环境标识对应的测试用例，并利用所述测试用例对所述目标代码文件进行测试。

需说明的是，上述装置实施例和上述方法实施例，在不相违背的前提下，可以互为补充。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

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