A code integration management method and system based on Jenkins

Abstract

The present invention discloses a code integration management method and system based on Jenkins, and relates to the field of computer technology. A specific implementation of the method includes: after monitoring and intercepting a code submission event, triggering the client to run, so as to trigger a Jenkins remote build task through the client; polling the monitoring plug-in in Jenkins to obtain the latest build status of each task; if all tasks are successfully built, the code is pushed to the code warehouse through the client, otherwise a push failure message is returned. On the one hand, this implementation can ensure that a continuous integration build check can be performed before the code is submitted to the code warehouse, so as to avoid the code in the code warehouse from being contaminated; on the other hand, the entire build environment is built in Jenkins, and each user does not need to repeatedly build the environment locally, while also ensuring the uniformity of the continuous integration environment.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a Jenkins-based code integration management method and system. Background Art

[0002] In software development, integrating codes written by different developers is the most common operation of the development team. In the process of code integration, a large number of integration problems are inevitably encountered. In order to ensure the efficiency and quality of software integration, an automated continuous integration method is proposed in agile development. In the process of implementing the present invention, the inventors found that the prior art has at least the following problems:

[0003] 1) Some methods trigger continuous integration builds only after users submit code to the code repository, which is a "pollution first, governance later" strategy, which is costly;

[0004] 2) In some other methods, although detection is implemented before code push, the detection of these plug-ins is based on the user's local environment. Due to the differences in the development environment of each developer, there are differences in the detection results; complex construction cannot be achieved, and each user is required to build a continuous integration environment locally, which is too cumbersome. Summary of the invention

[0005] In view of this, an embodiment of the present invention provides a code integration management method and system based on Jenkins, which can at least solve the problem in the prior art that the code is easily contaminated and the integrated environment cannot be uniformly built.

[0006] To achieve the above object, according to one aspect of an embodiment of the present invention, a code integration management method based on Jenkins is provided, comprising:

[0007] After monitoring and intercepting the code submission event, the client is triggered to run, so as to trigger the Jenkins remote build task through the client; the task is used to detect defects in the code in the code submission event;

[0008] Poll the monitoring plugin in Jenkins to get the latest build status of each task;

[0009] If all tasks are built successfully, the code is pushed to the code repository through the client, otherwise a push failure message is returned.

[0010] Optional, clients include continuous integration client and TortoiseSVN client;

[0011] After the code submission event is monitored and intercepted, the client is triggered to run, so as to trigger the Jenkins remote build task through the client, including:

[0012] Configure the continuous integration client as a hook program in the TortoiseSVN client;

[0013] After monitoring and intercepting the code submission event, the TortoiseSVN client starts the continuous integration client, so that the continuous integration client triggers the Jenkins remote build task;

[0014] If all tasks are built successfully, the code is pushed to the code repository through the client, otherwise push failure information is returned, including:

[0015] After all tasks are built, the continuous integration client determines whether the code meets the requirement of having defects according to whether the build result of each task is successful, and obtains the judgment result;

[0016] The judgment result is sent to the TortoiseSVN client. If successful, the code is pushed to the code repository through the TortoiseSVN client. Otherwise, a push failure message is returned.

[0017] Optionally, polling the monitoring plugin in Jenkins to obtain the latest build status of each task also includes:

[0018] The continuous integration client polls the monitoring plug-in at a preset time interval to obtain the latest build status of each task created by Jenkins using the status acquisition method in the monitoring plug-in.

[0019] Optionally, also include:

[0020] Set a hook script in the TortoiseSVN client, and set the hook type of the hook script to trigger the execution of the hook script before pushing the code to the code repository;

[0021] Receiving a configured working copy path, so that the hook script monitors the code submitted by the user under the working copy path and intercepts it to trigger a command line to be executed;

[0022] Receive the configured command line to be executed; wherein the command line includes the program command, the absolute path of the continuous integration client, and the name of the Jenkins task to be triggered. When the hook script is executed, the task name is passed to the continuous integration client under the absolute path in the form of a startup parameter to establish a binding relationship between the task and the code;

[0023] After monitoring and intercepting the code submission event, the TortoiseSVN client starts the continuous integration client, so that the continuous integration client triggers the Jenkins remote build task, including:

[0024] The hook script in the TortoiseSVN client, after monitoring and intercepting the code submitted by the user through the working copy path, triggers the startup of the continuous integration client under the absolute path through the command line to be executed, so that the continuous integration client obtains the task name from the startup parameters to trigger Jenkins to perform the task building operation.

[0025] Optionally, the method includes: after the hook script is executed, pushing the code to a code repository via a TortoiseSVN client.

[0026] Optionally, the continuous integration client obtains the task name from the startup parameters to trigger Jenkins to perform the task building operation, and further includes:

[0027] Using the TortoiseSVN client, detecting the changes of the intercepted code relative to the code in the local workspace, so as to generate a difference description file based on the changes; wherein the code in the local workspace is the same as the code in the Jenkins workspace;

[0028] The continuous integration client obtains the task name from the startup parameters, combines it with the Jenkins service address, generates a task build request and sends it to Jenkins to trigger Jenkins to perform a parameterized task build operation; wherein the task build request carries the difference description file.

[0029] Optionally, also include:

[0030] After receiving the task build request sent by the continuous integration client, Jenkins stores the difference description file in the task build request in the Jenkins workspace;

[0031] Download the latest code from the code repository and store it in Jenkins' workspace;

[0032] Apply the changes in the difference description file to the latest code in the Jenkins workspace to update the code, and then perform the parameterized task build operation.

[0033] Optionally, also include:

[0034] For any task built by Jenkins, receiving a configured file parameter; wherein the file parameter is used to store the difference description file in the workspace of Jenkins; and

[0035] Receive the selected code repository path and target strategy; wherein the target strategy is used to download the latest code from the code repository and store it in the Jenkins workspace, and then apply the changes in the difference description file to the latest code in the Jenkins workspace to update the code; and

[0036] A configured continuous integration process is received to detect defects on the code using the continuous integration process.

[0037] Optionally, the target strategy is also used to clean up the Jenkins workspace before each build task.

[0038] To achieve the above object, according to another aspect of an embodiment of the present invention, a Jenkins-based code integration management system is provided, comprising:

[0039] The trigger module is used to trigger the client to run after monitoring and intercepting the code submission event, so as to trigger the Jenkins remote build task through the client; the task is used to detect defects in the code in the code submission event;

[0040] The polling module is used to poll the monitoring plugin in Jenkins to obtain the latest build status of each task;

[0041] The push module is used to push the code to the code repository through the client if all tasks are built successfully, otherwise return push failure information.

[0042] Optional, clients include continuous integration client and TortoiseSVN client;

[0043] The trigger module is used to: configure the continuous integration client as a hook program in the TortoiseSVN client; after the TortoiseSVN client monitors and intercepts the code submission event, it starts the continuous integration client, so that the continuous integration client triggers the Jenkins remote build task;

[0044] The push module is used for: after all tasks are built, the continuous integration client determines whether the code meets the defect requirement according to whether the build result of each task is successful, and obtains the judgment result; the judgment result is sent to the TortoiseSVN client, and if successful, the code is pushed to the code repository through the TortoiseSVN client, otherwise, the push failure information is returned.

[0045] Optionally, the polling module is further used for: the continuous integration client polls the monitoring plug-in at a preset time interval to utilize the status acquisition system in the monitoring plug-in to obtain the latest build status of each task created by Jenkins.

[0046] Optionally, TortoiseSVN client is also included for:

[0047] Set a hook script in the TortoiseSVN client, and set the hook type of the hook script to trigger the execution of the hook script before pushing the code to the code repository;

[0048] Receiving a configured working copy path, so that the hook script monitors the code submitted by the user under the working copy path and intercepts it to trigger a command line to be executed;

[0049] Receive the configured command line to be executed; wherein the command line includes the program command, the absolute path of the continuous integration client, and the name of the Jenkins task to be triggered. When the hook script is executed, the task name is passed to the continuous integration client under the absolute path in the form of a startup parameter to establish a binding relationship between the task and the code;

[0050] The trigger module is used for: the hook script in the TortoiseSVN client, after monitoring and intercepting the code submitted by the user through the working copy path, triggers the startup of the continuous integration client under the absolute path through the command line to be executed, so that the continuous integration client obtains the task name from the startup parameters to trigger Jenkins to perform the task building operation.

[0051] Optionally, the method includes: after the hook script is executed, pushing the code to a code repository via a TortoiseSVN client.

[0052] Optionally, the trigger module is used to:

[0053] Using the TortoiseSVN client, detecting the changes of the intercepted code relative to the code in the local workspace, so as to generate a difference description file based on the changes; wherein the code in the local workspace is the same as the code in the Jenkins workspace;

[0054] The continuous integration client obtains the task name from the startup parameters, combines it with the Jenkins service address, generates a task build request and sends it to Jenkins to trigger Jenkins to perform a parameterized task build operation; wherein the task build request carries the difference description file.

[0055] Optionally, an update module is also included to:

[0056] After receiving the task build request sent by the continuous integration client, Jenkins stores the difference description file in the task build request in the Jenkins workspace;

[0057] Download the latest code from the code repository and store it in Jenkins' workspace;

[0058] Apply the changes in the difference description file to the latest code in the Jenkins workspace to update the code, and then perform the parameterized task build operation.

[0059] Optionally, building blocks are included to:

[0060] For any task built by Jenkins, receiving a configured file parameter; wherein the file parameter is used to store the difference description file in the workspace of Jenkins; and

[0061] Receive the selected code repository path and target strategy; wherein the target strategy is used to download the latest code from the code repository and store it in the Jenkins workspace, and then apply the changes in the difference description file to the latest code in the Jenkins workspace to update the code; and

[0062] A configured continuous integration process is received to detect defects on the code using the continuous integration process.

[0063] Optionally, the target strategy is also used to clean up the Jenkins workspace before each build task.

[0064] To achieve the above objective, according to another aspect of an embodiment of the present invention, a code integration management electronic device based on Jenkins is provided.

[0065] The electronic device of an embodiment of the present invention includes: one or more processors; a storage device for storing one or more programs, and when the one or more programs are executed by the one or more processors, the one or more processors implement any of the above-mentioned Jenkins-based code integration management methods.

[0066] To achieve the above-mentioned purpose, according to another aspect of an embodiment of the present invention, a computer-readable medium is provided, on which a computer program is stored, and when the program is executed by a processor, any of the above-mentioned code integration management methods based on Jenkins is implemented.

[0067] According to the solution provided by the present invention, one embodiment of the above invention has the following advantages or beneficial effects: it can realize functions such as code submission interception, differential code application to the server, unified server-side construction process, construction progress and result display, etc. By intercepting code submission and applying differential content to Jenkins, the problem of traditional code submission to the code repository before execution is solved. At the same time, the use of a unified Jenkins task construction also solves the problem of inconsistent client construction environment and cumbersome environment construction.

[0068] The further effects of the above-mentioned non-conventional optional manner will be described below in conjunction with the specific implementation manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0069] The accompanying drawings are used to better understand the present invention and do not constitute an improper limitation of the present invention.

[0070] Figure 1 This is a main flow chart of a code integration management method based on Jenkins according to an embodiment of the present invention;

[0071] Figure 2 It is a flowchart of an optional Jenkins-based code integration management method according to an embodiment of the present invention;

[0072] Figure 3 It is a flowchart of another optional Jenkins-based code integration management method according to an embodiment of the present invention;

[0073] Figure 4 It is a flowchart of another optional Jenkins-based code integration management method according to an embodiment of the present invention;

[0074] Figure 5 It is a flowchart of another optional Jenkins-based code integration management method according to an embodiment of the present invention;

[0075] Figure 6 This is a schematic diagram of main modules of a Jenkins-based code integration management system according to an embodiment of the present invention;

[0076] Figure 7 is an exemplary system architecture diagram to which embodiments of the present invention may be applied;

[0077] Figure 8 It is a schematic diagram of the structure of a computer system of a mobile device or a server suitable for implementing an embodiment of the present invention. DETAILED DESCRIPTION

[0078] The following is a description of exemplary embodiments of the present invention in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those of ordinary skill in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and conciseness, the description of well-known functions and structures is omitted in the following description.

[0079] See also Figure 1 , which shows a main flow chart of a code integration management method based on Jenkins provided by an embodiment of the present invention, including the following steps:

[0080] S101: After the code submission event is monitored and intercepted, the client is triggered to run, so as to trigger the Jenkins remote build task through the client; wherein the task is used to detect defects in the code in the code submission event;

[0081] S102: Poll the monitoring plugin in Jenkins to obtain the latest build status of each task;

[0082] S103: If all tasks are built successfully, the code is pushed to the code repository through the client, otherwise a push failure message is returned.

[0083] In the above implementation, for step S101, in actual operation, the user usually downloads the code in the code repository to the local computer for modification, and then pushes the modified code to the code repository for updating.

[0084] This solution uses Java to write a continuous integration client and uses AWT (Abstract Window Toolkit) technology to draw the display interface to load the build status of each task in Jenkins. The tasks here are used to perform continuous integration build / defect detection on the code submitted by the user.

[0085] The main function of the continuous integration client is to monitor and intercept the user's code submission events. When the user submits code using the TortoiseSVN client, it will automatically trigger the continuous integration client to run. The continuous integration client then polls the Jenkins rest API through the http method to trigger the Jenkins continuous integration system (i.e. the continuous integration server) to remotely build one or more tasks.

[0086] For example, create build tasks on Jenkins, such as code style check (CheckStyle), compilation check, static defect check (FindBugs), packaging check, unit test, etc., as shown in Table 1:

[0087] Table 1

[0088] DAILY_VISITOR_CHECKSTYLE DAILY_VISITOR_COMPILE DAILY_VISITOR_FINDBUGS DAILY_VISITOR_PACKAGE DAILY_VISITOR_TEST

[0089] For step S102, Jenkins uses the created monitoring plug-in to obtain the latest build status of each task, including the build progress and build results. Jenkins provides an interface to feedback the build status of each task to the continuous integration client in real time; at the same time, Jenkins provides an interface feedback mechanism to the user so that the user can view the build status of each task. Here, the continuous integration client can poll the monitoring plug-in of Jenkins every 1 second (i.e., the preset time interval, which is actually adjustable) to obtain the latest build status of each task.

[0090] For step S103, an example of the task build status returned by the monitoring plug-in at Jenkins is as follows:

[0091]

[0092] Among them, building is false, indicating that the current task has been completed, otherwise it is being executed; buildNum is the Jenkins task build number; jobName is the Jenkins task name; progress is the build progress, with a value of 0-100%; color is used to mark the build result, and its value is as follows:

[0093] 1) Task is being executed (i.e. building = true), color = empty string

[0094] 2) Task execution successful: color = BLUE

[0095] 3) Task execution failed: color = RED

[0096] 4) Task execution is unstable: color = YELLOW (If a post-build operation is configured in the task, such as sending an email, if the sending fails, it will be marked as unstable, that is, a non-core process and a failed item).

[0097] When all tasks are built, that is, building is false, it means that the build has been completed. You only need to determine whether the color of all tasks is BLUE. If the execution result of one task is RED, it means that there is a failed task, then the continuous integration fails and the code is not allowed to be pushed to the code repository. Otherwise, it means that the code submitted this time has no risks / defects, the build is successful, and the code can be pushed to the code repository.

[0098] For tasks that fail to build, such as DAILY_VISITOR_FINDBUGS, it means there are risks in the code. The continuous integration client will pop up a build failure confirmation box, and after the user confirms, the continuous integration client will exit and return -1. However, if the build steps of all tasks are BLUE, the continuous integration client will pop up a build success confirmation box, and after the user confirms, the continuous integration client will exit and return 0.

[0099] The method provided in the above embodiment can, on the one hand, ensure that continuous integration build checks can be performed before the code is submitted to the code repository to avoid code contamination in the code repository; on the other hand, the entire build environment is built on Jenkins, and each user does not need to repeatedly build the environment locally, while also ensuring the uniformity of the continuous integration environment.

[0100] See also Figure 2 , shows a flow chart of an optional Jenkins-based code integration management method according to an embodiment of the present invention, comprising the following steps:

[0101] S201: Configure the continuous integration client as a hook program in the TortoiseSVN client;

[0102] S202: After monitoring and intercepting the code submission event, the TortoiseSVN client starts the continuous integration client, so that the continuous integration client triggers the Jenkins remote build task; wherein, the task is used to detect defects in the code in the code submission event;

[0103] S203: The continuous integration client polls the monitoring plug-in in Jenkins to obtain the latest build status of each task;

[0104] S204: After all tasks are built, the continuous integration client determines whether the code has defects according to whether the build result of each task is successful, and obtains a determination result;

[0105] S205: Send the determination result to the TortoiseSVN client;

[0106] S206: If successful, push the code to the code repository through the TortoiseSVN client; otherwise, return a push failure message.

[0107] In the above embodiment, for step S203, see Figure 1 The description of step S102 is not repeated here.

[0108] For steps S201 to S202, the client in this solution includes a continuous integration client and a TortoiseSVN client, wherein the continuous integration client needs to be used in conjunction with SVN to monitor the code submission events of the TortoiseSVN client. For example, open the settings page of the TortoiseSVN client and select Hook Script to add a HookScript.

[0109] Hook Script is pre-configured with a setting interface. First, set the Hook Type. The TortoiseSVN client provides a variety of hook types. This solution prefers to use Pre-Commit Hook, that is, before submitting the code to the code repository, execute the batch script in "Command Line To Execute" and pass the detailed information of this submission, such as the list of changed files and submission notes, to the continuous integration client.

[0110] Secondly, set the Working Copy Path, which is the working directory used by the Hook Script. The execution of "Command Line ToExecute" will be triggered only when the user submits code (intercepted by the hook script) in this working directory.

[0111] Next, set Command Line To Execute. The command line can be a batch file, executable file, or other valid Windows-associated file, such as a Perl script. It includes program commands, the absolute path of the continuous integration client, and the name of the Jenkins task to be triggered.

[0112] Finally, check "Wait for the script to finish" at the bottom of the settings page, which means that you need to wait for the Hook Script to finish before executing the subsequent operation, which means pushing the code submitted by the user to the code repository. At this time, only the code push request is executed, and the request is intercepted by the Hook Script. You need to wait for the script to finish before continuing.

[0113] For example, java-jar D:\ci-client.jar[checkstyle,findbugs,compile,junitTest,pack age], where java-jar is the command to execute the jar program, D:\ci-client.jar is the absolute path of the continuous integration client, and [DAILY_VISITOR_CHECKSTYLE,DAILY_VISIT OR_COMPILE,DAILY_VISITOR_FINDBUGS,DAILY_VISITOR_PAC KAGE,DAILY_VISITOR_TEST] is the name of the Jenkins task to be triggered. When the Hook Script is executed, these task names will be passed to ci-client.jar in the form of startup parameters, thus realizing the binding of project code and build tasks.

[0114] At this time, when the user submits code in "D:\Workspace\CIProject", the Hook Script monitors and intercepts it, and triggers the startup of the continuous integration client (i.e., ci-client.jar) through the above command line. The continuous integration client obtains the Jenkins task name from the startup parameters and triggers the execution of these tasks in Jenkins. After the execution is successfully triggered, the display operation of the task build status will be started.

[0115] According to the above description, the continuous integration client and TortoiseSVN client need to be used together. The continuous integration client is configured as a hook program (SVN Hook) in the TortoiseSVN client. When the user submits code using TortoiseSVN, TortoiseSVN first starts the hook program, i.e. the continuous integration client. At this time, the continuous integration client triggers the Jenkins remote build task and feeds back the build status of each task to the user in real time.

[0116] For steps S204 to S206, after all tasks are built, the continuous integration client determines whether the submitted code has defects / risks based on whether each task is built successfully, and notifies the TortoiseSVN client of the judgment result. The TortoiseSVN client decides whether to continue pushing the code to the code repository based on the judgment result.

[0117] according to Figure 1As shown in the description, if the integration fails, the continuous integration client exits and returns -1, and the Hook Script receives the exit code -1, confirming that the script execution failed and the code submission was unsuccessful, so the code will not be pushed to the code repository. If the integration is successful, the continuous integration client exits and returns 0, and the Hook Script receives the exit code 0, confirming that the script execution was successful, and then the code will be pushed to the code repository.

[0118] The method provided in the above embodiment requires the continuous integration client and the TortoiseSVN client to be used in conjunction. The TortoiseSVN client is responsible for monitoring and intercepting code submission events, as well as triggering the startup of the continuous integration client. The continuous integration client then interacts with Jenkins to determine the push decision to control whether the TortoiseSVN client pushes the code to the code repository.

[0119] See also Figure 3 , shows another optional Jenkins-based code integration management method flow chart according to an embodiment of the present invention, including the following steps:

[0120] S301: Using the TortoiseSVN client, detecting the changes of the intercepted code relative to the code in the local workspace, so as to generate a difference description file based on the changes; wherein the code in the local workspace is the same as the code in the Jenkins workspace;

[0121] S302: The continuous integration client obtains the task name from the startup parameters, combines it with the Jenkins service address, generates a task build request and sends it to Jenkins to trigger Jenkins to perform a parameterized task build operation; wherein the task build request carries the difference description file.

[0122] S303: After receiving the task build request sent by the continuous integration client, Jenkins stores the difference description file in the task build request in the Jenkins workspace;

[0123] S304: Download the latest code from the code repository and store it in the Jenkins workspace;

[0124] S305: Apply the changes in the difference description file to the latest code in the Jenkins workspace to update the code, and then perform a parameterized task construction operation.

[0125] In the above implementation, for step S301, after the user submits the code, the TortoiseSVN client will intercept the code, compare it with the code in the local workspace, determine whether there is a difference, and then generate a difference description file patch.diff, which records the change details of the code submitted by the user. Here, the local workspace of the TortoiseSVN client can be equivalent to Figure 2 The working copy paths shown may not be the same, depending on the staff settings.

[0126] For step S302, the continuous integration client triggers the execution of the task in Jenkins. Jenkins supports directly triggering task building through http requests, such as sending the aforementioned patch.diff to the Jenkins build task through POST requests. The http trigger method is: ${JENKINS_URL} / job / ${jobName} / buildWithParameters, where JENKINS_URL is the address of the Jenkins service, jobName is the task name configured by the aforementioned "CommandLine To Execute", buildWithParameters means that the parameters are included during the build, and the patch.diff file is the accompanying difference description file.

[0127] For steps S303 to S305, after receiving the task building request transmitted by the continuous integration client, Jenkins first saves patch.diff in the Jenkins workspace, and then executes the task flow configured above, downloads the latest code from the code repository, and stores it in the Jenkins workspace. After the code is stored, the code changes in patch.diff are applied to the code in the Jenkins workspace to update the code, and then the subsequent parameter task building process is carried out. At this time, the code is already the user-modified version when it is rebuilt.

[0128] patch.diff describes the code changes in detail, and these differences can be directly applied to the specified file through the Linux command patch. For example, the code changes submitted by the current user are to add a line of code comments " / / ·Add a line of code comments". At this time, the Jenkins task executes the patch command, stores patch.diff in the Jenkins workspace, and writes the code changes to the code in the workspace, so that the code changes can be continuously integrated and built without submitting the code to the code repository.

[0129] The method provided in the above embodiment, by constructing a code difference description file, enables the code changes at the client to be quickly transmitted to Jenkins, thereby achieving the purpose of continuous integration and construction of the code changes without submitting the code to the code repository.

[0130] See also Figure 4 , shows a flow chart of another optional code integration management method based on Jenkins according to an embodiment of the present invention, comprising the following steps:

[0131] S401: For any task constructed by Jenkins, receiving a configured file parameter; wherein the file parameter is used to store the difference description file in the workspace of Jenkins;

[0132] S402: receiving the selected code repository path and target strategy; wherein the target strategy is used to download the latest code from the code repository and store it in the Jenkins workspace, and then apply the changes in the difference description file to the latest code in the Jenkins workspace to update the code;

[0133] S403: Receive a configured continuous integration process to perform defect detection on the code using the continuous integration process.

[0134] In the above implementation, for steps S401 to S403, the Jenkins environment building process is a relatively mature technology in the field and is a key process node in this solution. This solution focuses on applying its functions and will not be described in detail here.

[0135] In addition, the construction of the operating environment varies from project to project. For example, for JavaWeb projects, the Java operating environment JDK needs to be installed in the build server, and for Maven projects, the Maven tool needs to be installed. Other programming languages ​​can build environments according to needs. This solution takes the Java project as an example and builds a Maven project operating environment. The way to build the relevant environment is a common technical means in this field, which will not be repeated here.

[0136] Create build tasks on Jenkins, such as code style check (CHECKSTYLE), compile check (COMPILE), static defect check (FINDBUGS), package check (PACKAGE), unit test (TEST), etc. Take the compile check task DAILY_VISITOR_COMPILE as an example, its configuration content is as follows:

[0137] 1. Parameterized build process: Add a file parameter (File Parameter) in the parameterized build process. This parameter allows the user to pass a file as a build parameter when triggering a build, and can receive a difference description file from the continuous integration client. The file location (File Location) is configured as patch.diff. At this time, the received file is saved in the Jenkins workspace and named patch.diff.

[0138] 2. Latest code management, select Subversion version control system (or function) in the latest code management, the interface displays three functions: Modules, Additional Credentials, and Check-out Strategy. Configure the Repository URL (code repository) in the Modules module, and select "Always check out a fresh copy" under Check-out Strategy (code download strategy). In order to avoid mutual influence, this strategy will first clean up the workspace before each build task, and re-download the latest code from the code repository and store it in the Jenkins workspace, and then apply the changes in the difference description file to the latest code in the Jenkins workspace to update the code.

[0139] 3. Continuous integration build content configuration. For Maven projects, you can add Invoke top-level Maventargets (Maven project build process). Configure Goals (target instructions), which are Maven instructions to be executed. You can configure multiple instructions according to different needs. For other build tasks, you only need to adjust the "Goals" in this configuration. The purpose is to detect defects in the code. The details are as follows:

[0140] a Packaging check: clean package-Dmaven.test.skip, where Dmaven.test.skip is to skip unit testing and only perform the packaging process.

[0141] bUnit test: clean test

[0142] C code style check: checkstyle:checkstyle

[0143] dStatic defect analysis: compile findbugs:findbugs. The compile is added because the findbugs check is based on Java bytecode, so it is necessary to compile the Java bytecode through compile first.

[0144] Settings file can specify the Settings.xml file when Maven is executed. This solution reconfigures settings.xml and configures the specified settings-public.xml path here.

[0145] The method provided in the above embodiment can construct tasks for Jenkins according to actual needs to better detect defects in the code.

[0146] See also Figure 5 , shows a flow chart of another optional code integration management method based on Jenkins according to an embodiment of the present invention, comprising the following steps:

[0147] S501: The continuous integration client polls the monitoring plug-in in Jenkins at a preset time interval to obtain the latest build status of each task created by Jenkins using a status acquisition method in the monitoring plug-in;

[0148] S502: After all tasks are built, the continuous integration client determines whether the code has defects according to whether the build result of each task is successful, and obtains a determination result;

[0149] S503: Send the determination result to the TortoiseSVN client;

[0150] S504: If successful, push the code to the code repository through the TortoiseSVN client; otherwise, return a push failure message.

[0151] In the above embodiment, for steps S502 to S504, see Figure 2 As shown, no further details are given here.

[0152] For step S501, the monitoring plug-in is built on Jenkins. The plug-in provides two functions. First, it provides a task building process display page to view the task building progress and building results; second, it provides an http method for obtaining the task building progress (i.e., the status acquisition method).

[0153] Taking the first task in Table 1 as an example, its latest build status is "DAILY_VISITOR_CHECHSTYLE#13Successfully", where DAILY_VISITOR_CHECH STYLE is the Jenkins task name, #13 is the task execution number, and Successfully means that the task is successfully executed. Taking the third task as an example, its latest build status is "DAILY_VISITOR_FINDBLGS#13failed", and failed means that the task fails to execute. For the tasks in execution, the build progress will be displayed, for example, the execution progress of the fourth task "DAILY_VISITOR_PACKAGE" is 40%.

[0154] In addition, a JenkinsServer instance is built through JenkinsHelper, which can obtain the build number of the current task execution according to the task name. The current build status of the task can be obtained through the task query interface provided by the monitoring plug-in.

[0155] The monitoring plug-in can also support querying the execution results of the specified task through http polling to determine whether the continuous integration is successful on the continuous integration client. The request method is curl http: / / 192.168.31.273:8080 / jenkins / build-monitor / loadBuild? querys=TEST_JOB~4,TRUNK_VISITOR_CHECKSTYLE~4, and the input parameters are querys={JOB_NAME}~{build number}. Multiple parameters are separated by English commas. JOB_NAME is the configured task name, and the build number is the time when the task is triggered.

[0156] The method provided in the above embodiment obtains the construction progress and construction results of the specified task in real time by developing a Jenkins monitoring plug-in.

[0157] The method provided by the embodiment of the present invention aims to fill the shortcomings of existing continuous integration and solve the problem that the code is easily contaminated and a unified build environment cannot be achieved. 1. Realize remote private builds and perform defect detection before submitting the code to the code repository. That is, when the user submits the code, the code submission is intercepted and the changes are applied to Jenkins remotely to detect problems incrementally. 2. Realize a unified build environment: Ensure that the continuous integration environment of each user is consistent. Transferring all build scenarios to Jenkins can support complex build scenarios, and users do not have to build a continuous integration environment locally.

[0158] See also Figure 6, showing a schematic diagram of main modules of a Jenkins-based code integration management system 600 provided in an embodiment of the present invention, including:

[0159] The trigger module 601 is used to trigger the client to run after monitoring and intercepting the code submission event, so as to trigger the Jenkins remote build task through the client; wherein the task is used to detect defects in the code in the code submission event;

[0160] The polling module 602 is used to poll the monitoring plug-in in Jenkins to obtain the latest build status of each task;

[0161] The push module 603 is used to push the code to the code repository through the client if all tasks are built successfully, otherwise return the push failure information.

[0162] In the implementation system of the present invention, the client includes a continuous integration client and a TortoiseSVN client;

[0163] The trigger module 601 is used to: configure the continuous integration client as a hook program in the TortoiseSVN client; after the TortoiseSVN client monitors and intercepts the code submission event, it starts the continuous integration client, so that the continuous integration client triggers the Jenkins remote build task;

[0164] The push module 603 is used for: after all tasks are built, the continuous integration client determines whether the code meets the defect requirement according to whether the build result of each task is successful, and obtains the judgment result; sends the judgment result to the TortoiseSVN client, and if successful, pushes the code to the code repository through the TortoiseSVN client, otherwise returns the push failure information.

[0165] In the implementation system of the present invention, the polling module 602 is also used for: the continuous integration client polls the monitoring plug-in at a preset time interval to utilize the status acquisition system in the monitoring plug-in to obtain the latest build status of each task created by Jenkins.

[0166] The implementation system of the present invention also includes a TortoiseSVN client, which is used to:

[0167] Set a hook script in the TortoiseSVN client, and set the hook type of the hook script to trigger the execution of the hook script before pushing the code to the code repository;

[0168] Receiving a configured working copy path, so that the hook script monitors the code submitted by the user under the working copy path and intercepts it to trigger a command line to be executed;

[0169] Receive the configured command line to be executed; wherein the command line includes the program command, the absolute path of the continuous integration client, and the name of the Jenkins task to be triggered. When the hook script is executed, the task name is passed to the continuous integration client under the absolute path in the form of a startup parameter to establish a binding relationship between the task and the code;

[0170] The trigger module is used for: the hook script in the TortoiseSVN client, after monitoring and intercepting the code submitted by the user through the working copy path, triggers the startup of the continuous integration client under the absolute path through the command line to be executed, so that the continuous integration client obtains the task name from the startup parameters to trigger Jenkins to perform the task building operation.

[0171] In the implementation system of the present invention, after the hook script is executed, the code is pushed to the code warehouse through the TortoiseSVN client.

[0172] In the implementation system of the present invention, the trigger module 601 is used to:

[0173] Using the TortoiseSVN client, detecting the changes of the intercepted code relative to the code in the local workspace, so as to generate a difference description file based on the changes; wherein the code in the local workspace is the same as the code in the Jenkins workspace;

[0174] The continuous integration client obtains the task name from the startup parameters, combines it with the Jenkins service address, generates a task build request and sends it to Jenkins to trigger Jenkins to perform a parameterized task build operation; wherein the task build request carries the difference description file.

[0175] The implementation system of the present invention also includes an update module, which is used to:

[0176] After receiving the task build request sent by the continuous integration client, Jenkins stores the difference description file in the task build request in the Jenkins workspace;

[0177] Download the latest code from the code repository and store it in Jenkins' workspace;

[0178] Apply the changes in the difference description file to the latest code in the Jenkins workspace to update the code, and then perform the parameterized task build operation.

[0179] The implementation system of the present invention also includes a building block for:

[0180] For any task built by Jenkins, receiving a configured file parameter; wherein the file parameter is used to store the difference description file in the workspace of Jenkins; and

[0181] Receive the selected code repository path and target strategy; wherein the target strategy is used to download the latest code from the code repository and store it in the Jenkins workspace, and then apply the changes in the difference description file to the latest code in the Jenkins workspace to update the code; and

[0182] A configured continuous integration process is received to detect defects on the code using the continuous integration process.

[0183] In the implementation system of the present invention, the target strategy is also used to clean up the workspace of Jenkins before each build task.

[0184] In addition, the specific implementation content of the system described in the embodiment of the present invention has been described in detail in the method described above, so the repeated content will not be described again here.

[0185] Figure 7 An exemplary system architecture 700 to which embodiments of the present invention may be applied is shown, including terminal devices 701 , 702 , 703 , a network 704 and a server 705 (only an example).

[0186] Terminal devices 701, 702, 703 can be various electronic devices with display screens and supporting web browsing, and various communication client applications are installed. Users can use terminal devices 701, 702, 703 to interact with server 705 through network 704 to receive or send messages, etc.

[0187] The network 704 is used to provide a medium for communication links between the terminal devices 701, 702, 703 and the server 705. The network 704 may include various connection types, such as wired, wireless communication links or optical fiber cables.

[0188] Server 705 can be a server that provides various services, such as executing build hook scripts, monitoring code and intercepting, triggering client startup, triggering Jenkins build tasks, obtaining task build status and making decisions, etc.

[0189] It should be noted that the method provided in the embodiment of the present invention is generally executed by the server 705 , and accordingly, the system is generally set in the server 705 .

[0190] It should be understood that Figure 7 The number of terminal devices, networks and servers in the embodiment is only for illustration. Any number of terminal devices, networks and servers may be provided according to implementation requirements.

[0191] Reference below Figure 8 , which shows a schematic diagram of the structure of a computer system 800 of a terminal device suitable for implementing an embodiment of the present invention. Figure 8 The terminal device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0192] like Figure 8 As shown, the computer system 800 includes a central processing unit (CPU) 801, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 802 or a program loaded from a storage part 808 into a random access memory (RAM) 803. In the RAM 803, various programs and data required for the operation of the system 800 are also stored. The CPU 801, the ROM 802, and the RAM 803 are connected to each other via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0193] The following components are connected to the I / O interface 805: an input section 806 including a keyboard, a mouse, etc.; an output section 807 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 808 including a hard disk, etc.; and a communication section 809 including a network interface card such as a LAN card, a modem, etc. The communication section 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to the I / O interface 805 as needed. A removable medium 811, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 810 as needed, so that a computer program read therefrom is installed into the storage section 808 as needed.

[0194] In particular, according to the embodiments disclosed in the present invention, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present invention include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 809, and / or installed from the removable medium 811. When the computer program is executed by the central processing unit (CPU) 801, the above-mentioned functions defined in the system of the present invention are executed.

[0195] It should be noted that the computer-readable medium shown in the present invention may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present invention, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device. In the present invention, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable program code. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0196] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present invention. In this regard, each box in the flow chart or block diagram can represent a module, a program segment, or a part of a code, and the above-mentioned module, program segment, or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of the boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0197] The modules involved in the embodiments of the present invention may be implemented by software or hardware. The modules described may also be set in a processor. For example, they may be described as: a processor includes a trigger module, a polling module, and a push module. The names of these modules do not, in some cases, constitute limitations on the modules themselves. For example, a push module may also be described as a "code push module".

[0198] As another aspect, the present invention further provides a computer-readable medium, which may be included in the device described in the above embodiment; or may exist independently without being assembled into the device. The above computer-readable medium carries one or more programs, and when the above one or more programs are executed by a device, the device includes:

[0199] After monitoring and intercepting the code submission event, the client is triggered to run, so as to trigger the Jenkins remote build task through the client; the task is used to detect defects in the code in the code submission event;

[0200] Poll the monitoring plugin in Jenkins to get the latest build status of each task;

[0201] If all tasks are built successfully, the code is pushed to the code repository through the client, otherwise a push failure message is returned.

[0202] According to the technical solution of the embodiment of the present invention, functions such as code submission interception, differential code application to the server, unified server-side build process, build progress and result display can be realized. By intercepting code submission and applying differential content to Jenkins, the problem of traditional code submission to the code repository before execution is solved. At the same time, the use of a unified Jenkins task build also solves the problem of inconsistent client build environments and cumbersome environment construction.

[0203] The above specific implementations do not constitute a limitation on the protection scope of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may occur depending on design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A code integration management method based on Jenkins, characterized in that: include: After monitoring and intercepting the code submission event, triggering the client to run, so as to trigger the Jenkins remote build task through the client; wherein the task is used to detect defects in the code in the code submission event; the client includes a continuous integration client and a TortoiseSVN client; after monitoring and intercepting the code submission event, triggering the client to run, so as to trigger the Jenkins remote build task through the client, includes: configuring the continuous integration client as a hook program in the TortoiseSVN client; after monitoring and intercepting the code submission event, the TortoiseSVN client starts the continuous integration client, so as to trigger the Jenkins remote build task by the continuous integration client; Poll the monitoring plugin in Jenkins to get the latest build status of each task; If all tasks are built successfully, the code is pushed to the code repository through the client, otherwise a push failure message is returned, including: after all tasks are built, the continuous integration client determines whether the code has defects according to whether the build result of each task is successful, and obtains a judgment result; the judgment result is sent to the TortoiseSVN client, if successful, the code is pushed to the code repository through the TortoiseSVN client, otherwise a push failure message is returned.

2. The method according to claim 1, characterized in that The monitoring plugin in Jenkins is polled to obtain the latest build status of each task, including: The continuous integration client polls the monitoring plug-in at a preset time interval to obtain the latest build status of each task created by Jenkins using the status acquisition method in the monitoring plug-in.

3. The method according to claim 1, characterized in that Also includes: Set a hook script in the TortoiseSVN client, and set the hook type of the hook script to trigger the execution of the hook script before pushing the code to the code repository; Receiving a configured working copy path, so that the hook script monitors the code submitted by the user under the working copy path and intercepts it to trigger a command line to be executed; Receive the configured command line to be executed; wherein the command line includes the program command, the absolute path of the continuous integration client, and the name of the Jenkins task to be triggered. When the hook script is executed, the task name is passed to the continuous integration client under the absolute path in the form of a startup parameter to establish a binding relationship between the task and the code; After monitoring and intercepting the code submission event, the TortoiseSVN client starts the continuous integration client, so that the continuous integration client triggers the Jenkins remote build task, including: The hook script in the TortoiseSVN client, after monitoring and intercepting the code submitted by the user through the working copy path, triggers the startup of the continuous integration client under the absolute path through the command line to be executed, so that the continuous integration client obtains the task name from the startup parameters to trigger Jenkins to perform the task building operation.

4. The method according to claim 3, characterized in that include: After the hook script is executed, the code is pushed to the code repository through the TortoiseSVN client.

5. The method according to claim 3 or 4, characterized in that: The continuous integration client obtains the task name from the startup parameters to trigger Jenkins to perform the task building operation, and also includes: Using the TortoiseSVN client, detecting the changes of the intercepted code relative to the code in the local workspace, so as to generate a difference description file based on the changes; wherein the code in the local workspace is the same as the code in the Jenkins workspace; The continuous integration client obtains the task name from the startup parameters, combines it with the Jenkins service address, generates a task build request and sends it to Jenkins to trigger Jenkins to perform a parameterized task build operation; wherein the task build request carries the difference description file.

6. The method according to claim 5, characterized in that Also includes: After receiving the task build request sent by the continuous integration client, Jenkins stores the difference description file in the task build request in the Jenkins workspace; Download the latest code from the code repository and store it in Jenkins' workspace; Apply the changes in the difference description file to the latest code in the Jenkins workspace to update the code, and then perform the parameterized task build operation.

7. The method according to claim 6, characterized in that Also includes: For any task built by Jenkins, receiving a configured file parameter; wherein the file parameter is used to store the difference description file in the workspace of Jenkins; and Receive the selected code repository path and target strategy; wherein the target strategy is used to download the latest code from the code repository and store it in the Jenkins workspace, and then apply the changes in the difference description file to the latest code in the Jenkins workspace to update the code; and A configured continuous integration process is received to detect defects on the code using the continuous integration process.

8. The method according to claim 7, characterized in that The target strategy is also used to clean up the Jenkins workspace before each build task.

9. A code integration management system based on Jenkins, characterized in that: include: A trigger module is used to trigger the client to run after monitoring and intercepting a code submission event, so as to trigger a Jenkins remote build task through the client; wherein the task is used to detect defects in the code in the code submission event; the client includes a continuous integration client and a TortoiseSVN client; after monitoring and intercepting a code submission event, triggering the client to run to trigger a Jenkins remote build task through the client includes: configuring the continuous integration client as a hook program in the TortoiseSVN client; after monitoring and intercepting a code submission event, the TortoiseSVN client starts the continuous integration client, so as to trigger the Jenkins remote build task by the continuous integration client; The polling module is used to poll the monitoring plugin in Jenkins to obtain the latest build status of each task; The push module is used to push the code to the code repository through the client if all tasks are built successfully, otherwise return push failure information, including: after all tasks are built, the continuous integration client determines whether the code meets the defect requirements based on whether the build result of each task is successful, and obtains the judgment result; the judgment result is sent to the TortoiseSVN client, if successful, the code is pushed to the code repository through the TortoiseSVN client, otherwise return push failure information.

10. An electronic device, characterized in that: include: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 8.

11. A computer readable medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 8 is implemented.

Images