Continuous integration and continuous delivery method supporting complex Maven project

Abstract

The invention discloses a continuous integration and continuous delivery method supporting complex Maven projects, which comprises the following steps: distributing project group roles and permissions, and configuring key information; the method comprises the following steps of: configuring a code address and related information, which are pointed to a corresponding Gitlab, in Jenkins (Jenkins), wherein the code address and the related information of the corresponding Gitlab are configured in the Jenkins (Jenkins); the method comprises the following steps of: adding a core flow processing function into a Gitlab code warehouse corresponding to Global Pipeline Libraries, and adding a core flow processing function into the Gitlab code warehouse corresponding to the Global Pipeline Libraries; the method comprises the following steps of: adding a common function group into a Gitlab code warehouse corresponding to Global Pipeline Libraries, and adding a common function group into the Gitlab code warehouse corresponding to the Global Pipeline Libraries; each project group compiles a Pipeline script of each project in the Jenkins; a Webhook corresponding to the item code is configured in the Gitlab so as to trigger the CICD process; deleting a label in the Gitlab code library, labeling, and executing a Pipeline script corresponding to the project code library when branch codes are submitted and triggered; according to the invention, the safety, universality and flexibility of the CICD are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of software development, and particularly relates to a method for supporting continuous integration and continuous delivery of complex Maven projects. BACKGROUND

[0002] With the rapid development of the software industry, continuous integration and continuous delivery (CICD) plays a crucial role in ensuring code quality and improving development efficiency. However, traditional CICD methods often face challenges such as complex configuration and difficult maintenance when dealing with complex Maven projects. These problems mainly stem from excessive reliance on single scripts, resulting in low code reusability, difficult maintenance, and lack of sufficient flexibility and scalability, making it difficult to meet the individual needs of various projects, especially when there are many team members, the number of projects is growing, and Maven projects exist in various ways in Gitlab, such as single project, multiple sub-projects, multiple Maven sub-projects in multiple directories, etc. Therefore, there is an urgent need for a more efficient, flexible, and scalable CICD solution. SUMMARY

[0003] To solve the problems existing in the prior art, the purpose of the present application is to provide a method for supporting continuous integration and continuous delivery of complex Maven projects, which improves the security, universality and flexibility of continuous integration and continuous delivery.

[0004] To achieve the above-mentioned purpose, the technical solution adopted by the present application is as follows: a method for supporting continuous integration and continuous delivery of complex Maven projects, comprising the following steps:

[0005] Step 1: Assign project group roles and permissions through the Jenkins role management module;

[0006] Step 2: Configure key information using Jenkins system parameters;

[0007] Step 3: Configure Global Pipeline Libraries in Jenkins to point to the code address and related information in the corresponding Gitlab;

[0008] Step 4: Add core process handling functions in the Global Pipeline Libraries corresponding to the Gitlab code repository;

[0009] Step 5: Add a public function group in the Global Pipeline Libraries corresponding to the Gitlab code repository, which supports the configuration of project information parameters required during CICD, including template definition functions required for project information configuration parameters;

[0010] Step 6, each project team writes a project pipeline script in Jenkins, and the script creates project configuration information by calling public functions in Global Pipeline Libraries, and finally calls core process processing functions in Global Pipeline Libraries;

[0011] Step 7, configure the Webhook corresponding to the project code in Gitlab to trigger the CICD process;

[0012] Step 8, delete the label in the Gitlab code repository, and trigger the Pipeline script corresponding to the project code repository when tagging, branching code submission, and call the core process processing function of step 4 to complete the processing.

[0013] As a further improvement of the application, the step 1 specifically comprises the following steps:

[0014] Step 1.1, install the Role-Based Authorization Strategy plug-in in Jenkins, and set the security authorization strategy of Jenkins to Role-Based Strategy;

[0015] Step 1.2, configure permissions in the project role of the authorization management page in Jenkins, create roles and access rules corresponding to each group according to the research and development organization grouping, and assign permissions;

[0016] Step 1.3, bind the user and the role in the role assignment page of Jenkins.

[0017] As a further improvement of the application, the step 2 specifically comprises the following steps:

[0018] Step 2.1, create an access token used by the Jenkins system in the Gitlab system configuration;

[0019] Step 2.2, create the access configuration corresponding to Gitlab in the Jenkins system settings, and the Credentials content is the access token created in step 2.1;

[0020] Step 2.3, create an access token used by the Jenkins system in the SonarQube administrator security configuration;

[0021] Step 2.4, create the access configuration corresponding to SonarQube in the Jenkins system settings, and the Credentials content is the access token created in step 2.3;

[0022] Step 2.5, increase the authentication ID of Gitlab, the corresponding address of the mirror repository, the username and password information, and the url address information of SonarQube in the global properties of the Jenkins system settings.

[0023] As a further improvement of the application, the step 3 specifically comprises the following steps:

[0024] Step 3.1, create a code repository in the Gitlab system for the Global PipelineLibraries of Jenkins;

[0025] Step 3.2, add the address information of the code repository created in step 3.1 in the Global Pipeline Libraries of the Jenkins system settings.

[0026] As a further improvement of the application, in step 4, the core process function includes code cloning, SonarQube code checking, compilation and packaging, image pushing and environment deployment, and can assemble and execute the process according to the project parameter information, and supports detailed execution log output throughout the process.

[0027] As a further improvement of the application, in step 5, the template definition function includes project overall configuration Map template function, branch configuration template function, application configuration template function, application image configuration template function, environment configuration template function, general tag configuration template function and custom tag configuration function; wherein:

[0028] The project overall configuration Map template function is used to return the complete initialization Map structure data;

[0029] The branch configuration template function is used to return the initialization Map structure data of the branch;

[0030] The application configuration template function is used to return the initialization structure data of the application, and the application supports the jar generated by compiling and packaging when triggered, and also supports the application generated by other projects;

[0031] The application image configuration template function is used to return the initialization structure data of the application image, including the information of the pushed image;

[0032] The environment configuration template function is used to return the initialization Map structure data of the environment configuration;

[0033] The general tag configuration template function is used to return the initialization Map structure data of the general tag;

[0034] The self-defined label configuration function is used to return the initialized Map structure data of the general label, mainly supports the scene that there is special processing when each project is labeled, and the node initialization functions under the self-defined label configuration function are generated by using 5.3 and 5.4.

[0035] As a further improvement of the application, the step 6 specifically comprises the following steps:

[0036] Step 6.1, creating a pipeline-based task in Jenkins and configuring corresponding parameter information;

[0037] Step 6.2, defining the corresponding configuration information of the project in the Pipeline script of the task, configuring as a Map key-value pair structure, and configuring the configuration template of each node to call the function group definition function to generate, and setting the corresponding node information according to the project information.

[0038] As a further improvement of the application, in step 6.2, the configuration as a Map key-value pair structure specifically comprises branch configuration, general label configuration and self-defined label configuration; wherein:

[0039] The branch configuration is configured with the project branch name as the Key, including determining whether the code scanning is performed on the branch when the task is executed, the project path of each main Pom under the branch, the parameter of the image of the project compilation result into the warehouse and the application deployment configuration of multiple environments;

[0040] The general label configuration is configured with a fixed identifier as the Key, and is used for the corresponding processing of the Tag, and is used for the entire project code regardless of the number of times of Tag.

[0041] The self-defined label configuration is configured with a fixed identifier+version as the Key.

[0042] As a further improvement of the application, the step 8 specifically comprises the following steps:

[0043] Step 8.1, parsing the request information when triggered, and judging whether the event type is branch code submission or is Tag or is deleting Tag;

[0044] Step 8.2, if the branch key information in the branch submission event is consistent with the Key of the branch configuration in the project CICD configuration Map, the corresponding processing of the branch configuration content is executed, and the configuration parameters and the order are executed;

[0045] Step 8.3, if it is Tag, the corresponding processing of the Tag is executed;

[0046] Step 8.4, if it is deleting Tag, the corresponding processing of deleting Tag is executed.

[0047] As a further improvement of the present application, in step 8.3, if the Tag version key information in the labeling event matches the Key of the general label configuration in the project CICD configuration Map, the general label processing is performed according to the configuration content; if the Tag version key information in the labeling event matches the Key of the custom label configuration in the project CICD configuration Map, the custom label processing is performed according to the configuration content.

[0048] The present application solves the following problems:

[0049] Complex project configuration problem: support complex Maven project configuration, meet the needs of different projects, improve the universality and flexibility of CICD process.

[0050] Maintainability problem: manage core process function and public function set, convenient for later modification and expansion, improve the maintainability of CICD process.

[0051] Problem troubleshooting: provide detailed execution log output, convenient for developers to quickly locate and solve problems, improve the stability and reliability of CICD process.

[0052] Security problem: through the administrator to allocate role and right, configuration key information, ensure the security of CICD process, prevent unauthorized access and operation.

[0053] The present application aims at realizing safe and maintainable continuous integration and continuous deployment (CICD) in a complex Maven project. First, an administrator assigns project group roles and permissions through a Jenkins role management module and configures key information such as account passwords and other key information of Gitlab, SonarQube, and image repository using Jenkins system parameters. Then, the administrator configures Global Pipeline Libraries in Jenkins to point to the corresponding Gitlab code address and related information, adds core process handling functions in the code repository, which cover code cloning, SonarQube code checking, compilation and packaging, image pushing, environment deployment, and other functions, and supports detailed execution log output for developers to troubleshoot problems. Public function groups are also added, including various template definition functions required for project information configuration parameters, supporting complex Maven project configuration. After that, each project group writes a project Pipeline script in Jenkins, and the script construction node completes project configuration information creation by calling public functions in Global Pipeline Libraries, and then calls core process handling functions. Then, configure the Webhook corresponding to the project code in Gitlab to trigger the CICD process (branch code submission and tag event). Finally, when deleting tags, tagging, and submitting branch codes in the Gitlab code repository, the corresponding Pipeline script of the project code repository is triggered for execution, and the core library is called for processing.

[0054] The beneficial effects of the present application are:

[0055] The present application improves the security of the CICD process, prevents unauthorized access and operation, enhances the maintainability of the CICD process, facilitates the administrator to manage and modify the core process and public functions, supports complex Maven project configuration, improves the universality and flexibility of the CICD process, and provides detailed execution log output for developers to quickly locate and solve problems. BRIEF DESCRIPTION OF DRAWINGS

[0056] Figure 1 The flowchart of the embodiment of the present application is shown.

[0057] Figure 2 The Map structure definition diagram of the project CICD configuration in the embodiment of the present application is shown. DETAILED DESCRIPTION

[0058] The embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0059] EMBODIMENT

[0060] As Figure 1As shown, a CICD method based on Jenkins Pipeline Shared Libraries includes the following steps:

[0061] Step S1: Assign project group roles and permissions by the administrator through the Jenkins role management module based on security considerations;

[0062] The step S1 includes:

[0063] S1.1: Install the Role-Based Authorization Strategy plugin in Jenkins, and set the security authorization strategy of Jenkins to Role-Based Strategy.

[0064] S1.2: Configure permissions in the project role (Item roles) of the Jenkins authorization management page, create the corresponding Role and access rules for each group according to the research and development organization grouping, and assign permissions.

[0065] S1.3: Bind users and roles in the role assignment page in Jenkins.

[0066] Step S2: Use Jenkins system parameters to configure key information such as Gitlab, SonarQube, image repository account passwords and other key information by the administrator based on security and maintainability;

[0067] The step S2 includes:

[0068] S2.1: Create an access token used by the Jenkins system in the Gitlab system configuration.

[0069] S2.2: Create the access configuration corresponding to Gitlab in the Jenkins system settings, and the Credentials content is the access token created in S2.1.

[0070] S2.3: Create a token used by the Jenkins system in the SonarQube administrator security configuration.

[0071] S2.4: Create the access configuration corresponding to SonarQube in the Jenkins system settings, and the Credentials content is the access token created in S2.3.

[0072] S2.5: Add the authentication ID of Gitlab, the address, username, and password information of the image repository, and the url address of SonarQube in the global properties of the Jenkins system settings.

[0073] Step S3: Configure the Global Pipeline Libraries in Jenkins by the administrator to point to the code address and related information in the corresponding Gitlab.

[0074] The step S3 includes:

[0075] S3.1: Create a code library in the Gitlab system for the Global Pipeline Libraries of Jenkins.

[0076] S3.2: Add the Gitlab address and other information created in S3.1 in the Global Pipeline Libraries in the Jenkins system settings.

[0077] Step S4: Add the core process function in the Global Pipeline Libraries corresponding to the Gitlab code repository by the administrator, which mainly includes code cloning, SonarQube code checking, compilation and packaging, image pushing, environment deployment, etc. (flexible processing according to the business characteristics of the research and development organization), and can assemble the execution process according to the project parameter information, and support detailed execution log output throughout the process, which is convenient for developers to troubleshoot configuration problems.

[0078] Step S5: Add the public function group in the Global Pipeline Libraries corresponding to the Gitlab code repository by the administrator, which supports the configuration of project information parameters required when CICD, mainly including template definition functions required for project information configuration parameters (project overall configuration Map template function, branch configuration template function, application image configuration template function, environment configuration template function, general tag configuration template function, custom tag configuration template function, etc.), supports complex Maven project configuration, including a single independent Maven project (compilation and packaging output only one application), one Maven main project with multiple sub-projects (compilation and packaging output multiple applications), and multiple Maven main projects, where the main Maven may be a single independent Maven project (compilation and packaging output only one application), or a Maven main project with multiple sub-projects (compilation and packaging output multiple applications).

[0079] The step S5 includes:

[0080] S5.1: Create a project overall configuration Map template function, which returns a complete initialization Map structure data.

[0081] S5.2: Create a branch configuration template function, which returns the initialization Map structure data of the branch.

[0082] S5.3: Create an application configuration template function that returns the initialization structure data of the application. The application supports compiling and packaging jar generation triggered by submission, and also supports generating applications with other projects, such as using the same program for each business of the gateway application. Only configuration is different. Configure the application type in the application structure and specify the absolute path of the application. The application supports Jar, docker, K8S, and other ways of running.

[0083] S5.4: Create an application image configuration template function that returns the initialization structure data of the application image, including the necessary information for pushing the image.

[0084] S5.5: Create an environment (pointing to a running deployment environment) configuration template function that returns the initialization Map structure data of the environment configuration.

[0085] S5.6: Create a general tag configuration template function that returns the initialization Map structure data of the general tag. It mainly supports the same situation of processing compilation, image, and release application when each project is tagged. The node initialization function under it uses 5.3 and 5.4 to generate.

[0086] S5.7: Create a custom tag configuration function that returns the initialization Map structure data of the general tag. It mainly supports scenarios with special processing when each project is tagged. The node initialization function under it uses 5.3 and 5.4 to generate.

[0087] Step S6: Each project group writes a project Pipeline script in Jenkins. The script creates project configuration information by calling each public function in Global Pipeline Libraries, and finally calls the core process function in Global Pipeline Libraries.

[0088] The step S6 includes:

[0089] S6.1: Create a Pipeline-based task in Jenkins and configure the corresponding parameter information

[0090] S6.2: Define the project configuration information in the Pipeline script of the task as a Map key-value pair structure. Its definition is as shown in Figure 2 Each node configuration template calls the function group definition function in S5 to generate. Set the corresponding node information according to the project information.

[0091] S6.2.1: Figure 2 [1: Branch configuration] Configure with the project branch name as the Key

[0092] S6.2.1.1: Wherein [1.1: whether code scanning] determines whether the branch performs code scanning when the task is executed.

[0093] S6.2.1.2: Wherein [1.2: project path list []], configured as the project path of each main Pom under the branch, the list can support single Maven project or multiple independent Maven projects under git.

[0094] S6.2.1.3: Wherein [1.3: application image configuration list []], configure the necessary parameters for the image of the project compilation result.

[0095] S6.2.1.4: Wherein [1.4: environment configuration list []], support application deployment configuration for multiple environments (such as development, testing, production, demonstration, etc.), support deployment in jar package, docker container, k8S and other ways and the necessary parameter configuration under each way.

[0096] S6.2.2: Figure 2 [2: general tag configuration] is mainly aimed at the corresponding processing of Tag, and is used for the configuration content of the whole project code regardless of the number of times of Tag. A fixed identifier (such as AddTag) is used as the Key for configuration, and the configuration content data structure definition is completely consistent with that in [1 branch configuration].

[0097] S6.2.3: Figure 2 [3: custom tag configuration] is mainly aimed at the corresponding processing of Tag, which is different from S6.2.2. This configuration mainly solves the problem of customizing the processing content of some special Tag version. A fixed identifier + version is used as the Key (such as AddTag1.2.0, which can match the add Tag action in git as long as it is in the specific processing). The configuration content data structure definition is completely consistent with that in [1: branch configuration].

[0098] Step S7: Configure the Webhook corresponding to the project code in Gitlab to trigger the CICD process (branch code submission and tag event).

[0099] Step S8: Delete the tag in the Gitlab code library, and execute the Pipeline script corresponding to the project code library when the tag is created, branch code is submitted, which calls the core library of step S4 to complete the processing;

[0100] The step S8 includes:

[0101] S8.1: Resolve the trigger time request information, judge the event type is branch code submission or is tagging or is deleting tag.

[0102] S8.2: If it is a branch submission event, the branch key information is consistent with the 1:branch configuration Key in the project CICD configuration Map, then execute the branch configuration content corresponding processing, execute according to the configuration parameters and order, such as pulling the code, determining whether to execute the code scanning according to the configuration, executing the code compilation and packaging to each project path, completing the image pushing according to the application image configuration, executing the code release according to each environment configuration, and releasing the jar package or based on the container.

[0103] S8.3: If it is tagging, execute the tag corresponding processing.

[0104] S8.3.1: If the Tag version key information in the tagging event is consistent with the 2:general tag configuration Key in the project CICD configuration Map, then execute the general tag processing according to the configuration content, and the processing details are similar to S8.2.

[0105] S8.3.2: If the Tag version key information in the tagging event is consistent with the 3:customized tag configuration Key in the project CICD configuration Map, then execute the customized tag processing according to the configuration content, and the processing details are similar to S8.2.

[0106] S8.4: If it is deleting tag, execute the deleting tag corresponding processing, such as recording log and other research and development organization specification matters.

[0107] The above-described embodiments only express the specific implementation of the present application, and the description is more specific and detailed, but it cannot be understood as the limitation of the scope of the present application. It should be pointed out that for ordinary skilled in the art, without departing from the concept of the present application, a number of variations and improvements can be made, which belong to the protection scope of the present application.

Claims

1. A method for continuous integration and continuous delivery supporting complex Maven projects, characterized by: The following steps are involved: Step 1: Assign project team roles and permissions through the Jenkins role management module; Step 2. Use Jenkins system parameters to configure key information; Step 3. Configure Global Pipeline Libraries in Jenkins to point to the corresponding code address and related information in GitLab; Step 4. Add the core process processing function to the GitLab code repository corresponding to Global Pipeline Libraries. Step 5. Add a public function group to the GitLab code repository corresponding to Global Pipeline Libraries. The public function group supports configuring the project information parameters required for CICD, including the template definition functions required for project information configuration parameters. Step 6. Each project team writes a Pipeline script for each project in Jenkins. The script completes the creation of project configuration information by calling various public functions in the GlobalPipelineLibraries, and finally calls the core process processing function in the GlobalPipelineLibraries. Step 7. Configure the webhook corresponding to the project code in GitLab to trigger the CICD process; Step 8. Delete the tag in the Gitlab code base. When the tag is added or the branch code is submitted, the Pipeline script corresponding to the project code base is executed, and the core process processing function in step 4 is called to complete the processing.

2. The continuous integration and continuous delivery method for supporting complex Maven projects according to claim 1, characterized in that: The step 1 specifically includes the following steps: Step 1.

1. Install the Role-Based Authorization Strategy plug-in in Jenkins and set Jenkins' security authorization strategy to Role-Based Strategy. Step 1.2: Configure permissions in the project role on the authorization management page in Jenkins. Create roles and access rules for each group according to the R&D organization grouping and assign permissions. Step 1.3: Bind the user to the role on the Jenkins role assignment page.

3. The continuous integration and continuous delivery method for supporting complex Maven projects according to claim 1, characterized in that: The step 2 specifically includes the following steps: Step 2.

1. Create an access token for the Jenkins system in the GitLab system configuration. Step 2.

2. Create the access configuration corresponding to Gitlab in the Jenkins system settings. The Credentials content is the access token created in step 2.

1. Step 2.

3. Create an access token for the Jenkins system in the SonarQube administrator security configuration. Step 2.

4. Create the access configuration for SonarQube in the Jenkins system settings. The Credentials content is the access token created in step 2.

3. Step 2.

5. Add Gitlab's authentication ID, mirror repository address, username, password, and SonarQube's URL to the global properties of the Jenkins system settings.

4. The method for supporting continuous integration and continuous delivery of complex Maven projects according to claim 3, characterized in that: The step 3 specifically includes the following steps: Step 3.

1. Create a code repository in the GitLab system for use in Jenkins' Global Pipeline Libraries. Step 3.

2. Add the address of the code repository created in step 3.1 to the Global Pipeline Libraries setting in the Jenkins system.

5. The method for supporting continuous integration and continuous delivery of complex Maven projects according to claim 3, characterized in that: In step 4, the core process processing functions include code cloning, SonarQube code inspection, compilation and packaging, image push and environment deployment, and can assemble the execution process according to the project parameter information, and support detailed execution log output throughout the process.

6. The method for supporting continuous integration and continuous delivery of complex Maven projects according to claim 5, characterized in that: In step 5, the template definition function includes a project overall configuration map template function, a branch configuration template function, an application configuration template function, an application image configuration template function, an environment configuration template function, a general label configuration template function, and a custom label configuration function; wherein: The overall configuration Map template function of the project is used to return the complete initialization Map structure data; The branch configuration template function is used to return the initialization Map structure data of the branch; The application configuration template function is used to return the initialization structure data of the application. The application supports compiling and packaging the generated JAR file when the submission trigger is triggered, and also supports applications generated by other general projects. The application image configuration template function is used to return the initialization structure data of the application image, including the information of the pushed image; The environment configuration template function is used to return the initialization Map structure data of the environment configuration; The general tag configuration template function is used to return the initialization Map structure data of the general tag; The custom tag configuration function is used to return the initialization Map structure data of the general tag. It mainly supports scenarios where special processing is required each time a project is tagged. The initialization functions of each node under it are generated using 5.3 and 5.

4.

7. The method for supporting continuous integration and continuous delivery of complex Maven projects according to claim 6, characterized in that: The step 6 specifically includes the following steps: Step 6.

1. Create a Pipeline-based task in Jenkins and configure the corresponding parameter information; Step 6.2: Define the project configuration information in the Pipeline script of the task. Configure it as a Map key-value pair structure. The configuration template of each node calls the public function group definition function to generate the corresponding node information according to the project information.

8. The method for supporting continuous integration and continuous delivery of complex Maven projects according to claim 7, characterized in that: In step 6.2, the configuration is a Map key-value pair structure, specifically including branch configuration, general label configuration, and custom label configuration; where: The branch configuration is configured with the project branch name as the key, including whether the branch performs code scanning when the task is executed, the project path of each main Pom under the branch, the parameters for storing the project compilation result image, and the application deployment configuration for multiple environments; The general tag configuration is for the corresponding processing of tagging, and the configuration item content is used for the entire project code regardless of multiple tags, with a fixed identifier as the key for configuration; Custom tag configuration is for tagging corresponding processing, and is configured with a fixed identifier + version as the key.

9. The method for supporting continuous integration and continuous delivery of complex Maven projects according to claim 8, characterized in that: The step 8 specifically includes the following steps: Step 8.1: Parse the trigger request information to determine whether the event type is a branch code submission, tagging, or tag deletion; Step 8.2: If the branch key information in the branch submission event is consistent with the branch configuration key in the project CICD configuration map, the corresponding processing of the branch configuration content is executed according to the configuration parameters and order; Step 8.3: If the tag is being tagged, perform tag-related processing; Step 8.4: If the tag is deleted, execute the corresponding processing of the deleted tag.

10. The method for supporting continuous integration and continuous delivery of complex Maven projects according to claim 9, characterized in that: In step 8.3, if the tag version key information in the tagging event is consistent with the key of the general tag configuration in the project CICD configuration map, the general tag processing is performed according to the configuration content; if the tag version key information in the tagging event is consistent with the key of the custom tag configuration in the project CICD configuration map, the custom tag processing is performed according to the configuration content.

Images