软件包处理方法、装置、设备及介质

技术领域

本公开涉及计算机技术领域，尤其涉及一种软件包处理方法、装置、设备及介质。

背景技术

随着计算机技术的发展，如何开发业务系统成为一个重要的问题。

现阶段，在业务系统的开发过程中，程序开发人员可以将开发完成后，将本次开发完成的资源对象打包发送至资源库中，导致代码打包过程都是各自为战的，难于对资源对象进行统一管理。

发明内容

为了解决上述技术问题或者至少部分地解决上述技术问题，本公开提供了一种软件包处理方法、装置、设备及介质。

第一方面，本公开提供了一种软件包处理方法，包括：

在目标业务系统满足打包条件的情况下，从目标业务系统的多个管理文件中查找打包功能对应的目标管理文件，目标管理文件内存储有关联资源目录；

拉取关联资源目录涉及的关联资源对象，关联资源对象是多个管理文件中除目标管理文件之外的其他管理文件所管理的资源对象；

基于关联资源对象，生成目标业务系统的系统软件包。

第二方面，本公开提供了一种软件包处理装置，包括：

文件查找模块，配置为在目标业务系统满足打包条件的情况下，从目标业务系统的多个管理文件中查找打包功能对应的目标管理文件，目标管理文件内存储有关联资源目录；

资源对象拉取模块，配置为拉取关联资源目录涉及的关联资源对象，关联资源对象是多个管理文件中除目标管理文件之外的其他管理文件所管理的资源对象；

软件包生成模块，配置为基于关联资源对象，生成目标业务系统的系统软件包。

第三方面，本公开提供了一种软件包处理设备，包括：

处理器；

存储器，用于存储可执行指令；

其中，处理器用于从存储器中读取可执行指令，并执行可执行指令以实现第一方面的软件包处理方法。

第四方面，本公开提供了一种计算机可读存储介质，该存储介质存储有计算机程序，当计算机程序被处理器执行时，使得处理器实现第一方面的软件包处理方法。

本公开实施例提供的技术方案与现有技术相比具有如下优点：

本公开实施例的软件包处理方法、装置、设备及介质，能够在目标业务系统满足打包条件时，确定目标业务系统的打包功能对应的目标管理文件，利用该目标管理文件内的关联资源目录拉取关联资源对象生成目标业务系统的系统软件包。由于关联资源对象是目标业务系统中除目标管理文件之外的其他管理文件所管理的资源对象，本公开实施例基于业务系统的多个管理文件对关联资源对象进行打包，能够将以目标业务系统的资源对象打包生成一个系统软件包，从而实现了对目标业务系统的资源对象进行统一管理。

附图说明

结合附图并参考以下具体实施方式，本公开各实施例的上述和其他特征、优点及方面将变得更加明显。贯穿附图中，相同或相似的附图标记表示相同或相似的元素。应当理解附图是示意性的，原件和元素不一定按照比例绘制。

图1示出了一种相关技术中的资源对象的开发流程示意图；

图2示出了本公开实施例提供的一种资源对象的开发流程示意图；

图3示出了本公开实施例提供的一种示例性的目标业务系统的管理文件集合的示意图；

图4示出了本公开实施例提供的一种软件包处理系统的结构示意图；

图5示出了本公开实施例提供的另一种软件包处理系统的结构示意图；

图6示出了本公开实施例提供的一种软件包处理方法的流程示意图；

图7示出了本公开实施例提供的另一种软件包处理方法的流程示意图；

图8示出了本公开实施例提供的又一种软件包处理方法的流程示意图；

图9示出了本公开实施例提供的再一种软件包处理方法的流程示意图；

图10示出了本公开实施例提供的再一种软件包处理方法的流程示意图；

图11示出了本公开实施例提供的再一种软件包处理方法的流程示意图；

图12示出了本公开实施例提供的一种软件包处理装置的结构示意图；

图13示出了本公开实施例提供的一种软件包处理设备的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的实施例。虽然附图中显示了本公开的某些实施例，然而应当理解的是，本公开可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是，本公开的附图及实施例仅用于示例性作用，并非用于限制本公开的保护范围。

应当理解，本公开的方法实施方式中记载的各个步骤可以按照不同的顺序执行，和/或并行执行。此外，方法实施方式可以包括附加的步骤和/或省略执行示出的步骤。本公开的范围在此方面不受限制。

本文使用的术语“包括”及其变形是开放性包括，即“包括但不限于”。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”；术语“另一实施例”表示“至少一个另外的实施例”；术语“一些实施例”表示“至少一些实施例”。其他术语的相关定义将在下文描述中给出。

需要注意，本公开中提及的“第一”、“第二”等概念仅用于对不同的装置、模块或单元进行区分，并非用于限定这些装置、模块或单元所执行的功能的顺序或者相互依存关系。

需要注意，本公开中提及的“一个”、“多个”的修饰是示意性而非限制性的，本领域技术人员应当理解，除非在上下文另有明确指出，否则应该理解为“一个或多个”。

本公开实施方式中的多个装置之间所交互的消息或者信息的名称仅用于说明性的目的，而并不是用于对这些消息或信息的范围进行限制。

现阶段，随着业务平台的发展，业务平台已经不满足单一业务场景的发展需求，进而朝着多业务场景的方向发展。在多业务场景中，可以按照不同业务场景，将业务平台划分为多个业务系统。比如，对于推荐平台，其可以包括“猜你喜欢”推荐系统、“看了又看”推荐系统等。

在业务系统的发展过程中，程序开发人员可以对业务系统的任务资源对象进行开发。接下来，在开始介绍本公开实施例的软件包处理方案之前，下述部分先对资源对象开发技术进行简单说明。

图1示出了一种相关技术中的资源对象的开发流程示意图。

如图1所示，在该相关技术中，在对多资源对象进行开发时，多资源对象的开发流程主要包括下述步骤。

S110，手动创建一个资源对象。具体地，开发人员可以手动创建一个资源对象，比如Job资源。

S120，资源定义。具体地，开发人员可以对所创建的资源对象进行定义。比如，在该过程中，可以定义资源对象的键(key)值、组(group) 值以及类(class)值。

S130，编辑资源对象。

S140，选择资源对象的模板类型。

S150，编写资源的脚本。

S160，调试资源对象。

S170，判断该资源对象是否开发完成。如果开发完成，则继续执行S180来对开发完成的资源对象进行导出迁移至资源库。如果未完成该资源对象的开发，则重复执行S130至S170来对代码进行反复调试，直到该资源对象完成开发。以及，在该资源对象已完成开发之后，如果还需要继续开发其他资源对象，则重复执行S110至S170，直至完成对本次开发过程中所有待开发资源对象的开发。

在该种相关技术中，需要对多个资源对象进行逐个开发，如果资源对象数量较多，则需要多次重复上述步骤，开发效率较低。并且资源对象的管理、迁移过程非常麻烦，且容易遗漏。

为了优化资源开发流程，图2示出了本公开实施例提供的一种资源对象的开发流程示意图。

如图2所示，本公开实施例的资源对象的开发流程可以包括如下步骤。

S210，基于管理文件创建N个资源对象，其中N可以是大于或等于1的整数。

在一个实施例中，管理文件可以是诸如repo等能够对业务管理系统的各项功能或者各资源对象进行管理的文件。

在一个实施例中，在S210中，可以在管理文件中同时添加N个资源目录的方式来一次性创建N个资源对象。示例性地，以管理文件为 repo文件为例，可以通过在repo中创建Job.yaml格式的资源目录的形式，实现对N个Job资源的一次性配置。

S220，调试资源对象。具体地，可以通过管理文件将N个资源对象的代码拉取到编程人员的客户端之后，编程人员可以在S220中对N 个资源对象的代码进行调试。

S230，判断是否完成对N个资源对象的开发。若未完成N个资源的开发，则重复执行S220来对资源对象进行开发调试，直到完成N个资源对象的开发之后，继续执行S240。

S240，打包并存放至目标资源库。具体的，可以利用管理文件对开发完成的N个资源对象进行打包，并将得到的软件包发布至目标资源库，从而实现对N个资源对象的一次性配置。

在一个实施例中，编程人员在完成N个资源对象的开发之后，可以将N个资源对象的源程序文件提交至代码库。然后由打包管理平台从代码库中获取开发完成的源程序文件，将其打包后发送至目标资源库。示例性地，可以是编程人员将N个资源对象的源程序文件提交至 gitlab库(即一种代码管理库)，然后由打包管理平台从gitlab库提取N 个资源代码的源程序文件，对其进行持续集成(Continuous Integration， CI)打包后，得到一个镜像包，并将该镜像包存储至Flowengine hub (即一种资源库)。

相对于上述相关技术，本公开实施例利用管理文件可以能够一次性对多个Job资源进行配置和开发，提高了资源对象的开发效率。并且，利用管理文件，可以对多个资源对象的代码拉取、软件打包、软件发布等工作进行统一管理。

在初步介绍了上述资源对象开发技术之后，接下来本公开实施例将对软件包开发方案展开具体说明。

申请人通过研究发现，现有的软件开发都是各自为战的，即程序开发人员在对各资源对象完成发开后，会对其进行打包并放入资源库，导致资源对象的开发过程难于统一管理。

基于此，申请人提出一种软件包处理方案，可以应用于针对业务系统的开发场景中。本公开实施例可以基于业务系统的多个管理文件对关联资源对象进行打包，由于关联资源对象是目标业务系统中除目标管理文件之外的其他管理文件所管理的资源对象，相应地，本公开实施例能够将以目标业务系统所管理的资源对象打包生成一个系统软件包，从而实现了对资源对象进行统一管理。

在开始介绍本公开实施例提供的方案之前，下述部分先对本公开涉及的技术术语展开具体说明。

软件包，是指具有特定的功能，用来完成特定任务的一个程序或一组程序。比如，可以是实现某个功能的程序代码的集合，或者，可以是实现某部分功能的程序代码的集合。相应地，可以通过一个或者多个软件包，来实现对目标业务系统、目标业务系统的某项功能或者目标业务系统的某个资源对象的更新或者安装。

具体地，可以将某一待打包对象的源程序文件经过编译、打包之后，生成该待打包对象的软件包。其中，编译用于将用户编写的源代码文件编译为机器可识别的目标代码文件。

其中，源代码文件是指用汇编语言和/或高级语言写出来的、未经过编译的代码以及软件包的依赖资源。其中，依赖资源可以是执行编译任务时所需要的数据文件，例如编译资源可以包括图片、视频、文本、代码等，对依赖资源的具体类型不作限定。目标代码文件是指源代码经过编译程序产生的、能被待部署节点识别的代码。其中，待部署节点是需要部署目标业务系统的物理服务器、虚拟服务器或者容器等部署节点。

持续集成(Continuous Integration，CI)，即一种能够在代码提交之后能够自动化的构建、部署、测试，确保提交的代码没有错误或及早发现提交代码中的错误。

在本公开的一些实施例中，本公开实施例提供了一种业务系统，其可以是对应于业务平台的某一个业务场景的系统，一个业务系统能够支撑业务平台的一个场景方案。

具体地，业务系统可以包括多个功能项目，一个功能项目能够实现场景方案中的一个或者多个功能。在本公开实施例中，为了便于对目标业务系统进行统一开放管理，除了业务系统原有的功能项目之外，业务系统还包括打包功能项目。

需要说明的是，在部署节点部署业务系统时，打包功能项目可以部署至部署节点或者不部署至部署节点，对此不作限定。

在本公开的一些实施例中，为了便于对业务系统进行统一管理，本申请实施例还提供了一种业务系统的管理文件集合。

具体地，管理文件集合可以包括业务系统的各功能项目的管理文件。每一功能项目的管理文件能够对该功能项目进行软件开发和软件管理。

具体地，图3是本公开实施例提供的一种目标业务系统的管理文件集合的示意图。如图3所示，目标业务系统的管理文件集合可以包括目标业务系统的各功能项目的管理文件。比如，若目标业务系统包括功能A-功能F以及打包功能。则目标业务系统的管理文件集合内包括功能A-功能F各自的管理文件以及打包功能对应的目标管理文件。示例性地，若管理文件为repo，以咨询推荐业务系统为例，其可以包括咨询推荐业务系统的过滤功能的repo、数据插入组件功能的repo、超循环数据流功能的repo、自然语言功能的repo等等。其中，功能A- 功能F可以是目标业务系统的业务功能。

其中，对于功能A-功能F中任一功能X的管理文件，其可以对该功能下的多个资源对象进行管理，比如，对于任一功能X对应的管理文件，可以存储有该任一功能X所管理的资源对象的资源目录。又或者，还可以包括针对该任一功能X的打包脚本。其中，为了便于表述，本公开实施例的下述部分将除打包功能之外的其他功能的资源对象称为关联资源对象。在一个示例中，在本公开实施例中，可以先利用上述功能A-功能F中各项功能的管理文件先打包得到各项功能的项目软件包，再基于功能A-功能F的项目软件包打包得到目标业务系统的系统软件包。

打包功能对应的目标管理文件可以与功能A-功能F的管理文件中的资源对象进行关联，从而可以在需要生成目标业务系统的系统软件包时，能够调取功能A-功能F的各资源对象生成目标业务系统的文件集合。

在一个实施例中，打包功能对应的目标管理文件可以包括：关联资源目录。可选地，除了关联资源目录之外还可以待打包资源目录和/ 或其他文件。

接下来，针对上述关联资源目录、待打包资源目录、其他文件分别说明如下。

对于关联资源目录。

用于记录生成系统软件包时所需要调用的打包功能之外的关联资源对象。具体地，关联资源目录中可以包括一个或者多个资源目录，一个资源目录对应一个关联资源对象。示例性地，关联资源对象可以包括离线任务资源、流式任务资源和在线功能资源中的至少一类，其中，离线任务资源可以称为离线Job，流式任务资源可以称为流式Job，在线功能资源可以称为在线Function。需要说明的是，在本公开实施例中，关联资源目录可以包括各资源目录的目录文件，或者关联资源目录可以包括各资源目录的目录内容，或者，可以包括各资源目录的目录文件索引/链接，对此不作具体限定。

其中，一个资源目录可以包括至少一个目录项，每一目录项包括该目录项所属资源目录所对应的关联资源对象的至少部分的定义信息，从而使得通过一个资源目录的至少一个目录项中的定义信息可以唯一确定一个资源对象。可选地，为了便于开发人员开发，开发人员可以修改原有资源对象的资源目录或者添加新的资源目录的方式来修改 repo文件。其中，资源对象的资源目录的格式可以是预设设置的，从而当需要生成新的资源目录时，可以在资源模板内对资源进行定义，即可生成所定义资源的资源目录。可选地，资源目录可以是.yaml文件。

示例性地，离线Job的资源目录可以包括该资源对象的key、group、 class、版本、资源名、离线Job的功能描述信息、模板类型、代码文件、创建者信息、离线Job所需参数、产出配置信息、依赖资源信息等中的至少一者。其中，模板类型可以是DAG、SHELL、PYTHON3、JAVA 等中的一个或者多个。需要说明的是，还可以根据开发人员的定义需求，选择新的待定义内容，对此不作限定。

示例性地，流式Job的资源目录可以包括该资源对象的key、group、 class、版本、资源名、流式Job的功能描述信息、创建者信息、流式 Job所需参数、依赖资源信息等中的一个或者多个。需要说明的是，还可以根据开发人员的定义需求，选择新的待定义内容，对此不作限定。

示例性地，在线Function的资源目录可以包括该资源对象的key、 group、class、版本、资源名、在线Function的功能描述信息、创建者信息、标签、场景信息等中的一个或者多个。需要说明的是，还可以根据开发人员的定义需求，选择新的待定义内容，对此不作限定。

在介绍了关联资源目录之后，接下来对待打包资源目标进行具体说明。

对于待打包资源目录。

待打包资源目录用于记录生成系统软件包时所需要的待打包资源对象。具体地，待打包资源目录可以包括待打包资源对象的资源目录。需要说明的是，在本公开实施例中，待打包资源目录可以包括待打包资源对象的资源目录的目录文件，待打包资源对象的资源目录的目录内容或者待打包资源对象的资源目录的目录文件的索引/链接，对此不作具体限定。

为了便于说明待打包资源目标，本公开实施例下述部分先对涉及的待打包资源对象展开具体说明。

待打包资源对象可以是目标业务系统的资源对象和/或打包功能自身的资源对象，对此不作限定。相应地，待打包资源目录可以包括目标业务系统的资源对象的资源目录和/或打包功能自身的资源对象的资源目录。

示例性地，待打包资源对象可以包括以下至少一种：

方案(asol)、组件(component)、在线Function、离线Job、流式 Job、各项功能的项目软件包和打包功能所需代码脚本。

在初步介绍完关联资源对象和待打包资源对象之后，申请人对二者之间的关系说明如下：待打包资源对象可以包括目标业务系统除打包功能之外的其他各项功能的项目软件包。对于每一功能的项目软件包，其可以是由该功能的关联资源对象打包得到的。

在详细介绍了待打包资源目录之后，接下来本公开实施例的下述部分将对其他文件展开具体说明。

对于其他文件，其可以包括以下至少一种文件：容器(Docker) 的定义文件、拉取关联资源对象的执行脚本文件、打包的执行脚本文件、出包(meta)的执行脚本文件、软件包处理方法的执行脚本文件。

其中，容器(Docker)的定义文件中可以定义有Docker编译时执行的操作，比如复制自动生成的镜像包(.tar格式的软件包)到镜像里的操作。

其中，打包的执行脚本文件，即利用Docker进行编译以及镜像打包的脚本。

其中，软件包处理方法的执行脚本文件，其可以是.yaml格式的文件，可以是拉取关联资源对象、打包、生成文件包命名等步骤的执行脚本。需要说明的是，在本公开实施例中管理文件中可以有多个相同格式的文件，可选地，可以为多个相同格式的文件设置不同的文件名以对其进行区分。

需要说明的是，其他文件可以包括上述多个文件，或者包括上述多个文件的内容，或者包括上述多个文件的索引/链接，对此不作具体限定。

在一个实施例中，为了便于统一开发和管理，在创建业务系统的新的功能项目时，可以从目标地址拉取管理文件的模板。比如repo模板。开发人员通过对repo模板进行编辑，比如添加该功能的资源对象的资源目标等即可生成该项功能的管理文件。可选地，为了便于开发人员使用，repo模板中资源对象的资源目录内放置有一些示例。

在一个具体地示例中，在创建打包功能的repo文件时，还需要建立打包功能的repo文件与打包功能所属业务系统的其他各项功能的 repo文件之间的关联关系。

比如，可以将其他各项功能的repo文件(即其他各项功能的管理文件)中的资源目录添加至打包功能的repo文件的关联资源目录中(即可以将各项功能的管理文件中的资源目录的内容/文件/索引/链接添加至打包功能对应的目标管理文件的关联资源目录中)。又比如，可以将基于各项功能的repo文件打包得到的各项功能的项目软件包的软件包目录存放至打包功能的repo文件的关联资源目录中。需要说明的是，在关联资源目录中添加资源目录或者软件包目录的方式可以直接是直接添加目录文件、目录文件的链接/索引或者添加目标文件的内容，对具体添加方式不作限定。

在一个实施例中，如果需要建立新的业务逻辑(即新建pipeline)，比如为目标业务系统建立新的业务功能，或者为某一业务功能建立新的资源对象时，可以为新的业务功能建立新的管理文件，以及在新的管理文件中建立新的资源对象的资源目录。需要说明的是，在管理文件中添加资源目录或者软件包目录的方式可以直接是直接添加目录文件、目录文件的索引/链接或者添加目标文件的内容，对具体添加方式不作限定。

现有技术中对业务系统的软件分散在不同的项目组(project group)，从而导致业务系统的软件管理比较分散。而本公开实施例提供业务系统的管理文件集合，能够对同一业务系统的资源对象的代码进行统一管理。

在初步介绍了业务系统以及管理文件之后，接下来对针对业务系统进行开发、管理的软件包处理系统进行说明。

图4示出了本公开实施例提供的一种软件包处理系统的结构示意图。本公开实施例所提供的软件包处理方法可以应用于图3所示的软件包处理系统中。

如图4所示，该软件包处理系统40包括：软件包处理节点41以及目标资源库42。其中，图4中的双向箭头所指向的双方可以进行通信或者数据交互。比如可以利用诸如有线网络、无线网络等进行交互，对此不作具体限定。

软件包处理节点41，其用于对目标业务系统的软件开发过程进行管理和协调。在一些实施例中，软件包处理节点41可以是物理服务器、虚拟服务器或者一段进程。在一个实施例中，软件包处理节点41可以是能够运行Jenkins(一种持续集成应用程序)等具有软件开发管理功能的应用程序的节点。

在一些实施例中，软件包处理节点41内存储有目标业务系统的多个管理文件。其中，各管理文件的内容可以参见本公开实施例上述部分对管理文件的相关说明，在此不再赘述。

目标资源库42，其用于存放软件包处理节点41打包生成的系统软件包。在一些实施例中，目标资源库42可以是物理服务器、虚拟服务器等提供的存储空间。在一个实施例中，目标资源库42可以是github (一种软件管理平台)等数据库。

在一些实施例中，图5示出了本公开实施例提供的另一种软件包处理系统的结构示意图。如图5所示，软件包处理系统40还可以包括目标代码库43。

目标代码库43上可以存储有目标业务系统的各功能项目的代码文件。在一个实施例中，目标代码库43可以是能够运行gitlab(一种软件管理工具)等具有软件包管理功能的应用程序的节点。

目标代码库43可以用于通过软件开发客户端50发送开发人员需要的待开发资源对象的代码文件，以及接收开发人员对待开发资源对象的完成开发后上传的代码文件。具体地，软件开发客户端50可以基于各功能的管理文件，从目标代码库43拉取该功能的待开发资源对象的代码软件，通过在该功能的管理文件中修改或添加待开发资源对象的资源目录以及调试待开发资源对象等方式完成该待开发资源对象的软件开发之后，可以将待开发资源对象的代码文件上传至目标代码库43。

以及，目标代码库43还用于响应于软件包处理节点41的调用，将目标业务系统的各项资源对象的代码文件发送至软件包处理节点41。又或者，可以在检测到开发人员上传新的资源对象的代码文件之后，自动向软件包处理节点41发送目标业务系统的各项资源对象的代码文件。或者定期向软件包处理节点41发送目标业务系统的各项资源对象的代码文件，对此不作具体限定。

在一些实施例中，软件包处理系统40还可以包括打包容器docker，其能够提供统软件包的可部署节点的运行环境，从而使得经过docker 打包后的系统软件包能够在可部署节点运行。

在介绍了软件包处理系统的架构之后，接下来，本公开实施例的下述部分对本公开实施例提供的软件包处理方法、装置、设备以及计算机介质依次展开具体说明。

图6示出了本公开实施例提供的一种软件包处理方法的流程示意图。

在本公开实施例中，软件包处理方法各步骤的执行主体可以是软件包处理节点。其中，软件包处理节点可以是物理服务器、虚拟服务器或者一段进程。在一个实施例中，软件包处理节点可以是能够运行 Jenkins(一种持续集成应用程序)等具有软件开发管理功能应用程序的节点。

如图6所示，该软件包处理方法可以包括如下步骤。

S610，在目标业务系统满足打包条件的情况下，从目标业务系统的多个管理文件中查找打包功能对应的目标管理文件。其中，目标管理文件内存储有关联资源目录。示例性地，可以从如图3示出的文件集合中以目标管理文件的名字查找到目标管理文件。

在一些实施例中，打包条件可以是判断需要生成目标业务系统的系统软件包的条件。

在一个示例中，打包条件可以包括：目标业务系统的资源对象的发生了更新事件。其中，目标业务系统的资源对象可以包括目标业务系统的各功能项目的资源对象，即关联资源对象。

可选地，可以在目标代码库内目标业务系统的各功能的代码发生变更时，确定目标业务系统的资源对象发生了更新事件。

或者，可以在目标业务系统的各功能的管理文件中的资源目录发生变更时，确定目标业务系统的资源对象的发生了更新事件。其中，若软件开发人员对目标业务系统的任一功能的资源对象进行了增加，则也需要在该任一功能的管理文件也相应地增加了新增资源对象的资源目录。又一示例性地，若软件开发人员对目标业务系统的任一功能的资源对象进行了修改，比如进行了版本升级，则也需要在对该资源对象的原有资源目录进行修改。

在另一个示例中，打包条件可以包括：定期对目标业务系统进行打包。相应地，可以在距离上一次打包时刻达到预设时长时，确定达到了打包条件。其中，预设时长可以根据具体场景和实际需求设置，对此不再赘述。

在又一个示例中，打包条件可以是接收到相关人员的打包请求。其中，相关人员可以在开发完成后、或者存在目标业务系统的检测需求或者部署需求时，发起打包请求。比如，可以在需要对可部署节点部署目标业务系统时，为了保证系统的实时性，可以打包得到最新版的系统软件包。

需要说明的是，还可以根据实际的打包需求设置打包条件，对此不作具体限定。

目标管理文件的具体内容可以参见本公开实施例的具体描述，对此不再赘述。

S620，拉取关联资源目录涉及的关联资源对象。其中，关联资源对象是多个管理文件中除目标管理文件之外的其他管理文件所管理的资源对象。

在一些实施例中，关联资源对象可以是目标业务系统中除打包功能之外的其他功能的资源对象。示例性地，继续以图3为例，关联资源对象可以是功能A至功能F的资源对象。比如，可以是功能A-功能 F的管理文件中存在资源目录的资源对象。

在一些实施例中，可以通过关联资源目录中存在的关联资源对象的目录拉取关联资源对象。又或者，可以根据关联资源目录读取其他功能的管理文件，再获取所读取管理文件中的资源目录来拉取资源目标对应的资源对象，即关联资源对象。

需要说明的是，关联资源目录的具体内容可以参见本公开实施例上述部分结合图3的相关内容，在此不再赘述。

S630，基于关联资源对象，生成目标业务系统的系统软件包。

在一些实施例中，系统软件包可以是对目标业务系统内的待打包对象进行打包和编译后得到的系统软件包。其中，系统软件包可以是运行目标业务系统的功能时所需要的代码和依赖文件的打包文件的集合。具体地，对于待打包对象，其可以包括关联资源对象的代码和依赖文件。可选地，待打包对象还可以包括目标业务系统诸如组件等其他资源元素。又或者，待打包对象还可以包括其他需要进行打包的内容，比如打包脚本等。可以根据实际情况和具体需求设置系统软件包的内容，本公开实施例对此不再赘述。

通过系统软件包，可以在可部署节点快速地安装或者删除目标业务系统，实现了系统软件包的即插即拔式部署。

在一些实施例中，S630可以具体包括下述步骤A1。

步骤A1，利用目标容器对关联资源对象进行打包，得到镜像格式的系统软件包。其中，目标容器与系统软件包的可部署节点运行环境相同。可选地，可以利用目标管理文件中的打包脚本，利用目标容器打包得到镜像格式的系统软件包。

需要说明的是，通过该方式得到的镜像格式的系统软件包，可以在各部署节点运行，提高了软件包的部署效率。以及，通过目标容器打包得到镜像格式的系统软件包的方式，由于目标容器与可部署节点运行环境相同，从而保证了本地开发环境、测试环境、线上环境的一致性，从而使得开发完成的镜像格式的系统软件包可以直接迁移镜像或者更新到线上即可。此外，镜像格式的系统软件包还便于持续部署与测试。具体理由如下：通过目标容器打包镜像格式的系统软件包可以消除线上线下的环境差异，保证了目标业务系统生命周期的环境一致性标准化。开发人员使用镜像实现标准开发环境的构建，开发完成后通过封装完整环境和目标业务系统的镜像格式的系统软件包进行迁移，由此，测试和运维人员可以直接部署镜像格式的系统软件包来进行测试和发布，大大简化了持续集成、测试和发布的过程。

对于可部署节点，可部署节点可以是对目标业务系统存在部署需求的服务器。示例性地，可部署节点可以是预先设置的，或者是在相关人员在每次软件开发时指定的。又或者可以是能够从目标资源库获取待部署目标业务系统的节点。其中，可部署节点可以是内部环境的部署节点或者外部环境的部署节点。

在一些实施例中，为了便于对各资源对象进行管理、部署及应用，在S630可以具体包括下述步骤A2和步骤A3。

步骤A2，对多个关联资源对象分别打包，得到多个资源软件包。

在一个示例中，可以以功能为单位对关联资源对象进行打包。比如，可以对属于同一功能的资源对象进行打包，得到一个资源软件包。示例性地，可以依据该功能的repo文件拉取该功能的资源对象，并利用该功能的repo文件中的打包脚本对该功能的资源对象进行打包，得到该功能的功能软件包。比如，继续参见图3，可以利用功能C的管理文件，拉取功能C的资源对象，对其打包后得到功能C对应的资源软件包。

通过该打包方式，可以以功能为单位在目标部署节点对目标业务系统进行部署、更新以及管理，提高了便捷性。

在另一个示例中，可以以资源对象进行打包，比如，可以对各关联资源对象的代码和依赖文件进行编译、打包后得到一个资源软件包。

通过该打包方式，可以以资源对象为单位在目标部署节点对目标业务系统进行部署、更新以及管理，提高了便捷性。

需要说明的是，还可以根据实际场景和具体需求打包生成资源软件包，本公开实施例对此不作限定。

在一个实施例中，可以通过拉取关联资源对象的脚本，以 submodule的方式，拉取关联资源对象并生成资源软件包。

步骤A3，基于多个资源软件包，打包得到系统软件包。

其中，基于多个资源软件包生成系统软件包的内容与步骤A1类似，在此不再赘述。

在一个实施例中，在目标管理软件包括待打包资源目标的情况下，步骤A2可以具体包括下述步骤A21至步骤A24。

步骤A21，获取多个资源软件包的目录。

具体的，可以在得到多个资源软件包后，生成资源软件包的目录。可选地，可以将资源软件包发送至目标资源库进行存储。

步骤A22，利用多个软件资源包的目录更新待打包资源目录。

示例性地，可以将软件资源包的目录文件添加至待打包资源目录内。或者是将待打包资源目录内该资源软件包对应的原有目录文件替换为新获取的资源软件包的目录文件。

又一示例性地，可以将软件资源包的目录内容添加至待打包资源目录内。或者是将待打包资源目录内该资源软件包对应的原有目录内容替换为新获取的资源软件包的目录内容。

步骤A23，拉取更新后的待打包资源目录涉及的待打包对象。

通过步骤A23，可以拉取得到上述多个资源软件包，以及目标业务系统的其他资源元素。

其中，待打包对象可以参见本公开实施例上述部分对待打包元素的相关描述，在此不再赘述。

步骤A24，对待打包对象进行打包，得到目标业务系统的系统软件包。

具体的，步骤A24的具体内容与S630类似，在此不再赘述。

本公开实施例的软件包处理方法，能够在目标业务系统满足打包条件时，确定目标业务系统的打包功能对应的目标管理文件，利用该目标管理文件内的关联资源目录拉取关联资源对象生成目标业务系统的系统软件包。由于关联资源对象是目标业务系统中除目标管理文件之外的其他管理文件所管理的资源对象，本公开实施例基于业务系统的多个管理文件对关联资源对象进行打包，能够将以目标业务系统的资源对象打包生成一个系统软件包，从而实现了对目标业务系统的资源对象进行统一管理。

在介绍了软件包处理系统的架构之后，接下来，本公开实施例的下述部分对本公开实施例提供的软件包处理方法、装置、设备以及计算机介质依次展开具体说明。

图7示出了本公开实施例提供的另一种软件包处理方法的流程示意图。

在本公开实施例中，软件包处理方法各步骤的执行主体可以是软件包处理节点。其中，软件包处理节点可以是物理服务器、虚拟服务器或者一段进程。在一个实施例中，软件包处理节点可以是能够运行 Jenkins等具有软件开发管理功能应用程序的节点。

如图7所示，该软件包处理方法可以包括如下步骤。

S710，监测关联资源对象的更新事件。

示例性地，可以在目标代码库内目标业务系统的各功能的代码发生变更时，监测到目标业务系统的资源对象发生了更新事件。

或者，可以在目标业务系统的各功能的管理文件中的资源目录发生变更时，确定目标业务系统的资源对象的发生了更新事件。

需要的是，还可以通过其他方式确定是否发生关联资源对象的更新事件，本公开实施例对此不作限制。

S720，在监测到关联资源对象发生更新事件时，确定目标业务系统满足打包条件。

其中，打包条件的具体内容可以参见本公开实施例上述部分的相关描述，在此不再赘述。

S730，在目标业务系统满足打包条件的情况下，从目标业务系统的多个管理文件中查找打包功能对应的目标管理文件，目标管理文件内存储有关联资源目录。其中，S730与S610类似，在此不再赘述。

S740，拉取关联资源目录涉及的关联资源对象。其中，关联资源对象是多个管理文件中除目标管理文件之外的其他管理文件所管理的资源对象。其中，S740与S620类似，在此不再赘述。

S750，基于关联资源对象，生成目标业务系统的系统软件包。其中，S750与S630类似，在此不再赘述。

本公开实施例的软件包处理方法，能够在目标业务系统满足打包条件时，确定目标业务系统的打包功能对应的目标管理文件，利用该目标管理文件内的关联资源目录拉取关联资源对象生成目标业务系统的系统软件包。由于关联资源对象是目标业务系统中除目标管理文件之外的其他管理文件所管理的资源对象，本公开实施例基于业务系统的多个管理文件对关联资源对象进行打包，能够将以目标业务系统的资源对象打包生成一个系统软件包，从而实现了对目标业务系统的资源对象进行统一管理。

此外，通过对资源更新事件的监测，可以在相关人员进行软件开发之后，自动对软件包进行打包，实现了软件包的及时发布。可选地，在CI场景中，通过对资源更新事件的监测，可以在软件包开发之后，自动打包及部署，提高了软件的发布及部署的便捷性、规范性。

图8示出了本公开实施例提供的又一种软件包处理方法的流程示意图。

在本公开实施例中，软件包处理方法各步骤的执行主体可以是软件包处理节点。其中，软件包处理节点可以是物理服务器、虚拟服务器或者一段进程。在一个实施例中，软件包处理节点可以是能够运行 Jenkins等具有软件开发管理功能应用程序的节点。

如图8所示，该软件包处理方法可以包括如下步骤。

S810，获取软件包标签。其中，软件包标签包括软件包的索引号和/或打包序号。

在一些实施例中，该索引号唯一对应系统软件包。可选地，软件包的索引号可以是系统软件包的commit名、系统软件包的摘要、系统软件包的存储地址等，对此不作具体限定。

在一些实施例中，打包序号可以是软件包处理节点对软件包命名的打包序号。可选地，软件包处理节点在其打包的上一个软件包的打包序号上加1，得到当前软件包的打包序号。

可选地，由于打包序号随着软件包处理节点的打包次数增加，不同软件包其打包序号不同，相应地，可以利用打包序号区分不同软件包。

S820，基于软件包标签，生成软件包包名。示例性地，若软件包标签为“AA”，则生成的软件包包名可以是“XXXAAXXX.jar”。

在一些实施例中，软件包包名除了软件包标签之外，还可以包括软件包所在分支的分支序号、目标管理文件的文件名、变量名等，对其不作具体限定。其中，分支序号可以是“master”等，一个或者多个功能可以属于同一分支，变量名可以表示为“env”。

在一些实施例中，为了便于区分不同版本的同一软件包，可以利用软件包标签生成软件包版本，再基于软件包版本生成软件包包名。

S830，在目标业务系统满足打包条件的情况下，从目标业务系统的多个管理文件中查找打包功能对应的目标管理文件。其中，目标管理文件内存储有关联资源目录。其中，S830与S610类似，在此不再赘述。

S840，拉取关联资源目录涉及的关联资源对象。其中，关联资源对象是多个管理文件中除目标管理文件之外的其他管理文件所管理的资源对象。其中，S840与S620类似，在此不再赘述。

S850，基于关联资源对象，生成以上述软件包包名命名的系统软件包。其中，S850与S630类似，在此不再赘述。以及软件包包名的具体内容可参见上述S810部分的相关描述，在此不再赘述。

在一个示例中，结合S810至S850示出的软件包处理方法的具体步骤可以如下：

首先，可以基于分支名称(CI_COMMIT_REF_NAME)和预设变量名生成规则生成变量名，以及基于打包序号(CI_PIPELINE_IID)以及预设标签生成规则生成标签名。以及基于标签名、变量名、目标管理文件名称生成以标签名为版本号的软件包包名。示例性地，若标签名为“AA”、变量为“BB”、目标管理文件名称为“CC”，则生成的软件包包名为“xx/xx/BB/xx/xx/CC.tar:AA”。

然后，通过创建目录、建立链接等命令进行环境配置之后，可以基于软件包处理方法的执行脚本拉取关联资源对象、打包生成系统软件包、出包、将包推送至目标资源库、删除系统软件包等操作。

本公开实施例的软件包处理方法，能够在目标业务系统满足打包条件时，确定目标业务系统的打包功能对应的目标管理文件，利用该目标管理文件内的关联资源目录拉取关联资源对象生成目标业务系统的系统软件包。由于关联资源对象是目标业务系统中除目标管理文件之外的其他管理文件所管理的资源对象，本公开实施例基于业务系统的多个管理文件对关联资源对象进行打包，能够将以目标业务系统的资源对象打包生成一个系统软件包，从而实现了对目标业务系统的资源对象进行统一管理。

因为现有技术的打包是各自为战的，打包的版本都是一版一个样，导致无法准确知道部署节点上使用的软件版本，使得软件管理混乱。而本公开实施例可以为不同版本、不同业务系统的软件包生成不同的软件包包名，从而能够从软件包包名区分不同业务系统、不同版本的软件包，方便了软件包的管理、部署等工作。

图9示出了本公开实施例提供的又一种软件包处理方法的流程示意图。

在本公开实施例中，软件包处理方法各步骤的执行主体可以是软件包处理节点。其中，软件包处理节点可以是物理服务器、虚拟服务器或者一段进程。在一个实施例中，软件包处理节点可以是能够运行 Jenkins等具有软件开发管理功能应用程序的节点。

如图9所示，该软件包处理方法可以包括如下步骤。

S910，在目标业务系统满足打包条件的情况下，从目标业务系统的多个管理文件中查找打包功能对应的目标管理文件。其中，目标管理文件内存储有关联资源目录。其中，S910与S610类似，在此不再赘述。

S920，拉取关联资源目录涉及的关联资源对象的最新版源代码文件。其中，关联资源对象是多个管理文件中除目标管理文件之外的其他管理文件所管理的资源对象。

在一个示例中，可以通过资源目录中的版本号，拉取到各关联资源对象最新版的源代码文件。需要说明的是S920的其他内容与S620 类似，在此不再赘述。

S930，基于最新版源代码文件，生成最新版的系统软件包。其中， S930与S630类似，在此不再赘述。

本公开实施例的软件包处理方法，能够在目标业务系统满足打包条件时，确定目标业务系统的打包功能对应的目标管理文件，利用该目标管理文件内的关联资源目录拉取关联资源对象生成目标业务系统的系统软件包。由于关联资源对象是目标业务系统中除目标管理文件之外的其他管理文件所管理的资源对象，本公开实施例基于业务系统的多个管理文件对关联资源对象进行打包，能够将以目标业务系统的资源对象打包生成一个系统软件包，从而实现了对目标业务系统的资源对象进行统一管理。

另外，当程序人员对多个功能项目进行开发时，由于可以自动拉取的各功能项目的最近版本生成目标业务系统，从而可以保证生成的目标业务系统的各功能项目均是最新的，保证了目标业务系统对各功能项目的及时更新。

图10示出了本公开实施例提供的再一种软件包处理方法的流程示意图。

在本公开实施例中，软件包处理方法各步骤的执行主体可以是软件包处理节点。其中，软件包处理节点可以是物理服务器、虚拟服务器或者一段进程。在一个实施例中，软件包处理节点可以是能够运行 Jenkins(一种持续集成应用程序)等具有软件开发管理功能应用程序的节点。

如图10所示，该软件包处理方法可以包括如下步骤。

S1010，在目标业务系统满足打包条件的情况下，从目标业务系统的多个管理文件中查找打包功能对应的目标管理文件。其中，目标管理文件内存储有关联资源目录。其中，S1010与S610类似，在此不再赘述。

S1020，拉取关联资源目录涉及的关联资源对象。其中，关联资源对象是多个管理文件中除目标管理文件之外的其他管理文件所管理的资源对象。其中，S1020与S620类似，在此不再赘述。

S1030，基于关联资源对象，生成目标业务系统的系统软件包。其中，S1030与S630类似，在此不再赘述。

S1040，响应于系统软件包的生成事件，将系统软件包存储至目标资源库。

可选地，可以利用包含系统软件包的打包命令(比如docker命令)、以及自动发包命令(docker push)命名的打包脚本，使得能够自动响应于系统软件包的生成事件将系统软件包存储至目标资源库。

本公开实施例的软件包处理方法，能够在目标业务系统满足打包条件时，确定目标业务系统的打包功能对应的目标管理文件，利用该目标管理文件内的关联资源目录拉取关联资源对象生成目标业务系统的系统软件包。由于关联资源对象是目标业务系统中除目标管理文件之外的其他管理文件所管理的资源对象，本公开实施例基于业务系统的多个管理文件对关联资源对象进行打包，能够将以目标业务系统的资源对象打包生成一个系统软件包，从而实现了对目标业务系统的资源对象进行统一管理。

另外，通过本实施例，可以自动检测并响应于系统软件包的生成事件，将系统软件包自动发布至目标资源库(Flowengine hub)。相较于现有的、依靠人工导出再导入的发包方式，极大的减少了人力成本和错误概率，提高了软件开发的效率。

图11示出了本公开实施例提供的再一种软件包处理方法的流程示意图。

在本公开实施例中，软件包处理方法各步骤的执行主体可以是软件包处理节点。其中，软件包处理节点可以是物理服务器、虚拟服务器或者一段进程。在一个实施例中，软件包处理节点可以是能够运行 Jenkins(一种持续集成应用程序)等具有软件开发管理功能应用程序的节点。

如图11所示，该软件包处理方法可以包括如下步骤。

S1110，在目标业务系统满足打包条件的情况下，从目标业务系统的多个管理文件中查找打包功能对应的目标管理文件。其中，目标管理文件内存储有关联资源目录。其中，S1110与S610类似，在此不再赘述。

S1120，拉取关联资源目录涉及的关联资源对象。其中，关联资源对象是多个管理文件中除目标管理文件之外的其他管理文件所管理的资源对象。其中，S1120与S620类似，在此不再赘述。

S1130，基于关联资源对象，生成目标业务系统的系统软件包。其中，S1130与S630类似，在此不再赘述。

S1140，将软件包包名发送至目标资源库，以使所述目标部署节点从所述目标资源库拉取所述系统软件包。

对于目标部署节点，其可以是预先定义好的部署节点，或者是请求获取目标业务系统的系统软件包的部署节点，又或者是相关人员在更新资源对象时指定的部署节点。

在一个示例中，目标部署节点可以是软件包处理系统内部的部署节点，也就是说，目标部署节点处于软件包处理系统的内部环境中。相应地，目标部署节点对应的目标资源库可以与软件包处理节点处于同一软件包处理系统内。

在另一个示例中，目标部署节点可以是软件包处理系统外部的部署节点，也就是说，目标部署节点处于软件包处理系统的外部环境中。相应地，目标资源库可以与目标部署节点属于同一外部环境。

相应地，为了能够在外部环境访问软件包的同时兼顾安全性，可以将系统软件包推送至目标资源库之后，生成系统软件包的外部访问地址，然后可以使得目标部署节点以set image命名+外部访问地址等软件包更新方式来更新系统软件包。示例性地，系统软件包的外部访问地址可以是基于系统软件包的软件包包名和目标资源库的外部环境地址生成的。

在一个实施例中，目标部署节点可以向软件包处理节点发送软件包获取请求，然后由目标部署节点确定系统软件包在存储位置，然后从该存储位置提取系统软件包之后，将其发送至目标部署节点。

在一个示例中，目标部署节点可以使用编辑yml文件、patch更新或者set image命名+软件包包名等软件包更新方式来更新系统软件包。

在另一个实施例中，目标部署节点可以直接访问目标资源库来获取系统软件包。其中，目标部署节点直接访问目标资源库的方式与上述方式类似，在此不再赘述。

在又一个实施例中，软件包处理节点可以在产生系统软件包之后将其自动发布至软件包处理节点。示例性地，可以通过 mount-asol-package命令+系统软件包的存放地址，实现系统软件包的自动部署。

在一个实施例中，在目标部署节点上部署系统软件包的具体方法可以包括：根据系统软件包内关联资源对象中的每一可部署资源对象，执行以下步骤B1至步骤B3。其中，步骤B1至B3的执行主体可以是软件包处理节点或者是目标部署节点的控制模块。

步骤B1、获取可部署资源对象的资源目录和目标部署节点的已部署资源对象的资源目录。

在一个示例中，若步骤B1至B3的执行主体可以是目标部署节点的控制模块，则其可以接收软件包处理节点发送的关联资源对象的资源目录。其中，可以通过发送打包功能对应的目标管理文件的方式向目标部署节点发送关联资源对象的资源目录。或者还可以以其他方式发送，本公开对此不作限定。可选地，可以将关联资源对象的资源目录放置在系统软件包中发送，或者以其他方式发送。

步骤B2、若可部署资源对象的资源目录的资源定义值和目标部署节点的已部署资源对象的资源目录的资源定义值相同，则在目标部署节点上利用可部署资源对象替换已部署资源对象。

其中，资源目录中的资源定义值可以是资源对象的key值、group 值以及class值中的至少一个。可选地，若可部署资源对象和已部署资源对象的key值、group值和class值均相同，则证明可部署资源对象和已部署资源对象为同一资源对象。

在一个实施例中，若可部署资源对象的资源目录的资源定义值和目标部署节点的已部署资源对象的资源目录的资源定义值相同，则可以进一步判断二者的版本号是否一致，若二者不一致，则利用可部署资源对象替换已部署资源对象；若二者一致，则结束可部署资源对象的部署。也就是说，不在目标部署节点部署可部署资源对象，在目标部署节点保留已部署资源对象。

步骤B3、若可部署资源对象的资源目录的资源定义值和目标部署节点的已部署资源对象的资源目录的资源定义值不相同，则在目标部署节点上保留已部署资源对象的同时增添可部署资源对象。

本公开实施例的软件包处理方法，能够在目标业务系统满足打包条件时，确定目标业务系统的打包功能对应的目标管理文件，利用该目标管理文件内的关联资源目录拉取关联资源对象生成目标业务系统的系统软件包。由于关联资源对象是目标业务系统中除目标管理文件之外的其他管理文件所管理的资源对象，本公开实施例基于业务系统的多个管理文件对关联资源对象进行打包，能够将以目标业务系统的资源对象打包生成一个系统软件包，从而实现了对目标业务系统的资源对象进行统一管理。

本公开实施例还提供了一种用于实现上述的软件包处理方法的软件包处理装置，下面结合图12进行说明。

在本公开实施例中，软件包处理装置可以为软件包处理节点。其中，软件包处理节点可以是物理服务器、虚拟服务器或者一段进程。在一个实施例中，软件包处理节点可以是能够运行Jenkins等具有软件开发管理功能应用程序的节点。

图12示出了本公开实施例提供的一种软件包处理装置的结构示意图。

如图12所示，该软件包处理装置1200可以包括文件查找模块1210、资源拉取模块1220和软件包生成模块1230。

文件查找模块1210，配置为在目标业务系统满足打包条件的情况下，从目标业务系统的多个管理文件中查找打包功能对应的目标管理文件，目标管理文件内存储有关联资源目录；

资源拉取模块1220，配置为拉取关联资源目录涉及的关联资源对象，关联资源对象是多个管理文件中除目标管理文件之外的其他管理文件所管理的资源对象；

软件包生成模块1230，配置为基于关联资源对象，生成目标业务系统的系统软件包。

本公开实施例的软件包处理装置，能够在目标业务系统满足打包条件时，确定目标业务系统的打包功能对应的目标管理文件，利用该目标管理文件内的关联资源目录拉取关联资源对象生成目标业务系统的系统软件包。由于关联资源对象是目标业务系统中除目标管理文件之外的其他管理文件所管理的资源对象，本公开实施例基于业务系统的多个管理文件对关联资源对象进行打包，能够将以目标业务系统的资源对象打包生成一个系统软件包，从而实现了对目标业务系统的资源对象进行统一管理。

在本公开一些实施例中，软件包处理装置1200还包括事件检测模块以及判断模块。

事件检测模块，配置为监测关联资源对象的更新事件；

判断模块，配置为在监测到关联资源对象发生更新事件时，确定目标业务系统满足打包条件。

在本公开一些实施例中，关联资源对象的数量为多个，软件包生成模块1230可以包括：

第一打包单元，配置为对多个关联资源对象分别打包，得到多个资源软件包；

第二打包单元，配置为基于多个资源软件包，打包得到系统软件包。

进一步地，打包功能对应的目标管理文件还包括待打包资源目录，第二打包单元进一步配置为：

获取多个资源软件包的目录；

利用多个软件资源包的目录更新待打包资源目录；

拉取更新后的待打包资源目录涉及的待打包对象；

对待打包对象进行打包，得到系统软件包。

在本公开一些实施例中，软件包处理装置1200还包括标签获取模块和软件包命名模块。

标签获取模块，配置为获取软件包标签，软件包标签包括软件包的索引号和/或打包节点的打包序号；

软件包命名模块，配置为基于软件包标签，生成软件包包名；

相应地，软件包生成模块1230可以配置为：

基于关联资源对象，生成以软件包包名命名的系统软件包。

在本公开一些实施例中，资源拉取模块1220可以进一步配置为：

拉取关联资源对象的最新版源代码文件；

基于关联资源对象，生成目标业务系统的系统软件包，包括：

基于最新版源代码文件，生成最新版的系统软件包。

在本公开一些实施例中，软件包处理装置1200还包括软件包存储模块。

软件包存储模块，配置为响应于系统软件包的生成事件，将系统软件包存储至目标资源库。

进一步地，软件包处理装置1200还包括地址获取模块和地址分发模块。

地址获取模块，配置为获取系统软件包在目标资源库的存储地址；

地址分发模块，配置为将存储地址发送至目标部署节点，以使目标部署节点基于存储地址从目标资源库拉取系统软件包。

在本公开一些实施例中，软件包生成模块1230可以进一步配置为：

利用目标容器对关联资源对象进行打包，得到镜像格式的系统软件包，目标容器与系统软件包的可部署节点运行环境相同。

需要说明的是，图12所示的软件包处理装置1200可以执行图6 至图12所示的方法实施例中的各个步骤，并且实现图6至图12所示的方法实施例中的各个过程和效果，在此不做赘述。

图13示出了本公开实施例提供的一种软件包处理设备的结构示意图。

如图13所示，该软件包处理设备可以包括处理器1301以及存储有计算机程序指令的存储器1302。

具体地，上述处理器1301可以包括中央处理器(CPU)，或者特定集成电路(Application Specific Integrated Circuit，ASIC)，或者可以被配置成实施本申请实施例的一个或多个集成电路。

存储器1302可以包括用于信息或指令的大容量存储器。举例来说而非限制，存储器1302可以包括硬盘驱动器(Hard Disk Drive，HDD)、软盘驱动器、闪存、光盘、磁光盘、磁带或通用串行总线(Universal Serial Bus，USB)驱动器或者两个及其以上这些的组合。在合适的情况下，存储器1302可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器1302可在综合网关设备的内部或外部。在特定实施例中，存储器1302是非易失性固态存储器。在特定实施例中，存储器1302 包括只读存储器(Read-Only Memory，ROM)。在合适的情况下，该 ROM可以是掩模编程的ROM、可编程ROM(Programmable ROM， PROM)、可擦除PROM(Electrical Programmable ROM，EPROM)、电可擦除PROM(Electrically ErasableProgrammable ROM，EEPROM)、电可改写ROM(Electrically Alterable ROM，EAROM)或闪存，或者两个或及其以上这些的组合。

处理器1301通过读取并执行存储器1302中存储的计算机程序指令，以执行本公开实施例所提供的软件包处理方法的步骤。

在一个示例中，该软件包处理设备还可包括收发器1303和总线 1304。其中，如图13所示，处理器1301、存储器1302和收发器1303 通过总线1304连接并完成相互间的通信。

总线1304包括硬件、软件或两者。举例来说而非限制，总线可包括加速图形端口(Accelerated Graphics Port，AGP)或其他图形总线、增强工业标准架构(ExtendedIndustry Standard Architecture，EISA)总线、前端总线(Front Side BUS，FSB)、超传输(Hyper Transport，HT) 互连、工业标准架构(Industrial Standard Architecture，ISA)总线、无限带宽互连、低引脚数(Low Pin Count，LPC)总线、存储器总线、微信道架构(MicroChannel Architecture，MCA)总线、外围控件互连 (Peripheral ComponentInterconnect，PCI)总线、PCI-Express(PCI-X) 总线、串行高级技术附件(SerialAdvanced Technology Attachment，SATA) 总线、视频电子标准协会局部(VideoElectronics Standards Association Local Bus，VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线1304可包括一个或多个总线。尽管本申请实施例描述和示出了特定的总线，但本申请考虑任何合适的总线或互连。

本公开实施例还提供了一种计算机可读存储介质，该存储介质可以存储有计算机程序，当计算机程序被处理器执行时，使得处理器实现本公开实施例所提供的软件包处理方法。

上述的存储介质可以例如包括计算机程序指令的存储器1302，上述指令可由软件包处理设备的处理器1301执行以完成本公开实施例所提供的软件包处理方法。可选地，存储介质可以是非临时性计算机可读存储介质，例如，非临时性计算机可读存储介质可以是ROM、随机存取存储器(Random Access Memory，RAM)、光盘只读存储器 (Compact DiscROM，CD-ROM)、磁带、软盘和光数据存储设备等。

需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。

以上所述仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文所述的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。