CN111651352A

CN111651352A - 一种仓库代码的合并方法及装置

Info

Publication number: CN111651352A
Application number: CN202010479488.6A
Authority: CN
Inventors: 李丹
Original assignee: Chengdu Xinchao Media Group Co Ltd
Current assignee: Chengdu Xinchao Media Group Co Ltd
Priority date: 2020-05-29
Filing date: 2020-05-29
Publication date: 2020-09-11
Anticipated expiration: 2040-05-29
Also published as: CN111651352B

Abstract

本发明涉及软件开发技术领域，公开了一种仓库代码的合并方法及装置，所述方法包括：通过合并代码Job，在git仓库的被监控分支中，获取最近一次变动代码对应的日志信息；判断日志信息中是否包含有识别字段，若是，则根据日志信息生成文件；判断文件是否存在，若是，则根据文件，触发文件对应的服务部署Job。本发明通过监控代码的变更，完成对应变更后文件的生成，即实现了一个服务对应一个文件，完成了服务的拆分，在代码发生变更时，可完成对应服务的触发，避免了传统未对服务进拆分而导致的无法根据监控到的动作去触发对应服务的问题，简洁了自动化测试的步骤，缩短了测试时间。

Description

一种仓库代码的合并方法及装置

技术领域

本发明涉及软件开发技术领域，具体涉及一种仓库代码的合并方法及装置。

背景技术

随着互联网的快速发展，网站、服务器和软件的使用频率越来越高，每个软件项目在开发时都需要进行自动化测试流程，以保证软件运行的可靠性，在进行自动化测试流程中，包含了代码的自动合并，即实现持续集成(Continuous Interration，CI)/持续交付(Continuous Delivery，CD)。

但是，目前在进行自动化测试过程中，整个项目所有的服务都在同一个git(一个开源的分布式版本控制系统)仓库中，没有对项目中的服务进行拆分，而开发人员一旦更改实现服务的代码，当使用工具监控整个git仓库时，无法根据监控到的动作去触发对应服务，而要实现触发git仓库中对应的服务，就需要将git仓库中所有服务对应的代码部署到相应的运行环境中，这不仅增加了测试的流程、提高了测试人员的工作量，还大大的增加了自动化测试的时长。

发明内容

为了解决现有自动化测试流程中所存在的没有对服务进行拆分，所导致的无法根据监控到的动作去触发对应服务，造成测试步骤冗长，测试时间长的问题，本发明的目的在于提供一种能够根据监控到的动作，去获取对应代码文件的变更，实现触发对应服务的仓库代码的合并方法及装置和计算机可读存储介质。

第一方面，本发明提供了一种仓库代码的合并方法，包括：

Jenkins服务器通过合并代码Job，在git仓库的被监控分支中，获取最近一次变动代码对应的日志信息；

Jenkins服务器判断所述日志信息中是否包含有识别字段，若是，则根据所述日志信息生成文件，其中，所述识别字段根据最近一次变动代码所执行的功能得到；

Jenkins服务器判断所述文件是否存在，若是，则根据所述文件，触发所述文件对应的服务部署Job，以通过所述服务部署Job，在容器中获取git仓库中的目标分支和所述被监控分支，以便将所述被监控分支中的变动代码合并到所述目标分支中，并将合并后的目标分支部署到对应的运行环境中。

基于上述发明内容，本发明通过Jenkins服务器中的合并代码Job，获取git仓库中被监控分支中最近一次变动代码的日志信息(即代码变化，实质为服务发生变化，如代码进行改动、新增、删除等)，从而根据变动代码的日志信息来生成文件，最后，根据文件的存在与否，来决定是否触发文件对应的服务部署Job，以便通过服务部署Job，在容器中将被监控分支中的变动代码合并至目标分支中，最终将合并后的目标分支部署到对应的运行环境中。

通过上述设计，本发明通过监控代码的变更，完成对应变更后文件的生成，(即实现了一个服务对应一个文件)，进而通过生成的文件存在与否，来决定是否触发文件对应的服务部署Job，并在触发后，实现变更后代码与目标分支的自动合并，以及将合并后的目标分支部署至对应的运行环境中，从而完成变更后服务的对应触发。即本发明对每个服务进行了拆分，在代码发生变更时，可完成对应服务的触发，避免了传统未对服务进拆分而导致的无法根据监控到的动作去触发对应服务的问题，简洁了自动化测试的步骤，缩短了测试时间。

在一个可能的设计中，Jenkins服务器在在获取最近一次变动代码对应的日志信息前，所述方法还包括：

用户终端向Gitee平台上传变动代码以及变动代码的提交命令类型；

Gitee平台接收所述变动代码和所述变动代码的提交命令类型，并存储在内部git仓库的被监控分支中；

Jenkins服务器获取git仓库中被监控分支内变动代码的提交命令类型；

Jenkins服务器判断所述提交命令类型是否属于所述合并代码Job中的触发命令类型，若是，则自动触发所述合并代码Job；

Jenkins服务器通过所述合并代码Job，获取所述被监控分支中的所有代码，并从所有代码中得到所述被监控分支中的变动代码；

Jenkins服务器通过所述合并代码Job，获取所述git仓库中的目标分支，将所述变动代码合并到所述目标分支中，得到新目标分支。

基于上述公开的内容，本发明在Jenkins服务器中设置触发代码自动合并的触发命令类型，Jenkins服务器在监控到git仓库的被监控分支中出现变动代码时，通过检测变动代码的提交命令类型是否属于触发命令类型(即命令类型表明代码所要进行的操作，为Jenkins服务器监控的动作)，从而来判断是否进行代码的自动合并，并在触发后，在平台中完成变动代码与目标分支的合并，得到新目标分支，进而为后续在git仓库中完成与目标分支的合并提供数据基础。

在一个可能的设计中，所述方法还包括：

Jenkins服务器构建一个布尔值参数，其中，所述布尔值参数是用于控制所述合并后的目标分支执行冒烟用例的参数。

在一个可能的设计中，Jenkins服务器在触发所述文件对应的服务部署Job后，所述方法还包括：

判断所述布尔值参数是否为真；

若是，则对所述合并后的目标分支执行冒烟用例，并在冒烟用例通过后，将所述新目标分支上传至所述git仓库中的目标分支，完成所述新目标分支与所述git仓库中目标分支的合并。

基于上述公开的内容，通过构建布尔值参数，用于控制容器中合并后的目标分支进行冒烟用例，可实现合并后目标分支中代码的运行测试，确认合并后的代码会按预期运行，且不会破坏整个项目的稳定性，进而在冒烟用例通过后，将新目标分支上传至git仓库中的目标分支，完成新目标分支与git仓库中目标分支的合并，实现git仓库中目标分支的更新。

在一个可能的设计中，在所述合并后的目标分支执行冒烟用例失败或触发所述文件对应的服务部署Job失败时，所述方法还包括：

触发恢复Job，其中，所述恢复Job用于在所述合并后的目标分支执行冒烟用例失败或触发所述文件对应的服务部署Job失败时，恢复所述冒烟用例的执行运行环境或所述合并后的目标分支的运行环境。

基于上述公开的内容，在冒烟用例执行失败时或触发所述文件对应的服务部署Job失败时，通过触发恢复Job，来恢复执行环境，可便于下一代码对应文件的生成以及对应服务部署Job的触发。

在一个可能的设计中，Jenkins服务器将所述变动代码合并到所述目标分支中，得到新目标分支，包括：

通过所述合并代码Job，将所述变动代码存储到预设的路径中；

在所述预设的路径中，将所述变动代码合并到所述目标分支中，得到所述新目标分支。

在一个可能的设计中，在得到所述新目标分支后，所述方法还包括：

删除所述预设路径下根据服务生成的所有文件，以避免所述预设路径下的文件，干扰所述文件对应的服务部署Job的触发。

基于上述公开的内容，通过删除预设路径下根据服务生成的文件，能够避免预设路径中的文件，干扰后续根据日志信息生成文件对应服务部署Job的触发，保证变动代码对应文件服务的准确触发。

在一个可能的设计中，Jenkins服务器在通过合并代码Job，获取所述被监控分支中的所有代码前，所述方法还包括：

进行参数化构建，构建第一字符参数和第二字符参数，其中，所述第一字符参数用于参数化所述被监控分支，所述第二字符参数用于参数化所述目标分支；

配置所述git仓库的地址，其中，所述地址用于获取所述被监控分支中的所有代码；

配置至少一个触发命令类型，以使所述变动代码的提交命令类型属于所述触发命令类型时，自动触发所述合并代码Job。

基于上述发明内容，通过在Jenkins服务器中进行合并代码Job的参数配置，实现了git仓库中被监控分支内变动代码的自动监控，进而根据变动代码所对应的提交命令类型是否属于合并代码Job中配置的触发命令类型，来实现合并代码Job的自动触发，最终在平台中达到变动代码与目标分支中代码的自动合并。当然，上述配置过程仅仅为合并代码Job参数配置中的一种。

第二方面，本发明提供了一种仓库代码的合并装置，将装置以Jenkins服务器为例，包括：合并代码Job单元、第一判断单元、文件生成单元、第二判断单元和第一触发单元；

所述合并代码Job单元，用于通过合并代码Job，在git仓库的被监控分支中，获取最近一次变动代码对应的日志信息；

所述第一判断单元，用于判断所述日志信息中是否包含有识别字段；

所述文件生成单元，用于在所述第一判断单元判断出所述日志信息中包含有识别字段后，根据所述日志信息生成文件；

所述第二判断单元，用于判断所述文件是否存在；

所述第一触发单元，用于在所述第二判断单元判断出所述文件存在时，根据所述文件，触发所述文件对应的服务部署Job，以通过所述服务部署Job，在容器中获取git仓库中的目标分支和所述被监控分支，以便将所述被监控分支中的变动代码合并到所述目标分支中，并将合并后的目标分支部署到对应的运行环境中。

在一个可能的设计中，所述Jenkins服务器还包括：获取单元、第三判断单元和第二触发单元；

所述获取单元，用于获取git仓库中被监控分支内变动代码的提交命令类型；

所述第三判断单元，用于判断所述提交命令类型是否属于所述合并代码Job中的触发命令类型；

所述第二触发单元，用于在所述第三判断单元判断所述提交命令类型属于所述合并代码Job中的触发命令类型时，自动触发所述合并代码Job；

所述合并代码Job单元，还用于通过所述合并代码Job，获取所述被监控分支中的所有代码，并从所有代码中得到所述被监控分支中的变动代码；

所述合并代码Job单元，还用于通过所述合并代码Job，获取所述git仓库中的目标分支，并将所述变动代码合并到所述目标分支中，得到新目标分支。

在一个可能的设计中，所述Jenkins服务器还包括：构建单元；

所述构建单元，用于构建一个布尔值参数，其中，所述布尔值参数是用于控制所述合并后的目标分支执行冒烟用例的参数。

在一个可能的设计中，所述构建单元还用于：

构建第一字符参数和第二字符参数，其中，所述第一字符参数用于参数化所述被监控分支，所述第二字符参数用于参数化所述目标分支；

配置所述git仓库的地址，其中，所述地址用于获取所述被监控分支中的所有代码；和/或

在一个可能的设计中，所述Jenkins服务器还包括：第四判断单元、执行单元和发送单元；

所述第四判断单元，用于判断所述布尔值参数是否为真；

所述执行单元，在所述第四判断单元判断出所述布尔值参数为真时，对所述合并后的目标分支执行冒烟用例；

所述发送单元，用于在所述所述执行单元执行冒烟用例通过后，将所述新目标分支上传至所述git仓库中的目标分支，完成所述新目标分支与所述git仓库中目标分支的合并。

在一个可能的设计中，所述Jenkins服务器还包括：恢复单元；

所述恢复单元，用于在所述合并后的目标分支执行冒烟用例失败或触发所述文件对应的服务部署Job失败时，触发恢复Job，以通过恢复Job恢复所述冒烟用例的执行运行环境或所述合并后的目标分支的运行环境。

在一个可能的设计中，所述合并代码Job单元具体通过所述合并代码Job，将所述变动代码存储到预设路径中，并在所述预设路径中，将所述变动代码合并到所述目标分支中，得到所述新目标分支。

在一个可能的设计中，所述Jenkins服务器还包括：删除单元；

所述删除单元，用于在得到所述新目标分支后，删除所述预设路径下根据服务生成的所有文件，以避免所述预设路径下的文件，干扰所述文件对应的服务部署Job的触发。

第三方面，本发明提供了一种仓库代码的合并系统，包括：用户终端、Gitee平台和Jenkins服务器；

所述用户终端，用于将变动代码上传至Gitee平台；

所述Gitee平台，通信连接所述用户终端，用于接收所述用户终端上传的所述变动代码，并存储至内部git仓库的被监控分支中；

所述Jenkins服务器，通信连接所述Gitee平台，用于在git仓库的被监控分支中，获取最近一次变动代码对应的日志信息，根据所述日志信息生成文件，并判断文件是否存在，以便在文件存在时，根据所述文件，触发所述文件对应的服务部署Job，以通过所述服务部署Job，在容器中获取git仓库中的目标分支和所述被监控分支，以便将所述被监控分支中的变动代码合并到所述目标分支中，并将合并后的目标分支部署到对应的运行环境中。

在一个可能的设计中：

所述用户终端还用于将所述变动代码的提交命令类型发送至Gitee平台；

所述Gitee平台，还用于接收所述用户终端上传的所述变动代码的提交命令类型，并存储至内部git仓库的被监控分支中；

所述Jenkins服务器，还用于获取git仓库中被监控分支中的所有代码以及变动代码的提交命令类型，并根据所述提交命令类型，判断是否触发合并代码Job，并在触发所述合并代码Job后，生成新目标分支，且在容器中的合并后的目标分支冒烟用例通过后，将新目标分支上传至git仓库中的目标分支，完成新目标分支与git仓库中目标分支的合并。

第四方面，本发明还提供了另一种仓库代码的合并装置，包括：依次通信相连的存储器、处理器和收发器，其中，所述存储器用于存储计算机程序，所述收发器用于收发消息，所述处理器用于读取所述计算机程序，执行第一方面所述的仓库代码的合并方法。

第五方面，本发明提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有指令，当所述指令在计算机上运行时，执行第一方面所述的仓库代码的合并方法。

第六方面，本发明提供了一种包含指令的计算机程序产品，当所述指令在计算机上运行时，使所述计算机执行如第一方面所述的仓库代码的合并方法。

附图说明

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

图1是本发明提供的仓库代码的合并方法的流程示意图。

图2是本发明提供的当仓库代码的合并装置为Jenkins服务器时的结构示意图。

图3是本发明提供的仓库代码的合并系统的结构示意图。

图4是本发明提供的另一种仓库代码的合并装置的结构示意图。

具体实施方式

下面结合附图及具体实施例来对本发明作进一步阐述。在此需要说明的是，对于这些实施例方式的说明虽然是用于帮助理解本发明，但并不构成对本发明的限定。本文公开的特定结构和功能细节仅用于描述本发明的示例实施例。然而，可用很多备选的形式来体现本发明，并且不应当理解为本发明限制在本文阐述的实施例中。

应当理解，尽管本文可能使用术语第一、第二等等来描述各种单元，但是这些单元不应当受到这些术语的限制。这些术语仅用于区分一个单元和另一个单元。例如可以将第一单元称作第二单元,并且类似地可以将第二单元称作第一单元，同时不脱离本发明的示例实施例的范围。

应当理解，对于本文中可能出现的术语“和/或”，其仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，单独存在B，同时存在A和B三种情况；对于本文中可能出现的术语“/和”，其是描述另一种关联对象关系，表示可以存在两种关系，例如，A/和B，可以表示：单独存在A，单独存在A和B两种情况；另外，对于本文中可能出现的字符“/”，一般表示前后关联对象是一种“或”关系。

应当理解，在本文中若将单元称作与另一个单元“连接”、“相连”或“耦合”时，它可以与另一个单元直相连接或耦合，或中间单元可以存在。相対地，在本文中若将单元称作与另一个单元“直接相连”或“直接耦合”时，表示不存在中间单元。另外，应当以类似方式来解释用于描述单元之间的关系的其他单词(例如，“在……之间”对“直接在……之间”,“相邻”对“直接相邻”等等)。

应当理解，本文使用的术语仅用于描述特定实施例，并不意在限制本发明的示例实施例。若本文所使用的，单数形式“一”、“一个”以及“该”意在包括复数形式，除非上下文明确指示相反意思。还应当理解，若术语“包括”、“包括了”、“包含”和/或“包含了”在本文中被使用时,指定所声明的特征、整数、步骤、操作、单元和/或组件的存在性,并且不排除一个或多个其他特征、数量、步骤、操作、单元、组件和/或他们的组合存在性或增加。

应当理解，还应当注意到在一些备选实施例中，所出现的功能/动作可能与附图出现的顺序不同。例如,取决于所涉及的功能/动作,实际上可以实质上并发地执行,或者有时可以以相反的顺序来执行连续示出的两个图。

应当理解，在下面的描述中提供了特定的细节,以便于对示例实施例的完全理解。然而,本领域普通技术人员应当理解可以在没有这些特定细节的情况下实现示例实施例。例如可以在框图中示出系统，以避免用不必要的细节来使得示例不清楚。在其他实例中，可以不以不必要的细节来示出众所周知的过程、结构和技术，以避免使得示例实施例不清。

实施例

本实施例第一方面所提供的仓库代码的合并方法，适用于非微服务架构，非微服务架构是未对一个大型的应用程序或服务进行拆分的架构，而本实施例第一方面提供的合并方法，即是将一个大型的应用程序或服务拆分成数个甚至数十个的微服务，完成一个大型应用程序或服务的拆分，从而转换为微服务架构，满足服务等级协议，实现敏捷开发和部署。

如图1所示，本实施例第一方面所提供的仓库代码的合并方法，其适用于在用户终端、Gitee平台和Jenkins服务器侧执行，可以但不限于包括有如下步骤S101～S103。

S101.Jenkins服务器通过合并代码Job，在git仓库的被监控分支中，获取最近一次变动代码对应的日志信息。

步骤S101则是对git仓库中被监控分支内代码进行监控的过程，由于项目的所有服务均是通过软件代码来实现的，所以，当需要变更服务时，也是直接通过代码实现，即代码的新增、删除、改动均表示服务的变更。当被监控分支中出现了变动代码，即表明被监控分支中的服务发生了变化。

在本实施例中，变动代码所对应的日志信息，在用户终端上传至git仓库中的被监控分支中时，可自动生成，为一种现有技术。在本实施例中，日志信息包含有实现变动代码所表示功能的变更信息，举例可以但不限于为：变更代码文件的路径。

在本实施例中，合并代码Job可在Jenkins服务器(是一种开源软件，是基于Java开发的一种持续集成工具)中创建，通过配置合并代码Job的各种参数，从而实现对git仓库中各种数据的获取，为一种现有技术。

在本实施例中，git仓库存储在Gitee平台中，Gitee平台是一种基于Git的代码托管和研发协作平台，支持开源的分布式管理控制系统(Git)和开放源代码的版本控制系统(Subversion，SVN)，提供免费的私有仓库托管。

在本实施例中，git仓库中的被监控分支表示为需要进行服务变更的分支，也称为源分支。例如，当在进行自动化测试过程中，被监控分支即是开发分支，即表示项目源代码的分支。

在获取到被监控分支中最近一次变动代码的日志信息后，即可进行步骤S102，通过变动代码的日志信息生成变动代码对应的服务文件，如步骤S102所示：

S102.Jenkins服务器判断所述日志信息中是否包含有识别字段，若是，则根据所述日志信息生成文件，其中，所述识别字段根据最近一次变动代码所执行的功能得到。

步骤S102则是根据识别字段判断是否可以根据日志信息中的变更信息，进行变更文件路径识别的过程，若能够通过识别字段实现变更文件路径的识别，则生成文件(即生成变动代码的服务文件)，即每个变动代码的日志信息，只要能够识别出识别字段，均能生成对应的文件，实现了一个变动代码对应一个服务，完成了服务的拆分。

在本实施例中，识别字段是根据最近一次变动代码所执行的功能得到，由于变动代码的作用即是进行项目服务的改变，所以，在上传变动代码时，则会导致变动代码存储文件的变更，所以，识别字段的实质作用为：识别变更的文件。

所以，在步骤S102中通过识别字段识别出变更的文件后，即可生成变动代码对应的务文件(即步骤S102中的文件)。

在本实施例中，识别字段可以但不限于为：开发人员根据实际开发进行预设，即在识别脚本中，插入能够识别变更文件的字符即可，插入的字符即为识别字段，Jenkins服务器则根据识别字段进行变更文件的识别，若根据识别字段识别出变更的文件，即可建立文件，并进行步骤S103，否则则停止整个操作。

下面对识别脚本进行具体的举例：

在上述给出的脚本中，if中的语句就是进行识别字段的识别，其中$check_results后面的字段则是识别字段，在上述举例中，每个if对应一个服务的识别字段，即上述命令中对应有6个服务。

在本实施例中，当用户终端上传变动代码的方式不同，生成的文件的个数也会有不同，具体举例如下：

第一种：同时上传A、B、C三串变动代码，此时仅进行了依次代码的上传，所以日志信息只有一个，对应生成的文件也只有一个。

第二种：依次上传A、B、C三串变动代码，即分三次上传，每次只上传一串变动代码。此时，每上传一次变动代码，均会有对应的日志信息生成，而一旦均能识别日志信息中的识别字段时，会对应有三个文件，即A的文件、B的文件以及C的文件。

当然，两种上传方式生成的每个文件，均需要判断是否存在，即进行步骤S103。

S103.Jenkins服务器判断所述文件是否存在，若是，则根据所述文件，触发所述文件对应的服务部署Job，以通过所述服务部署Job，在容器中获取git仓库中的目标分支和所述被监控分支，以便将所述被监控分支中的变动代码合并到所述目标分支中，并将合并后的目标分支部署到对应的运行环境中。

步骤S103则是根据文件来判断是否触发文件对应的服务部署Job，即是否在容器中，拉取git仓库被监控分支中和目标分支，将被监控分支中变动代码与合并至目标分支中，完成对合并后的目标分支的运行环境的部署。

通过本步骤，即可实现变动代码的对应文件的生成，通过文件来触发服务部署Job，以完成变动代码与目标分支的自动合并，并实现运行环境的部署，进而达到对变动代码服务对应触发的功能。

在本实施例中，容器为Docker容器，其是一个开源的应用容器引擎，可让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的Linux机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口几乎没有性能开销,可以很容易地在机器和数据中心中运行。

在本实施例中，在容器中将变动代码合并至目标分支是便于进行运行环境的部署，进而实现变动代码生成文件的对应服务的触发。

在本实施例中，服务部署Job也可在Jenkins服务器中构建，也为一种现有技术。

由此通过步骤S101～S103所详细描述的基于非微服务架构仓库代码的方法，本发明通过监控代码的变更，完成对应变更后文件的生成，(即实现了一个服务对应一个文件)，进而通过生成的文件存在与否，来决定是否触发文件对应的服务部署Job，从而完成变更后服务的对应触发。即本发明对每个服务进行了拆分，在代码发生变更时，可完成对应服务的触发，避免了传统未对服务进拆分而导致的无法根据监控到的动作去触发对应服务的问题，简洁了自动化测试的步骤，缩短了测试时间。

另外，由于在容器中进行代码合并后得到的目标分支仅仅用于运行环境的部署，为了实现整个项目服务的运行，还必须在Jenkins服务器将变动代码合并至目标分支，为后续git仓库中目标分支的代码更新提供数据基础，如以下步骤S001～S006所示。

S001.用户终端向Gitee平台上传变动代码以及变动代码的提交命令类型。

S002.Gitee平台接收所述变动代码和所述变动代码的提交命令类型，并存储在内部git仓库的被监控分支中。

所述步骤S001和步骤S002则是用户新增服务的过程，在上传变动代码的同时，即可生成日志信息，为步骤S102文件的生成提供信息基础。

同时，变动代码的提交命令类型则是触发合并代码Job的条件，即根据提交命令类型，决定是否在Jenkins服务器中进行代码的自动合并，以便为后续git仓库中目标分支中代码的更新提供数据基础。

S003.Jenkins服务器获取git仓库中被监控分支内变动代码的提交命令类型。

S004.Jenkins服务器判断所述提交命令类型是否属于所述合并代码Job中的触发命令类型，若是，则自动触发所述合并代码Job。

步骤S003和步骤S004则是进行代码监控的过程(即进行服务的监控)，在本实施例中，采用Jenkins服务器中的合并代码Job，来实现git仓库中被监控分支内代码的实时监控。

由于变动代码由用户终端上传(可以但不限于为开发人员通过开发工具上传)，即用户终端决定了变动代码所要执行的功能，也决定了变动代码所要进行的操作，所以，在上传变动代码时，会有相应的提交命令类型，以便使变动代码完成相应的操作，即变动代码的提交命令类型表示变动代码所要执行的动作。

在本实施例中，本发明即通过识别变动代码的提交命令类型(动作)来判断是否触发Jenkins服务器中的合并代码Job，进而判断是否进行代码的自动合并。

在本实施例中，当用户终端上传变动代码的方式不同，对应的触发方式也会不同，具体举例如下：

第一种为：同时上传A、B、C三串变动代码，此时，A、B、C对应的提交命令类型只有一种，且当属于触发命令类型时，会同时触发合并代码Job，与目标分支进行代码的合并，得到新目标分支。所以采用第一种方式上传变动代码，只触发一次。

第二种：依次上传A、B、C三串变动代码，即分三次上传，每次只上传一串变动代码，当A、B和C的提交命令类型均属于触发命令类型时，会进行独立的三次触发合并代码Job，即进行三次独立的合并。所以，采用第二种方式上传变动代码，会触发三次。

在本实施例中，变动代码的提交命令类型的获取以及识别均是通过合并代码Job来实现的，在Jenkins服务器中创建合并代码Job时，会预设合并代码Job的各种参数，以实现被监控分支中变动代码的实时监控以及提交命令类型的识别。

在本实施例中，对合并代码Job进行参数的配置可以但不限于包括如下步骤S004a～S004c。

S004a。进行参数化构建，构建第一字符参数和第二字符参数，其中，所述第一字符参数用于参数化所述被监控分支，所述第二字符参数用于参数化所述目标分支。

所述步骤S004a则是对git仓库中被监控分支以及目标分支进行参数化的过程，通过对被监控分支和目标分支进行参数化，可实现被监控分支中代码以及目标分支中代码与Jenkins服务器的快速传递。在本实施例中，Jenkins服务器中的参数化构建为一种现有技术。

S004b.配置所述git仓库的地址，其中，所述地址用于获取所述被监控分支中的所有代码。

步骤S004b则是配置git仓库地址的过程，其中，在配置合并代码Job中的参数时，会进行触发器的配置，其中，触发器中的统一资源定位符(Uniform Resource Locator，URL)，则是表示git仓库的地址。只有配置了git仓库的地址，Jenkins服务器中的合并代码Job才能根据地址与git仓库进行通信，获取git仓库中被监控分支中的所有代码，实现代码的合并。

在本实施例中，对于目标分支中代码的获取，可通过在Jenkins服务器输入命令实现，其中，获取目标分支中代码的命令为现有命令。

S004c.配置至少一个触发命令类型，以使所述变动代码的提交命令类型属于所述触发命令类型时，自动触发所述合并代码Job。

步骤S004c则是进行触发命令类型的配置，由于Jenkins服务器中的合并代码Job会实时监控git仓库中被监控分支内的代码状态，即监控是否出现代码的新增、删除、改动等(即服务的变化)，并根据变动代码的提交命令类型来判断是否触发合并代码Job，所以，在配置合并代码Job的参数时，在其对应的触发器中，会配置触发命令类型，从而根据命令类型来实现合并代码Job的自动触发。

在本实施例中，举例触发命令类型可以但不限于包括有：Push events(当有代码提交到仓库则会被触发)、Tag push events(当有一个新的标签提交到仓库则会被触发)、Comments(当新增了备注则会被触发)、Confidential Comments(当有人在私密的评论添加评论时则会触发)、Issues events(当有一个问题新增或者更新或者合并时会被触发)等。

例如，配置的触发命令类型为：Push events，只有变动代码的提交命令类型为Push events时，才能自动触发合并代码Job，进行代码的自动合并。

又如，当配置的命令类型为Push events、Tag push events和Comments时，当变动代码的提交命令类型为上述三种中的任意一种时，即可自动触发所述合并代码Job，进行代码的自动合并。

在本实施例中，在Jenkins服务器中创建合并代码Job也为一种现有技术。

在通过合并代码Job，实现提交命令类型与触发命令类型的判断后，即可通过合并代码Job实现代码的自动合并，当然，代码的自动合并在Jenkins服务器中进行且实现，即如步骤S005和步骤S006所示

S005.Jenkins服务器通过所述合并代码Job，获取所述被监控分支中的所有代码，并从所有代码中得到所述被监控分支中的变动代码。

S006.Jenkins服务器通过所述合并代码Job，获取所述git仓库中的目标分支，将所述变动代码合并到所述目标分支中，得到新目标分支。

步骤S005和步骤S006则是进行代码自动合并的过程，首先需要将git仓库中的目标分支以及被监控分支中的所有代码读取到Jenkins服务器的合并代码Job中，然后获取被监控分支中的变动代码，最后，将变动代码合并到目标分支中，得到新目标分支。

在本实施例中，步骤S006中将变动代码合并至目标分支与步骤S103中的代码合并，是属于两次相互独立的合并过程，但得到的结果均是一样，只是步骤S103是为了触发变动代码生成的文件对应的服务，而步骤S006中的合并则是为了在触发服务后，将步骤S006得到的新目标分支上传至git仓库中目标分支，完成git仓库中目标分支内代码的更新，保证项目服务的正常运行。

在本实施例中，git仓库的目标分支是指需要将变动代码合并至的分支。例如，在自动化流程的测试中，目标分支则是指测试分支。

在本实施例中，Jenkins服务器将所述变动代码合并到所述目标分支中，可以但不限于包括如下步骤S006a～S006b。

S006a.通过所述合并代码Job，将所述变动代码存储到预设的路径中。

在本实施例中，需要在Jenkins服务器中读取被监控分支内的变动代码，并存储在本地，即在Jenkins服务器中进行代码的合并，是在本地进行合并，并没有上传至git仓库，实现目标分支的更新。

在本实施例，预设的路径可根据实际开发环境进行设定。例如，Jenkins服务器的工作路径是workspace，那么预设的路径就可在workspace下的设置任意路径，如workspace/setpoint-service。

S006b.在所述预设的路径中，将所述变动代码合并到所述目标分支中，得到所述新目标分支。

步骤S006b则是进行合并的过程，即在上述预设的路径下，将变动代码合并到目标分支中，即目标分支就包含了变动代码。

在本实施例中，在得到新目标分支后，还删除了预设路径下根据服务生成的所有文件，其原因为：避免预设路径下，根据服务生成的文件干扰步骤S103中所述文件对应的服务部署Job的触发，保证了服务部署Job的准确触发。

在本实施例中，为了使合并了变动代码的目标分支能够稳定运行，还设置布尔值参数，以便通过布尔值参数控制容器中合并后的目标分支执行冒烟用例，实现代码的测试，其中，冒烟用例的执行可以但不限于包括如下步骤S104～S107。

S104.构建一个布尔值参数，其中，所述布尔值参数是用于控制所述合并后的目标分支执行冒烟用例的参数。

S105.判断所述布尔值参数是否为真。

S106.若是，则对所述合并后的目标分支执行冒烟用例，并在冒烟用例通过后，将所述新目标分支上传至所述git仓库中的目标分支。

S107.Gitee平台接收所述新目标分支，并将所述新目标分支合并至内部git仓库中的所述目标分支中，完成所述新目标分支与所述git仓库中目标分支的合并。

通过上述步骤，即可实现对合并后的目标分支执行冒烟用例，在本实施例中，冒烟用例可实现合并后的目标分支的测试，确认合并后的目标分支内的代码会按预期运行，且不会破坏整个项目的稳定性，同时，只有在冒烟用例成功后，Jenkins服务器才会将步骤S006中的新目标分支上传至git仓库中的目标分支，完成git仓库中目标分支内代码的更新，保证整个项目服务在线上的稳定运行。

同时，在合并后的目标分支执行冒烟用例失败或步骤S103中触发所述文件对应的服务部署Job失败时，Jenkins服务器还会触发恢复Job，恢复所述冒烟用例的执行运行环境或所述合并后的目标分支的运行环境。通过上述设计，通过触发恢复Job，来恢复执行环境，可便于下一代码对应文件的生成以及对应服务部署Job的触发。

在本实施例中，恢复Job也是在Jenkins服务器中创建，为一种现有技术。

如图2所述，本实施例第二方面提供了一种实现实施例第一方面所述的仓库代码的合并方法的硬件装置，在本实施例第二方面中，以装置为Jenkins服务器举例，其包括：合并代码Job单元、第一判断单元、文件生成单元、第二判断单元和第一触发单元。

所述合并代码Job单元，用于通过合并代码Job，在git仓库的被监控分支中，获取最近一次变动代码对应的日志信息。

所述第一判断单元，用于判断所述日志信息中是否包含有识别字段。

所述文件生成单元，用于在所述第一判断单元判断出所述日志信息中包含有识别字段后，根据所述日志信息生成文件。

所述第二判断单元，用于判断所述文件是否存在。

在一个可能的设计中，所述Jenkins服务器还包括：获取单元、第三判断单元和第二触发单元。

所述获取单元，用于获取git仓库中被监控分支内变动代码的提交命令类型。

所述第三判断单元，用于判断所述提交命令类型是否属于所述合并代码Job中的触发命令类型。

所述第二触发单元，用于在所述第三判断单元判断所述提交命令类型属于所述合并代码Job中的触发命令类型时，自动触发所述合并代码Job。

所述合并代码Job单元，还用于通过所述合并代码Job，获取所述被监控分支中的所有代码，并从所有代码中得到所述被监控分支中的变动代码。

在一个可能的设计中，所述Jenkins服务器还包括：构建单元。

在一个可能的设计中，所述构建单元还用于：

在一个可能的设计中，所述Jenkins服务器还包括：第四判断单元、执行单元和发送单元。

所述第四判断单元，用于判断所述布尔值参数是否为真。

所述执行单元，在所述第四判断单元判断出所述布尔值参数为真时，对所述合并后的目标分支执行冒烟用例。

在一个可能的设计中，所述Jenkins服务器还包括：恢复单元。

在一个可能的设计中，所述Jenkins服务器还包括：删除单元。

本实施例第二方面提供的硬件装置的工作过程、工作细节和技术效果，可以参见实施例第一方面，于此不再赘述。

如图3所示，本实施例第三方面提供了一种仓库代码的合并系统，包含有实施例第一方面中用户终端、Gitee平台和Jenkins服务器。

所述用户终端，用于将变动代码上传至Gitee平台。

所述Gitee仓库，通信连接所述用户终端，用于接收所述用户终端上传的所述变动代码，并存储至内部git仓库的被监控分支中。

在一个可能的设计中：

所述用户终端还用于将所述变动代码的提交命令类型发送至Gitee平台。

所述Gitee平台，还用于接收所述用户终端上传的所述变动代码的提交命令类型，并存储至内部git仓库的被监控分支中。

本实施例第三方面提供的系统的工作过程、工作细节和技术效果，可以参见实施例第一方面，于此不再赘述。

如图4所示，本实施例第四方面提供了另一种执行实施例第一方面所述的仓库代码的合并方法的硬件装置，包括依次通信相连的存储器、处理器和收发器，其中，所述存储器用于存储计算机程序，所述收发器用于收发消息，所述处理器用于读取所述计算机程序，执行如实施例第一方面所述的仓库代码的合并方法。

具体举例的，所述存储器可以但不限于包括随机存取存储器(RAM)、只读存储器(ROM)、闪存(Flash Memory)、先进先出存储器(FIFO)和/或先进后出存储器(FILO)等等；所述处理器可以不限于采用型号为STM32F105系列的微处理器、ARM(Advanced RISCMachines)、X86等架构处理器或集成NPU(neural-network processing units)的处理器；所述收发器可以但不限于为WiFi(无线保真)无线收发器、蓝牙无线收发器、通用分组无线服务技术(General Packet Radio Service，GPRS)无线收发器、紫蜂协议(基于IEEE802.15.4标准的低功耗局域网协议，ZigBee)无线收发器、3G收发器、4G收发器和/或5G收发器等。

本实施例第四方面提供的装置的工作过程、工作细节和技术效果，可以参见实施例第一方面，于此不再赘述。

本实施例第五方面提供了一种存储包含有实施例第一方面所述的仓库代码的合并方法的指令的计算机可读存储介质，即所述计算机可读存储介质上存储有指令，当所述指令在计算机上运行时，执行如第一方面所述的仓库代码的合并方法。其中，所述计算机可读存储介质是指存储数据的载体，可以但不限于包括软盘、光盘、硬盘、闪存、优盘和/或记忆棒(Memory Stick)等，所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。

本实施例第五方面提供的计算机可读存储介质的工作过程、工作细节和技术效果，可以参见实施例第一方面，于此不再赘述。

本实施例第六方面提供了一种包含指令的计算机程序产品，当所述指令在计算机上运行时，使所述计算机执行如实施例第一方面所述的仓库代码的合并方法，其中，所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。

以上所描述的多个实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台仓库代码的合并装置执行各个实施例或者实施例的某些部分所述的方法。

本发明不局限于上述可选实施方式，任何人在本发明的启示下都可得出其他各种形式的产品，但不论在其形状或结构上作任何变化，凡是落入本发明权利要求界定范围内的技术方案，均落在本发明的保护范围之内。

Claims

1.一种仓库代码的合并方法，其特征在于，包括：

通过合并代码Job，在git仓库的被监控分支中，获取最近一次变动代码对应的日志信息；

判断所述日志信息中是否包含有识别字段，若是，则根据所述日志信息生成文件，其中，所述识别字段根据最近一次变动代码所执行的功能得到；

判断所述文件是否存在，若是，则根据所述文件，触发所述文件对应的服务部署Job，以通过所述服务部署Job，在容器中获取git仓库中的目标分支和所述被监控分支，以便将所述被监控分支中的变动代码合并到所述目标分支中，并将合并后的目标分支部署到对应的运行环境中。

2.如权利要求1所述的方法，其特征在于，在获取最近一次变动代码对应的日志信息前，所述方法还包括：

获取git仓库中被监控分支内变动代码的提交命令类型；

判断所述提交命令类型是否属于所述合并代码Job中的触发命令类型，若是，则自动触发所述合并代码Job；

通过所述合并代码Job，获取所述被监控分支中的所有代码，并从所有代码中得到所述被监控分支中的变动代码；

通过所述合并代码Job，获取所述git仓库中的目标分支，将所述变动代码合并到所述目标分支中，得到新目标分支。

3.如权利要求2所述的方法，其特征在于，所述方法还包括：

构建一个布尔值参数，其中，所述布尔值参数是用于控制所述合并后的目标分支执行冒烟用例的参数。

4.如权利要求3所述的方法，其特征在于，在触发所述文件对应的服务部署Job后，所述方法还包括：

判断所述布尔值参数是否为真；

5.如权利要求4所述的方法，其特征在于，在所述合并后的目标分支执行冒烟用例失败或触发所述文件对应的服务部署Job失败时，所述方法还包括：

6.如权利要求2所述的方法，其特征在于，将所述变动代码合并到所述目标分支中，得到新目标分支，包括：

通过所述合并代码Job，将所述变动代码存储到预设路径中；

在所述预设路径中，将所述变动代码合并到所述目标分支中，得到所述新目标分支。

7.如权利要求6所述的方法，其特征在于，在得到所述新目标分支后，所述方法还包括：

8.一种仓库代码的合并装置，其特征在于，包括：合并代码Job单元、第一判断单元、文件生成单元、第二判断单元和第一触发单元；

所述第二判断单元，用于判断所述文件是否存在；

9.一种仓库代码的合并装置，其特征在于：包括依次通信相连的存储器、处理器和收发器，其中，所述存储器用于存储计算机程序，所述收发器用于收发消息，所述处理器用于读取所述计算机程序，执行如权利要求1～7任意一项所述的仓库代码的合并方法。

10.一种计算机可读存储介质，其特征在于：所述计算机可读存储介质上存储有指令，当所述指令在计算机上运行时，执行如权利要求1～7任意一项所述的仓库代码的合并方法。