一种代码提交方法和设备与流程

本申请实施例涉及通信技术领域，特别涉及一种代码提交方法和设备。

背景技术：

在现有技术中，是通过工具监控指定代码仓库的变更，在发现有新代码提交入库时，将代码仓库的新代码检出到本地，按照配置项和配置步骤，触发持续集成执行，但触发持续集成执行的一个重要前提是：代码必须真实的提交到代码仓库，否则不会触发任务的执行。而提交入库的代码，如果因为build break或测试执行失败导致持续集成的任务失败，已经对最终的测试结果和检出代码到本地的其他团队成员产生了实质性的影响，其他人或任务必须依赖此次失败修复后，才能正常继续执行，这种方式不利于尽早发现问题、且违反了过程成本的软件工程原则，另外，这种方式没有把code review(CR：Code Review，代码审查)的环节纳入整个流程中，因此无法保证提交代码的准确性。

技术实现要素：

针对现有技术中的不利于尽早发现问题，且无法保证代码准确性的缺陷，本申请提出了一种代码提交方法，包括：

获取预备向代码仓库提交的待提交增量代码；

对所述待提交增量代码进行检测；

提交检测通过的待提交增量代码到所述代码仓库。

可选的，所述对所述待提交增量代码进行检测，具体包括：

对所述待提交增量代码进行代码审查；

对所述待提交增量代码进行任务测试。

若所述代码审查通过且所述任务测试通过，则确定对所述待提交增量代码的检测通过。

可选的，所述对所述待提交增量代码进行代码审查，具体包括：

将所述待提交增量代码发送给多个审查者进行审查；

接收审查者反馈的审查结果；

如审查结果为超过预设个数的审查者审查所述待提交增量代码通过，则确定所述待提交增量代码审查通过。

可选的，所述对所述待提交增量代码进行任务测试，具体包括：

对所述待提交增量代码的依赖代码执行编译；

在对依赖代码执行编译时进行指定任务的任务测试；

在对依赖代码编译完成之后进行预设任务的任务测试；

获取指定任务与预设任务的任务测试结果；

若任务测试结果为全部通过，则确定对所述待提交增量代码的任务测试通过。

可选的，所述对所述待提交增量代码的依赖代码执行编译，具体包括：

监控所述待提交增量代码的依赖代码是否发生变化；

编译发生了变化的依赖代码；

提取没有发生变化的依赖代码对应的库文件到指定位置，以便在对所述待提交增量代码进行编译时，直接引用所述库文件。

可选的，进行任务测试，具体包括：

基于所述待提交增量代码的存储路径地址在配置库中指定位置查找任务配置文件；

若在指定位置没有查找到所述任务配置文件，则在所述指定位置的父目录所在位置查找所述任务配置文件，并利用查找到的任务配置文件进行任务 测试；

若在父路径所在位置查找到所述任务配置文件，提取查找到的最新的任务配置文件，并利用提取的最新的任务配置文件进行任务测试；

若在父路径所在位置未查找到所述任务配置文件，基于预设的通用配置来进行任务测试。

可选的，所述提交检测通过后的待提交增量代码到所述代码仓库，具体包括：

判断检测通过后的待提交增量代码是否存在多个；

若判断结果为是，判断是否存在检测通过后的多个待提交增量代码对应于同一源代码，且对应于同一源代码的检测通过后的多个待提交增量代码进行代码修改的位置一致；

若判断结果为是，则确定对应同一个源代码，且代码修改的位置一致的多个检测通过后的待提交增量代码为存在冲突且检测通过后的待提交增量代码；

基于优先级评估因素对多个存在冲突且检测通过后的待提交增量代码进行优先级评估；

按照评估得到的优先级顺序从高到低依次提交存在冲突且检测通过后的待提交增量代码到所述代码仓库。

可选的，所述优先级评估因素包括对代码进行修改的修改时间，代码修改行数，以及代码重要性；

所述基于优先级评估因素对多个存在冲突且检测通过后的待提交增量代码进行优先级评估，具体包括：

基于影响程度对各个存在冲突且检测通过的待提交增量代码的代码重要性进行评估，以及获取各个存在冲突且检测通过的待提交增量代码的修改时间和代码修改行数；

基于修改时间，代码修改行数以及代码重要性来对各个存在冲突且检测通过的待提交增量代码的优先级进行评估；

基于评估结果确定各个存在冲突且检测通过的待提交增量代码的优先级顺序。

本申请还提出了一种代码提交设备，包括：

获取模块，用于获取预备向代码仓库提交的待提交增量代码；

检测模块，用于对所述待提交增量代码进行检测；

提交模块，用于提交检测通过的待提交增量代码到所述代码仓库。

可选的，所述检测模块，具体用于：

对所述待提交增量代码进行代码审查；

对所述待提交增量代码进行任务测试。

若所述代码审查通过且所述任务测试通过，则确定对所述待提交增量代码的检测通过。

可选的，所述检测模块对所述待提交增量代码进行代码审查，具体包括：

将所述待提交增量代码发送给多个审查者进行审查；

接收审查者反馈的审查结果；

如审查结果为超过预设个数的审查者审查所述待提交增量代码通过，则确定所述待提交增量代码审查通过。

可选的，所述检测模块对所述待提交增量代码进行任务测试，具体包括：

对所述待提交增量代码的依赖代码执行编译；

在对依赖代码执行编译时进行指定任务的任务测试；

在对依赖代码编译完成之后进行预设任务的任务测试；

获取指定任务与预设任务的任务测试结果；

若任务测试结果为全部通过，则确定对所述待提交增量代码的任务测试 通过。

可选的，所述检测模块对所述待提交增量代码的依赖代码执行编译，具体包括：

监控所述待提交增量代码的依赖代码是否发生变化；

编译发生了变化的依赖代码；

提取没有发生变化的依赖代码对应的库文件到指定位置，以便在对所述待提交增量代码进行编译时，直接引用所述库文件。

可选的，所述检测模块进行任务测试，具体包括：

基于所述待提交增量代码的存储路径地址在配置库中指定位置查找任务配置文件；

若在指定位置没有查找到所述任务配置文件，则在所述指定位置的父目录所在位置查找所述任务配置文件，并利用查找到的任务配置文件进行任务测试；

若在父路径所在位置查找到所述任务配置文件，提取查找到的最新的任务配置文件，并利用提取的最新的任务配置文件进行任务测试；

若在父路径所在位置未查找到所述任务配置文件，基于预设的通用配置来进行任务测试。

可选的，所述提交模块，具体用于：

判断检测通过后的待提交增量代码是否存在多个；

若判断结果为是，判断是否存在检测通过后的多个待提交增量代码对应于同一源代码，且对应于同一源代码的检测通过后的多个待提交增量代码进行代码修改的位置一致；

若判断结果为是，则确定对应同一个源代码，且代码修改的位置一致的多个检测通过后的待提交增量代码为存在冲突且检测通过后的待提交增量代码；

基于优先级评估因素对多个存在冲突且检测通过后的待提交增量代码进行优先级评估；

按照评估得到的优先级顺序从高到低依次提交存在冲突且检测通过后的待提交增量代码到所述代码仓库。

可选的，所述优先级评估因素包括对代码进行修改的修改时间，代码修改行数，以及代码重要性；

所述提交模块基于优先级评估因素对多个存在冲突且检测通过后的待提交增量代码进行优先级评估，具体包括：

基于影响程度对各个存在冲突且检测通过的待提交增量代码的代码重要性进行评估，以及获取各个存在冲突且检测通过的待提交增量代码的修改时间和代码修改行数；

基于修改时间，代码修改行数以及代码重要性来对各个存在冲突且检测通过的待提交增量代码的优先级进行评估；

基于评估结果确定各个存在冲突且检测通过的待提交增量代码的优先级顺序。

与现有技术相比，本申请中通过获取预备向代码仓库提交的待提交增量代码；对所述待提交增量代码进行检测；提交检测通过的待提交增量代码到所述代码仓库，从而在提交代码之前先对代码进行检测，保证了提交代码的准确性，且可以尽早发现问题，不会影响到其他需要利用该提交代码的程序或者过程。

附图说明

图1为本申请提出的一种代码提交方法的流程示意图；

图2为本申请提出的一种代码提交设备的结果示意图。

具体实施方式

如背景技术，现有技术中的风险评估方案无法准确评估风险，为此，本申请中为了更好地评估风险，提出了一种代码提交方法，如图1所示，包括以下步骤：

步骤101、获取预备向代码仓库提交的待提交增量代码。

在一个具体的应用场景中，在用户修改完代码后，会预备提交该代码到代码仓库，也由此可以获取修改后的预备向代码仓库提交的待提交增量代码，至于与此不同的其他代码，则不会执行获取的操作。

步骤102、对待提交增量代码进行检测。

在获取到待提交增量代码之后，就需要对待提交增量代码进行检测，而具体的检测包括：对待提交增量代码进行代码审查和对待提交增量代码进行任务测试，也即包括以下两个过程：

(1)、对待提交增量代码进行代码审查：

将待提交增量代码发送给多个审查者进行审查；接收审查者反馈的审查结果；如审查结果为超过预设个数的审查者审查待提交增量代码通过，则确定待提交增量代码审查通过。

具体的，将待提交增量代码发送给审查者，审查者审查该待提交增量代码后，会给出审查结果，通过或者不通过，而为了保证审查的准确性，可以预设只有在超过预设个数的审查者审查通过，例如可以设置为2个审查者审查通过，则可以确定该待提交增量代码通过。

(2)、对待提交增量代码进行任务测试，具体包括：

对待提交增量代码的依赖代码执行编译；在对依赖代码执行编译时进行指定任务的任务测试；在对依赖代码编译完成之后进行预设任务的任务测试；获取指定任务与预设任务的任务测试结果；若任务测试结果为全部通过，则确定对待提交增量代码的任务测试通过。

有些测试任务需要在进行编译时进行任务测试，例如UT(Unit Test，单元测试)，还有一些需要在编译完成之后再进行任务测试，例如BVT(Build Verification Test，冒烟测试)，具体的根据其测试任务的特性来选择相应的时机来进行任务测试，在此不再进行赘叙，而任务测试通过需要所有进行的任务测试的结果都通过。

对待提交增量代码的依赖代码执行编译，具体包括：

监控待提交增量代码的依赖代码是否发生变化；编译发生了变化的依赖代码；提取没有发生变化的依赖代码对应的库文件到指定位置，以便在对待提交增量代码进行编译时，直接引用库文件。

具体的编译不需要进行全量的编译，由于待提交增量代码会引用某些代码来实现相应的功能，被引用的代码即为待提交增量代码的依赖代码，也由此，在进行编译时，只需要编译发生了变化的依赖代码，对与没有发生变化的依赖代码，可以直接提取依赖代码的库文件到指定位置，而不需要执行编译的过程，以此在保证了功能的实现的同时，减少了资源的消耗和提升了效率。

而具体的，进行任务测试，具体包括：

基于待提交增量代码的存储路径地址(后续待提交增量代码根据存储路径地址进行代码的提交过程)在配置库中指定位置查找任务配置文件；若在指定位置没有查找到任务配置文件，则在指定位置的父目录所在位置查找任务配置文件，并利用查找到的任务配置文件进行任务测试；若在父路径所在位置查找到任务配置文件，提取查找到的最新的任务配置文件，并利用提取的最新的任务配置文件进行任务测试；若在父路径所在位置未查找到任务配置文件，基于预设的通用配置来进行任务测试。

具体的，由于需要根据任务配置文件来进行任务测试，而测试的任务有可能之前已经进行过，因此会存在任务配置文件，在此情况下可以利用之前 的任务配置文件来进行任务测试，而若之前进行过任务测试，其任务配置文件会存在指定的位置(可以基于待提交增量代码的存储路径地址查找到)，或者指定位置的父目录所在位置，因此先在指定位置查找，若查找到，则根据任务配置文件进行任务测试；若没有查找到，则在父目录所在位置查找，也即在指定位置的上一层所在的位置进行查找，若查找到，则基于查找到的最新任务配置文件进行任务测试；若之前没有进行过任务测试，也即不会存在任务配置文件，在此情况下，就可以基于通用配置来进行任务测试。

如此通过对待提交增量代码进行对待提交增量代码进行代码审查以及任务测试，当代码审查通过且任务测试通过时，确定对待提交增量代码的检测通过。

具体的，经过步骤102对待提交增量代码进行检测后，会有两种结果，检测通过或不通过，若检测通过，则执行步骤103、若检测不通过，则结束操作和/或进行检测不通过告警。

步骤103、提交检测通过的待提交增量代码。

由于只会提交检测通过的待提交增量代码到所述代码仓库，因此具体的提交过程包括：

判断检测通过后的待提交增量代码是否存在多个；若判断结果为是，判断是否存在检测通过后的多个待提交增量代码对应于同一源代码，且对应于同一源代码的检测通过后的多个待提交增量代码进行代码修改的位置一致；若判断结果为是，则确定对应同一个源代码，且代码修改的位置一致的多个检测通过后的待提交增量代码为存在冲突且检测通过后的待提交增量代码；基于优先级评估因素对多个存在冲突且检测通过后的待提交增量代码进行优先级评估；按照评估得到的优先级顺序从高到低依次提交存在冲突且检测通过后的待提交增量代码到所述代码仓库。

具体的，由于可能出现同一源代码可能被多个修改者同时修改，且修改 的位置一致(具体为修改的代码行数，例如修改都是第7行)，这样会产生多个待提交增量代码，且多个待提交增量代码的对应于同一源代码，在此情况下，由于这多个待提交增量代码之间是存在冲突的，在此情况下可以对多个待提交增量代码进行优先级评估，以确定优先级的高低，最后基于优先级的高低来确定提交的顺序，在一个具体的实施例中，优先级的评估因素可以包括对代码进行修改的修改时间，代码修改行数，以及代码重要性；具体的，若其他两个因素一致，修改时间越早，对应的优先级越高；代码重要性越高(也即修改后的代码的影响程度越大)，对应的优先级越高；代码修改行数越多，对应的优先级越高；在此情况下，基于优先级评估因素对多个存在冲突且检测通过的待提交增量代码进行优先级评估，具体包括：

基于影响程度对各个存在冲突且检测通过的待提交增量代码的代码重要性进行评估，以及获取各个存在冲突且检测通过的待提交增量代码的修改时间和代码修改行数；基于修改时间，代码修改行数以及代码重要性来对各个存在冲突且检测通过的待提交增量代码的优先级进行评估；基于评估结果确定各个存在冲突且检测通过的待提交增量代码的优先级顺序；具体的，可以利用一个公式ΣP＝(C,K,T)来进行评估，具体的，C为代码修改行数，K为代码重要性(具体体现为修改后的代码的影响程度)，T为时间因素，初始基准值为1，按照提交时间的倒序排序，T的取值按照2^(n-1)递增，以此通过这三个因素来对多个存在冲突且检测通过后的待提交增量代码的优先级∑P进行评估。

为了对本申请进行进一步的说明，本申请实施例二还公开了一种具体场景下的代码提交，包括以下步骤；

步骤1，Review Board(即审查板，属于整个服务器的一部分)获取用户修改完代码后，通过RBT Client(RBT客户端)上传的修改后的代码，具体， 修改后的代码请求对修改后的代码进行审查的审查请求，Review Board为该请求分配一个审查ID(Review ID)，并将该Review ID返回给RBT Client，以便RBT Client将该Review ID以及其他的修改后的代码标识发送给Task Server(任务服务器)。

步骤2、Review Board将修改后的代码发送给多个审查者进行审查，并获取审查者的审查结果(审查通过或审查不通过)，同时Task Server基于Review ID轮询Review Board获取审查结果，若审查结果为有2个或多于2个审查者的审查结果为通过，则可以确定代码审查通过。

在具体的过程中，审查者在做完审查之后，给予审查通过的标记，一个审查者可以给出一个有效的+1ship it标记，可以设置要求有+2的标记才算本次审查通过，由此通过查询ship it来确定是否审查通过。

步骤3、Task Server获取测试任务所需的配置文件，并将配置文件发送给CISE(Continuous Integration Servevice Engine，持续集成服务执行引擎)，以便CISE基于配置文件来执行任务测试，并将测试结果返回给Task Server，Task Server在接收到测试结果后存储在数据库中。

Task Server基于代码标识，例如差别文件，源代码标识，版本服务器等，复原修改后的代码，当然，也可以直接获取修改后的代码，不过考虑到原代码可能比较长，以复原的方式效率较高，节约了资源，在赋予了修改后的代码后，查找与任务相关的配置文件(Yaml配置文件)，其中，具体包括以下三种情况：

一、首先从SVN/Git的脚本库中，检测指定位置是否存在Yaml配置文件，若存在，按照此配置文件执行整个任务；

二、若指定位置不存在Yaml配置文件，首先根据SVN/Git地址，根据指定位置的父路径(即只到trunk或branches这一级目录结构)在Task Server维护的配置库中进行查找，如果存在对应父目录的配置，则自动获取父目录 下最新的规则配置作为此新加入任务的配置使用；

三、对于不存在任何配置的任务，则从数据库中获取通用任务配置规则，以默认的执行规则进行处理。其中，默认配置规则是区分语言环境的，具体语言环境根据RBT Client传递的信息获取；

具体的，任务中也包括编译，具体的在准备编译时，先获取确定修改后的代码的依赖代码的变更情况，具体可以基于变更时间戳来进行判断，看是否一致，若一致，则说明未发生变更，基于makefile(其中存储有修改后的代码的标识与依赖代码之间的关系)生成最新makefile的配置副本，将之前的依靠编译生成依赖库的操作替换为指定路径的库文件，同时，动态更新Yaml配置文件(利用了makefile的配置副本，任务发送了变化)，下载库文件到指定路径，与makefile配置副本保持一致；对于发生变更的情况，则保持各配置项不变，按照依赖顺序执行编译构建过程；

CISE任务执行结束后，将最新编译生成的库文件上传至OSS(Open Storage Service)云空间中，按照文件名+Unix时间戳的形式存放，同时编译生成的模块信息和时间戳(也即标识)会以JSON串的形式通过Save接口更新到数据库中，作为后续任务执行的依据，JSON串data部分内容及格式如下：

步骤4、Task Server轮询数据库中的任务测试结果，若审查通过，则可以提交该修改后的代码。

当然需要提交代码时，在预提交的过程中，也即已经进行代码审查通过，和任务测试通过，若发现针对该修改后的代码对应的源代码还有其他的代码变更同步发生(也即多个代码变更对应同一个源代码，且进行修改的位置一致)，且多个代码变更也都是审查通过和任务测试通过的，针对该场景，本申请从对代码进行修改的修改时间(T)、变更复杂度(C)和关键路径影响(K)三个因素综合对比，其中，变更复杂度具体体现为代码修改行数，代码修改行数越多，变更复杂度越高；而关键路径影响则体现为代码重要性，依据公式计算向量模长判断优先级：ΣP＝(C,K,T)，其中：变更复杂度C以代码修改行数作为判断依据；关键路径影响以变更影响的方法个数作为判断依据，变更影响的方法个数越多，对应的，体现为代码重要性越高；对于时间因子T，则是靠前提交的任务取值较大其初始基准值为1，多个任务之间按照提交时间的倒序排序，T的取值按照2^(n-1)递增，从而保证靠前任务优先被提交；此处以对同一模块代码的相关文件的两个并发提交为实例进行说明，第一个提交任务的增量代码行数为20，影响方法个数为2，T取值为2(基准值为1，倒序排列)；第二个提交任务的增量代码行数是20，影响方法个数为6，T取值为1。计算向量的模长的公式为根据计算结果可以确定第二个提交任务的代码优先被提交。

本申请实施例还公开了一种代码提交设备，如图2所示，包括：

获取模块201，用于获取预备向代码仓库提交的待提交增量代码；

检测模块202，用于对所述待提交增量代码进行检测；

提交模块203，用于提交检测通过的待提交增量代码到所述代码仓库。

所述检测模块202，具体用于：

对所述待提交增量代码进行代码审查；

对所述待提交增量代码进行任务测试。

若所述代码审查通过且所述任务测试通过，则确定对所述待提交增量代码的检测通过。

所述检测模块202对所述待提交增量代码进行代码审查，具体包括：

将所述待提交增量代码发送给多个审查者进行审查；

接收审查者反馈的审查结果；

如审查结果为超过预设个数的审查者审查所述待提交增量代码通过，则确定所述待提交增量代码审查通过。

所述检测模块202对所述待提交增量代码进行任务测试，具体包括：

对所述待提交增量代码的依赖代码执行编译；

在对依赖代码执行编译时进行指定任务的任务测试；

在对依赖代码编译完成之后进行预设任务的任务测试；

获取指定任务与预设任务的任务测试结果；

若任务测试结果为全部通过，则确定对所述待提交增量代码的任务测试通过。

所述检测模块202对所述待提交增量代码的依赖代码执行编译，具体包括：

监控所述待提交增量代码的依赖代码是否发生变化；

编译发生了变化的依赖代码；

提取没有发生变化的依赖代码对应的库文件到指定位置，以便在对所述待提交增量代码进行编译时，直接引用所述库文件。

所述检测模块202进行任务测试，具体包括：

基于所述待提交增量代码的存储路径地址在配置库中指定位置查找任务配置文件；

若在指定位置没有查找到所述任务配置文件，则在所述指定位置的父目录所在位置查找所述任务配置文件，并利用查找到的任务配置文件进行任务测试；

若在父路径所在位置查找到所述任务配置文件，提取查找到的最新的任务配置文件，并利用提取的最新的任务配置文件进行任务测试；

若在父路径所在位置未查找到所述任务配置文件，基于预设的通用配置来进行任务测试。

提交模块203，具体用于：

判断检测通过后的待提交增量代码是否存在多个；

若判断结果为是，判断是否存在检测通过后的多个待提交增量代码对应于同一源代码，且对应于同一源代码的检测通过后的多个待提交增量代码进行代码修改的位置一致；

若判断结果为是，则确定对应同一个源代码，且代码修改的位置一致的多个检测通过后的待提交增量代码为存在冲突且检测通过后的待提交增量代码；

基于优先级评估因素对多个存在冲突且检测通过后的待提交增量代码进行优先级评估；

按照评估得到的优先级顺序从高到低依次提交存在冲突且检测通过后的待提交增量代码到所述代码仓库。

所述优先级评估因素包括对代码进行修改的修改时间，代码修改行数， 以及代码重要性；

所述提交模块203提交模块基于优先级评估因素对多个存在冲突且检测通过后的待提交增量代码进行优先级评估，具体包括：

基于影响程度对各个存在冲突且检测通过的待提交增量代码的代码重要性进行评估，以及获取各个存在冲突且检测通过的待提交增量代码的修改时间和代码修改行数；

基于修改时间，代码修改行数以及代码重要性来对各个存在冲突且检测通过的待提交增量代码的优先级进行评估；

基于评估结果确定各个存在冲突且检测通过的待提交增量代码的优先级顺序。

与现有技术相比，本申请中在获取待提交增量代码之后，会对待提交增量代码进行检测，只有再检测通过后的待提交增量代码才会提交，这样使得代码递交后，保证了被提交代码的准确性，且可以尽早发现问题，不会影响到其他需要利用该提交代码的程序或者过程。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可以通过硬件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施场景所述的方法。

本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本申请所必须的。

本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施 场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本申请序号仅仅为了描述，不代表实施场景的优劣。

以上公开的仅为本申请的几个具体实施场景，但是，本申请并非局限于此，任何本领域的技术人员能思之的变化都应落入本申请的保护范围。