A code quality control method and system

Abstract

The present invention particularly relates to a code quality control method and system. The code quality control method and system are intended to use the data obtained through the automated testing of the code quality management tool sonar and the component vulnerability testing tool dependency‑check as the basis for evaluation during the automated testing process, and obtain the number of discussions, discussion resolutions, and the number of merges of corresponding requests from the manual code review process to participate in the evaluation; finally, the success of the pipeline execution for testing the quality of the code is determined based on the evaluation results. If the pipeline execution fails, the code cannot be merged into the specified branch. The code quality control method and system evaluates the code by performing automated testing and manual code review during the pipeline execution process, controls the quality of the incoming code from the source code merging stage, and standardizes the coding habits of R&D personnel through the rigid execution of code specifications, thereby improving the coding quality of R&D personnel.

Description

Technical Field

[0001] The present invention relates to the technical field of software development management, and in particular to a code quality control method and system. Background Art

[0002] Currently, using GitLab to build private code repositories has become the choice of many companies and enterprises. When R&D personnel submit code using GitLab, due to differences in technical levels and coding habits, the increase in code merge requests causes a decline in code quality. Currently, code quality can be ensured by formulating code specifications and effective management and control methods.

[0003] The warehouse management system GitLab provides the CI / CD pipeline function. The results of the pipeline execution can be further associated with the permissions of the merge request for further execution. Therefore, binding the code specification with the execution results of the pipeline can effectively control the influx of unqualified code.

[0004] The code specification consists of two modules: automatic code quality detection and manual review. By obtaining the specified attributes in these two modules and comparing them with the formulated code specification indicators, if they meet the specifications, the pipeline execution is successful, and if they do not meet the specifications, the pipeline execution fails. If the pipeline fails, the ability to further merge branches is lost.

[0005] Based on the above situation, the present invention proposes a code quality control method and system. Summary of the invention

[0006] In order to overcome the deficiencies of the prior art, the present invention provides a simple and efficient code quality control method and system.

[0007] The present invention is achieved through the following technical solutions:

[0008] A code quality control method, characterized in that: in the process of automated testing, the code unit test coverage, reliability, repetition rate, number of blocking problems and the number of problems labeled CRITICAL and HIGH after scanning by the component vulnerability testing tool dependency-check are obtained through the code quality management tool sonar and the component vulnerability testing tool dependency-check, and the obtained data is used as the basis for evaluation, the number of discussions is obtained from the manual code review process, and the discussion on whether the problem is solved and the number of merged requests are involved in the evaluation; finally, the success or failure of the pipeline execution is determined based on whether the evaluation result meets the code specification, thereby controlling whether the merge request is merged into the specified branch. If the pipeline execution fails, the code cannot be merged into the specified branch, thereby automatically preventing the inflow of unqualified code;

[0009] The code standard refers to comparing the attributes obtained from the automated detection module and the manual review module with the custom values ​​of the code standard. The comparison rules are as follows:

[0010] If the number of likes in the corresponding merge request in the code repository is less than the code specification custom value A1, the pipeline execution fails;

[0011] If the number of discussions in the merge request is less than the custom value A2 of the code standard, the pipeline execution fails;

[0012] If there is a discussion with the "unresolved" label among the existing discussions, the pipeline execution fails;

[0013] If the number of CRITICAL and HIGH types in the problem tags scanned by the component vulnerability testing tool dependency-check is greater than the code standard custom value A3, the pipeline execution fails;

[0014] If the code unit test coverage and reliability are less than the code specification custom value A4, the pipeline execution fails;

[0015] If the repetition rate and the number of blocking problems are greater than the code specification custom value A5, the pipeline execution fails.

[0016] Use GitLab as the code repository, enable the CI / CD service in GitLab, and use the pipeline execution result as one of the execution conditions of the merge request; at the same time, add the .gitlab-ci.yaml file to the root directory of the source code, and create an automated detection module and a manual review module in the .gitlab-ci.yaml file;

[0017] Bind the code standards to the execution results of the pipeline in GitLab, and use the final execution results of the pipeline as the basis for whether the code can be merged into the specified branch, automatically preventing the influx of unqualified code to ensure code quality.

[0018] The automated detection module is used for application execution code quality management sonar testing and component vulnerability testing dependency-check testing;

[0019] The manual review module is used to obtain discussion details in a specified merge request.

[0020] When the R&D personnel submit code to the merge branch in the merge request, the GitLab pipeline is triggered to execute automatically. The pipeline performs code quality checks based on the code in the current merge branch. At the same time, the pipeline gives the current values ​​of various attributes of the code check, as well as the detection report generation addresses of the code quality management tool sonar and the component vulnerability testing tool dependency-check; the R&D personnel find the location of the unqualified attributes in the report based on the returned address and correct them.

[0021] Based on the manual review module, when a reviewer raises a discussion on a specified merge request, the corresponding R&D personnel will receive a notification email; during the pipeline execution process, for discussions that have not been replied to or have been replied to but the discussion status has not been modified, the R&D personnel will modify the branch code based on the discussion results.

[0022] During each submission, the difference between the evaluation indicators of the two branch codes is obtained, and the code quality score of the current branch is calculated using the following formula:

[0023] Among them, S1 represents the difference in unit test coverage, and d1 represents the weight of this attribute; S2 represents the difference in reliability, with a weight of d2; S3 represents the difference in the percentage of repeated code, with a weight of d3; S4 represents the difference in the number of blocked questions, with a weight of d4; S5 represents the difference in CRITICAL references in dependency checks, with a weight of d5; S6 represents the difference in HIGH references in dependency checks, with a weight of d6;

[0024] The values ​​of weights d1 to d6 are all between -1 and 1, and k represents the code increment in thousands of lines;

[0025] By setting weights d1 to d6, the influence of each factor is balanced. If the code quality score j is greater than the custom value A6, a like operation is automatically triggered in the merge request. The automatic like operation reduces the number of likes for the merge request in the code specification by 1.

[0026] The code automation test module performs code quality management sonar testing and component vulnerability testing dependency-check detection. The specific steps are as follows:

[0027] Step S1.1, clone the code branch to be merged into the local executor;

[0028] Step S1.2, by reading the annotation information of the code quality management sonar tool in the .gitlab-ci.yaml file, the code type, scanning path, exclusion path and scanning scheme parameters of the current branch are obtained;

[0029] Step S1.3, call the code quality management sonar tool interface, create a corresponding code inspection task on the code quality management sonar tool, and obtain the task id;

[0030] Step S1.4, start the code inspection task according to the ID returned by the code quality management sonar tool interface in step S1.3, and monitor until the task is completed or fails;

[0031] Step S1.5: After monitoring that the code quality management sonar tool has completed the code inspection, obtain the inspection result details of the code quality management sonar tool, and obtain the code unit test coverage, reliability, repetition rate, and number of blocking problems from the details;

[0032] Step S1.6, by reading the relevant information of the component vulnerability test dependency-check tool in the .gitlab-ci.yaml file, obtain the scanning path required during the execution of the component vulnerability test dependency-check tool;

[0033] Step S1.7, execute component vulnerability test dependency-check tool scan and generate report;

[0034] Step S1.8, obtaining the number of vulnerabilities labeled as CRITICAL and HIGH from the generated report;

[0035] Step S1.9, clone the code of the merged branch to the local computer, and execute steps S1.2 to S1.8 to obtain the properties in the above process;

[0036] Step S1.10: By subtracting the values ​​of the same attributes of the two branches, the incremental code quality details of the merged branch are obtained. When the quality of the newly added code meets the code specification requirements, the like operation is automatically triggered, and the number of likes for the merge request is increased by 1.

[0037] The manual review module obtains the discussion details of a specified merge request. The specific steps are as follows:

[0038] Step S2.1: Designate code reviewers to manually review the code of the branch where the merge request is located, and raise a discussion under the merge request, requiring R&D personnel to reply to the discussion. The reviewer approves the discussion and manually likes it based on the reply results and code quality;

[0039] Step S2.2, obtaining discussion information in a specified merge request from the current project, obtaining the number of replies in the current discussion information and a label indicating whether the discussion is passed;

[0040] Step S2.3, obtain the number of likes in the specified merge request from the current project, and count the number of likes.

[0041] The system of the code quality control method of the present invention is characterized by comprising a code warehouse GitLab, an automatic detection module and a manual review module; the automatic detection module and the manual review module are set in the .gitlab-ci.yaml file in the root directory of the source code;

[0042] The code repository GitLab starts the CI / CD service and uses the pipeline execution result as one of the execution conditions of the merge request;

[0043] The automated detection module is used for application execution code quality management sonar testing and component vulnerability testing dependency-check testing;

[0044] The manual review module is used to obtain discussion details in a specified merge request.

[0045] The beneficial effects of the present invention are as follows: the code quality control method and system evaluates the code by performing automated code testing and manual code review during the pipeline execution process, controls the quality of the incoming code from the source code merging stage, and standardizes the coding habits of R&D personnel through the rigid execution of code specifications, thereby improving the coding quality of R&D personnel. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0047] Attached Figure 1 Schematic diagram of the code quality control method of the present invention.

[0048] Attached Figure 2 This is a schematic diagram of the .gitlab-ci.yaml file format of the present invention. DETAILED DESCRIPTION

[0049] In order to enable those skilled in the art to better understand the technical solutions in the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0050] The code quality control method, during the automated testing process, obtains the code unit test coverage, reliability, repetition rate, number of blocking problems, and the number of problems labeled CRITICAL and HIGH after scanning by the component vulnerability testing tool dependency-check through the code quality management tool sonar and the component vulnerability testing tool dependency-check, and uses the obtained data as the evaluation basis, obtains the number of discussions from the manual code review process, and discusses whether the situation is resolved and the number of merges of the corresponding requests for evaluation; finally, the success or failure of the pipeline execution is determined based on whether the evaluation result meets the code specification, thereby controlling whether the merge request is merged into the specified branch. If the pipeline execution fails, the code cannot be merged into the specified branch, thereby automatically preventing the influx of unqualified code;

[0051] The code standard refers to comparing the attributes obtained from the automated detection module and the manual review module with the custom values ​​of the code standard. The comparison rules are as follows:

[0052] If the number of likes in the corresponding merge request in the code repository is less than the code specification custom value A1, the pipeline execution fails;

[0053] If the number of discussions in the merge request is less than the custom value A2 of the code standard, the pipeline execution fails;

[0054] If there is a discussion with the "unresolved" label among the existing discussions, the pipeline execution fails;

[0055] If the number of CRITICAL and HIGH types in the problem tags scanned by the component vulnerability testing tool dependency-check is greater than the code standard custom value A3, the pipeline execution fails;

[0056] If the code unit test coverage and reliability are less than the code specification custom value A4, the pipeline execution fails;

[0057] If the repetition rate and the number of blocking problems are greater than the code specification custom value A5, the pipeline execution fails.

[0058] Use GitLab as the code repository, enable the CI / CD service in GitLab, and use the pipeline execution result as one of the execution conditions of the merge request; at the same time, add the .gitlab-ci.yaml file to the root directory of the source code, and create an automated detection module and a manual review module in the .gitlab-ci.yaml file;

[0059] Bind the code standards to the execution results of the pipeline in GitLab, and use the final execution results of the pipeline as the basis for whether the code can be merged into the specified branch, automatically preventing the influx of unqualified code to ensure code quality.

[0060] The automated detection module is used for application execution code quality management sonar testing and component vulnerability testing dependency-check testing;

[0061] The manual review module is used to obtain discussion details in a specified merge request.

[0062] When the R&D personnel submit code to the merge branch in the merge request, the GitLab pipeline is triggered to execute automatically. The pipeline performs code quality checks based on the code in the current merge branch. At the same time, the pipeline gives the current values ​​of various attributes of the code check, as well as the detection report generation addresses of the code quality management tool sonar and the component vulnerability testing tool dependency-check; the R&D personnel find the location of the unqualified attributes in the report based on the returned address and correct them.

[0063] Based on the manual review module, when a reviewer raises a discussion on a specified merge request, the corresponding R&D personnel will receive a notification email; during the pipeline execution process, for discussions that have not been replied to or have been replied to but the discussion status has not been modified, the R&D personnel will modify the branch code based on the discussion results.

[0064] During each submission, the difference between the evaluation indicators of the two branch codes is obtained, and the code quality score of the current branch is calculated using the following formula:

[0065] Among them, S1 represents the difference in unit test coverage, and d1 represents the weight of this attribute; S2 represents the difference in reliability, with a weight of d2; S3 represents the difference in the percentage of repeated code, with a weight of d3; S4 represents the difference in the number of blocked questions, with a weight of d4; S5 represents the difference in CRITICAL references in dependency checks, with a weight of d5; S6 represents the difference in HIGH references in dependency checks, with a weight of d6;

[0066] The values ​​of weights d1 to d6 are all between -1 and 1, and k represents the code increment in thousands of lines;

[0067] By setting weights d1 to d6, the influence of each factor is balanced. If the code quality score j is greater than the custom value A6, a like operation is automatically triggered in the merge request. The automatic like operation reduces the number of likes for the merge request in the code specification by 1.

[0068] The code automation test module performs code quality management sonar testing and component vulnerability testing dependency-check detection. The specific steps are as follows:

[0069] Step S1.1, clone the code branch to be merged into the local executor;

[0070] Step S1.2, by reading the annotation information of the code quality management sonar tool in the .gitlab-ci.yaml file, the code type, scanning path, exclusion path and scanning scheme parameters of the current branch are obtained;

[0071] Step S1.3, call the code quality management sonar tool interface, create a corresponding code inspection task on the code quality management sonar tool, and obtain the task id;

[0072] Step S1.4, start the code inspection task according to the ID returned by the code quality management sonar tool interface in step S1.3, and monitor until the task is completed or fails;

[0073] Step S1.5: After monitoring that the code quality management sonar tool has completed the code inspection, obtain the inspection result details of the code quality management sonar tool, and obtain the code unit test coverage, reliability, repetition rate, and number of blocking problems from the details;

[0074] Step S1.6, by reading the relevant information of the component vulnerability test dependency-check tool in the .gitlab-ci.yaml file, obtain the scanning path required during the execution of the component vulnerability test dependency-check tool;

[0075] Step S1.7, execute component vulnerability test dependency-check tool scan and generate report;

[0076] Step S1.8, obtaining the number of vulnerabilities labeled as CRITICAL and HIGH from the generated report;

[0077] Step S1.9, clone the code of the merged branch to the local computer, and execute steps S1.2 to S1.8 to obtain the properties in the above process;

[0078] Step S1.10: By subtracting the values ​​of the same attributes of the two branches, the incremental code quality details of the merged branch are obtained. When the quality of the newly added code meets the code specification requirements, the like operation is automatically triggered, and the number of likes for the merge request is increased by 1.

[0079] The manual review module obtains the discussion details of a specified merge request. The specific steps are as follows:

[0080] Step S2.1: Designate code reviewers to manually review the code of the branch where the merge request is located, and raise a discussion under the merge request, requiring R&D personnel to reply to the discussion. The reviewer approves the discussion and manually likes it based on the reply results and code quality;

[0081] Step S2.2, obtaining discussion information in a specified merge request from the current project, obtaining the number of replies in the current discussion information and a label indicating whether the discussion is passed;

[0082] Step S2.3, obtain the number of likes in the specified merge request from the current project, and count the number of likes.

[0083] The system of the code quality control method of the present invention is characterized by comprising a code warehouse GitLab, an automatic detection module and a manual review module; the automatic detection module and the manual review module are set in the .gitlab-ci.yaml file in the root directory of the source code;

[0084] The code repository GitLab starts the CI / CD service and uses the pipeline execution result as one of the execution conditions of the merge request;

[0085] The automated detection module is used for application execution code quality management sonar testing and component vulnerability testing dependency-check testing;

[0086] The manual review module is used to obtain discussion details in a specified merge request.

[0087] Compared with the existing technology, the code quality control method and system have the following characteristics:

[0088] First, the code is evaluated by performing automated code testing and manual code review during the pipeline execution process.

[0089] Second, the quality of incoming code is controlled from the source code merging stage. At the same time, the coding habits of R&D personnel are standardized through the rigid implementation of code specifications, thereby improving the coding quality of R&D personnel.

[0090] The embodiment described above is only one specific implementation of the present invention. Common changes and substitutions made by those skilled in the art within the scope of the technical solution of the present invention should be included in the protection scope of the present invention.

Claims

1. A code quality control method, characterized by: During the automated testing process, the code unit test coverage, reliability, repetition rate, number of blocking issues, and the number of issues labeled CRITICAL and HIGH after scanning by the component vulnerability testing tool dependency-check are obtained through the code quality management tool sonar and the component vulnerability testing tool dependency-check. The obtained data is used as the basis for evaluation, and the number of discussions, whether the discussion is resolved, and the number of merged requests are obtained from the manual code review process to participate in the evaluation; finally, the success or failure of the pipeline execution is determined based on whether the evaluation result meets the code specification, thereby controlling whether the merge request is merged into the specified branch. If the pipeline execution fails, the code cannot be merged into the specified branch, thereby automatically preventing the influx of unqualified code; The code standard refers to comparing the attributes obtained from the automated detection module and the manual review module with the custom values ​​of the code standard. The comparison rules are as follows: If the number of likes in the corresponding merge request in the code repository is less than the code specification custom value A1, the pipeline execution fails; If the number of discussions in the merge request is less than the custom value A2 of the code standard, the pipeline execution fails; If there is a discussion with the "unresolved" label in the existing discussions, the pipeline execution fails; If the number of CRITICAL and HIGH types in the problem tags scanned by the component vulnerability testing tool dependency-check is greater than the code standard custom value A3, the pipeline execution fails; If the code unit test coverage and reliability are less than the code specification custom value A4, the pipeline execution fails; If the repetition rate and the number of blocking problems are greater than the code specification custom value A5, the pipeline execution fails.

2. The code quality control method according to claim 1, characterized in that: Use GitLab as the code repository, enable the CI / CD service in GitLab, and use the pipeline execution result as one of the execution conditions of the merge request; at the same time, add the .gitlab-ci.yaml file to the root directory of the source code, and create an automated detection module and a manual review module in the .gitlab-ci.yaml file; Bind the code specifications to the execution results of the pipeline in GitLab, and use the final execution results of the pipeline as the basis for whether the code can be merged into the specified branch, automatically preventing the influx of unqualified code to ensure code quality; The automated detection module is used for application execution code quality management sonar testing and component vulnerability testing dependency-check testing; The manual review module is used to obtain discussion details in a specified merge request.

3. The code quality control method according to claim 2, characterized in that: When the R&D personnel submit code to the merge branch in the merge request, the GitLab pipeline is triggered to execute automatically. The pipeline performs code quality checks based on the code in the current merge branch. At the same time, the pipeline gives the current values ​​of various attributes of the code check, as well as the detection report generation addresses of the code quality management tool sonar and the component vulnerability testing tool dependency-check; the R&D personnel find the location of the unqualified attributes in the report based on the returned address and correct them.

4. The code quality control method according to claim 3, characterized in that: Based on the manual review module, when a reviewer raises a discussion on a specified merge request, the corresponding R&D personnel will receive a notification email; During the execution of the pipeline, for discussions that have not been replied to or have been replied to but the discussion status has not been modified, R&D personnel will modify the branch code based on the discussion results.

5. The code quality control method according to claim 4, characterized in that: During each submission, the difference between the evaluation indicators of the two branch codes is obtained, and the code quality score of the current branch is calculated using the following formula: Among them, S1 represents the difference in unit test coverage, and d1 represents the weight of this attribute; S2 represents the difference in reliability, with a weight of d2; S3 represents the difference in the percentage of repeated code, with a weight of d3; S4 represents the difference in the number of blocked questions, with a weight of d4; S5 represents the difference in CRITICAL references in dependency checks, with a weight of d5; S6 represents the difference in HIGH references in dependency checks, with a weight of d6; The values ​​of weights d1 to d6 are all between -1 and 1, and k represents the code increment in thousands of lines; By setting weights d1 to d6, the influence of each factor is balanced. If the code quality score j is greater than the custom value A6, a like operation is automatically triggered in the merge request. The automatic like operation reduces the number of likes for the merge request in the code specification by 1.

6. The code quality control method according to claim 3, characterized in that: The code automation test module performs code quality management sonar testing and component vulnerability testing dependency-check detection, and the specific steps are as follows: Step S1.1, clone the code branch to be merged into the local executor; Step S1.2, by reading the annotation information of the code quality management sonar tool in the .gitlab-ci.yaml file, the code type, scanning path, exclusion path and scanning scheme parameters of the current branch are obtained; Step S1.3, call the code quality management sonar tool interface, create a corresponding code inspection task on the code quality management sonar tool, and obtain the task id; Step S1.4, start the code inspection task according to the ID returned by the code quality management sonar tool interface in step S1.3, and monitor until the task is completed or fails; Step S1.5: After monitoring that the code quality management sonar tool has completed the code inspection, obtain the inspection result details of the code quality management sonar tool, and obtain the code unit test coverage, reliability, repetition rate, and number of blocking problems from the details; Step S1.6, by reading the relevant information of the component vulnerability test dependency-check tool in the .gitlab-ci.yaml file, obtain the scanning path required during the execution of the component vulnerability test dependency-check tool; Step S1.7, execute component vulnerability test dependency-check tool scan and generate report; Step S1.8, obtaining the number of vulnerabilities labeled as CRITICAL and HIGH from the generated report; Step S1.9, clone the code of the merged branch to the local computer, and execute steps S1.2 to S1.8 to obtain the properties in the above process; Step S1.10: By subtracting the values ​​of the same attributes of the two branches, the incremental code quality details of the merged branch are obtained. When the quality of the newly added code meets the code specification requirements, the like operation is automatically triggered, and the number of likes for the merge request is increased by 1.

7. The code quality control method according to claim 4, characterized in that: The manual review module obtains the discussion details of a specified merge request. The specific steps are as follows: Step S2.1: Designate code reviewers to manually review the code of the branch where the merge request is located, and raise a discussion under the merge request, requiring R&D personnel to reply to the discussion. The reviewer approves the discussion and manually likes it based on the reply results and code quality; Step S2.2, obtain the discussion information in the specified merge request from the current project, obtain the number of replies in the current discussion information and the label of whether the discussion is passed; Step S2.3, obtain the number of likes in the specified merge request from the current project, and count the number of likes.

8. The system of the code quality control method according to any one of claims 1 to 7, characterized in that: It includes a code repository GitLab, an automated detection module and a manual review module; the automated detection module and the manual review module are set in the .gitlab-ci.yaml file in the source code root directory; The code repository GitLab starts the CI / CD service and uses the pipeline execution result as one of the execution conditions of the merge request; The automated detection module is used for application execution code quality management sonar testing and component vulnerability testing dependency-check testing; The manual review module is used to obtain discussion details in a specified merge request.

Images