CN110888652B - 基于jenkins插件的多版本构建方法及终端 - Google Patents

Abstract

本发明公开了基于jenkins插件的多版本构建方法及终端，初始化构建环境；接收并解析应用配置文件，得到jenkins插件的配置插件版本号；获取并安装与配置插件版本号对应的业务模块代码至构建环境；执行与业务模块代码对应的业务逻辑，构建并输出应用文件包。本发明通过在一个jenkins插件内，可以获取并安装不同版本的业务模块代码，来控制应用版本的构建和兼容应用的各种特性，即将jenkins插件灵活应对各个特性版本业务的集成构建，扩大了jenkins插件的可使用场景，降低了jenkins插件的维护成本，并且通用性高、开发维护方便且代码复用率高。

Description

基于jenkins插件的多版本构建方法及终端

技术领域

本发明涉及软件工程设计领域，特别涉及基于jenkins插件的多版本构建方法及终端。

背景技术

软件行业中通常通过聚合不同基础业务组件，通过开发jenkins插件来实现应用业务的持续集成交付。对于一个项目组来说，在应用的基础功能组件完成后，开发jenkins插件适配应用的基础功能，进行构建打包。应用开发者再对构建输出包进行测试、发布版本。

当应用有新的特性推出时，jenkins插件部分业务代码需要同步修改逻辑进行适配，以支持新特性的构建，jenkins插件版本随之迭代增加。下一次构建就会使用最新插件代码进行构建。

由于应用会基于基础版本，同时向上扩展出若干个特性版本进行开发构建，但大多数情况下构建服务只需要存在一个插件来满足业务即可，随着插件业务逻辑的更新，不同特性版本的业务逻辑需要独立区分，会使得最新插件版本代码无法兼容所有的特性。并且无法每次都根据特性，重新开发或更换jenkins插件，更新或增加插件都需要重启jenkins服务等问题。

发明内容

本发明所要解决的技术问题是：提供基于jenkins插件的多版本构建方法及终端，以应对各个特性版本业务的集成构建。

为了解决上述技术问题，本发明采用的技术方案为：

基于jenkins插件的多版本构建方法，包括步骤：

S1、初始化构建环境；

S2、接收并解析应用配置文件，得到jenkins插件的配置插件版本号；

S3、获取并安装与所述配置插件版本号对应的业务模块代码至所述构建环境；

S4、执行与所述业务模块代码对应的业务逻辑，构建并输出应用文件包。

为了解决上述技术问题，本发明采用的另一种技术方案为：

请参照图2，基于jenkins插件的多版本构建终端，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现以下步骤：

S1、初始化构建环境；

S2、接收并解析应用配置文件，得到jenkins插件的配置插件版本号；

S3、获取并安装与所述配置插件版本号对应的业务模块代码至所述构建环境；

S4、执行与所述业务模块代码对应的业务逻辑，构建并输出应用文件包。

本发明的有益效果在于：基于jenkins插件的多版本构建方法及终端，在一个jenkins插件内，可以获取并安装不同版本的业务模块代码，来控制应用版本的构建和兼容应用的各种特性，即将jenkins插件灵活应对各个特性版本业务的集成构建，扩大了jenkins插件的可使用场景，降低了jenkins插件的维护成本，并且通用性高、开发维护方便且代码复用率高。

附图说明

图1为本发明实施例的基于jenkins插件的多版本构建方法的流程示意图；

图2为本发明实施例的基于jenkins插件的多版本构建终端的结构示意图。

标号说明：

1、基于jenkins插件的多版本构建终端；2、处理器；3、存储器。

具体实施方式

为详细说明本发明的技术内容、所实现目的及效果，以下结合实施方式并配合附图予以说明。

请参照图1，基于jenkins插件的多版本构建方法，包括步骤：

S1、初始化构建环境；

S2、接收并解析应用配置文件，得到jenkins插件的配置插件版本号；

S3、获取并安装与所述配置插件版本号对应的业务模块代码至所述构建环境；

S4、执行与所述业务模块代码对应的业务逻辑，构建并输出应用文件包。

从上述描述可知，本发明的有益效果在于：在一个jenkins插件内，可以获取并安装不同版本的业务模块代码，来控制应用版本的构建和兼容应用的各种特性，即将jenkins插件灵活应对各个特性版本业务的集成构建，扩大了jenkins插件的可使用场景，降低了jenkins插件的维护成本，并且通用性高、开发维护方便且代码复用率高。

进一步地，所述步骤S3具体为：

判断所述配置插件版本号是否与默认插件版本号一致，若是，则执行步骤S4，否则获取与所述配置插件版本号对应的业务模块代码，安装并部署至所述构建环境之后执行步骤S4，所述默认插件版本号所对应的默认插件版本预先对jenkins插件进行全局安装，所述默认插件版本为对应用基础功能所构建的一个基础插件版本。

从上述描述可知，jenkins服务器允许预先在全局安装jenkins插件的默认插件版本，在默认插件版本已安装的情况下，即使在远程插件代码仓库内获取不到业务模块代码安装的情况，也可以进行基础功能的构建，使其作为异常情况的兜底方案。同时，若进行的是基础功能构建的话，可以每次不用都去拉取代码，以节省构建时间和网络开销。

进一步地，若所述步骤S2中未能得到所述应用配置文件的配置插件版本号，则所述步骤S3中获取最新版本的业务模块代码，安装并部署至所述构建环境。

从上述描述可知，若未在应用配置文件中获取到配置插件版本号，则默认构建最新版本的应用文件。

进一步地，所述步骤S1具体为：

使用docker命令创建一个独立的构建环境，复制jenkins插件所需要环境变量。

从上述描述可知，使用docker命令创建一个独立的构建环境，进行各个环境的构建隔离，在多个应用同时构建时，可以防止并发带来的版本数据错乱的情况。

进一步地，所述步骤S1具体为：

使用docker命令为每一个应用版本创建一个独立构建环境，在每一个独立构建环境中复制jenkins插件所需要环境变量；

所述步骤S2具体为：

接收并解析每一个应用版本的应用配置文件，得到每一个应用版本的配置插件版本号；

所述步骤S3具体为：

获取并安装与每一个应用版本的配置插件版本号对应的业务模块代码至每一个应用版本所对应的独立构建环境；

所述步骤S4具体为：

分别执行不同的独立构建环境内的业务逻辑，构建并输出每一个应用版本的应用文件包。

从上述描述可知，当配置好应用配置文件的插件版本号，配合独立的构建环境，从而实现对多个不同的应用版本同时进行构建输出。

请参照图2，基于jenkins插件的多版本构建终端，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现以下步骤：

S1、初始化构建环境；

S2、接收并解析应用配置文件，得到jenkins插件的配置插件版本号；

S3、获取并安装与所述配置插件版本号对应的业务模块代码至所述构建环境；

S4、执行与所述业务模块代码对应的业务逻辑，构建并输出应用文件包。

从上述描述可知，本发明的有益效果在于：在一个jenkins插件内，可以获取并安装不同版本的业务模块代码，来控制应用版本的构建和兼容应用的各种特性，即将jenkins插件灵活应对各个特性版本业务的集成构建，扩大了jenkins插件的可使用场景，降低了jenkins插件的维护成本，并且通用性高、开发维护方便且代码复用率高。

进一步地，执行所述步骤S3时，所述处理器执行所述计算机程序时具体实现以下步骤：

判断所述配置插件版本号是否与默认插件版本号一致，若是，则执行步骤S4，否则获取与所述配置插件版本号对应的业务模块代码，安装并部署至所述构建环境之后执行步骤S4，所述默认插件版本号所对应的默认插件版本预先对jenkins插件进行全局安装，所述默认插件版本为对应用基础功能所构建的一个基础插件版本。

从上述描述可知，jenkins服务器允许预先在全局安装jenkins插件的默认插件版本，在默认插件版本已安装的情况下，即使在远程插件代码仓库内获取不到业务模块代码安装的情况，也可以进行基础功能的构建，使其作为异常情况的兜底方案。同时，若进行的是基础功能构建的话，可以每次不用都去拉取代码，以节省构建时间和网络开销。

进一步地，若所述步骤S2中未能得到所述应用配置文件的配置插件版本号，则所述步骤S3中获取最新版本的业务模块代码，安装并部署至所述构建环境。

从上述描述可知，若未在应用配置文件中获取到配置插件版本号，则默认构建最新版本的应用文件。

进一步地，执行所述步骤S1时，所述处理器执行所述计算机程序时具体实现以下步骤：

使用docker命令创建一个独立的构建环境，复制jenkins插件所需要环境变量。

从上述描述可知，使用docker命令创建一个独立的构建环境，进行各个环境的构建隔离，在多个应用同时构建时，可以防止并发带来的版本数据错乱的情况。

进一步地，执行所述步骤S1时，所述处理器执行所述计算机程序时具体实现以下步骤：

使用docker命令为每一个应用版本创建一个独立构建环境，在每一个独立构建环境中复制jenkins插件所需要环境变量；

执行所述步骤S2时，所述处理器执行所述计算机程序时具体实现以下步骤：

接收并解析每一个应用版本的应用配置文件，得到每一个应用版本的配置插件版本号；

执行所述步骤S3时，所述处理器执行所述计算机程序时具体实现以下步骤：

获取并安装与每一个应用版本的配置插件版本号对应的业务模块代码至每一个应用版本所对应的独立构建环境；

执行所述步骤S4时，所述处理器执行所述计算机程序时具体实现以下步骤：

分别执行不同的独立构建环境内的业务逻辑，构建并输出每一个应用版本的应用文件包。

从上述描述可知，当配置好应用配置文件的插件版本号，配合独立的构建环境，从而实现对多个不同的应用版本同时进行构建输出。

请参照图1，本发明的实施例一为：

基于jenkins插件的多版本构建方法，包括步骤：

S1、初始化构建环境，即在执行拆件之前启动一个构建预处理，即使用docker命令创建一个独立的构建环境，复制jenkins插件所需要环境变量。

S2、接收并解析应用配置文件，得到jenkins插件的配置插件版本号，即当当构建流程进行到此插件执行时，会进行构建应用参数的处理，即解析所接收到的应用配置文件，以获取jenkins插件的配置插件版本号；

S3、获取并安装与配置插件版本号对应的业务模块代码至构建环境；

具体的，在获取到配置插件版本号后，将会与目前jenkins插件所在的服务器中的默认插件版本号进行比对，判断配置插件版本号是否与默认插件版本号一致，若是，则执行步骤S4，否则获取与配置插件版本号对应的业务模块代码，安装并部署至构建环境之后执行步骤S4，其中，默认插件版本号所对应的默认插件版本预先对jenkins插件进行全局安装，默认插件版本为对应用基础功能所构建的一个基础插件版本；

同时，若步骤S2中未能得到应用配置文件的配置插件版本号，则步骤S3中获取最新版本的业务模块代码，安装并部署至构建环境；

S4、执行与所述业务模块代码对应的业务逻辑，构建并输出应用文件包。

由于使用docker命令创建一个独立的构建环境，因此本实施例也可以在多个不同的应用版本同时构建场景下，同样满足构建需求。

具体如下：

使用docker命令为每一个应用版本创建一个独立构建环境，在每一个独立构建环境中复制jenkins插件所需要环境变量；

接收并解析每一个应用版本的应用配置文件，得到每一个应用版本的配置插件版本号；

获取并安装与每一个应用版本的配置插件版本号对应的业务模块代码至每一个应用版本所对应的独立构建环境，每一个的构建可参照上述步骤S3；

分别执行不同的独立构建环境内的业务逻辑，构建并输出每一个应用版本的应用文件包。

请参照图1，本发明的实施例二为：

基于jenkins插件的多版本构建方法，在本实施例中，其目的是为了构建和发布多版本的移动应用apk。

项目组将推出一款移动应用，它由若干个不同的基础组件聚合后，通过jenkins插件的方式来实现构建逻辑的处理，最后输出一份apk安装包提交给测试人员测试、项目组发布。插件版本会随着特性而迭代。

以下为移动应用项目的开发生命周期说明：

1、项目组已开发完若干个不同的基础组件，并且开发出对应的jenkins插件。将当前的构建插件版本标记为V1.0。使用jenkins对其进行集成构建，输出可用的apk安装包作为基础版本，并且测试人员测试通过。则该应用的默认插件版本即为上述的基础版本，默认插件版本号即为V1.0。

2、之后项目组接到各种需求，推出两个不同的业务特性，并提供新特性的apk安装包：

Jenkins构建服务需要构建插件同步修改业务代码。由于不同特性在业务层面要独立区分开，构建后需要输出不同特性的apk安装包。这种情况下jenkins中构建插件只有一个，若将两个特性的代码合在一起实现的话，可能导致其中一个特性版本的构建就会因兼容发生构建失败。此时按照每个业务特性，进行独立版本开发并且提供两个版本的构建插件。

3、插件开发者收到需求，完成这两个特性的构建插件代码，定版为V1.0.1和V1.0.2，自测完成并发布到远程代码仓库中。

4、在应用构建之前，将第一个特性的应用配置文件的配置插件版本号设置为V1.0.1，第二个特性的应用配置文件的配置插件版本号设置为V1.0.2，对不同特性的应用分别执行应用构建。

5、构建执行时，插件将执行命令创建出构建环境，并获取应用配置文件的配置插件版本号，从远程插件代码仓库中获取与配置插件版本号对应的业务模块代码，安装部署到独立构建环境中，根据具体业务逻辑输出对应业务特性的apk安装包，即应用文件包。

6、测试人员针对输出的不同业务特性的apk安装包进行系统的功能测试。

7、测试通过后，即可发布apk安装包。

即本实施例通过jenkins插件能完成多个特性的构建，提供了版本控制的能力。

其中，通过版本控制，业务项目方可使用对应版本的插件进行构建对应特性。而不一定是用最新的插件版本，因为有一部分的持续集成，需要用旧版本的插件来进行的。假设构建win7和win10系统，构建win7的插件代码一般会是旧的，而win10使用最新的，因此可将插件灵活应对各个特性版本业务的集成构建。

同时，一个插件可以适用于各个应用构建，不必要为了不同的项目，再单独开发插件，因此通用性高。

另外，插件代码只需要在一个jenkins插件上维护，开发维护方便，扩大插件的可使用场景，减少代码冗余，从而提高了代码复用率。

请参照图2，本发明的实施例三为：

基于jenkins插件的多版本构建终端1，包括存储器3、处理器2及存储在存储器3上并可在处理器2上运行的计算机程序，处理器2执行所述计算机程序时实现上述实施例一的步骤。

其中，在基于jenkins插件的多版本构建终端1上设置有一个多版本适配的jenkins插件，在本实施例中，将jenkins插件的功能进行分离，主要为以下两个模块内容：版本控制模块和业务逻辑模块。

其中，版本控制模块主要提供三个能力：创建构建环境能力(即为步骤S1)、插件版本控制能力(即为步骤S2)以及调用业务模块的能力(即为步骤S3)。业务逻辑模块提供执行业务逻辑的功能，每个模块版本都将满足不同业务场景的构建，依靠版本控制拉取安装不同特性的业务模块，就可以对不同特性的应用进行持续集成构建，输出不同的构建包。

由此可知，由于插件分为两个模块，版本控制模块大多数情况是不会变动的，改动的情况多数为业务逻辑模块，因此，本实施例主要是根据配置版本号拉取业务模块代码。

同时，本申请的终端还与远程插件代码仓库连接，远程插件代码仓库用于对业务模块代码的各个版本存储以及管理，依靠一个jenkins持续集成构件服务去执行多版本适配的jenkins插件以及去远程插件代码仓库拉取业务模块代码。

综上所述，本发明提供的基于jenkins插件的多版本构建方法及终端，在一个jenkins插件内，可以获取并安装不同版本的业务模块代码，来控制应用版本的构建和兼容应用的各种特性，即将jenkins插件灵活应对各个特性版本业务的集成构建，扩大了jenkins插件的可使用场景，降低了jenkins插件的维护成本，并且通用性高、开发维护方便且代码复用率高；jenkins服务器允许预先在全局安装jenkins插件的默认插件版本，在默认插件版本已安装的情况下，即使在远程插件代码仓库内获取不到业务模块代码安装的情况，也可以进行基础功能的构建，使其作为异常情况的兜底方案。同时，若进行的是基础功能构建的话，可以每次不用都去拉取代码，以节省构建时间和网络开销；使用docker命令创建一个独立的构建环境，进行各个环境的构建隔离，在多个应用同时构建时，可以防止并发带来的版本数据错乱的情况；当配置好应用配置文件的插件版本号，配合独立的构建环境，从而实现对多个不同的应用版本同时进行构建输出。

以上所述仅为本发明的实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等同变换，或直接或间接运用在相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (6)

1.基于jenkins插件的多版本构建方法，其特征在于，包括步骤：

S1、初始化构建环境；

所述步骤S1具体为：

使用docker命令为每一个应用版本创建一个独立构建环境，在每一个独立构建环境中复制jenkins插件所需要环境变量；

S2、接收并解析应用配置文件，得到jenkins插件的配置插件版本号；

所述步骤S2具体为：

接收并解析每一个应用版本的应用配置文件，得到每一个应用版本的配置插件版本号；

S3、获取并安装与所述配置插件版本号对应的业务模块代码至所述构建环境；

所述步骤S3具体为：

获取并安装与每一个应用版本的配置插件版本号对应的业务模块代码至每一个应用版本所对应的独立构建环境；

S4、执行与所述业务模块代码对应的业务逻辑，构建并输出应用文件包；

所述步骤S4具体为：

分别执行不同的独立构建环境内的业务逻辑，构建并输出每一个应用版本的应用文件包。

2.根据权利要求1所述的基于jenkins插件的多版本构建方法，其特征在于，所述步骤S3具体为：

判断所述配置插件版本号是否与默认插件版本号一致，若是，则执行步骤S4，否则获取与所述配置插件版本号对应的业务模块代码，安装并部署至所述构建环境之后执行步骤S4，所述默认插件版本号所对应的默认插件版本预先对jenkins插件进行全局安装，所述默认插件版本为对应用基础功能所构建的一个基础插件版本。

3.根据权利要求2所述的基于jenkins插件的多版本构建方法，其特征在于，若所述步骤S2中未能得到所述应用配置文件的配置插件版本号，则所述步骤S3中获取最新版本的业务模块代码，安装并部署至所述构建环境。

4.基于jenkins插件的多版本构建终端，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现以下步骤：

S1、初始化构建环境；

执行所述步骤S1时，所述处理器执行所述计算机程序时具体实现以下步骤：

使用docker命令为每一个应用版本创建一个独立构建环境，在每一个独立构建环境中复制jenkins插件所需要环境变量；

S2、接收并解析应用配置文件，得到jenkins插件的配置插件版本号；

执行所述步骤S2时，所述处理器执行所述计算机程序时具体实现以下步骤：

接收并解析每一个应用版本的应用配置文件，得到每一个应用版本的配置插件版本号；

S3、获取并安装与所述配置插件版本号对应的业务模块代码至所述构建环境；

执行所述步骤S3时，所述处理器执行所述计算机程序时具体实现以下步骤：

获取并安装与每一个应用版本的配置插件版本号对应的业务模块代码至每一个应用版本所对应的独立构建环境；

S4、执行与所述业务模块代码对应的业务逻辑，构建并输出应用文件包；

执行所述步骤S4时，所述处理器执行所述计算机程序时具体实现以下步骤：

分别执行不同的独立构建环境内的业务逻辑，构建并输出每一个应用版本的应用文件包。

5.根据权利要求4所述的基于jenkins插件的多版本构建终端，其特征在于，执行所述步骤S3时，所述处理器执行所述计算机程序时具体实现以下步骤：

判断所述配置插件版本号是否与默认插件版本号一致，若是，则执行步骤S4，否则获取与所述配置插件版本号对应的业务模块代码，安装并部署至所述构建环境之后执行步骤S4，所述默认插件版本号所对应的默认插件版本预先对jenkins插件进行全局安装，所述默认插件版本为对应用基础功能所构建的一个基础插件版本。

6.根据权利要求5所述的基于jenkins插件的多版本构建终端，其特征在于，若所述步骤S2中未能得到所述应用配置文件的配置插件版本号，则所述步骤S3中获取最新版本的业务模块代码，安装并部署至所述构建环境。

Images