基于多类型仓库事件驱动的持续集成和持续部署方法

摘要

本发明提供了一种基于多类型仓库事件驱动的持续集成和持续部署方法，包括以下步骤：用户提交代码到代码仓库；代码仓库接受用户的代码提交请求，并触发webhook机制，向指定URL地址发送通知信息；驱动程序获取通知信息，格式化信息，根据参数判断事件类型；如果事件类型被判断为通过，信息被传递给任务执行器，如果事件类型被判断为不通过，则不做任何操作；当事件类型被判断为通过，信息被传递给任务执行器后，任务执行器检索关键字参数，和现有任务模板进行信息匹配；以及如果匹配成功，则执行任务，如果匹配不成功，则不执行任何操作。

说明书

技术领域

本发明涉及计算机领域，尤其涉及一种基于多类型仓库事件驱动的持续集成和持续部署方法。

背景技术

事件驱动是指在持续事务管理过程中，进行决策的一种策略，即跟随当前时间点上出现的事件，调动可用资源，执行相关任务，使不断出现的问题得以解决，防止事务堆积。

持续集成(Continuous Integration)和持续部署(Continuous Deployment)的简称是CICD。持续集成和持续部署是指在开发过程中自动执行一系列脚本来减低开发引入计算机领域漏洞(bug)的概率，在新代码从开发到部署的过程中，尽量减少人工的介入。

如图1所示，为现有技术中的相关系统以及方法。用户在本地通过GIT系列命令，向远程代码仓库提交代码(此为提交事件)：代码仓库接受用户的代码提交请求，之后通过仓库原生的webhook机制向指定的服务地址发送通知(发送到开源软件项目Jenkins的任务JOB中)；Jenkins服务配置的JOB任务设置了通过webhook消息通知触发执行，当webhook发消息时，此任务JOB就会自动执行；JOB任务中可以根据用户实际情况，配置不同的任务流程执行，例如代码编译，代码检查等等。

如图1中的现有技术中，存在一些缺点。例如：

(1)强依赖

现有技术方案完全依赖gitlab等三方代码仓库自带的webhook机制。

(2)需三方插件支持

Jenkins集成工具需要和三方代码仓库进行集成(一般都是安装特定的插件，使之能够获取，接受来自代码仓库的事件通知消息)。

(3)配置过于繁琐

代码开发过程中，为了实现根据不同的事件触发不同的操作，往往需要针对单一事件配置不同的JOB任务，配置工作量大。例如：现有项目A，在代码仓库中有master，dev，test，prod四个分支，在开发过程中，向不同的分支提交代码(提价事件)时，应为分支的不同，往往触发的任务也不相同，这里就需要在Jenkins上面配置最少4个任务JOB。一个项目不可能只存在提交事件，还有合并，分支提交，等等事件，针对不同的事件配置各种任务JOB是一件非常令人头痛的事情。

(4)迁移备份恢复难度高效率低下

如发生机房故障或因其它需要而迁移代码仓库(gitlab/svn)，当前配置的webhook需要重新配置。

同理，Jenkins服务如果迁移，其上配置的任务JOB恢复难度过高，不利于迁移和备份。

因此，需要一种基于多类型仓库事件驱动的持续集成和持续部署方法，将代码仓库和持续集成工具强绑定。

发明内容

本发明的目的之一在于提供一种基于多类型仓库事件驱动的持续集成和持续部署方法，能够将代码仓库和持续集成工具强绑定。

本发明的目的之一在于提供一种基于多类型仓库事件驱动的持续集成和持续部署方法，无需人员重复配置，简单，便捷，方便，灵活高效。

本发明的目的之一在于提供一种基于多类型仓库事件驱动的持续集成和持续部署方法，完全封装了CICD任务JOB，可以重复利用。

本发明的目的之一在于提供一种基于多类型仓库事件驱动的持续集成和持续部署方法，流程更加灵活，用户可以根据实际情况自行编写符合实际需求的任务JOB模板。

本发明的目的之一在于提供一种基于多类型仓库事件驱动的持续集成和持续部署方法，不依赖任何第三方的集成工具，解耦合。

本发明的目的之一在于提供一种基于多类型仓库事件驱动的持续集成和持续部署方法，可以和任务工具结合使用，任务执行模式是命令行模式，任何有CLI(客户端命令)命令的三方服务都可以结合使用。

为了实现上述至少一个发明目的，本发明提供了一种基于多类型仓库事件驱动的持续集成和持续部署方法，包括以下步骤：

用户提交代码到代码仓库；

代码仓库接受用户的代码提交请求，并触发webhook机制，向指定URL地址发送通知信息；

驱动程序获取通知信息，格式化信息，根据参数判断事件类型；

如果事件类型被判断为通过，信息被传递给任务执行器，如果事件类型被判断为不通过，则不做任何操作；

当事件类型被判断为通过，信息被传递给任务执行器后，任务执行器检索关键字参数，和现有任务模板进行信息匹配；以及

如果匹配成功，则执行任务，如果匹配不成功，则不执行任何操作。

在一些实施例中，其中，用户提交代码到代码仓库为提交事件步骤，用户在本地通过仓库原生客户端系列命令，向远程代码仓库提交代码。

在一些实施例中，其中，所述基于多类型仓库事件驱动的持续集成和持续部署方法还包括提交事件以及合并事件的驱动程序触发。

在一些实施例中，其中，所述基于多类型仓库事件驱动的持续集成和持续部署方法还包括以下部署步骤：

代码仓库使用webhook机制向指定地址发送事件消息；

接口服务接收到事件通知消息，根据信息，判断当前事件类型，例如判断是提交事件还是合并事件；

初始化事件信息，为后续事件判断做准备；以及

根据信息中关键信息选择不同的任务执行。

在一些实施例中，其中，所述部署步骤还包括：提交事件任务，不同的提交事件触发不同的任务。

在一些实施例中，其中，所述部署步骤还包括：合并事件任务，不同的合并事件触发不同的任务。

在一些实施例中，其中，所述部署步骤还包括：其它事件任务，所有未匹配的事件默认执行，任务为空。

在一些实施例中，其中，所述基于多类型仓库事件驱动的持续集成和持续部署方法还包括：驱动程序设置有持续运行的进程，接收来自代码仓库的webhook信息；在代码仓库配置webhook，选择所有事件触发；测试提交代码，触发事件通知，获取事件信息后，格式化信息。

在一些实施例中，其中，所述基于多类型仓库事件驱动的持续集成和持续部署方法还包括：根据参数的值判断当前事件的类型以及当前代码提交的分支信息；根据信息判断项目语言类型；根据获取的分支信息以及用户信息，匹配任务模板执行任务；其中，任务模板被定义为用户预先设定好的格式文件，任务模板中的名称被定义为master分支提交事件任务；任务模板中的描述被定义为当触发提交事件，并且分支为master，用户符合特性用户时，执行此任务；任务模板中的任务流被定义为代码编译，代码构建，代码检测以及发布。

在一些实施例中，其中，所述基于多类型仓库事件驱动的持续集成和持续部署方法还包括：驱动程序根据任务模板执行任务，其中还设置有执行前置操作步骤，拉取代码到本地，使用代码仓库的自带命令。

附图说明

图1是现有技术中的一种方案图。

图2是根据本发明的一个优选实施例的一种基于多类型仓库事件驱动的持续集成和持续部署方法的方案设计图。

图3是根据本发明的上述优选实施例的所述基于多类型仓库事件驱动的持续集成和持续部署方法的驱动程序触发流程图。

图4是根据本发明的上述优选实施例的所述基于多类型仓库事件驱动的持续集成和持续部署方法的驱动程序设计方案。

图5是根据本发明的上述优选实施例的所述基于多类型仓库事件驱动的持续集成和持续部署方法的驱动程序设计方案中的一个举例示意图。

图6是根据本发明的上述优选实施例的所述基于多类型仓库事件驱动的持续集成和持续部署方法的另一种标记语言文件图。

图7是根据本发明的上述优选实施例的所述基于多类型仓库事件驱动的持续集成和持续部署方法的整体执行流程图。

具体实施方式

以下描述用于揭露本发明以使本领域技术人员能够实现本发明。以下描述中的优选实施例只作为举例，本领域技术人员可以想到其他显而易见的变型。在以下描述中界定的本发明的基本原理可以应用于其他实施方案、变形方案、改进方案、等同方案以及没有背离本发明的精神和范围的其他技术方案。

本领域技术人员应理解的是，在本发明的揭露中，术语“纵向”、“横向”、“上”、“下”、“前”、“后”、“左”、“右”、“竖直”、“水平”、“顶”、“底”“内”、“外”等指示的方位或位置关系是基于附图所示的方位或位置关系，其仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此上述术语不能理解为对本发明的限制。

可以理解的是，术语“一”应理解为“至少一”或“一个或多个”，即在一个实施例中，一个元件的数量可以为一个，而在另外的实施例中，该元件的数量可以为多个，术语“一”不能理解为对数量的限制。

本发明提供了一种基于多类型仓库事件驱动的持续集成和持续部署方法，应用于系统，能够将代码仓库和持续集成工具强绑定，独立性强，不需要第三方插件，在代码开发过程中，配置简洁，降低迁移备份恢复的难度以及提高效率。所述基于多类型仓库事件驱动的持续集成和持续部署方法，无需人员重复配置，简单，便捷，方便，灵活高效，完全封装了CICD任务JOB，可以重复利用，流程更加灵活，用户可以根据实际情况自行编写符合实际需求的任务JOB模板，不依赖任何第三方的集成工具，解耦合，可以和任务工具结合使用，任务执行模式是命令行模式，任何有客户端命令的三方服务都可以结合使用。

如图2至图7所示为基于本发明的优选实施例的一种基于多类型仓库事件驱动的持续集成和持续部署方法。如图2所示，展示了本发明的所述基于多类型仓库事件驱动的持续集成和持续部署方法的方案设计图。现有技术中依赖代码仓库自带的webhook机制，根据不同的事件发送不同的消息通知，持续集成工具根据不同的事件，事先编排好需要执行的任务。而应用了本发明的所述基于多类型仓库事件驱动的持续集成和持续部署方法的方案中，是事件和任务的一对一绑定关系。也就是说，一份项目代码，在开发中，为了利于管理，会切分不同的分支，每个分支的作用都不完全相同，具有有利于最后发版的master分支，有利于测试的test等等优点。

在具体的实施例中，任务JOB数量的计算公式为：项目代码数量×代码分支数量×分支事件数量。例如，现有项目代码一份，此代码为了开发方便，存在3个分支(master，dev，prod)，每个分支默认存在3个默认任务JOB：

JOB1代码检测，即检测代码的规范性，重复率，是否有漏洞；

JOB2代码构建，即生成部署包，用于后面服务的快速部署；

JOB3代码发布，即部署服务，便于开发人员或者测试人员调试服务，发布到实际生产环境，对外提供服务，也可以用作用户回归测试等。

在以上的例子中，根据任务JOB数量的计算公式，任务JOB数量为1×3×3＝9，即有9个任务JOB数量。此代码为了实现基本的CICD功能，需要配置9个任务JOB，工作量大。因此，在应用了本发明的所述基于多类型仓库事件驱动的持续集成和持续部署方法的方案中，为了更好的利用代码仓库的webhook消息通知机制，使用事件驱动编程(为需要处理的事件编写相应的事件处理程序)的特性，从而实现本发明的所述基于多类型仓库事件驱动的持续集成和持续部署方法。如图2所示的应用了本发明的所述基于多类型仓库事件驱动的持续集成和持续部署方法的方案设计中，包括以下步骤：

用户向远程代码仓库提交代码；

代码仓库接受用户的代码提交请求；

代码仓库发送事件通知至驱动程序；以及

驱动程序根据获取的消息，进行匹配，自动的执行事先编排好的任务。

更具体地，在具体的实施例中，应用了本发明的所述基于多类型仓库事件驱动的持续集成和持续部署方法的方案设计中，包括以下步骤：

提交事件，即用户在本地通过仓库原生客户端系列命令，向远程代码仓库提交代码；

代码仓库接受用户的代码提交请求，之后通过代码仓库原生的webhook机制向指定的服务地址发送通知(发送到驱动程序中)；

驱动程序根据获取的消息，进行匹配，自动的执行事先编排好的任务，例如检测、构建、编译、发布、步骤以及打包等。

如图3所示为本发明的所述基于多类型仓库事件驱动的持续集成和持续部署方法的提交事件步骤以及合并事件步骤的驱动程序触发流程图，可以理解的是，事件可以根据实际情况自行添加。

具体地，包括以下部署步骤：

部署1：代码仓库使用webhook机制向指定地址发送事件消息；

部署2：接口服务接收到事件通知消息，根据信息，判断当前事件类型，例如判断是提交事件还是合并事件；

部署3：初始化事件信息，为后续事件判断做准备；

部署4：根据信息中关键信息(例如分支，操作人)等选择不同的任务执行；

部署5：提交事件任务，不同的提交事件触发不同的任务；

部署6：合并事件任务，不同的合并事件触发不同的任务；

部署7：其它事件任务，所有未匹配的事件默认执行，任务可以为空。

进一步地，在应用了本发明的所述基于多类型仓库事件驱动的持续集成和持续部署方法的驱动程序设计方案中，图4显示了优选实施例中的使用127.0.0.1地址，表示本机自启动驱动程序的界面。应用了本发明的所述基于多类型仓库事件驱动的持续集成和持续部署方法的驱动程序需要有一个进程一直运行，负责接收来自代码仓库的webhook信息。具体地，提供一个HTTP服务，接收标准的RESTful API的POST请求即可，此接口接java类型代码的事件信息。不同类型的代码提供不同的接口，便于后续执行任务时，无需判断代码语言类型。进一步地，在代码仓库gitlab上面配置webhook，选择所有事件触发。优选地，这个优选实施例中，选用127.0.0.1地址，表示本机自启动驱动程序。进一步地，测试提交代码，触发事件通知，获取事件信息后，格式化信息。优选地，在这个优选实施例中，如图5所示，以gitlab的webhook消息举例提交事件的触发。具体地，根据参数“object_kind”的值判断当前事件的类型，push代表当前事件是提交事件；根据参数“ref”的值判断，当前代码提交的分支信息，当前分支为master分支；

根据信息判断项目语言类型(默认java)，在这个优选实施例的举例中，因为是http://127.0.0.1:999/java接口获取的信息，默认代码语言环境为java；根据以上获取的相关信息(分支信息，用户)，匹配合适的任务模板执行任务。其中，任务模板是用户事先设定好的(YAML格式文件)，例如图6中举例展示的：

名称：master分支提交事件任务；

描述：当触发提交事件，并且分支为master，用户符合特性用户时，执行此任务；

任务流：代码编译，代码构建，代码检测，发布。

进一步地，驱动程序根据任务模板执行任务。优选地，在这个优选实施例中：

执行前置操作：拉取代码到本地，使用git自带命令；

build：编译代码(执行mvn build命令)；

packge：打包代码(执行mvn package)；

detect：检测代码(执行sonar-scanner)；

deploy：发布代码(执行java–jar*.jar)。

至此，在应用了本发明的所述基于多类型仓库事件驱动的持续集成和持续部署方法的驱动程序设计方案中，当前项目的提交事件触发的CICD任务就自动执行完成。

如图7所示，展示了本发明的所述基于多类型仓库事件驱动的持续集成和持续部署方法的整体执行流程图。

本发明的所述基于多类型仓库事件驱动的持续集成和持续部署方法包括以下步骤：

用户提交代码到代码仓库；

代码仓库触发webhook机制，向指定URL地址(Uniform Resource Locator,统一资源定位器，是WWW的统一资源定位标志，就是指网络地址)发送通知信息；

驱动程序获取通知信息，格式化信息，根据参数判断事件类型；

如果事件类型被判断为通过，信息被传递给任务执行器，如果事件类型被判断为不通过，则不做任何操作；

事件类型被判断为通过，信息被传递给任务执行器后，任务执行器检索关键字参数，和现有任务模板进行信息匹配；

如果匹配成功，则执行任务，如果匹配不成功，则不执行任何操作。

本领域的技术人员应理解，上述描述及附图中所示的本发明的实施例只作为举例而并不限制本发明。本发明的目的已经完整并有效地实现。本发明的功能及结构原理已在实施例中展示和说明，在没有背离所述原理下，本发明的实施方式可以有任何变形或修改。