一种基于版本控制流程的目标代码合并控制方法及系统与流程

文档序号:15888484发布日期:2018-11-09 19:49阅读:147来源:国知局
一种基于版本控制流程的目标代码合并控制方法及系统与流程

本发明涉及计算机应用技术领域,尤其涉及一种基于版本控制流程的目标代码合并控制方法及系统。

背景技术

现有的代码检测技术主要包括全量检测和本地增量检测,全量检测基于全量代码进行扫描,常用的扫描工具有coverity和cpplint;增量检测由开发人员在本地自主进行,没有版本控制流程结合起来。

现有技术方案下,全量检测存在扫描过程靠后,代码扫描量大,耗时长,结果庞杂,无法定位对应责任人,推动解决困难,问题解决率低等问题;增量检测则位于开发人员本地,没有与版本控制流程结合,导致开发人员主控性过大,出现问题解决率低等问题。



技术实现要素:

为了解决上述技术问题,本发明提出了一种基于版本控制流程的目标代码合并控制方法及系统。本发明具体是以如下技术方案实现的:

第一方面,一种基于版本控制流程的目标代码合并控制方法,包括:

配置检测任务,所述配置检测任务包括配置检测服务器,以及配置版本控制系统中的检测对象,所述版本控制系统用于对代码进行版本管理,所述版本控制系统包括开发分支和目标分支;所述检测服务器用于对开发分支提交的代码进行自动检测;

获取提交至开发分支的目标代码;

判断所述目标代码是否属于所述检测对象;

若是,则触发所述检测服务器以实现对所述目标代码的增量式检测和检测结果的反馈,并根据所述检测结果控制所述目标代码向目标分支的合并流程。

第二方面,一种基于版本控制流程的目标代码合并控制系统,包括版本控制系统、检测任务配置管理器和检测服务器;

所述检测任务配置管理器包括:

检测任务配置模块,用于配置检测任务,所述配置检测任务包括配置检测服务器,以及配置版本控制系统中的检测对象,所述版本控制系统包括开发分支和目标分支;

目标代码获取模块,用于获取提交至开发分支的目标代码;

判断模块,用于判断所述目标代码是否属于所述检测对象;

触发模块,用于触发所述检测服务器以实现对所述目标代码的增量式检测和检测结果的反馈;

流程控制模块,用于根据所述检测结果控制所述目标代码向目标分支的合并流程。

第三方面,一种计算机可读存储介质,用于存储程序,所述程序被执行时实现上述一种基于版本控制流程的目标代码合并控制方法的步骤。

本发明提供了一种基于版本控制流程的目标代码合并控制方法及系统,本方案中将代码检测过程与版本控制流程相结合,对提交的代码能够进行增量式检测。相较于现有技术中的全量检测,本方案检测过程靠前,检测速度快,结果简洁,相较于现有技术中的本地增量检测,本方案能够与版本控制流程相结合。若增量式检测不合格,目标代码无法合并入目标分支,只有开发人员解决目标代码存在的问题后,才可以最终合并到目标分支。因此本方案基于版本控制流程和增量式检测保证了开发人员提交的目标代码的质量。

附图说明

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

图1是本发明实施例提供的一种基于版本控制流程的目标代码检测方法实施环境示意图;

图2是本发明实施例提供的一种基于版本控制流程的目标代码合并控制方法流程图;

图3是本发明实施例提供的检测服务器执行代码增量式检测的方法流程图;

图4是本发明实施例提供的基于所述测试用例库对代码进行增量式检测的方法流程图;

图5是本发明实施例提供的测试用例部署结构示意图;

图6是本发明实施例提供的根据检测结果控制目标代码向目标分支的合并流程图;

图7是本发明实施例提供的检测任务配置管理器框图;

图8是本发明实施例提供的检测服务器框图;

图9是本发明实施例提供的检测模块框图;

图10是本发明实施例提供的流程控制模块框图;

图11是本发明实施例提供的基于版本控制流程的目标代码合并控制系统运行设备示意图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分的实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本发明保护的范围。

需要说明的是,本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

当前主流的静态代码检测方法基本基于代码的全量扫描,通常都是多数开发人员将代码提交后,在产品的主线或者发布线进行代码的全量扫描,代码的全量扫描的缺点比较明显,主要包括:扫描时机比较靠后,提交到主线或者发布线的代码如果有问题,需要回滚,影响主线或者发布线中代码的功能;扫描时间慢,比如浏览器内核代码的全量扫描可能要数个小时;扫描结果多,开发在有限的时间很难去解决问题;责任划分不清楚,多数开发只会对自己提交的代码负责,全量扫描很难定位到具体问题的出现位置,也难以找到责任人。

此外,现有技术中还存在一些本地的增量检测方法,但是本地检测很容易被开发人员自由控制,并且无法与版本控制流程紧密的结合在一起。为了提升代码检测的效率,将检测流程与版本控制流程紧密结合在一起,因此,本发明实施例提供一种基于版本控制流程的目标代码合并控制方法及系统。

参见图1,本发明实施例提供的一种基于版本控制流程的目标代码合并控制方法实施环境示意图。该实施环境包括:分布式版本控制系统101、检测任务配置管理器102和检测服务器103。

其中,分布式版本控制系统101用于进行代码版本控制管理,检测服务器103用于实施代码增量式检测,检测任务配置管理器102用于配置检测任务,并控制检测服务器103进行代码增量式检测,以及控制分布式版本控制系统101中的代码版本控制流程。

分布式版本控制系统101、检测任务配置管理器102和检测服务器103之间可以通过无线网络或者有线网络进行通信。

参见图2,本发明实施例具体提供了一种基于版本控制流程的目标代码合并控制方法,包括:

s101.配置检测任务,所述配置检测任务包括配置检测服务器,以及配置分布式版本控制系统中的检测对象,所述分布式版本控制系统包括开发分支和目标分支。

所述分布式版本控制系统可以有效、高速的处理各种项目版本管理,常见的有svn和git。本发明实施例将以git为例描述基于版本控制流程的目标代码合并控制方法。

git是linustorvalds为了帮助管理linux内核开发而开发的一个开放源码的版本控制软件。git支持从服务器上克隆完整的git仓库(包括代码和版本信息)到单机上,并支持创建分支,以及合并分支。通常情况下,各个部门的开发人员在各自对应的开发分支上提交代码,git支持将各个开发分支上的代码合并到目标分支。通常目标分支也可以被称为主分支,其具体可以为master分支或者release分支。当开发分支上的代码被合并入目标分支后,代码即完成了在开发流程上的合并。

本发明实施例中配置检测任务的目的在于保证在开发人员提交代码的时候可以触发检测服务器对于目标代码的自动检测,本发明实施例中具体公开下述配置内容:

1)仓库地址:分布式版本控制系统中需要被进行增量式检测的代码仓库的地址,配置仓库地址的目的在于确保增量式检测发生在指定的仓库。

2)开发分支:对于各个部门的开发人员,其提交的代码可能位于不同的开发分支上。通常情况下,各个部门的开发人员都会基于拉取属于自己开发分支的代码,在代码开发完毕后,也会被提交至属于开发人员自己的开发分支,而开发分支的代码被存储在某个代码仓库之中。因此,在配置开发分支和仓库地址之后,即可确定哪些代码被提交会触发自动检测。

事实上,在实际的开发流程中,对于各个开发分支都应该施行目标代码的检测,为了能够检测所有开发分支提交的代码,本发明实施例中使用正则表达式匹配所有开发分支的情况。为了提高匹配效率可以和开发人员约定所有开发分支使用相同前缀,比如采用“dev/”这样的名字作为开发分支前缀,从而达到对所有开发分支上提交的代码均进行自动检测的目的。

3)检测服务器:检测服务器用于对开发分支提交的代码进行自动检测。为了使得检测服务器具备自动检测的能力,本发明实施例中在检测服务器中进行了下述配置:

检测脚本:检测脚本可以配置于检测服务器或代码仓库之中,用于对开发分支提交的代码进行自动检测。检测脚本可以包括下述内容:增量式检测工具的部署和更新相关代码,检测工具自动执行的相关代码以及检测结果处理的相关代码。检测脚本能够按照预设的代码检查规则进行增量式检测,比如是否存在tab键,是否不允许log输出的检查等。

环境变量:检测脚本运行所需环境变量。所述环境变量与开发分支可以存在对应关系,即不同的开发分支提交的代码在自动检测时,检测脚本所依赖的环境变量可以不同。

检测结果配置:检测结果评价所需的评价规则。所述评价规则与开发分支可以存在对应关系,即不同的开发分支提交的代码在自动检测时,检测脚本所依据的评价规则可以不同。比如可以灵活设置不同级别的问题数满足什么条件时测试通过与不通过,比如代码质量检测结果的warning级别问题数小于等于5时为通过,大于5时为不通过。

进一步地,为了提升配置检测任务的规范性,本发明实施例中能够进行检测任务配置的相关人员至少应当对于代码仓库具备开发权限以上的管理权限,并且通过安全认证。

s103.获取提交至开发分支的目标代码。

所述目标代码为开发人员每一次完成的并且向开发分支提交的代码。

s105.判断所述目标代码是否属于所述检测对象。

根据上述配置内容可知,在步骤s105中可以判断步骤s103中的开发分支是否属于配置任务中配置的开发分支,并且开发分支所对应的代码仓库的地址是否也同样位于配置任务中,若是,则所述目标代码属于检测对象。

s107.若是,则触发所述检测服务器以实现对所述目标代码的增量式检测和检测结果的反馈,并根据所述检测结果控制所述目标代码向目标分支的合并流程。

增量式检测即只对开发人员改动的代码部分进行代码检测,没有改动的部分不进行代码检测,检测出来的代码质量问题由代码提交者(开发人员)负责。增量式检测由开发人员将代码提交到开发分支触发,属于一种代码静态检测。

git代码仓库是公司级的代码管理平台,当开发人员提交代码时,会依据检测任务配置的开发分支,触发对应的检测服务器进行代码的增量式检测。本发明实施例进一步公开检测服务器执行代码增量式检测的方法,如图3所示,包括:

p1.将所述目标代码所在的开发分支的代码拉取至检测服务器本地。

p1的目的在于确保检测服务器上存在最新的代码。

p3.执行检测脚本。

具体地,所述检测脚本的主要功能包括:部署或者更新增量式代码检测工具,控制执行增量式代码检测工具,和控制检测结果的迁移和删除。

p5.向分布式版本控制系统输出检测结果。

具体地,可以向所述开发分支输出检测结果,也可以同时向数据统计中心输出检测结果,所述数据统计中心用于对每次增量代码的检测结果进行记录和后续的统计。

进一步地,在所述增量式检测完成后,所述开发分支对应的环境变量也相应被修改,所述环境变量位于所述检测服务器之中。所述环境变量保存了所述开发分支最后一次提交代码的提交位置。本发明实施例中环境变量被定义为git_branch_revision_last,对于git而言,就是git中最后一次提交的commitid被录入环境变量git_branch_revision_last。

本发明实施例中检测脚本中调用两种工具,即增量代码检测工具和测试用例库。

所述增量代码检测工具用于基于所述测试用例库对代码进行增量式检测,如图4所示,所述检测方法包括:

a1.根据所述目标代码获取增量代码。

具体地,所述增量代码的获取可以通过增量代码检测工具中的命令行工具实现。

所述命令行工具获取通过检测服务器提供的环境变量得到所述开发分支上一次提交的代码位置,然后通过gitdiff命令获取到增量代码。

a2.根据所述增量代码向所述测试用例库调取目标测试用例。

a3.运行所述目标测试用例。

具体地,在所述目标测试用例的运行过程中,还可以用到一些通用的测试用例,为了避免代码冗余,降低耦合度可以将通用的测试用例单独罗列出来,生成公共测试用例库,本发明实施例中所述公共测试用例库内嵌于所述增量代码检测工具之中。

a4.生成检测结果。

本发明测试用例库也可以按照开发人员的代码管理方法进行管理,对于不同开发分支的代码进行测试的相应的测试用例也被一同放置在开发分支上。本发明测试用例库中测试用例按照目录层级部署,如图5所示,通过白名单控制,以便于根据增量代码定位目标测试用例所在的目录。测试用例执行时只运行目标测试用例所在的目录以及子目录中的代码,本发明实施例中越是通用的检测规则,应该越放在顶层目录。

具体地,本发明实施例进一步公开根据所述检测结果控制所述目标代码向目标分支的合并流程,如图6所示,包括:

s1071.获取合并请求。

合并请求即mr(mergerequest),开发人员申请将目标代码合并到稳定的目标分支的过程。

具体地,当开发人员对自己提交的目标代码进行合并申请时,目标代码的增量式检测结果会同步展现出来。开发人员若对检测结果不满意,可以不发起对于本次目标代码的合并请求,而是重新修改,重新提交,直至检测结果满意后发起合并请求。

s1073.响应于所述合并请求,判断检测结果是否合格。

s1075.若合格,则将所述目标代码合并入目标分支。

s1077.若不合格,则拒绝将所述目标代码合并入目标分支,并发布回滚指令以便于开发人员重新提交修改后的目标代码。

在一种可行的实施方式中,可以让目标代码的复检员(codereview)参考检测结果决定代码是否合格,如果存在问题则直接拒绝开发人员发起的合并请求,并发布回滚指令以便于开发人员重新提交修改后的目标代码,对应的开发人员修改完代码质量问题后,再次走提交流程,再次进入下一个增量式检测。

复检员审阅代码后,通常用lgtm(全屏lookgoodtome)作为回复,当检测结果合格,并且复检员认为代码没问题时,回复lgtm,并将代码合并入目标分支。

在另一种可行实施例中,可以不依赖复检员,直接根据检测结果合并或者拒绝合并。

在另一种可行的实施例中,若检测结果不合格,则直接不允许开发人员发起合并请求。

本发明实施例提供一种基于版本控制流程的目标代码合并控制方法,能够直接解决当前全量代码检测过程中遇到的检测慢,检测阶段靠后,检测结果繁多,责任人无法明确,问题解决率低等问题。检测流程工作在独立服务器上,通过正则匹配,不需要开发本地配合接入,减少本地检测接入的推动成本。本技术方案的检测规则与版本控制流程结合在一起,并且针对提交代码进行质量检测,检测速度快,问题责任开发者明确,与提交流程绑定,通过一定的约束力可以高效解决当次提交的代码质量问题,长期运行可以整体提升项目代码质量。

本发明另一实施例提供了一种基于版本控制流程的目标代码合并控制系统,包括分布式版本控制系统101、检测任务配置管理器102和检测服务器103;

所述检测任务配置管理器102,如图7所示,包括:

检测任务配置模块1021,用于配置检测任务,所述配置检测任务包括配置检测服务器,以及配置分布式版本控制系统中的检测对象,所述分布式版本控制系统包括开发分支和目标分支。

目标代码获取模块1022,用于获取提交至开发分支的目标代码。

判断模块1023,用于判断所述目标代码是否属于所述检测对象。

触发模块1024,用于触发所述检测服务器以实现对所述目标代码的增量式检测和检测结果的反馈。

流程控制模块1025,用于根据所述检测结果控制所述目标代码向目标分支的合并流程。

所述配置分布式版本控制系统中的检测对象包括配置仓库地址和开发分支,所述配置检测服务器包括配置检测脚本、环境变量和检测结果评价所需的评价规则。

如图8所示,所述检测服务器103包括:

代码拉取模块1031,用于将所述目标代码所在的开发分支的代码拉取至检测服务器本地。

检测模块1032,用于执行检测脚本;所述检测脚本调用增量代码检测工具和测试用例库。

输出模块1033,用于向分布式版本控制系统输出检测结果。

如图9所示,所述检测模块1033包括:

增量代码获取单元1031,用于根据所述目标代码获取增量代码。

测试用例调用单元1032,用于根据所述增量代码向所述测试用例库调取目标测试用例。

测试用例运行单元1033,用于运行所述目标测试用例。

检测结果生成单元1034,用于生成检测结果。

如图10所示,所述流程控制模块1025包括:

合并请求获取单元10251,用于获取合并请求。

判断单元10252,用于响应于所述合并请求,判断检测结果是否合格。

合并单元10253,用于将所述目标代码合并入目标分支。

拒绝单元10254,用于拒绝将所述目标代码合并入目标分支,并发布回滚指令以便于开发人员重新提交修改后的目标代码。

本发明的装置实施例中所述的一种基于版本控制流程的目标代码合并控制系统与方法实施例基于同样地发明构思。

本发明的实施例还提供了一种存储介质,所述存储介质可用于保存用于实现方法实施例中基于版本控制流程的目标代码合并控制方法的程序代码。可选地,在本实施例中,上述存储介质可以位于计算机网络的多个网络设备中的至少一个网络设备。可选地,在本实施例中,上述存储介质可以包括但不限于:u盘、只读存储器(rom,read-onlymemory)、随机存取存储器(ram,randomaccessmemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

请参阅图11,图11是本发明实施例公开的基于版本控制流程的目标代码合并控制系统运行设备结构示意图。所述运行设备可以包括上述基于版本控制流程的目标代码合并控制系统中一个或几个功能模块。该运行设备800可因配置或性能不同而产生比较大的差异,可以包括一个或一个以上中央处理器(centralprocessingunits,cpu)822(例如,一个或一个以上处理器)和存储器832,一个或一个以上存储应用程序842或数据844的存储介质830(例如一个或一个以上海量存储设备)。其中,存储器832和存储介质830可以是短暂存储或持久存储。存储在存储介质830的程序可以包括一个或一个以上模块(图示未示出),每个模块可以包括对运行设备中的一系列指令操作。更进一步地,中央处理器822可以设置为与存储介质830通信,在运行设备800上执行存储介质830中的一系列指令操作。运行设备800还可以包括一个或一个以上电源826,一个或一个以上有线或无线网络接口850,一个或一个以上输入输出接口858,和/或,一个或一个以上操作系统841,例如windowsservertm,macosxtm,unixtm,linuxtm,freebsdtm等等。上述方法实施例所执行的步骤可以基于该图11所示的运行设备结构。

需要说明的是:上述本发明实施例的先后顺序仅仅为了描述,不代表实施例的优劣。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成,也可以通过程序来指令相关的硬件完成,所述的程序可以存储于一种计算机可读存储介质中,上述提到的存储介质可以是只读存储器,磁盘或光盘等。

以上所述仅为本发明的较佳实施例,并不用以限制本发明,凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1