Common module extraction method, device, equipment and medium for service merging

Abstract

The present application relates to the technical field of computer and medical platform, and discloses a method, device, equipment and medium for extracting common modules for service merging, wherein the method comprises: parsing the code repository of the integration target service project according to the received integration request, and judging whether the code repository of the integration target service project is the same code repository according to the parsing result; if the code repository of the integration target service project is a different code repository, extracting the common configuration code between the integration target service projects by Git Submodule method to obtain the first common module; if the code repository of the integration target service project is the same code repository, extracting the common configuration code between the integration target service projects by Gradle Module method to obtain the second common module. The present application can quickly extract and integrate common codes in the face of different code repository distributions when private deployment is required and the number of servers is insufficient, thereby improving the extraction efficiency and reliability of common modules.

Description

Technical Field

[0001] The present application relates to the technical field of computers and medical platforms, and in particular to a method, device, equipment and medium for extracting a common module for service merging. Background Art

[0002] In terms of company application deployment, the existing technologies are mainly deployed in two ways: one is to deploy the application on its own public cloud, and the other is to privatize the system for deployment on the customer side. As the trend of system microservices becomes more and more common, and a single system has a large number of service splits, the question of whether the company's server resources can meet the requirements of private deployment is becoming more and more obvious.

[0003] At the same time, in the context of insufficient server resources and the need to reduce costs and increase efficiency in small and medium-sized enterprises, it is usually required that each microservice be deployed on a single machine after integration. For example, a medical platform needs to integrate multiple microservice projects, so it is necessary to extract redundant code from some modules to form a common module. However, in the process of forming a common module, when the code repositories of microservices are not in the same code base, service integration problems will arise due to differences in code bases, resulting in a decrease in the efficiency of public module integration when services are merged, and the need to occupy too many server resources, which increases the server burden and cost, and increases the difficulty of microservice mergers and privatization deployment, which is not conducive to the company's cost reduction and efficiency improvement. Summary of the invention

[0004] The main purpose of this application is to provide a common module extraction method, device, equipment and medium for service merging, aiming to solve the problem that when microservice projects need to extract common code as common modules, the efficiency of common module integration decreases due to differences in code libraries.

[0005] In order to achieve the above-mentioned invention object, a first aspect of an embodiment of the present application proposes a common module extraction method for service merging, the method comprising:

[0006] Receiving integration requests of several service projects through a development tool, parsing the code repositories of the integration target service projects according to the integration requests, and determining whether the code repositories of the integration target service projects are the same code repositories according to the parsing results;

[0007] If the code repositories of the integration target service projects are different code repositories, a first extraction method is used to extract the common configuration code between the integration target service projects to obtain a corresponding first common module; wherein the first extraction method is to extract the common configuration code between the integration target service projects using a Git Submodule method;

[0008] If the code repositories of the integration target service projects are the same code repositories, a second extraction method is used to extract the common configuration codes between the integration target service projects to obtain a corresponding second common module; wherein the second extraction method is to extract the common configuration codes between the integration target service projects using a Gradle Module method.

[0009] In a possible implementation of the first aspect, extracting the common configuration code between the integrated target service items in a first extraction manner to obtain a corresponding first common module includes:

[0010] Set one of the integrated target service projects as the first parent module, and set the service projects other than the first parent module as the first submodule public configuration class;

[0011] Use a development tool to copy the warehouse code of the first parent module to the local computer and then open it, execute the add submodule command in the current first parent module directory, store the first submodule public configuration class to the corresponding submodule directory according to the path information in the add submodule command, and generate the first submodule;

[0012] Using an automated build tool to introduce the first submodule into the configuration file of the first parent module, and adding automated build configuration of the first submodule;

[0013] The automated construction configuration of the first submodule is run to extract the corresponding first common module.

[0014] In a possible implementation of the first aspect, extracting the common configuration code between the integrated target service items by using the second extraction method to obtain the corresponding second common module includes:

[0015] Set one of the integrated target service projects as the second parent module, and set the service projects other than the second parent module as the second submodule public configuration class;

[0016] Using a development tool, add a first configuration rule to an automated build configuration file of a common configuration class of the second submodule;

[0017] Adding a second configuration rule in the automated construction configuration file of the second parent module according to the first configuration rule;

[0018] The development tool is used to directly reference the second submodule public configuration class as a submodule of the second parent module according to the first configuration rule and the second configuration rule, and the corresponding second public module is extracted.

[0019] In a possible implementation manner of the first aspect, after extracting the common configuration code between the integration target service items by using the first extraction method to obtain the corresponding first common module, the method further includes:

[0020] When it is detected that the project maintenance of the first submodule changes or an instruction to replace the first submodule is received, the original first submodule is deleted.

[0021] In a possible implementation manner of the first aspect, deleting the original first submodule specifically includes:

[0022] Delete the record of the original first submodule in the code version control tool version according to the submodule path information;

[0023] Edit the first code version control tool configuration file, delete the configuration node information corresponding to the original first submodule, and clean up the configuration file and associated warehouse folder of the original first submodule;

[0024] Delete the remaining file directory of the original first submodule and clean up the corresponding dirty data.

[0025] In a possible implementation manner of the first aspect, performing code repository parsing on the integration target service project according to the integration request includes:

[0026] Parse the received integration request to obtain the corresponding integration target service project set;

[0027] Extracting source tag information from each service item in the integration target service item set;

[0028] The source tag information is matched in pairs, and the integration target service items are classified and counted according to the corresponding code repositories.

[0029] In a possible implementation of the first aspect, receiving integration requests for multiple service projects through a development tool, parsing code repositories of integration target service projects according to the integration requests, and determining whether code repositories of the integration target service projects are the same code repositories according to the parsing results, further includes:

[0030] According to the classification statistics of the integration target service items, the service items are sorted from high to low in terms of priority;

[0031] According to the preset priority rules, the common modules of the integrated target service projects are extracted first.

[0032] The second aspect of the embodiment of the present application further proposes a common module extraction device for service merging, comprising:

[0033] A code repository judgment module is used to receive integration requests of several service projects through a development tool, and perform code repository analysis on the integration target service projects according to the integration requests, and judge whether the code repositories of the integration target service projects are the same code repository according to the analysis results;

[0034] A Git Submodule extraction module is used to extract the common configuration code between the integration target service projects by a first extraction method if the code repositories of the integration target service projects are different code repositories, so as to obtain a corresponding first common module; wherein the first extraction method is to extract the common configuration code between the integration target service projects by a Git Submodule method;

[0035] The Gradle Module extraction module is used to extract the common configuration code between the integration target service projects by a second extraction method if the code repository of the integration target service projects is the same code repository, so as to obtain the corresponding second common module; wherein the second extraction method is to extract the common configuration code between the integration target service projects by a Gradle Module method.

[0036] A third aspect of an embodiment of the present application further proposes a computer device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of any of the above methods when executing the computer program.

[0037] A fourth aspect of the embodiments of the present application further proposes a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the steps of any of the methods described above are implemented.

[0038] The common module extraction method, device, equipment and medium for service merging of the present application receive integration requests of several service projects through a development tool, and parse the code repository of the integration target service project according to the integration request, and determine whether the code repository of the integration target service project is the same code repository according to the analysis result, so as to allocate the corresponding common module integration method according to the analysis result, thereby improving the efficiency and flexibility of common module integration; if the code repository of the integration target service project is a different code repository, then a first extraction method is used to extract the common configuration code between the integration target service projects to obtain the corresponding first common module; wherein, the first extraction method is to extract the common configuration code between the integration target service projects by using the GitSubmodule method, so as to quickly complete the extraction of common modules when integrating microservice projects of different code repositories, improve the efficiency of common module extraction, and reduce the burden on the server; if the code repository of the integration target service project is the same code repository, then a second extraction method is used to extract the common configuration code between the integration target service projects to obtain the corresponding second common module; wherein, the second extraction method is to use Gradle The module method extracts the common configuration code between the target service projects for integration, so that the extraction of common modules when integrating microservice projects in the same code repository can be completed quickly. The common code can also be quickly extracted without occupying too many server resources, thereby improving the efficiency of code integration and microservice project merging. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 A flowchart of a common module extraction method for service merging according to an embodiment of the present application;

[0040] Figure 2 This is a schematic block diagram of the structure of a common module extraction device for service merging according to an embodiment of the present application;

[0041] Figure 3 A schematic block diagram of the structure of a computer device according to an embodiment of the present application.

[0042] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0043] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0044] Reference Figure 1In order to achieve the above-mentioned purpose of the invention, the present application provides a method for extracting a common module for service merging, the method comprising:

[0045] S1. Receive integration requests of several service projects through a development tool, and perform code repository analysis on the integration target service projects according to the integration requests, and determine whether the code repositories of the integration target service projects are the same code repository according to the analysis results.

[0046] S2. If the code repositories of the integration target service projects are different code repositories, a first extraction method is used to extract the common configuration code between the integration target service projects to obtain a corresponding first common module; wherein the first extraction method is to use a Git Submodule method to extract the common configuration code between the integration target service projects.

[0047] S3. If the code repositories of the integrated target service projects are the same code repositories, a second extraction method is used to extract the common configuration codes between the integrated target service projects to obtain a corresponding second common module; wherein the second extraction method is to extract the common configuration codes between the integrated target service projects using a Gradle Module method.

[0048] The present invention is applied to the application deployment of the company. In the production environment of Internet enterprises, application deployment is an indispensable and important link. Each Web application runs in different environments such as the environment of integrated testing, the pre-release environment, and the environment for providing services to the outside world (formal environment). In each environment, the application runs on several machines (virtual machines / containers). During deployment, it may be carried out in stages and batches. There are specific methods and steps for the deployment of each machine, which are defined in the specific environment of this application. The process experienced by the application deployment in the production environment of Internet enterprises is roughly divided into three stages: physical machine deployment, virtual machine deployment, and containerized deployment. Different deployment parameters and even different deployment methods can be configured for different environments of the same application. For example, the daily environment is deployed through container services, while the formal environment is deployed through scripts. With the increasing attention paid to the development of medical platforms, the medical platforms of various institutions need to integrate multiple microservice projects of demand. Therefore, in the process of integrating microservice projects, it is necessary to solve the problem of reduced efficiency of extraction and integration of public modules due to differences in code bases.

[0049] For step S1, first, the integration request of several service projects is received through the development tool, and the source analysis of the target integration service projects to be integrated is performed according to different integration requests, that is, the code warehouse corresponding to each service project target to be integrated is parsed to determine whether it comes from the same code warehouse, so as to allocate the corresponding public module integration method according to the parsing result, thereby improving the efficiency and flexibility of public module integration. Among them, the development tools appearing in the embodiments of the present application are uniformly referred to as IDEA, the full name of which is IntelliJ IDEA, which is an integrated environment for Java language development (can also be used for other languages).

[0050] For step S2, after parsing the code warehouse of the integration target service project corresponding to the received integration request, it is determined whether the code warehouse of the integration target service project is the same code warehouse according to the parsing result; if not, the public module of microservice integration is introduced by Git Submodule. In this field, Git, as a code version control tool, is a distributed version control system, which is commonly used in daily development, and Submodule is a submodule function in Git, which is used to establish the dependency relationship between the current project and the submodule, including the submodule path, the remote warehouse of the submodule and the version number of the submodule. Among them, the Git-Submodule command can reference the modules of other warehouses to the current project warehouse as the submodule of the current project. When two microservice projects need to be integrated, and the two code warehouses are not the same warehouse, by proposing some commonly used public configuration classes and tool classes, the Git Submodule method is used to extract the public configuration code as the first public module, and it is only necessary to synchronize and update the first public module when necessary, so that the public module extraction during the integration of microservice projects in different code warehouses can be completed quickly, the efficiency of public module extraction is improved, and the burden on the server is reduced.

[0051] For step S3, it is determined whether the code repository of the integrated target service project is the same code repository according to the parsing result. If so, the second common module of the integrated target service project is extracted by Gradle Module. Gradle provides different ways to enable different projects to share configurations. In the present invention, Gradle Module is adopted. Subprojects is also a property of the parent Project, just like allprojects, and this property will return all subprojects. In the build.gradle script of the parent project, a closure containing configuration information is passed to subprojects, and the settings common to all subprojects can be configured, such as common plug-ins, repositories, dependency versions, and dependency configurations; this will set java plug-ins for all subprojects, use mavenCentral as the repository for all subprojects, and project dependencies on Guava and JUnit. In addition, the version of the dependent package is also configured in ext, which is convenient for future upgrades. In the present invention, configure can also be used for extraction. Since not all subprojects have the same configuration in the project, but some subprojects have the same configuration, it is necessary to add war plug-ins to these two subprojects. Gradle's configure can pass in an array of subprojects and set related configurations for these subprojects. configure needs to pass in an array of Project objects, find all subprojects whose project names contain war, and set the war plugin for them.

[0052] In a preferred embodiment, the extracting the common configuration code between the integration target service items by the first extraction method to obtain the corresponding first common module includes:

[0053] Set one of the integrated target service projects as the first parent module, and set the service projects other than the first parent module as the first submodule public configuration class;

[0054] Use a development tool to copy the warehouse code of the first parent module to the local computer and then open it, execute the add submodule command in the current first parent module directory, store the first submodule public configuration class to the corresponding submodule directory according to the path information in the add submodule command, and generate the first submodule;

[0055] Using an automated build tool to introduce the first submodule into the configuration file of the first parent module, and adding automated build configuration of the first submodule;

[0056] The automated construction configuration of the first submodule is run to extract the corresponding first common module.

[0057] In this embodiment, when two microservice projects need to be integrated and the code repositories of the two projects are not the same code repository, the submodules are extracted as common modules by using the Git Submodule method. It is only necessary to synchronize the submodules when necessary. In this way, the common modules of the microservice projects in the same code repository can be extracted quickly without occupying too many server resources, which is beneficial for enterprises to reduce costs and increase efficiency.

[0058] In a specific embodiment, the specific process of the Git Submodule method is as follows: first, add a submodule, prepare two engineering projects to be integrated, set one of the engineering projects as the first parent module, and the other engineering project as the first submodule public configuration class test_common. The development tool can be IDEA, and then copy the test_a warehouse code to the local, open the current project test_a with IDEA, and execute the add submodule command in the current directory. The command is as follows: gitsubmodule add <url> <path>; Among them, url is the path of the submodule, and path is the directory path where the submodule is stored. For example:

[0059] git submodule add;

[0060] ssh: / / git@code.paic.com.cn:8004 / pasc_medical_mall / test_common.git;

[0061] test_common.

[0062] After successful execution, you can see that a file (.gitmodules) is added to the first parent module test_a in the current project, and a directory (test_common) of the first submodule is generated; at the same time, the code of the first submodule (test_common) is pulled locally, that is, in the submodule directory.

[0063] After adding the submodule, you also need to configure the Gradle configuration of the first parent module and the first submodule. Since the present invention uses the Gradle automated build tool, at this time, the first parent module project test_a only references the first submodule test_common in the git version management, but the first submodule test_common just introduced does not exist in Gradle, so we need to add it to the Gradle Module, and add the following configuration to the first parent module settings.gradle and build.gradle configuration files:

[0064] settings.gradle;

[0065] include'test_common'#Introduce test_common;

[0066] build.gradle;

[0067] compile project(":test_common")#Compile test_common module;

[0068] Next, configure the first submodule Gradle, and add the following configuration in the build.gradle of the first submodule test_common: jar.enabled = true. After running the first submodule Gradle configuration, the common configuration code of the first parent module and the first submodule is automatically extracted as the first common module corresponding to the first parent module and the second submodule.

[0069] In a preferred embodiment, the extracting the common configuration code between the integration target service items by the second extraction method to obtain the corresponding second common module includes:

[0070] Set one of the integrated target service projects as the second parent module, and set the service projects other than the second parent module as the second submodule public configuration class;

[0071] Using a development tool, add a first configuration rule to an automated build configuration file of a common configuration class of the second submodule;

[0072] Adding a second configuration rule in the automated construction configuration file of the second parent module according to the first configuration rule;

[0073] The development tool is used to directly reference the second submodule public configuration class as a submodule of the second parent module according to the first configuration rule and the second configuration rule, and the corresponding second public module is extracted.

[0074] In a specific embodiment, it is determined whether the code repository of the integrated target service project is the same code repository according to the parsing result. If so, the common module of the integrated target service project is extracted by Gradle Module. Gradle is a project automation construction tool based on the concepts of Apache Ant and Apache Maven. It uses a Groovy-based domain-specific language to declare project settings instead of traditional XML. Currently, the languages ​​it supports are limited to Java, Groovy and Scala. Gradle Module refers to configuring Module in the automated construction tool Gradle. In a specific embodiment, the specific process of the Gradle Module method is as follows: prepare two engineering projects to be integrated, set one of the engineering projects as the second parent module test_a, set the other engineering project as the second child module public configuration class test_common, use IDEA as the development tool, add the following first configuration rule to the build.gradle of the second child module test_common module: jar.enabled=true; then add the following second configuration rule to the build.gradle of the second parent module engineering project test_a: compile project(":test-common"); the Gradle Module direct reference module can be completed, the second child module public configuration class test_common is directly referenced as a submodule of the second parent module, and the corresponding public configuration code is automatically extracted as the second public module.

[0075] In a preferred embodiment, after extracting the common configuration code between the integration target service items by the first extraction method to obtain the corresponding first common module, the method further includes:

[0076] When it is detected that the project maintenance of the first submodule changes or an instruction to replace the first submodule is received, the original first submodule is deleted.

[0077] In a specific embodiment, when the prompt "repository has changed" is displayed when pulling the first submodule code, that is, when it is detected that the project maintenance address of the first submodule has changed or a new submodule needs to be referenced to replace the original first submodule, the original first submodule is deleted and the first submodule is updated synchronously, which is conducive to improving the reliability and real-time performance of extracting the first submodule to obtain the first common module through the Git Submodule method.

[0078] In a preferred embodiment, the deleting the original first submodule is specifically:

[0079] Delete the record of the original first submodule in the code version control tool version according to the submodule path information;

[0080] Edit the first code version control tool configuration file, delete the configuration node information corresponding to the original first submodule, and clean up the configuration file and associated warehouse folder of the original first submodule;

[0081] Delete the remaining file directory of the original first submodule and clean up the corresponding dirty data.

[0082] In a specific embodiment, the specific steps for deleting the first submodule are as follows: delete the record of the first submodule in the Git version according to the path information; the instruction is git rm--cached[path]; edit the .gitmodules file, delete the relevant configuration nodes of the first submodule, and clean up the configuration of the first submodule; edit the .git / config file. Since the configuration information of the first submodule also exists in config, all the configuration information about the first submodule in this configuration file also needs to be cleaned up; enter the .git / module directory, delete the original warehouse folder associated with the first submodule; delete the remaining directory of the first submodule, and clean up dirty files or dirty data. Because in database technology, dirty data is generated in temporary updates (dirty reads). For example, transaction A updates a data item X, but for some reason, transaction A has a problem, so A needs to be rolled back. But before rolling back, another transaction B reads the value of data item X (after A is updated), A rolls back the transaction, and the data item is restored to its original value. What transaction B reads is a "temporary" value of data item X, which is dirty data. Therefore, dirty data needs to be cleaned to detect and correct (or delete) inaccurate or damaged records in record sets, tables or databases, which can help enterprises save time and improve efficiency when integrating microservices.

[0083] In a preferred embodiment, the code repository parsing of the integration target service project according to the integration request includes:

[0084] Parse the received integration request to obtain a corresponding integration target service project set;

[0085] Extracting source tag information from each service item in the integration target service item set;

[0086] The source tag information is matched in pairs, and the integration target service items are classified and counted according to the corresponding code repositories.

[0087] In a specific embodiment, after receiving integration requests for several service projects, the target service projects to be integrated corresponding to each integration request are first parsed and divided into different sets; for the source tag information of each service project in the target service projects to be integrated in different sets, the source tag information mainly marks the code repository of each service project, and the code repository where the code of the service project is located can be quickly identified based on the source tag information; the source tag information of the service items in different sets are matched pairwise, and different integration target service projects are classified and counted according to different code repositories, so as to provide accurate data support for the subsequent judgment of the extraction method of the corresponding common modules assigned to the service projects to be integrated, thereby improving the efficiency and reliability of extracting common modules.

[0088] In a preferred embodiment, the step of receiving integration requests of several service projects through a development tool, parsing the code repositories of the integration target service projects according to the integration requests, and determining whether the code repositories of the integration target service projects are the same code repositories according to the parsing results, further includes:

[0089] According to the classification statistics of the integration target service items, the service items are sorted from high to low in terms of priority;

[0090] According to the preset priority rules, the common modules of the integrated target service projects are extracted first.

[0091] In a specific embodiment, priority sorting is performed based on the classification statistics of the target projects to be integrated. Factors affecting the priority sorting include whether it is the same code repository, the number of different project categories and the size of the project in the same code repository, the number of the same project categories and the size of each project in the same code repository, the number of different project categories and the size of the project in different code repositories, and the number of the same project categories and the size of the project in different code repositories, etc. The target service projects to be integrated are given priority in extracting common modules according to the priority rules preset by the user. For example, the same category of service projects in the same code repository are given priority in extracting common modules. Classifying and prioritizing the target service projects to be integrated in advance can flexibly extract common modules according to user needs, thereby improving the flexibility and practicality of common module extraction.

[0092] Reference Figure 2 The present application also proposes a common module extraction device for service merging, comprising:

[0093] The code repository judgment module 100 is used to receive integration requests of several service projects through a development tool, and perform code repository analysis on the integration target service projects according to the integration requests, and judge whether the code repositories of the integration target service projects are the same code repository according to the analysis results;

[0094] Git Submodule extraction module 200, used to extract the common configuration code between the integration target service projects by using a first extraction method to obtain a corresponding first common module if the code repositories of the integration target service projects are different code repositories; wherein the first extraction method is to extract the common configuration code between the integration target service projects by using a Git Submodule method;

[0095] The Gradle Module extraction module 300 is used to extract the common configuration code between the integration target service projects by a second extraction method if the code repository of the integration target service projects is the same code repository, and obtain the corresponding second common module; wherein the second extraction method is to extract the common configuration code between the integration target service projects by a Gradle Module method.

[0096] This embodiment receives integration requests for several service projects through a development tool, and performs code repository analysis on the integration target service project according to the integration request, and determines whether the code repository of the integration target service project is the same code repository according to the analysis result, thereby allocating the corresponding common module integration method according to the analysis result, thereby improving the efficiency and flexibility of common module integration; if the code repository of the integration target service project is a different code repository, then a first extraction method is used to extract the common configuration code between the integration target service projects to obtain the corresponding first common module; wherein, the first extraction method is to extract the common configuration code between the integration target service projects using the Git Submodule method, thereby being able to quickly complete the extraction of common modules when integrating microservice projects of different code repositories, thereby improving the efficiency of common module extraction and reducing the burden on the server; if the code repository of the integration target service project is the same code repository, then a second extraction method is used to extract the common configuration code between the integration target service projects to obtain the corresponding second common module; wherein, the second extraction method is to use Gradle The module method extracts the common configuration code between the target service projects for integration, so that the extraction of common modules when integrating microservice projects in the same code repository can be completed quickly. The common code can also be quickly extracted without occupying too many server resources, thereby improving the efficiency of code integration and microservice project merging.

[0097] Reference Figure 3 In an embodiment of the present application, a computer device is also provided. The computer device may be a server, and its internal structure may be as follows: Figure 3 As shown. The computer device includes a processor, a memory, a network interface and a database connected through a system bus. Among them, the processor designed by the computer is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store data such as a common module extraction method for service merging. The network interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a common module extraction method for service merging is implemented. The common module extraction method for service merging includes: receiving integration requests of several service projects through a development tool, and parsing the code repository of the integration target service project according to the integration request, and judging whether the code repository of the integration target service project is the same code repository according to the parsing result; if the code repository of the integration target service project is different code repository, extracting the common configuration code between the integration target service projects by a first extraction method to obtain a corresponding first common module; wherein, the first extraction method is to extract the common configuration code between the integration target service projects by a Git Submodule method; if the code repository of the integration target service project is the same code repository, extracting the common configuration code between the integration target service projects by a second extraction method to obtain a corresponding second common module; wherein, the second extraction method is to extract the common configuration code between the integration target service projects by a GradleModule method.

[0098] An embodiment of the present application also provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, a common module extraction method for service merging is implemented, comprising the steps of: receiving integration requests of several service projects through a development tool, and performing code repository analysis on the integration target service project according to the integration request, and judging whether the code repository of the integration target service project is the same code repository according to the analysis result; if the code repository of the integration target service project is a different code repository, extracting the common configuration code between the integration target service projects by a first extraction method to obtain a corresponding first common module; wherein the first extraction method is to extract the common configuration code between the integration target service projects by a Git Submodule method; if the code repository of the integration target service project is the same code repository, extracting the common configuration code between the integration target service projects by a second extraction method to obtain a corresponding second common module; wherein the second extraction method is to extract the common configuration code between the integration target service projects by a GradleModule method.

[0099] The above-mentioned implementation of the common module extraction method for service merging, this embodiment receives integration requests for several service projects through a development tool, and performs code repository analysis on the integration target service project according to the integration request, and determines whether the code repository of the integration target service project is the same code repository according to the analysis result, thereby allocating the corresponding common module integration method according to the analysis result, thereby improving the efficiency and flexibility of common module integration; if the code repository of the integration target service project is a different code repository, then a first extraction method is used to extract the common configuration code between the integration target service projects to obtain the corresponding first common module; wherein, the first extraction method is to extract the common configuration code between the integration target service projects using the GitSubmodule method, thereby being able to quickly complete the extraction of common modules when integrating microservice projects of different code repositories, thereby improving the efficiency of common module extraction and reducing the burden on the server; if the code repository of the integration target service project is the same code repository, then a second extraction method is used to extract the common configuration code between the integration target service projects to obtain the corresponding second common module; wherein, the second extraction method is to use Gradle The module method extracts the common configuration code between the target service projects for integration, so that the extraction of common modules when integrating microservice projects in the same code repository can be completed quickly. The common code can also be quickly extracted without occupying too many server resources, thereby improving the efficiency of code integration and microservice project merging.

[0100] Those of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media provided in this application and used in the embodiments may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0101] It should be noted that, in this article, the term "includes", "comprising" or any other variation thereof is intended to cover non-exclusive inclusion, so that a process, device, article or method including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, device, article or method. In the absence of further restrictions, an element defined by the sentence "comprising a ..." does not exclude the existence of other identical elements in the process, device, article or method including the element.

[0102] The above description is only a preferred embodiment of the present application, and does not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.< / path> < / url>

Claims

1. A common module extraction method for service merging, characterized in that: The method comprises: Receiving integration requests of several service projects through a development tool, parsing the code repositories of the integration target service projects according to the integration requests, and determining whether the code repositories of the integration target service projects are the same code repositories according to the parsing results; If the code repositories of the integration target service projects are different code repositories, a first extraction method is used to extract the common configuration code between the integration target service projects to obtain a corresponding first common module; wherein the first extraction method is to extract the common configuration code between the integration target service projects using a Git Submodule method; If the code repositories of the integration target service projects are the same code repositories, a second extraction method is used to extract the common configuration code between the integration target service projects to obtain a corresponding second common module; wherein the second extraction method is to extract the common configuration code between the integration target service projects using a Gradle Module method; The extracting the common configuration code between the integration target service items by the first extraction method to obtain the corresponding first common module includes: Set one of the integrated target service projects as the first parent module, and set the service projects other than the first parent module as the first submodule public configuration class; Use a development tool to copy the warehouse code of the first parent module to the local computer and then open it, execute the add submodule command in the current first parent module directory, store the first submodule public configuration class to the corresponding submodule directory according to the path information in the add submodule command, and generate the first submodule; Using an automated build tool to introduce the first submodule into the configuration file of the first parent module, and adding automated build configuration of the first submodule; The automated construction configuration of the first submodule is run to extract the corresponding first common module.

2. The common module extraction method for service merging according to claim 1, characterized in that: The extracting the common configuration code between the integration target service items by the second extraction method to obtain the corresponding second common module includes: Set one of the integrated target service projects as the second parent module, and set the service projects other than the second parent module as the second submodule public configuration class; Using a development tool, add a first configuration rule to an automated build configuration file of a common configuration class of the second submodule; Adding a second configuration rule in the automated construction configuration file of the second parent module according to the first configuration rule; The development tool is used to directly reference the second submodule public configuration class as a submodule of the second parent module according to the first configuration rule and the second configuration rule, and the corresponding second public module is extracted.

3. The common module extraction method for service merging according to claim 1, characterized in that: After extracting the common configuration code between the integration target service items by the first extraction method to obtain the corresponding first common module, the method further includes: When it is detected that the project maintenance of the first submodule changes or an instruction to replace the first submodule is received, the original first submodule is deleted.

4. The common module extraction method for service merging according to claim 3, characterized in that: The deletion of the original first submodule is specifically as follows: Delete the record of the original first submodule in the code version control tool version according to the submodule path information; Edit the first code version control tool configuration file, delete the configuration node information corresponding to the original first submodule, and clean up the configuration file and associated warehouse folder of the original first submodule; Delete the remaining file directory of the original first submodule and clean up the corresponding dirty data.

5. The common module extraction method for service merging according to claim 1, characterized in that: The code repository parsing of the integration target service project according to the integration request includes: Parse the received integration request to obtain the corresponding integration target service project set; Extracting source tag information from each service item in the integration target service item set; The source tag information is matched in pairs, and the integration target service items are classified and counted according to the corresponding code repositories.

6. The common module extraction method for service merging according to claim 1, characterized in that: The receiving of integration requests of several service projects through the development tool, parsing the code repositories of the integration target service projects according to the integration requests, and determining whether the code repositories of the integration target service projects are the same code repositories according to the parsing results, further includes: According to the classification statistics of the integration target service items, the service items are sorted from high to low in terms of priority; According to the preset priority rules, the common modules of the integrated target service projects are extracted first.

7. A common module extraction device for service merging, characterized in that: include: A code repository judgment module is used to receive integration requests of several service projects through a development tool, and perform code repository analysis on the integration target service projects according to the integration requests, and judge whether the code repositories of the integration target service projects are the same code repository according to the analysis results; A Git Submodule extraction module is used to extract the common configuration code between the integration target service projects by using a first extraction method to obtain a corresponding first common module if the code repositories of the integration target service projects are different code repositories; wherein the first extraction method is to extract the common configuration code between the integration target service projects by using a Git Submodule method; the extraction of the common configuration code between the integration target service projects by using the first extraction method to obtain the corresponding first common module includes: Set one of the integrated target service projects as the first parent module, and set the service projects other than the first parent module as the first submodule public configuration class; Use a development tool to copy the warehouse code of the first parent module to the local computer and then open it, execute the add submodule command in the current first parent module directory, store the first submodule public configuration class to the corresponding submodule directory according to the path information in the add submodule command, and generate the first submodule; Using an automated build tool to introduce the first submodule into the configuration file of the first parent module, and adding automated build configuration of the first submodule; Running the automated construction configuration of the first submodule to extract the corresponding first common module; The Gradle Module extraction module is used to extract the common configuration code between the integration target service projects by a second extraction method if the code repository of the integration target service projects is the same code repository, so as to obtain the corresponding second common module; wherein the second extraction method is to extract the common configuration code between the integration target service projects by a Gradle Module method.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images