WO2017036335A1 - 一种代码提交方法和设备 - Google Patents

一种代码提交方法和设备 Download PDF

Info

Publication number
WO2017036335A1
WO2017036335A1 PCT/CN2016/096585 CN2016096585W WO2017036335A1 WO 2017036335 A1 WO2017036335 A1 WO 2017036335A1 CN 2016096585 W CN2016096585 W CN 2016096585W WO 2017036335 A1 WO2017036335 A1 WO 2017036335A1
Authority
WO
WIPO (PCT)
Prior art keywords
code
submitted
incremental
task
passed
Prior art date
Application number
PCT/CN2016/096585
Other languages
English (en)
French (fr)
Inventor
姜善林
龚悦
翁开域
杨小亮
Original Assignee
阿里巴巴集团控股有限公司
姜善林
龚悦
翁开域
杨小亮
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 阿里巴巴集团控股有限公司, 姜善林, 龚悦, 翁开域, 杨小亮 filed Critical 阿里巴巴集团控股有限公司
Publication of WO2017036335A1 publication Critical patent/WO2017036335A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software

Definitions

  • the embodiments of the present invention relate to the field of communications technologies, and in particular, to a code submission method and device.
  • the tool monitors the change of the specified code warehouse, and when the new code is found to be put into the library, the new code of the code warehouse is checked out to the local, and the continuous integration execution is triggered according to the configuration item and the configuration step, but
  • An important prerequisite for triggering continuous integration execution is that the code must be actually submitted to the code repository, otherwise the execution of the task will not be triggered.
  • the code submitted to the repository if the task of continuous integration fails due to a build break or test execution failure, has already had a substantial impact on the final test results and the checkout code to other local team members, other people or tasks must After relying on this failure fix, it can continue to execute normally.
  • This method is not conducive to early detection of problems and software engineering principles that violate the process cost.
  • this method does not have code review (CR: Code Review). The link is included in the entire process, so the accuracy of the submitted code cannot be guaranteed.
  • the present application proposes a code submission method, including:
  • the detecting the incremental code to be submitted includes:
  • the performing code review on the incremental code to be submitted includes:
  • the review result is that the reviewer submits the incremental code to be submitted for more than a preset number of times, it is determined that the incremental code review to be submitted is passed.
  • the performing the task test on the incremental code to be submitted includes:
  • the compiling the dependent code of the incremental code to be submitted comprises:
  • perform task testing including:
  • the task configuration file is searched for in the location of the parent directory of the specified location, and the task profile is used to perform the task. test;
  • the latest task configuration file found is extracted, and the task task is tested by using the extracted latest task configuration file;
  • the task profile is not found at the location of the parent path, the task is tested based on the preset common configuration.
  • the submitting detects the to-be-delivered incremental code to the code repository, including:
  • the result of the determination is yes, the incremental code corresponding to the same source code and the position of the code modification is consistent, and the incremental code to be submitted after the detection is the conflict and the incremental code to be submitted after the detection is passed;
  • the incremental code to be submitted after the conflict has passed and the detected pass is submitted to the code warehouse in descending order of the priority order of the evaluation.
  • the priority evaluation factor includes a modification time of modifying the code, a code modification line number, and a code importance;
  • the code modifies the number of rows and the code importance to evaluate the priority of each conflicting and detected pass-through incremental code
  • the priority order of each of the conflicting and detected passing incremental codes is determined.
  • the application also proposes a code submission device, including:
  • An obtaining module configured to obtain an incremental code to be submitted submitted to the code warehouse
  • a detecting module configured to detect the incremental code to be submitted
  • the submitting module is configured to submit the detected incremental code to be submitted to the code warehouse.
  • the detecting module is specifically configured to:
  • the detecting module performs code review on the incremental code to be submitted, and specifically includes:
  • the review result is that the reviewer submits the incremental code to be submitted for more than a preset number of times, it is determined that the incremental code review to be submitted is passed.
  • the detecting module performs task testing on the incremental code to be submitted, and specifically includes:
  • the detecting module performs compilation on the dependent code of the incremental code to be submitted, and specifically includes:
  • the detecting module performs task testing, and specifically includes:
  • the task configuration file is searched for in the location of the parent directory of the specified location, and the task profile is searched by using the found task configuration file;
  • the latest task configuration file found is extracted, and the task task is tested by using the extracted latest task configuration file;
  • the task profile is not found at the location of the parent path, the task is tested based on the preset common configuration.
  • the submitting module is specifically configured to:
  • the result of the determination is yes, the incremental code corresponding to the same source code and the position of the code modification is consistent, and the incremental code to be submitted after the detection is the conflict and the incremental code to be submitted after the detection is passed;
  • the incremental code to be submitted after the conflict has passed and the detected pass is submitted to the code warehouse in descending order of the priority order of the evaluation.
  • the priority evaluation factor includes a modification time of modifying the code, a code modification line number, and a code importance;
  • the submitting module performs priority evaluation on the plurality of conflicting and detected incremental code to be submitted based on the priority evaluation factor, and specifically includes:
  • the code modifies the number of rows and the code importance to evaluate the priority of each conflicting and detected pass-through incremental code
  • the priority order of each of the conflicting and detected passing incremental codes is determined.
  • the incremental code to be submitted submitted to the code warehouse is obtained; the incremental code to be submitted is detected; and the incremental code to be submitted through the detection is submitted to the code warehouse. Therefore, the code is detected before the code is submitted, the accuracy of the submitted code is ensured, and the problem can be found as early as possible, without affecting other programs or processes that need to utilize the submitted code.
  • FIG. 2 is a schematic diagram of the result of a code submission device proposed by the present application.
  • Step 101 Acquire an incremental code to be submitted that is prepared to be submitted to the code warehouse.
  • the code is prepared to be submitted to the code repository, and thus the modified incremental code to be submitted to the code warehouse is obtained, and the other is different.
  • the code does not perform the fetched operation.
  • step 102 the incremental code is submitted for detection.
  • the specific detection includes: performing the code review for submitting the incremental code and performing the task test for submitting the incremental code, that is, including the following two process:
  • the incremental code to be submitted is sent to the reviewer, and after the reviewer reviews the incremental code to be submitted, the review result is given, passed or not, and in order to ensure the accuracy of the review, the preset may only be exceeded.
  • the preset number of reviewers pass the review for example, it can be set to 2 reviewers to pass the review, and then the incremental code to be submitted can be determined to pass.
  • Compute compilation of dependent code that submits incremental code perform task test of specified task when compiling with dependent code; perform task test of preset task after compiling dependent code; obtain task test of specified task and preset task Result; if the task test result is all passed, it is determined that the task test for submitting the incremental code passes.
  • test tasks require task testing when compiling, such as UT (Unit Test), and some need to perform task testing after compilation is completed, such as BVT (Build Verification Test).
  • UT Unit Test
  • BVT Build Verification Test
  • the dependent code that submits the incremental code is compiled, including:
  • Monitor whether the dependent code of the incremental code to be submitted changes compile the dependent code that has changed; extract the library file corresponding to the dependent code that has not changed to the specified location, so as to directly reference the library when compiling the incremental code to be submitted file.
  • the referenced code is the dependent code of the incremental code to be submitted, and thus, when compiling It only needs to compile the dependent code that has changed. For the dependent code that has not changed, you can directly extract the library file that depends on the code to the specified location without executing the compilation process, so as to ensure the implementation of the function. , reducing resource consumption and improving efficiency.
  • the task test including:
  • the task configuration file is searched for in the specified location in the configuration repository based on the storage path address of the incremental code to be submitted (the subsequent pending incremental code is submitted according to the storage path address); if the task configuration file is not found in the specified location, Find the task configuration file in the location of the parent directory of the specified location, and use the found task configuration file to perform the task test; if the task configuration file is found in the location of the parent path, extract the latest task configuration file found, and use the extraction The latest task configuration file is used for task testing; if the task configuration file is not found at the location of the parent path, the task is tested based on the preset common configuration.
  • Task configuration file for task testing, and if the task test has been performed before, the task configuration file will exist in the specified location (can be found based on the storage path address of the incremental code to be submitted), or the location of the parent directory of the specified location Therefore, it is first searched at the specified location.
  • the task is tested according to the task configuration file; if it is not found, it is searched at the location of the parent directory, that is, at the location of the upper layer of the specified location, if If found, the task is tested based on the latest task configuration file found; if the task test has not been performed before, the task configuration file will not exist. In this case, the task can be tested based on the common configuration.
  • step 102 After the step 102 is used to detect the submitted incremental code, there are two results, and the detection passes or fails. If the detection passes, step 103 is performed, and if the detection fails, the operation ends and/or the detection is not performed. Pass the alarm.
  • Step 103 Submit the incremental code to be submitted for detection.
  • the specific submission process includes:
  • the same source code may be modified by multiple modifiers at the same time, and modified The position is consistent (specifically, the number of modified lines of code, for example, the modification is line 7), which will generate multiple incremental codes to be submitted, and multiple incremental codes corresponding to the same source code, in this case
  • the priority of the plurality of pending incremental codes can be evaluated to determine the priority level, and finally based on the priority level.
  • the evaluation factors of the priority may include the modification time of modifying the code, the number of lines modified by the code, and the importance of the code; specifically, if the other two factors are consistent, the modification time The earlier the priority, the higher the priority; the higher the code importance (that is, the greater the impact of the modified code), the higher the corresponding priority; the more code modification lines, the higher the corresponding priority; In this case, based on the priority evaluation factor, the priority evaluation of the plurality of conflicting and detected pending incremental codes is performed, including:
  • the second embodiment of the present application also discloses a code submission in a specific scenario, including the following steps;
  • Step 1 The Review Board (which is part of the entire server) obtains the modified code uploaded by the RBT Client (RBT client) after the user has modified the code. Specifically, The modified code requests a review request for reviewing the modified code. The Review Board assigns a review ID to the request and returns the review ID to the RBT Client for the RBT Client to review the review ID and others. The modified code ID is sent to the Task Server (task server).
  • the Task Server task server
  • Step 2 The Review Board sends the modified code to multiple reviewers for review, and obtains the review result of the reviewer (the review pass or the review fails), and the Task Server polls the Review Board based on the Review ID to obtain the review result. If the result of the review is that two or more examiners have passed the review, it can be determined that the code review is passed.
  • the reviewer will give the mark of the review.
  • One reviewer can give a valid +1 ship it mark, and can set the mark with the requirement of +2 to pass the review. This is done by querying ship it to determine if the review is passed.
  • Step 3 The Task Server obtains the configuration file required for the test task, and sends the configuration file to CISE (Continuous Integration Service Engine), so that CISE performs the task test based on the configuration file, and returns the test result to Task Server, Task Server is stored in the database after receiving the test results.
  • CISE Continuous Integration Service Engine
  • Task Server based on code identification such as differential files, source code identification, version server, etc.
  • code identification such as differential files, source code identification, version server, etc.
  • restore the modified code of course, you can also directly obtain the modified code, but considering that the original code may be longer, the recovery method is more efficient High, saving resources, after giving the modified code, look for the task-related configuration file (Yaml configuration file), which includes the following three cases:
  • the Yaml configuration file does not exist in the specified location, first according to the SVN/Git address, according to the parent path of the specified location (that is, only to the trunk or branches level directory structure) in the configuration library maintained by the Task Server, if there is Corresponding to the configuration of the parent directory, the parent directory is automatically obtained The latest rule configuration is used as the configuration for this new join task;
  • the general task configuration rules are obtained from the database and processed by the default execution rules.
  • the default configuration rule is to distinguish the locale, and the specific locale is obtained according to the information transmitted by the RBT client.
  • the task also includes compiling. Specifically, when preparing for compiling, the change of the dependent code that determines the modified code is first obtained, and the determination may be based on the change timestamp to see whether it is consistent. If they are consistent, the description is not A change occurs, based on the makefile (where the relationship between the modified code identifier and the dependent code is stored) to generate a configuration copy of the latest makefile, replacing the previous operation of relying on the compiled build dependent library with the library file of the specified path, and Dynamically update the Yaml configuration file (using the configuration copy of the makefile, the task sent changes), download the library file to the specified path, consistent with the makefile configuration copy; for the case of changes, keep the configuration items unchanged, in order of dependency Perform the compilation build process;
  • compiling when preparing for compiling, the change of the dependent code that determines the modified code is first obtained, and the determination may be based on the change timestamp to see whether it is consistent. If they are consistent, the description is not A change occurs
  • the latest compiled library file is uploaded to the OSS (Open Storage Service) cloud space, stored in the file name + Unix timestamp, and the generated module information and time stamp (that is, the identifier) are compiled. It will be updated to the database through the Save interface in the form of a JSON string.
  • the content and format of the JSON string data are as follows:
  • Step 4 The Task Server polls the task test result in the database, and if the review passes, the modified code can be submitted.
  • T the time factor
  • T values according to 2 (n-1) is incremented, so as to ensure forward the task priority is submitted; here to the same module to Two concurrent submissions of the relevant files of the code are described as examples.
  • the number of incremental code lines of the first submitted task is 20, the number of affected methods is 2, and the value of T is 2 (the reference value is 1, reverse order);
  • the number of incremental code lines for the second commit task is 20, the number of affected methods is 6, and the value of T is 1.
  • the formula for calculating the modulus length of a vector is According to the calculation result, it can be determined that the code of the second submitting task is preferentially submitted.
  • the embodiment of the present application further discloses a code submission device, as shown in FIG. 2, including:
  • the obtaining module 201 is configured to obtain an incremental code to be submitted that is submitted to the code warehouse;
  • the detecting module 202 is configured to detect the incremental code to be submitted
  • the submitting module 203 is configured to submit the detected incremental code to be submitted to the code repository.
  • the detecting module 202 is specifically configured to:
  • the detecting module 202 performs code review on the incremental code to be submitted, and specifically includes:
  • the review result is that the reviewer submits the incremental code to be submitted for more than a preset number of times, it is determined that the incremental code review to be submitted is passed.
  • the detecting module 202 performs task testing on the incremental code to be submitted, and specifically includes:
  • the detecting module 202 performs compilation on the dependent code of the incremental code to be submitted, and specifically includes:
  • the detecting module 202 performs task testing, and specifically includes:
  • the task configuration file is searched for in the location of the parent directory of the specified location, and the task profile is searched by using the found task configuration file;
  • the latest task configuration file found is extracted, and the task task is tested by using the extracted latest task configuration file;
  • the task profile is not found at the location of the parent path, the task is tested based on the preset common configuration.
  • the submitting module 203 is specifically configured to:
  • the result of the determination is yes, the incremental code corresponding to the same source code and the position of the code modification is consistent, and the incremental code to be submitted after the detection is the conflict and the incremental code to be submitted after the detection is passed;
  • the incremental code to be submitted after the conflict has passed and the detected pass is submitted to the code warehouse in descending order of the priority order of the evaluation.
  • the priority evaluation factors include modification time for modifying the code, number of lines modified by the code, and code importance;
  • the submitting module 203 submits a module to perform priority evaluation on the plurality of conflicting and detected incremental code to be submitted based on the priority evaluation factor, and specifically includes:
  • the code modifies the number of rows and the code importance to evaluate the priority of each conflicting and detected pass-through incremental code
  • the priority order of each of the conflicting and detected passing incremental codes is determined.
  • the incremental code to be submitted is detected, and only the incremental code to be submitted after the re-test is passed, so that the code is submitted, and then the guarantee is guaranteed.
  • the accuracy of the submitted code, and the problem can be discovered as early as possible, without affecting other programs or processes that need to use the submitted code.
  • the present application can be implemented by hardware, or by software plus a necessary general hardware platform.
  • the technical solution of the present application may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (which may be a CD-ROM, a USB flash drive, a mobile hard disk, etc.), including several The instructions are for causing a computer device (which may be a personal computer, server, or network device, etc.) to perform the methods described in various implementation scenarios of the present application.
  • modules in the device in the implementation scenario can follow the implementation scenario. Descriptions are performed in devices that are distributed throughout the implementation scenario, and corresponding changes may be made in one or more devices that are different from the present embodiment.
  • the modules of the above implementation scenarios may be combined into one module, or may be further split into multiple sub-modules.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

一种代码提交方法和设备，该方法包括：获取预备向代码仓库提交的待提交增量代码（101）；对待提交增量代码进行检测（102）；提交检测通过的待提交增量代码到代码仓库（103）。通过提交代码之前先对代码进行检测，保证了提交代码的准确性，且可以尽早发现问题，不会影响到其他需要利用该提交代码的程序或者过程。

Description

一种代码提交方法和设备 技术领域
本申请实施例涉及通信技术领域，特别涉及一种代码提交方法和设备。
背景技术
在现有技术中，是通过工具监控指定代码仓库的变更，在发现有新代码提交入库时，将代码仓库的新代码检出到本地，按照配置项和配置步骤，触发持续集成执行，但触发持续集成执行的一个重要前提是：代码必须真实的提交到代码仓库，否则不会触发任务的执行。而提交入库的代码，如果因为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个审查者的审查结果为通过，则可以确定代码审查通过。
在具体的过程中，审查者在做完审查之后，给予审查通过的标记，一个审查者可以给出一个有效的+1 ship 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部分内容及格式如下：
Figure PCTCN2016096585-appb-000001
Figure PCTCN2016096585-appb-000002
步骤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。计算向量的模长的公式为
Figure PCTCN2016096585-appb-000003
根据计算结果可以确定第二个提交任务的代码优先被提交。
本申请实施例还公开了一种代码提交设备，如图2所示，包括：
获取模块201，用于获取预备向代码仓库提交的待提交增量代码；
检测模块202，用于对所述待提交增量代码进行检测；
提交模块203，用于提交检测通过的待提交增量代码到所述代码仓库。
所述检测模块202，具体用于：
对所述待提交增量代码进行代码审查；
对所述待提交增量代码进行任务测试。
若所述代码审查通过且所述任务测试通过，则确定对所述待提交增量代码的检测通过。
所述检测模块202对所述待提交增量代码进行代码审查，具体包括：
将所述待提交增量代码发送给多个审查者进行审查；
接收审查者反馈的审查结果；
如审查结果为超过预设个数的审查者审查所述待提交增量代码通过，则确定所述待提交增量代码审查通过。
所述检测模块202对所述待提交增量代码进行任务测试，具体包括：
对所述待提交增量代码的依赖代码执行编译；
在对依赖代码执行编译时进行指定任务的任务测试；
在对依赖代码编译完成之后进行预设任务的任务测试；
获取指定任务与预设任务的任务测试结果；
若任务测试结果为全部通过，则确定对所述待提交增量代码的任务测试通过。
所述检测模块202对所述待提交增量代码的依赖代码执行编译，具体包括：
监控所述待提交增量代码的依赖代码是否发生变化；
编译发生了变化的依赖代码；
提取没有发生变化的依赖代码对应的库文件到指定位置，以便在对所述待提交增量代码进行编译时，直接引用所述库文件。
所述检测模块202进行任务测试，具体包括：
基于所述待提交增量代码的存储路径地址在配置库中指定位置查找任务配置文件；
若在指定位置没有查找到所述任务配置文件，则在所述指定位置的父目录所在位置查找所述任务配置文件，并利用查找到的任务配置文件进行任务测试；
若在父路径所在位置查找到所述任务配置文件，提取查找到的最新的任务配置文件，并利用提取的最新的任务配置文件进行任务测试；
若在父路径所在位置未查找到所述任务配置文件，基于预设的通用配置来进行任务测试。
提交模块203，具体用于：
判断检测通过后的待提交增量代码是否存在多个；
若判断结果为是，判断是否存在检测通过后的多个待提交增量代码对应于同一源代码，且对应于同一源代码的检测通过后的多个待提交增量代码进行代码修改的位置一致；
若判断结果为是，则确定对应同一个源代码，且代码修改的位置一致的多个检测通过后的待提交增量代码为存在冲突且检测通过后的待提交增量代码；
基于优先级评估因素对多个存在冲突且检测通过后的待提交增量代码进行优先级评估；
按照评估得到的优先级顺序从高到低依次提交存在冲突且检测通过后的待提交增量代码到所述代码仓库。
所述优先级评估因素包括对代码进行修改的修改时间，代码修改行数，以及代码重要性；
所述提交模块203提交模块基于优先级评估因素对多个存在冲突且检测通过后的待提交增量代码进行优先级评估，具体包括：
基于影响程度对各个存在冲突且检测通过的待提交增量代码的代码重要性进行评估，以及获取各个存在冲突且检测通过的待提交增量代码的修改时间和代码修改行数；
基于修改时间，代码修改行数以及代码重要性来对各个存在冲突且检测通过的待提交增量代码的优先级进行评估；
基于评估结果确定各个存在冲突且检测通过的待提交增量代码的优先级顺序。
与现有技术相比，本申请中在获取待提交增量代码之后，会对待提交增量代码进行检测，只有再检测通过后的待提交增量代码才会提交，这样使得代码递交后，保证了被提交代码的准确性，且可以尽早发现问题，不会影响到其他需要利用该提交代码的程序或者过程。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可以通过硬件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施场景所述的方法。
本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本申请所必须的。
本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景 描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。
上述本申请序号仅仅为了描述，不代表实施场景的优劣。
以上公开的仅为本申请的几个具体实施场景，但是，本申请并非局限于此，任何本领域的技术人员能思之的变化都应落入本申请的保护范围。

Claims (16)

  1. 一种代码提交方法，其特征在于，包括：
    获取预备向代码仓库提交的待提交增量代码；
    对所述待提交增量代码进行检测；
    提交检测通过的待提交增量代码到所述代码仓库。
  2. 如权利要求1所述的方法，其特征在于，所述对所述待提交增量代码进行检测，具体包括：
    对所述待提交增量代码进行代码审查；
    对所述待提交增量代码进行任务测试。
    若所述代码审查通过且所述任务测试通过，则确定对所述待提交增量代码的检测通过。
  3. 如权利要求2所述的方法，其特征在于，所述对所述待提交增量代码进行代码审查，具体包括：
    将所述待提交增量代码发送给多个审查者进行审查；
    接收审查者反馈的审查结果；
    如审查结果为超过预设个数的审查者审查所述待提交增量代码通过，则确定所述待提交增量代码审查通过。
  4. 如权利要求2所述的方法，其特征在于，所述对所述待提交增量代码进行任务测试，具体包括：
    对所述待提交增量代码的依赖代码执行编译；
    在对依赖代码执行编译时进行指定任务的任务测试；
    在对依赖代码编译完成之后进行预设任务的任务测试；
    获取指定任务与预设任务的任务测试结果；
    若任务测试结果为全部通过，则确定对所述待提交增量代码的任务测试 通过。
  5. 如权利要求4所述的方法，其特征在于，所述对所述待提交增量代码的依赖代码执行编译，具体包括：
    监控所述待提交增量代码的依赖代码是否发生变化；
    编译发生了变化的依赖代码；
    提取没有发生变化的依赖代码对应的库文件到指定位置，以便在对所述待提交增量代码进行编译时，直接引用所述库文件。
  6. 如权利要求4所述的方法，其特征在于，进行任务测试，具体包括：
    基于所述待提交增量代码的存储路径地址在配置库中指定位置查找任务配置文件；
    若在指定位置没有查找到所述任务配置文件，则在所述指定位置的父目录所在位置查找所述任务配置文件，并利用查找到的任务配置文件进行任务测试；
    若在父路径所在位置查找到所述任务配置文件，提取查找到的最新的任务配置文件，并利用提取的最新的任务配置文件进行任务测试；
    若在父路径所在位置未查找到所述任务配置文件，基于预设的通用配置来进行任务测试。
  7. 如权利要求1所述的方法，其特征在于，所述提交检测通过后的待提交增量代码到所述代码仓库，具体包括：
    判断检测通过后的待提交增量代码是否存在多个；
    若判断结果为是，判断是否存在检测通过后的多个待提交增量代码对应于同一源代码，且对应于同一源代码的检测通过后的多个待提交增量代码进行代码修改的位置一致；
    若判断结果为是，则确定对应同一个源代码，且代码修改的位置一致的多个检测通过后的待提交增量代码为存在冲突且检测通过后的待提交增量代 码；
    基于优先级评估因素对多个存在冲突且检测通过后的待提交增量代码进行优先级评估；
    按照评估得到的优先级顺序从高到低依次提交存在冲突且检测通过后的待提交增量代码到所述代码仓库。
  8. 如权利要求7所述的方法，其特征在于，所述优先级评估因素包括对代码进行修改的修改时间，代码修改行数，以及代码重要性；
    所述基于优先级评估因素对多个存在冲突且检测通过后的待提交增量代码进行优先级评估，具体包括：
    基于影响程度对各个存在冲突且检测通过的待提交增量代码的代码重要性进行评估，以及获取各个存在冲突且检测通过的待提交增量代码的修改时间和代码修改行数；
    基于修改时间，代码修改行数以及代码重要性来对各个存在冲突且检测通过的待提交增量代码的优先级进行评估；
    基于评估结果确定各个存在冲突且检测通过的待提交增量代码的优先级顺序。
  9. 一种代码提交设备，其特征在于，包括：
    获取模块，用于获取预备向代码仓库提交的待提交增量代码；
    检测模块，用于对所述待提交增量代码进行检测；
    提交模块，用于提交检测通过的待提交增量代码到代码仓库。
  10. 如权利要求9所述的设备，其特征在于，所述检测模块，具体用于：
    对所述待提交增量代码进行代码审查；
    对所述待提交增量代码进行任务测试。
    若所述代码审查通过且所述任务测试通过，则确定对所述待提交增量代码的检测通过。
  11. 如权利要求10所述的设备，其特征在于，所述检测模块对所述待提交增量代码进行代码审查，具体包括：
    将所述待提交增量代码发送给多个审查者进行审查；
    接收审查者反馈的审查结果；
    如审查结果为超过预设个数的审查者审查所述待提交增量代码通过，则确定所述待提交增量代码审查通过。
  12. 如权利要求10所述的设备，其特征在于，所述检测模块对所述待提交增量代码进行任务测试，具体包括：
    对所述待提交增量代码的依赖代码执行编译；
    在对依赖代码执行编译时进行指定任务的任务测试；
    在对依赖代码编译完成之后进行预设任务的任务测试；
    获取指定任务与预设任务的任务测试结果；
    若任务测试结果为全部通过，则确定对所述待提交增量代码的任务测试通过。
  13. 如权利要求12所述的设备，其特征在于，所述检测模块对所述待提交增量代码的依赖代码执行编译，具体包括：
    监控所述待提交增量代码的依赖代码是否发生变化；
    编译发生了变化的依赖代码；
    提取没有发生变化的依赖代码对应的库文件到指定位置，以便在对所述待提交增量代码进行编译时，直接引用所述库文件。
  14. 如权利要求12所述的设备，其特征在于，所述检测模块进行任务测试，具体包括：
    基于所述待提交增量代码的存储路径地址在配置库中指定位置查找任务配置文件；
    若在指定位置没有查找到所述任务配置文件，则在所述指定位置的父目 录所在位置查找所述任务配置文件，并利用查找到的任务配置文件进行任务测试；
    若在父路径所在位置查找到所述任务配置文件，提取查找到的最新的任务配置文件，并利用提取的最新的任务配置文件进行任务测试；
    若在父路径所在位置未查找到所述任务配置文件，基于预设的通用配置来进行任务测试。
  15. 如权利要求9所述的设备，其特征在于，所述提交模块，具体用于：
    判断检测通过后的待提交增量代码是否存在多个；
    若判断结果为是，判断是否存在检测通过后的多个待提交增量代码对应于同一源代码，且对应于同一源代码的检测通过后的多个待提交增量代码进行代码修改的位置一致；
    若判断结果为是，则确定对应同一个源代码，且代码修改的位置一致的多个检测通过后的待提交增量代码为存在冲突且检测通过后的待提交增量代码；
    基于优先级评估因素对多个存在冲突且检测通过后的待提交增量代码进行优先级评估；
    按照评估得到的优先级顺序从高到低依次提交存在冲突且检测通过后的待提交增量代码到所述代码仓库。
  16. 如权利要求15所述的设备，其特征在于，所述优先级评估因素包括对代码进行修改的修改时间，代码修改行数，以及代码重要性；
    所述提交模块基于优先级评估因素对多个存在冲突且检测通过后的待提交增量代码进行优先级评估，具体包括：
    基于影响程度对各个存在冲突且检测通过的待提交增量代码的代码重要性进行评估，以及获取各个存在冲突且检测通过的待提交增量代码的修改时间和代码修改行数；
    基于修改时间，代码修改行数以及代码重要性来对各个存在冲突且检测通过的待提交增量代码的优先级进行评估；
    基于评估结果确定各个存在冲突且检测通过的待提交增量代码的优先级顺序。
PCT/CN2016/096585 2015-09-01 2016-08-24 一种代码提交方法和设备 WO2017036335A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201510552904.X 2015-09-01
CN201510552904.XA CN106484606B (zh) 2015-09-01 2015-09-01 一种代码提交方法和设备

Publications (1)

Publication Number Publication Date
WO2017036335A1 true WO2017036335A1 (zh) 2017-03-09

Family

ID=58188450

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/096585 WO2017036335A1 (zh) 2015-09-01 2016-08-24 一种代码提交方法和设备

Country Status (2)

Country Link
CN (1) CN106484606B (zh)
WO (1) WO2017036335A1 (zh)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109783128A (zh) * 2018-12-13 2019-05-21 平安普惠企业管理有限公司 代码改动通知方法、设备、存储介质及装置
CN110377497A (zh) * 2019-05-27 2019-10-25 深圳壹账通智能科技有限公司 代码检测方法、装置、计算机装置及存储介质
CN110866730A (zh) * 2018-12-29 2020-03-06 北京安妮全版权科技发展有限公司 一种代码考核系统及方法
CN111399856A (zh) * 2020-03-11 2020-07-10 山东汇贸电子口岸有限公司 一种服务部署中文件配置编辑方法及系统
CN111427543A (zh) * 2020-03-23 2020-07-17 中国建设银行股份有限公司 一种软件产品开发的处理方法及装置
CN111541563A (zh) * 2020-04-17 2020-08-14 成都千立网络科技有限公司 有序生效配置的系统及方法
CN111610999A (zh) * 2020-05-26 2020-09-01 北京字节跳动网络技术有限公司 一种检查方法、装置、计算机设备及存储介质
CN112083927A (zh) * 2020-07-06 2020-12-15 宁波三星医疗电气股份有限公司 现场获取电力采集终端内软件svn版本信息的方法
CN112558981A (zh) * 2020-12-23 2021-03-26 上海万向区块链股份公司 基于jenkinsfile的自定义编译部署方法及系统
CN113031960A (zh) * 2021-03-18 2021-06-25 北京达佳互联信息技术有限公司 代码编译方法、装置、服务器及存储介质
CN113688028A (zh) * 2020-05-19 2021-11-23 成都鼎桥通信技术有限公司 代码提交方法和装置

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106933591A (zh) * 2017-03-15 2017-07-07 东软集团股份有限公司 代码合并的方法及装置
CN107122218A (zh) * 2017-03-30 2017-09-01 北京深思数盾科技股份有限公司 一种软件开发方法及系统
CN107908420A (zh) * 2017-11-16 2018-04-13 泰康保险集团股份有限公司 一种代码处理方法、装置及系统
CN108089984A (zh) * 2017-12-14 2018-05-29 泰康保险集团股份有限公司 代码评审的实现方法、装置、存储介质及电子设备
CN108334313A (zh) * 2017-12-27 2018-07-27 苏州中晟宏芯信息科技有限公司 用于大型soc研发的持续集成方法、装置及代码管理系统
CN108733366A (zh) * 2018-05-22 2018-11-02 深圳Tcl新技术有限公司 软件产品释放代码的方法、装置及计算机可读存储介质
CN109002294A (zh) * 2018-07-16 2018-12-14 浪潮电子信息产业股份有限公司 一种代码审查方法、装置、设备及可读存储介质
CN109240734A (zh) * 2018-07-17 2019-01-18 北京奇虎科技有限公司 代码提交方法及装置
CN109726114A (zh) * 2018-09-07 2019-05-07 网联清算有限公司 代码质量管控方法、装置及电子设备
CN109359438A (zh) * 2018-09-20 2019-02-19 摩尔元数（厦门）科技有限公司 web端实现代码开源的方法及MC-Studio插件
CN109491663A (zh) * 2018-11-01 2019-03-19 北京车和家信息技术有限公司 代码审查方法及装置
CN109634865B (zh) * 2018-12-13 2024-03-22 平安科技（深圳）有限公司 一种代码转测方法、装置及转测终端
CN111338632A (zh) * 2018-12-19 2020-06-26 中国移动通信集团湖南有限公司 一种云平台镜像构建方法和装置
CN111382049B (zh) * 2018-12-28 2023-05-02 阿里云计算有限公司 代码提交方法、装置及电子设备
CN110704298A (zh) * 2019-08-23 2020-01-17 北京奇艺世纪科技有限公司 一种代码验证的方法、装置、终端设备及存储介质
CN110825427B (zh) * 2019-10-12 2024-01-26 天航长鹰(江苏)科技有限公司 一种代码管理方法、装置、服务器及存储介质
CN112905224B (zh) * 2019-12-04 2024-04-30 阿里巴巴集团控股有限公司 一种用于代码评审的耗时确定方法、装置及设备
CN112068895B (zh) * 2020-08-10 2023-12-19 深圳市鼎盛光电有限公司 代码配置方法、装置、视频播放设备及存储介质
CN113094066B (zh) * 2021-03-16 2024-03-26 北京优奥创思科技发展有限公司 一种多服务器代码发布方法及系统
CN113126998B (zh) * 2021-04-21 2023-11-07 北京字节跳动网络技术有限公司 一种增量源码获取方法、装置、电子设备及存储介质
CN113535206B (zh) * 2021-07-23 2024-02-20 上海幻电信息科技有限公司 多版本代码升级方法及系统
CN115114626B (zh) * 2022-08-26 2022-12-30 国网江西省电力有限公司电力科学研究院 工业设备代码检测方法、系统、计算机设备及存储介质
CN115374762B (zh) * 2022-10-26 2023-05-26 深圳市明源云采购科技有限公司 基于VS code的代码模板共享方法、装置、电子设备及介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101149682A (zh) * 2007-10-31 2008-03-26 金蝶软件（中国）有限公司 一种日构建方法、装置及系统
CN101963911A (zh) * 2010-09-29 2011-02-02 用友软件股份有限公司 补丁生成方法和装置
CN102012814A (zh) * 2010-11-24 2011-04-13 中兴通讯股份有限公司 软件版本的构建方法和系统
US20130152047A1 (en) * 2011-11-22 2013-06-13 Solano Labs, Inc System for distributed software quality improvement
CN104077140A (zh) * 2014-07-04 2014-10-01 用友软件股份有限公司 用于持续集成的自动化编译方法和编译装置

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103390183B (zh) * 2012-05-09 2019-07-19 顾泽苍 一种适用于手机识别的防伪代码的生成方法
CN103645985B (zh) * 2013-11-28 2017-03-22 广州视源电子科技股份有限公司 一种源代码宏配对检测方法
CN103677831B (zh) * 2013-12-12 2017-02-08 迈普通信技术股份有限公司 在线代码审查系统及方法
CN104809071B (zh) * 2015-05-14 2017-08-11 北京润科通用技术有限公司 一种代码测试方法及装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101149682A (zh) * 2007-10-31 2008-03-26 金蝶软件（中国）有限公司 一种日构建方法、装置及系统
CN101963911A (zh) * 2010-09-29 2011-02-02 用友软件股份有限公司 补丁生成方法和装置
CN102012814A (zh) * 2010-11-24 2011-04-13 中兴通讯股份有限公司 软件版本的构建方法和系统
US20130152047A1 (en) * 2011-11-22 2013-06-13 Solano Labs, Inc System for distributed software quality improvement
CN104077140A (zh) * 2014-07-04 2014-10-01 用友软件股份有限公司 用于持续集成的自动化编译方法和编译装置

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109783128A (zh) * 2018-12-13 2019-05-21 平安普惠企业管理有限公司 代码改动通知方法、设备、存储介质及装置
CN110866730A (zh) * 2018-12-29 2020-03-06 北京安妮全版权科技发展有限公司 一种代码考核系统及方法
CN110866730B (zh) * 2018-12-29 2023-11-21 北京安妮全版权科技发展有限公司 一种代码考核系统及方法
CN110377497A (zh) * 2019-05-27 2019-10-25 深圳壹账通智能科技有限公司 代码检测方法、装置、计算机装置及存储介质
CN111399856A (zh) * 2020-03-11 2020-07-10 山东汇贸电子口岸有限公司 一种服务部署中文件配置编辑方法及系统
CN111427543B (zh) * 2020-03-23 2023-08-11 中国建设银行股份有限公司 一种软件产品开发的处理方法及装置
CN111427543A (zh) * 2020-03-23 2020-07-17 中国建设银行股份有限公司 一种软件产品开发的处理方法及装置
CN111541563A (zh) * 2020-04-17 2020-08-14 成都千立网络科技有限公司 有序生效配置的系统及方法
CN113688028A (zh) * 2020-05-19 2021-11-23 成都鼎桥通信技术有限公司 代码提交方法和装置
CN113688028B (zh) * 2020-05-19 2023-08-15 成都鼎桥通信技术有限公司 代码提交方法和装置
CN111610999A (zh) * 2020-05-26 2020-09-01 北京字节跳动网络技术有限公司 一种检查方法、装置、计算机设备及存储介质
CN112083927A (zh) * 2020-07-06 2020-12-15 宁波三星医疗电气股份有限公司 现场获取电力采集终端内软件svn版本信息的方法
CN112083927B (zh) * 2020-07-06 2023-06-30 宁波三星医疗电气股份有限公司 现场获取电力采集终端内软件svn版本信息的方法
CN112558981A (zh) * 2020-12-23 2021-03-26 上海万向区块链股份公司 基于jenkinsfile的自定义编译部署方法及系统
CN112558981B (zh) * 2020-12-23 2024-02-06 上海万向区块链股份公司 基于jenkinsfile的自定义编译部署方法及系统
CN113031960A (zh) * 2021-03-18 2021-06-25 北京达佳互联信息技术有限公司 代码编译方法、装置、服务器及存储介质
CN113031960B (zh) * 2021-03-18 2024-04-30 北京达佳互联信息技术有限公司 代码编译方法、装置、服务器及存储介质

Also Published As

Publication number Publication date
CN106484606B (zh) 2019-07-26
CN106484606A (zh) 2017-03-08

Similar Documents

Publication Publication Date Title
WO2017036335A1 (zh) 一种代码提交方法和设备
US10346282B2 (en) Multi-data analysis based proactive defect detection and resolution
US10606739B2 (en) Automated program code analysis and reporting
US9824002B2 (en) Tracking of code base and defect diagnostic coupling with automated triage
US9535818B2 (en) Identifying high impact bugs
US10719431B2 (en) Graph based code performance analysis
US9703692B2 (en) Development supporting system
US9280331B2 (en) Hash-based change tracking for software make tools
US10474456B2 (en) Software version fingerprint generation and identification
CN113227971A (zh) 实时应用错误识别和缓解
US20150106663A1 (en) Hash labeling of logging messages
US8904352B2 (en) Systems and methods for processing source code during debugging operations
US11366713B2 (en) System and method for automatically identifying and resolving computing errors
US11836072B2 (en) Risk-based root cause identification methods and related autobuild systems
US9329979B2 (en) Derivation of generalized test cases
US20150186195A1 (en) Method of analysis application object which computer-executable, server performing the same and storage media storing the same
US20160292062A1 (en) System and method for detection of duplicate bug reports
CN111654495B (zh) 用于确定流量产生来源的方法、装置、设备及存储介质
US9563541B2 (en) Software defect detection identifying location of diverging paths
JP6419667B2 (ja) テストｄｂデータ生成方法及び装置
US10241957B2 (en) Workload patterns for realistic load recreation in performance testing
US10949333B1 (en) Application maturity console
KR102021383B1 (ko) 동적 분석과 정적 분석을 연계한 프로그램을 분석하기 위한 방법 및 장치
KR102090229B1 (ko) 바이너리에 대한 보안 취약점 및 그 원인 위치의 식별 방법 및 그 장치
Lavoie et al. A case study of TTCN-3 test scripts clone analysis in an industrial telecommunication setting

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16840764

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16840764

Country of ref document: EP

Kind code of ref document: A1