Pipeline automated patching method and system based on low-code SDK

Abstract

The present invention relates to the field of low-code application development and continuous integration / continuous deployment technology, and provides a pipeline-based automated patching method and system based on a low-code SDK. The method includes using an SDK tool to compile a specified project and obtain a metadata file; compiling the metadata file under the specified project and packaging it to generate a corresponding metadata package; extracting deliverables from the metadata package; generating a pom file based on the Maven dependencies in the specified project; pushing the pom file, metadata package, and jar packages in the deliverables to a specified artifact repository based on the version number of the specified project; obtaining changes to configuration files of two version branches through a pipeline to pull the corresponding version of the artifact from the artifact repository, packaging the pulled artifacts according to the path structure, and generating incremental patch files. The present invention significantly improves work efficiency and reduces the possibility of human error.

Description

Technical Field

[0001] The present invention relates to the technical field of low-code application development and continuous integration / continuous deployment (CI / CD), and in particular to a pipeline automated patch production method and system based on a low-code SDK. Background Art

[0002] The statements in this section merely provide background information related to the present invention and do not necessarily constitute prior art.

[0003] With the development of low-code platforms, the demand for rapid iteration and efficient patch releases is growing. However, existing solutions mostly focus on automating a single step in the front-end or back-end, leaving a significant gap in automating the entire process. Furthermore, there is currently no solution for the dependencies between multiple low-code projects, resulting in limited compilation and push for a single project.

[0004] Existing technical deficiencies primarily manifest in excessive manual work and a low degree of automation, leading to low efficiency and inconsistent quality. The root cause of these issues lies in the lack of a complete automated toolchain that covers every step from code changes to patch releases.

[0005] While some automation features are currently available, they still lack flexibility and adaptability, particularly in multi-repository dependency management and multi-module dependencies within low-code projects. Furthermore, existing solutions fail to address key technical challenges unique to low-code platforms, such as the mixed compilation of metadata and source code, multi-dimensional artifact dependency management, and automated version alignment. Summary of the Invention

[0006] To address the technical issues presented in the aforementioned background technology, the present invention provides a pipeline-based automated patching method and system based on a low-code SDK. This invention develops an SDK (Software Development Kit) tool specifically designed for low-code applications. This SDK tool can be used during the CI (Consolidation and Integration) process to provide capabilities such as compiling, packaging, extracting, and pushing metadata artifacts for low-code applications. Through version difference analysis and pipeline automation, it enables the efficient generation and deployment of patches for low-code applications.

[0007] In order to achieve the above object, the present invention adopts the following technical solutions:

[0008] The first aspect of the present invention provides a pipeline automated patch production method based on a low-code SDK.

[0009] A pipeline automated patching method based on a low-code SDK, including:

[0010] Map the acquired input command to a CLI command. Based on the CLI command, use the SDK tool to determine the incoming path of the CLI command and judge the type of the incoming path. If it is a project path, execute the command operation on the single project. If it is a business object path, sort all projects under the business object according to the dependencies between the projects, and execute the command operation according to the order.

[0011] Use SDK tools to compile the specified project and obtain metadata files; compile the metadata files under the specified project and package them into corresponding metadata packages; extract the deliverables in the metadata packages; generate pom files based on the Maven dependencies in the specified project; push the pom files, metadata packages, and jar packages in the deliverables to the specified artifact repository according to the version number of the specified project;

[0012] The changes in the configuration files of the two version branches are obtained through the pipeline to pull the corresponding version of the artifacts from the artifact repository, package the pulled artifacts according to the path structure, and generate incremental patch files.

[0013] Furthermore, the SDK tool is used to compile a specified project and obtain a metadata file; the method includes: using the SDK tool to obtain a specified project, assembling metadata package header node information based on the basic information of the project to obtain SU information from the gspproject.json file and obtain inter-project dependencies from the mdproj file; assembling a manifest file based on the SU information and inter-project dependencies; and scanning the metadata folder under the specified project directory to obtain all metadata files of the project.

[0014] Furthermore, the metadata files under the specified project are compiled and packaged to generate the corresponding metadata package; the method includes: calling local Maven through MavenInvoker, parsing the pom file to obtain module information; verifying whether the project structure is correct, and obtaining the dependency relationship between projects, compiling the code according to the dependency order between projects, and packaging to generate the corresponding metadata package.

[0015] Furthermore, the pom file is generated according to the maven dependencies in the specified project; the method includes: obtaining the maven dependencies of the project in the mdproj file, excluding the project dependencies, and generating the pom file according to the remaining maven dependencies.

[0016] Furthermore, the pom file, metadata package and jar package in the deliverable are pushed to the designated artifact warehouse according to the version number of the designated project; the method includes: selecting a code branch, running the pipeline, and injecting the parameter PUBLISH_VERSION to indicate the version number of the designated project release; the pipeline automatically compiles and packages the project, generates a jar package, metadata package and npm package, and pushes them to the target artifact warehouse, wherein the metadata package is pushed to the artifact warehouse in the form of a zip package.

[0017] Furthermore, the SDK tool runs independently and is integrated into the CI / CD tool chain. The CI / CD tool chain is provided with a low-code engineering CI template, and the pipeline scripts of each low-code engineering repository directly reference the low-code engineering CI template.

[0018] Furthermore, the changes in the configuration files of the two version branches are obtained through the pipeline; the method includes: submitting all configuration modifications to the warehouse, and selecting the corresponding patch version branch to run the pipeline; when running the pipeline, according to the input private key, whether the patch is generated, the old version branch and the new version branch, the contents of the two branches are obtained, and the changes in the configuration files of the two version branches are automatically compared.

[0019] The second aspect of the present invention provides a pipeline automated patch production system based on a low-code SDK.

[0020] A pipeline automated patching system based on a low-code SDK, including:

[0021] The command parsing and dependency identification module is configured to: map the received input command to a CLI command; based on the CLI command, use the SDK tool to determine the incoming path of the CLI command and judge the type of the incoming path. If it is a project path, the command operation is executed on the single project; if it is a business object path, all projects under the business object are sorted according to the dependencies between the projects, so that the command operation is executed in the order of priority;

[0022] The first-level pipeline module is configured to: use the SDK tool to compile the specified project and obtain the metadata file; compile the metadata file under the specified project and package it into the corresponding metadata package; extract the deliverables in the metadata package; generate the pom file based on the Maven dependencies in the specified project; and push the pom file, metadata package, and jar package in the deliverable to the specified artifact repository according to the version number of the specified project.

[0023] The secondary pipeline module is configured to obtain changes in configuration files of two version branches through the pipeline to pull the corresponding version of the artifacts from the artifact repository, package the pulled artifacts according to the path structure, and generate incremental patch files.

[0024] A third aspect of the present invention provides a computer device, comprising:

[0025] a processor adapted to execute a computer program;

[0026] Computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of the pipeline automated patch production method based on the low-code SDK as described in the first aspect above are implemented.

[0027] The fourth aspect of the present invention provides a computer-readable storage medium storing a computer program, which is suitable for being loaded by a processor and executing the steps in the pipeline automated patch production method based on the low-code SDK as described in the first aspect above.

[0028] Compared with the prior art, the present invention has the following beneficial effects:

[0029] The present invention provides a pipeline automated patch production method and system based on a low-code SDK, the method comprising: mapping the obtained input command to a CLI command; based on the CLI command, using an SDK tool to determine the incoming path of the CLI command, judging the type of the incoming path, and if it is a project path, executing the command operation on a single project; if it is a business object path, sorting the execution order of all projects under the business object according to the dependency relationship between the projects, so as to execute the command operation according to the sorting; using the SDK tool to compile a specified project and obtain a metadata file; compiling the metadata file under the specified project, and packaging it to generate a corresponding metadata package; extracting the deliverables in the metadata package; generating a pom file according to the Maven dependency in the specified project; pushing the pom file, metadata package, and jar package in the deliverable to a specified artifact warehouse according to the version number of the specified project; obtaining changes in the configuration files of two version branches through the pipeline to pull the corresponding version of the artifact from the artifact warehouse, packaging the pulled artifacts according to the path structure, and generating an incremental patch file. This invention adopts low-code SDK tools and pipeline methods, executes low-code SDK tool commands through predefined templates and scripts, and automatically completes the entire process from code submission to product release, solving the problems of inefficiency and error-proneness of traditional manual patch production, significantly improving work efficiency, and reducing the possibility of human errors. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] The accompanying drawings, which constitute a part of the present invention, are used to provide a further understanding of the present invention. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute improper limitations on the present invention.

[0031] Figure 1 This is a flow chart of a method for automated patch production based on a pipeline using a low-code SDK, according to an embodiment of the present invention;

[0032] Figure 2 This is a flowchart of another embodiment of a pipeline automated patch production method based on a low-code SDK according to an embodiment of the present invention;

[0033] Figure 3 is a flowchart of patch generation shown in an embodiment of the present invention;

[0034] Figure 4 is a schematic diagram showing a dependency relationship according to an embodiment of the present invention;

[0035] Figure 5 is a schematic diagram of the SDK tool architecture shown in an embodiment of the present invention;

[0036] Figure 6 is a flowchart of patch generation shown in an embodiment of the present invention;

[0037] Figure 7 This is a structural diagram of a pipeline automated patch production system based on a low-code SDK according to an embodiment of the present invention;

[0038] Figure 8 It is a structural diagram of a computer device shown in an embodiment of the present invention. DETAILED DESCRIPTION

[0039] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0040] It should be noted that the following detailed descriptions are illustrative and intended to provide further explanation of the present invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which the present invention belongs.

[0041] It should be noted that the terms used herein are only for describing specific embodiments and are not intended to limit the exemplary embodiments according to the present invention. As used herein, unless the context clearly indicates otherwise, the singular form is intended to include the plural form. In addition, it should be understood that when the terms "comprise" and / or "include" are used in this specification, they indicate the presence of features, steps, operations, devices, components and / or combinations thereof.

[0042] As described in the background technology section, low-code development platforms simplify and accelerate the application development process. With the widespread adoption of DevOps practices, continuous integration (CI) and continuous deployment (CD) have become integral to the modern software development lifecycle. Traditional CI / CD pipelines primarily focus on automating native development processes. To better adapt low-code platforms to modern software delivery models, tools and plug-ins for low-code applications need to be developed to seamlessly integrate them into existing CI / CD environments. This can further unleash the potential of low-code platforms and help companies maintain their leading position in the fiercely competitive market.

[0043] However, currently in low-code platforms, patch generation relies on manual operations, manual version comparisons, and file collection, including steps such as modifying configuration files, compiling projects, and packaging metadata. These processes are not only time-consuming but also prone to errors. In addition, manual processes are inefficient and can easily lead to problems such as version control confusion and missing key files, affecting the quality and release speed of patches. Low-code projects often involve multiple artifact repositories (such as Maven and NPM), and existing solutions cannot flexibly handle multi-repository dependencies. Existing solutions also cannot efficiently handle multi-project dependencies and mixed compilation (metadata and source code). These problems are due to the lack of a unified, automated tool to manage and optimize the entire patch production process, and the lack of a unified metadata compilation and artifact push standardized process, which requires developers to spend a lot of time and energy to ensure that each step is executed correctly.

[0044] To solve the above problems, the present invention provides a pipeline automated patch production method and system based on a low-code SDK. The technical solution of the present invention is described in detail below through several embodiments:

[0045] Figure 1 This is a flowchart of a method for automated patch production based on a low-code SDK according to an embodiment of the present invention; Figure 1 , the method comprising:

[0046] Map the acquired input command to a CLI command. Based on the CLI command, use the SDK tool to determine the incoming path of the CLI command and judge the type of the incoming path. If it is a project path, execute the command operation on the single project. If it is a business object path, sort all projects under the business object according to the dependencies between the projects, and execute the command operation according to the order.

[0047] Use SDK tools to compile the specified project and obtain metadata files; compile the metadata files under the specified project and package them into corresponding metadata packages; extract the deliverables in the metadata packages; generate pom files based on the Maven dependencies in the specified project; push the pom files, metadata packages, and jar packages in the deliverables to the specified artifact repository according to the version number of the specified project;

[0048] The changes in the configuration files of the two version branches are obtained through the pipeline to pull the corresponding version of the artifacts from the artifact repository, package the pulled artifacts according to the path structure, and generate incremental patch files.

[0049] The present invention adopts low-code SDK tools and pipeline methods, executes low-code SDK tool commands through predefined templates and scripts, automatically completes the entire process from code submission to product release, and reduces manual intervention.

[0050] Figure 2 This is a flowchart of another embodiment of the pipeline automated patch production method based on the low-code SDK shown in an embodiment of the present invention; Figure 2 , the present invention adopts UBML SDK tool chain and two-stage pipeline architecture:

[0051] During the development phase, developers submit metadata, source code, configuration data, etc. in low-code applications to the gitlab repository on the code hosting platform.

[0052] The two-tiered pipeline architecture is as follows: The first-tier pipeline: The "UBML SDK" tool is primarily responsible for compiling, packaging, extracting, and pushing packages for low-code projects, and pushes the compiled artifacts to the artifact repository under version management. The second-tier pipeline: By creating patch plugins, comparing branch differences, pulling artifacts, and creating incremental patches, the low-code SDK tool completes the front-end and back-end compilation, packaging, and pushing of low-code projects, achieving automated conversion from source code to artifacts.

[0053] In this embodiment, the low-code SDK tool is specifically: based on the Spring Shell framework, a low-code engineering command line tool is developed. The tool can run independently and be integrated into the existing CI / CD tool chain to complete the compilation, packaging, extraction, and package push tasks of the low-code project.

[0054] In the process of implementing the first-level pipeline, the compilation command can be igix build metadata_project. Use the build instruction to compile the specified metadata project and generate the corresponding resource metadata and multilingual metadata.

[0055] In some embodiments, the command for the compilation operation may also be igix packmd metadata_project, which uses the packmd instruction to compile metadata under a specified project and pack it to generate a corresponding metadata package.

[0056] In this embodiment, during the implementation of the first-level pipeline, the command for the packaging operation may be igix compilemetadata_project maven_path, using the compile instruction and the specified Maven configuration file to compile the generated code project and package it to generate the corresponding jar package.

[0057] In this embodiment, during the implementation of the first-level pipeline, the extraction operation command may be igix extractmetadata_project, which uses the extract instruction to extract compiled and packaged files, including jar packages, js scripts, metadata packages, resource metadata files, dbo, etc.

[0058] In this embodiment, during the implementation of the first-level pipeline, the push operation command may be igix pushmetadata_project repoId maven_path mdpkg_version. The push instruction is used to push the metadata package and the corresponding jar package to the selected remote repository according to the version number of the current code project.

[0059] The above compilation, packaging, extraction, and push commands, when passing the low-code project path, compile, package, extract, and push operations on a single path. When there are multiple projects under a business object, when the business object path is passed, the dependencies between the multiple projects under the business object will be identified, and the command execution order will be sorted out according to the dependency relationship, and the projects will be compiled, packaged, extracted, and pushed in order.

[0060] The implementation process of the pipeline automated patch creation method based on the low-code SDK described in this embodiment may include:

[0061] (1) Command parsing: The SDK tool uses the @ShellMethod annotation to define commands, parameters, and options, and automatically maps them to CLI commands that can be executed in the terminal. Each command method is defined using the @ShellMethod annotation, and each method is registered as an available CLI command. When the user enters a command in the terminal, the input is parsed and matched to the corresponding method.

[0062] (2) Dependency identification: Figure 3 This is a flowchart of patch generation shown in an embodiment of the present invention; Figure 3The SDK tool will identify the path passed in the command and determine whether it is a project path. If it is a project path, the operation will be performed on the single project. However, if it is a business object path, all project paths under the business object will be obtained, and the dependencies of all projects will be traversed according to the mdproj file. A directed graph will be used to represent the dependencies between projects, and the execution order will be sorted out according to the dependencies, and the command operations will be executed in sequence.

[0063] Figure 4 This is a schematic diagram showing the dependency relationship of an embodiment of the present invention; Figure 4 The constructed directed graph includes Project A, Project B, Project C, Project D, and Project E, and the dependency relationship is shown in the figure.

[0064] The SDK tool uses directed graph modeling to automatically resolve project dependencies and compile low-code projects in the order of dependencies, achieving automatic resolution and optimization of command execution order.

[0065] (3) Compile metadata: The SDK tool obtains the low-code project object and assembles the metadata header node information based on the basic information of the project such as name and version, reads the SU information from the gspproject.json file, obtains the project dependencies from the mdproj file, etc., and assembles the manifest file based on this information. Then, it scans the metadata folder under the project directory, obtains all metadata files under the project, and packages and compresses them into an mdpkg file.

[0066] (4) Compile code project: The SDK tool will call the local Maven through MavenInvoker, parse the pom file to obtain module information, then verify whether the project structure is correct, obtain the dependencies, compile the code in the dependency order, and generate a jar package and store it in the target directory.

[0067] (5) Extract deliverables: The SDK tool will traverse the generation paths of various deliverables, obtain all generated deliverables, and copy the deliverables to the corresponding publish directory.

[0068] (6) Pushing artifacts: The SDK tool first obtains the Maven dependencies of the project in the mdproj file, and also excludes the project dependencies. It then generates a pom file based on the remaining Maven dependencies, prepares the artifacts to be pushed, and uses the Maven Deploy plug-in to push the pom file and the corresponding jar and metadata packages to the corresponding artifact repository.

[0069] Figure 5 This is a schematic diagram of the SDK tool architecture shown in an embodiment of the present invention; Figure 5The SDK tools include a presentation layer, a service layer, a model layer, and a document library. The presentation layer includes WebIDE, a metadata compiler, and low-code engineering tools. The service layer includes the Restful API and Spring Shell. The model layer includes various metadata implementation elements and metadata frameworks. The metadata implementation elements include: From SPI extension, Form serializer, BE events, VO SPI extension, BESPI extension, BE serializer, VO events, etc. The metadata framework includes: metadata CRUD, serialization / deserialization, metadata events, metadata SPI, metadata compilation, project packaging, reference management, etc. The document library includes the metadata library, business entity library, examples, and documentation.

[0070] In this embodiment, the SDK tool runs independently and is integrated into the existing CI / CD tool chain. The CI / CD tool chain is provided with a low-code engineering CI template. The low-code engineering CI template includes: ① Providing a low-code application CI script, and based on the pipeline job extension mechanism, pre-setting a low-code application engineering CI template to reduce repeated configuration, maintain simplicity and maintainability; ② The low-code application engineering can quickly configure the pipeline in the form of an extended template to complete the compilation, packaging, and push of metadata. ③ Upload the compiled pipeline template of the low-code engineering to a public location, such as a product warehouse. The pipeline scripts of each low-code engineering warehouse can directly reference these template files. If the process changes later, only the template file needs to be modified to ensure the consistency and maintainability of the configuration.

[0071] In this embodiment, the low-code engineering CI pipeline is executed according to the low-code engineering CI template, including: inputting the low-code engineering CI template file and defining global variables; pushing the official warehouse of the jar package and metadata package; pushing snapshots of the jar package and metadata package; building the back-end project; integrating the back-end engineering compilation template in the template file; the variable is the path of the back-end project in the warehouse.

[0072] Specifically, after uploading the code to the repository, select the code branch, run the pipeline, and inject the parameter PUBLISH_VERSION to indicate the version to be released; the pipeline will automatically compile and package the project, generate jar packages, metadata packages, and npm packages, and push them to the target repository, where the metadata packages are pushed to the product repository in the form of zip packages.

[0073] Various artifacts, such as metadata packages, jar packages, and npm packages, have their own version management mechanisms, enabling multi-dimensional version control through configuration files such as pom.xml and web.yaml. This invention supports multiple types of artifact repositories, such as Maven and npm repositories. When pulling artifacts, you can pull them from multiple different artifact repositories. This allows you to create patches for deliverables from multiple repositories and projects, making patch generation more flexible.

[0074] In this embodiment, the multi-dimensional version of the product includes: a pom.xml file and a web.yaml file.

[0075] Among them, the pom.xml file: maintains its own component list, and the version number is required in <properties / > Defined in [web.yaml], this section primarily maintains each module's own JAR package, metadata list, and artifact version information. These artifacts can come from different artifact repositories and can also be compiled and packaged through the pipeline from different source code repositories. web.yaml file: web.yaml is primarily used to identify the npm packages to be included in the frontend, including their names, repository addresses, version information, and target paths.

[0076] In this embodiment, the patch configuration file includes a patch.xml file and a CHANGELOG.yaml file.

[0077] The patch.xml file specifies the artifact list and the path to each JAR package, metadata package, and pre-configured file within the patch. The CHANGELOG.yaml file contains patch information, such as the patch name and number. The pipeline will create the patch based on the latest patch information in the file.

[0078] Figure 6 This is a flowchart of patch generation shown in an embodiment of the present invention; Figure 6 , the patch production pipeline includes: submitting all configuration changes to the warehouse, and selecting the corresponding patch version branch to run the pipeline. When running the pipeline, you need to enter the following parameters. The pipeline will obtain the contents of the two branches, automatically compare the changes in the configuration files of the two version branches, and pull the corresponding version products from the product warehouse based on these changes. The pulled products are packaged according to the path structure defined by patch.xml to generate incremental patch files. By modifying the product version in the patch version branch, the product version can be aligned with the patch version. The present invention has the ability to automatically identify patch requirements and can automatically generate incremental patch files according to different code branches.

[0079] Specifically, the input parameters include:

[0080] GIT_SSH_PRIVATE_KEY: Git private key, used to access the repository.

[0081] ENABLE_CAF_PATCH_GENERATION: Whether to generate patches, set to true.

[0082] CAF_GEN_PATCH_OLD_REF: Old version branch.

[0083] CAF_GEN_PATCH_NEW_REF: New version branch.

[0084] Combination of the above Figure 1 The pipeline automated patch production method based on low-code SDK provided by an embodiment of the present invention is introduced in detail. Next, the pipeline automated patch production system based on low-code SDK provided by an embodiment of the present invention will be introduced in conjunction with the accompanying drawings.

[0085] Figure 7 This is a structural diagram of the pipeline automated patch production system based on the low-code SDK shown in an embodiment of the present invention, referring to Figure 7 , the system of the present invention comprises:

[0086] The command parsing and dependency identification module is configured to: map the received input command to a CLI command; based on the CLI command, use the SDK tool to determine the incoming path of the CLI command and judge the type of the incoming path. If it is a project path, the command operation is executed on the single project; if it is a business object path, all projects under the business object are sorted according to the dependencies between the projects, so that the command operation is executed in the order of priority;

[0087] The first-level pipeline module is configured to: use the SDK tool to compile the specified project and obtain the metadata file; compile the metadata file under the specified project and package it into the corresponding metadata package; extract the deliverables in the metadata package; generate the pom file based on the Maven dependencies in the specified project; and push the pom file, metadata package, and jar package in the deliverable to the specified artifact repository according to the version number of the specified project.

[0088] The secondary pipeline module is configured to obtain changes in configuration files of two version branches through the pipeline to pull the corresponding version of the artifacts from the artifact repository, package the pulled artifacts according to the path structure, and generate incremental patch files.

[0089] In some embodiments, the first-level pipeline module is specifically configured as follows: using the SDK tool to obtain the specified project, assembling the metadata header node information based on the basic information of the project to obtain the SU information from the gspproject.json file and the inter-project dependencies from the mdproj file; assembling the manifest file based on the SU information and the inter-project dependencies; and scanning the metadata folder under the specified project directory to obtain all metadata files of the project.

[0090] In some embodiments, the first-level pipeline module is further configured to: call local Maven through MavenInvoker, parse the pom file to obtain module information; verify whether the project structure is correct, and obtain the dependencies between projects, compile the code according to the dependency order between projects, and package and generate the corresponding metadata package.

[0091] In some embodiments, the first-level pipeline module is further configured to: obtain the Maven dependencies of the project in the mdproj file, exclude the project dependencies, and generate a pom file based on the remaining Maven dependencies.

[0092] In some embodiments, the first-level pipeline module is further configured to: select a code branch, run the pipeline, and inject the parameter PUBLISH_VERSION to indicate the version number of the specified project release; the pipeline automatically compiles and packages the project, generates a jar package, a metadata package, and an npm package, and pushes it to the target artifact repository, where the metadata package is pushed to the artifact repository in the form of a zip package.

[0093] In some embodiments, the SDK tool runs independently and is integrated into a CI / CD tool chain. A low-code engineering CI template is provided in the CI / CD tool chain, and the pipeline scripts of each low-code engineering repository directly reference the low-code engineering CI template.

[0094] In some embodiments, the secondary pipeline module is specifically configured to: submit all configuration modifications to the warehouse, and select the corresponding patch version branch to run the pipeline; when running the pipeline, based on the input private key, whether a patch is generated, the old version branch and the new version branch, obtain the contents of the two branches, and automatically compare the changes in the configuration files of the two version branches.

[0095] According to an embodiment of the present invention, the pipeline automatic patch production system based on the low-code SDK can correspond to the method described in the embodiment of the present invention, and the above and other operations and / or functions of each module of the pipeline automatic patch production system based on the low-code SDK are respectively to achieve Figure 1 For the sake of brevity, the corresponding processes of each method in are not repeated here.

[0096] See also Figure 8 The structural diagram of a computer device shown in FIG. includes a processor, a communication interface, and a computer-readable storage medium. The processor, communication interface, and computer-readable storage medium may be connected via a bus or other means. The communication interface is used to receive and send data. The computer-readable storage medium may be stored in the memory of the computer device. The computer-readable storage medium is used to store a computer program, which includes program instructions. The processor is used to execute the program instructions stored in the computer-readable storage medium. The processor (or CPU (Central Processing Unit)) is the computing and control core of the computer device. It is suitable for implementing one or more instructions, and is specifically suitable for loading and executing one or more instructions to implement the corresponding steps in the embodiment of the pipeline automated patch production method based on the low-code SDK.

[0097] This embodiment provides a computer-readable storage medium (Memory). This computer-readable storage medium is a memory device within a computer device that is used to store programs and data. It should be understood that the computer-readable storage medium herein may include both built-in storage media within the computer device and, of course, extended storage media supported by the computer device. The computer-readable storage medium provides storage space that stores the processing system of the computer device.

[0098] Furthermore, the storage space also stores one or more instructions suitable for being loaded and executed by the processor. These instructions may be one or more computer programs (including program code). It should be noted that the computer-readable storage medium herein may be a high-speed RAM memory or a non-volatile memory, such as at least one disk storage device; alternatively, it may be at least one computer-readable storage medium located remotely from the processor.

[0099] In one embodiment, one or more instructions are stored in the computer-readable storage medium; the processor loads and executes the one or more instructions stored in the computer-readable storage medium to implement the corresponding steps in the above-mentioned embodiment of the pipeline automated patch production method based on the low-code SDK.

[0100] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Thus, the present invention may take the form of hardware embodiments, software embodiments, or embodiments combining software and hardware. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage and optical storage, etc.) containing computer-usable program code.

[0101] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0102] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0103] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0104] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing the relevant hardware through a computer program. The program can be stored in a computer-readable storage medium. When executed, the program can include the processes in the above-described method embodiments. The storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0105] The foregoing description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Those skilled in the art will readily appreciate that various modifications and variations of the present invention are possible. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention are intended to be within the scope of protection of the present invention.

Claims

1. The pipeline automated patch production method based on low-code SDK is characterized by: include: Map the acquired input command to a CLI command. Based on the CLI command, use the SDK tool to determine the incoming path of the CLI command and the type of the incoming path. If it is a project path, execute the command operation on a single project. If it is a business object path, all projects under the business object are sorted in order of execution based on the dependencies between the projects, so that command operations are executed in order; Use SDK tools to compile the specified project and obtain the metadata file; Compile the metadata files under the specified project and package them to generate the corresponding metadata data package; Extract the deliverables from the metadata package; generate the pom file based on the Maven dependencies in the specified project; push the pom file, metadata package, and jar package in the deliverables to the specified artifact repository based on the version number of the specified project; The pipeline obtains changes to the configuration files of the two version branches, pulls the corresponding version of the artifacts from the artifact repository, packages the pulled artifacts according to the path structure, and generates incremental patch files; The low-code SDK tool specifically includes: developing a low-code engineering command line tool based on the Spring Shell framework. The tool runs independently and is integrated into the CI / CD tool chain to complete the compilation, packaging, extraction, and package push tasks of the low-code project.

2. The pipeline automated patch production method based on low-code SDK according to claim 1 is characterized in that: The SDK tool is used to compile a specified project and obtain a metadata file. The method includes: using the SDK tool to obtain the specified project, assembling metadata package header node information based on the basic information of the project to obtain SU information from the gspproject.json file and obtain inter-project dependencies from the mdproj file; assembling a manifest file based on the SU information and inter-project dependencies; and scanning the metadata folder under the specified project directory to obtain all metadata files of the project.

3. The pipeline automated patch production method based on low-code SDK according to claim 1 is characterized in that: The method comprises: calling local Maven through MavenInvoker, parsing the pom file to obtain module information; verifying whether the project structure is correct, obtaining the dependency relationship between projects, compiling the code according to the dependency order between projects, and packaging to generate the corresponding metadata package.

4. The pipeline automated patch production method based on low-code SDK according to claim 1 is characterized in that: The pom file is generated according to the maven dependencies in the specified project; the method includes: obtaining the maven dependencies of the project in the mdproj file, excluding the project dependencies, and generating the pom file according to the remaining maven dependencies.

5. The pipeline automated patch production method based on low-code SDK according to claim 1 is characterized in that: The method pushes the pom file, metadata package and jar package in the deliverable to the designated artifact warehouse according to the version number of the specified project; the method includes: selecting a code branch, running the pipeline, and injecting the parameter PUBLISH_VERSION to indicate the version number of the specified project release; the pipeline automatically compiles and packages the project, generates a jar package, metadata package and npm package, and pushes them to the target artifact warehouse, wherein the metadata package is pushed to the artifact warehouse in the form of a zip package.

6. The pipeline automated patch production method based on low-code SDK according to claim 1 is characterized in that: The SDK tool runs independently and is integrated into the CI / CD tool chain. The CI / CD tool chain is provided with a low-code engineering CI template, and the pipeline scripts of each low-code engineering warehouse directly reference the low-code engineering CI template.

7. The pipeline automated patch production method based on low-code SDK according to claim 1 is characterized in that: The method of obtaining changes to configuration files of two version branches through the pipeline includes: submitting all configuration modifications to the warehouse and selecting the corresponding patch version branch to run the pipeline; when running the pipeline, based on the input private key, whether a patch is generated, the old version branch and the new version branch, obtaining the contents of the two branches and automatically comparing the changes to the configuration files of the two version branches.

8. The pipeline automated patch production system based on low-code SDK is characterized by: include: The command parsing and dependency identification module is configured to: map the acquired input command to a CLI command; based on the CLI command, use the SDK tool to determine the incoming path of the CLI command, determine the type of the incoming path, and if it is a project path, execute the command operation on a single project; If it is a business object path, all projects under the business object are sorted in order of execution based on the dependencies between the projects, so that command operations are executed in order; The first-level pipeline module is configured to: use the SDK tool to compile the specified project and obtain the metadata file; Compile the metadata files under the specified project and package them to generate the corresponding metadata data package; Extract the deliverables from the metadata package; generate the pom file based on the Maven dependencies in the specified project; push the pom file, metadata package, and jar package in the deliverables to the specified artifact repository based on the version number of the specified project; The secondary pipeline module is configured to: obtain changes to configuration files of two version branches through the pipeline, pull artifacts of the corresponding versions from the artifact repository, package the pulled artifacts according to the path structure, and generate incremental patch files; The low-code SDK tool specifically includes: developing a low-code engineering command line tool based on the Spring Shell framework. The tool runs independently and is integrated into the CI / CD tool chain to complete the compilation, packaging, extraction, and package push tasks of the low-code project.

9. A computer device, characterized in that: a processor adapted to execute a computer program; A computer-readable storage medium, wherein a computer program is stored in the computer-readable storage medium. When the computer program is executed by the processor, the steps in the pipeline automated patch production method based on the low-code SDK are implemented as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which is suitable for being loaded by a processor and executing the steps in the pipeline automated patch production method based on a low-code SDK as described in any one of claims 1-7.

Images