A low-code development platform and method supporting automated independent deployment

Abstract

The present invention provides a low-code development platform and method supporting automated independent deployment, belonging to the field of software development technology, comprising: a microservice framework, an operation center and an automated independent deployment module; the microservice architecture comprises an independent user management module, a gateway service module, a form design module, a data storage module, an API management module and a process engine module; the operation center uses configuration files or environment variables to manage different deployment environments; the automated independent deployment module uses the application management package helm to start services for containerization and orchestration; Ansible automated operation and maintenance is used to start independent applications to support independent deployment for starting virtual machines; the problem of how to start low-code running applications in an automated manner is solved, and the efficiency and accuracy of starting low-code running applications are improved.

Description

Technical Field

[0001] The present invention belongs to the field of software development technology and relates to a low-code development platform and method that supports automated independent deployment. Background Art

[0002] With the development of low-code platforms, developers and non-developers can quickly create and iterate applications through visual development environments and pre-built components, lowering the development threshold.

[0003] Although low-code platforms provide the advantage of rapid development, when deployed independently, applications are tightly coupled with the platform, resulting in difficulties in migration and leaving the platform, and it is difficult to start new running services from the original application.

[0004] Patent application number CN202410440431.3 mentions "Methods, devices, processors, and computer-readable storage media for implementing cross-center independent deployment control of applications on a low-code platform." This patent describes how to achieve independent deployment, but it is still based on a low-code base application image, and the application cannot run independently, not truly independently deployed and operated. After removing design dependencies, the industry currently supports manually exporting application-related information, then using traditional network transmission (SSH / HTTP) or USB copying to the machine where the installation package needs to run independently, and then starting the service. However, this method requires operations personnel to follow the steps step by step, placing the package files required for installation and running and starting them one by one, or writing scripts in Shell, Go, or other scripting languages. This manual operation is prone to errors, such as incorrect configuration file input and inaccurate command input, which can easily lead to system instability or failure. At the same time, when there are many projects, a large number of repetitive operations will be generated, which is extremely inefficient.

[0005] Therefore, there is currently no solution in the industry for how to start low-code running applications in an automated manner. This article will propose an independent deployment solution for applications through automation for different usage scenarios. Summary of the Invention

[0006] In order to solve the technical problems existing in the above background technology, the present invention adopts the following technical solutions:

[0007] In a first aspect, the present invention provides a low-code development platform that supports automated independent deployment, including: a microservices framework, an operations center, and an automated independent deployment module;

[0008] The microservice architecture includes independent user management modules, gateway service modules, form design modules, data storage modules, API management modules, and process engine modules. The microservice architecture separates different functions and independently deploys and maintains each service.

[0009] The operation center uses configuration files or environment variables to manage different deployment environments, uses a template system to define deployment configurations, and supports automatic generation of configuration files for different environments. The same set of code can be flexibly deployed in different environments.

[0010] The automated independent deployment module uses the application management package helm to start services for containerization and orchestration; it uses Ansible automated operation and maintenance to start independent applications and support independent deployment for starting virtual machines.

[0011] Furthermore, the microservice architecture selects traditional programming languages ​​and frameworks, using VUE3 for the front end and Java + Spring Boot for the back end. For data storage, the database is selected according to needs. The front-end and back-end interactions use the APIs provided by each microservice, including RESTful interfaces, and use JSON for data exchange. Nacos is used as a service discovery tool to manage the dynamic registration and discovery of microservices, and the load balancer Nginx is used to distribute requests.

[0012] Furthermore, the environment of the operation center includes host management, data source management, Redis management, Minio management, and Nacos management. Each environment selects specific hosts, data sources, Redis configurations, and static information according to actual needs, and persists the environment information after the selection is completed, and generates different configuration information according to the selected deployment scenario type.

[0013] Furthermore, for containerized scenarios, the configuration files of the operation center are the Nacos YAML file and the value.yml file used for helm orchestration.

[0014] Furthermore, for the virtual machine scenario, the operation center uses the bootstrap.yml configuration file required to start each module, and the middleware configuration file uses Nginx's ngnix.conf file.

[0015] Furthermore, we automate the containerization of independently deployed modules, packaging applications and dependencies into containers to ensure consistency and portability across different environments.

[0016] Furthermore, the automated independent deployment module uses the orchestration tool Kubernetes to manage the deployment, scaling, and operation of containers.

[0017] Furthermore, the steps of using the application management package helm to start the service include: publishing and saving the designed application image, then writing a template file through the helm chart, and passing in the name of the running service image to be deployed, and starting the service through "helm install".

[0018] Furthermore, the specific steps for using Ansible to automate operations and maintenance to start independent applications and support independent deployment include: first, configuring the basic Ansible environment and control nodes in the running deployment center; creating an AnsiblePlaybook file to manage, and creating a virtual machine startup module to manage the virtual machine, and the file host information is dynamically adjusted according to the configuration center parameters; then deploying application services for low-code independent services, writing middleware and application service module information for the low-code platform, and finally configuring the Ansible Inventory file and running Playbooks, and the service can be automatically started and deployed.

[0019] In a second aspect, the present invention provides a working method of a low-code development platform that supports automated independent deployment, the steps comprising:

[0020] First, build an independent operation center to configure the environment of the operation state service; export the dependent components, menus, and view data when publishing the design state application;

[0021] Use Helm technology to manage Kubernetes applications for cloud environments, create and start running microservices;

[0022] Use Ansible services to automate operation and maintenance of virtual machines, automatically start remote virtual machines, or deploy running application services.

[0023] The beneficial effects of the present invention are:

[0024] 1. The present invention adopts a low-code development platform that supports automated independent deployment, including: a microservices framework, an operation center, and an automated independent deployment module. First, an independent operation center is built to configure the environment of the running service; at the same time, the dependent components, menus, views and other data are exported when the design application is released; then, Helm technology is used to manage Kubernetes applications for the cloud environment, and running microservices are created and started; Ansible services are used to achieve automated operation and maintenance for virtual machines, automatically start remote virtual machines or deploy running application services, which solves the problem of how to start low-code running applications in an automated manner and improves the efficiency and accuracy of starting low-code running applications.

[0025] 2. The present invention designs a low-code development platform that supports independent deployment in an automated manner. The system supports functional decoupling of the design state and the running state. By setting the static configuration required for the running state in advance, the running state can run independently in the form of a container or on an independent virtual machine after obtaining the basic configuration information; the system supports the export and import analysis of basic configuration information, and can store the corresponding export information including but not limited to application information, form information, and dictionary information through persistent files.

[0026] Advantages of additional aspects of the present invention will be given in part in the following description and in part will be obvious from the following description, or will be learned through practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] 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.

[0028] Figure 1 This is a diagram of the independent deployment system architecture of the low-code platform of the present invention;

[0029] Figure 2 This is a flow chart for the independent deployment system of the low-code platform of the present invention;

[0030] Figure 3 A schematic diagram of creating and starting an application for the low-code platform Ansible of the present invention. DETAILED DESCRIPTION

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

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

[0033] 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.

[0034] In the present invention, terms such as "upper", "lower", "left", "right", "front", "back", "vertical", "horizontal", "side", "bottom", etc. indicating directions or positional relationships are based on the directions or positional relationships shown in the accompanying drawings. They are relational words determined only for the convenience of describing the structural relationships of the various parts or elements of the present invention, and do not specifically refer to any part or element in the present invention, and should not be understood as limiting the present invention.

[0035] In the present invention, terms such as "fixed connection," "connected," and "connection" should be interpreted broadly to mean a fixed connection, an integral connection, or a detachable connection; a direct connection or an indirect connection through an intermediary. Relevant researchers or technicians in this field may determine the specific meanings of these terms in the present invention based on specific circumstances, and they should not be construed as limitations of the present invention.

[0036] Low-code platforms are divided into design and runtime states. The runtime state relies on data from the design state, including component information, permissions, rules, and configurations, resulting in significant coupling. Therefore, to achieve independent deployment, it's necessary to extract the common and differentiated content required by different runtime applications. Common content, of course, refers to the program's functionality, which supports the operation of runtime services; differentiated content includes the configuration and environment information required for program startup. Therefore, a separate runtime center is established to configure the runtime service environment. Dependent data such as components, menus, and views is exported when the design state application is released. Helm technology is then used to manage Kubernetes applications in cloud environments, creating and launching runtime microservices. Ansible services are used for automated operations and maintenance of virtual machines, automating the startup of remote VMs or the deployment of runtime application services.

[0037] Designing a low-code development platform that supports independent deployment in an automated manner requires the system to first support the functional decoupling of design state and runtime state. By pre-setting the static configuration required for runtime state, the runtime state can run independently in the form of a container or on a separate virtual machine after obtaining basic configuration information. Such a system requires the system to support the export and import parsing of basic configuration information. This can be achieved by storing the corresponding exported information, including but not limited to application information, form information, dictionary information, etc., in persistent files.

[0038] Example 1, as Figure 1-Figure 3 As shown, this embodiment provides a low-code development platform that supports automated independent deployment, including:

[0039] 1) Microservices Architecture: A low-code development platform that supports automated, independent deployment must first support a microservices architecture and modular design. Using a microservices architecture, different functions are separated, allowing each service to be independently deployed and maintained. This microservices architecture first defines service boundaries based on key functional modules, splitting these modules into independent microservices such as user management, gateway services, form design, data storage, API management, and process engines. Each microservice has a single responsibility, making it easier to maintain and scale. Traditional programming languages ​​and frameworks are used here, such as VUE3 for the front-end and Java + Spring Boot for the back-end. For data storage, appropriate databases are selected based on requirements, such as relational databases (MySQL, PostgreSQL) or NoSQL databases (MongoDB, Redis). Front-end and back-end interactions utilize defined APIs provided by each microservice, including RESTful interfaces, using JSON for data exchange. Service discovery and load balancing are also implemented. This example uses Nacos as a service discovery tool to manage dynamic registration and discovery of microservices, and uses the load balancer Nginx to distribute requests.

[0040] On a platform that supports independent deployment, the design state and the running state are decoupled into independent microservices, thus ensuring that the running state can run independently. Figure 1 As shown, the development and design of the application to be released is completed in the design state. After independent deployment, it runs independently in the running state and requires UC-IF (User Center Interface) and gateway services.

[0041] Before the split, the design state and runtime state shared the same architecture, sharing services like the gateway, user center, and process engine. The runtime state could even rely on the design state. However, to achieve independent deployment, both are independent. The design state is more comprehensive and supports all functions, while the runtime state is deployed on demand. Services include essential runtime services such as the database, user center, and form management. Other functions can be subsets of these or combinations of different functions, such as the process engine and messaging service.

[0042] 2) Operation Center, Configuration Files, and Environment Variables: Use configuration files or environment variables to manage the configuration of different deployment environments, such as development, testing, and production. This allows the same set of code to be flexibly deployed in different environments. Specifically, the same set of code here means that the code is the same, but different Nacos configuration files are generated based on the configured environment information, including data sources, Redis, Minio, etc., so that running application services can be started in different environments with different system configurations. Template System: Use the template system to define deployment configurations and support the automated generation of configuration files for different environments. The template system can be based on technologies such as Velocity, FreeMarker, and Thymeleaf. Taking FreeMarker technology as an example, users need to customize template files for different service startups. Different services use different template files. The template file icd-app-service.ftl is used to generate the corresponding ip-app-service.yml in the Nacos configuration, and icd-base.ftl is used to generate the icd-base.yml in the Nacos configuration. During the configuration file generation process, the system will replace the data source information, Minio information, and Redis information in the configuration file according to the information entered on the front-end page, thereby generating independent configuration files for different environments, which are then used to start the corresponding services.

[0043] This environment includes host management, data source management, Redis management, Minio management, and Nacos management. Each environment selects a specific host, data source, Redis configuration, and all other required static information based on actual needs. After selection, the environment information is persisted and different configuration information is generated based on the selected deployment scenario type. Host information includes host IP, port, SSH key, etc.; data source information includes data source host address, port, username, password, etc.; Redis management information includes address, port, and password; Minio management information includes address, port, accessKey, and secretKey configuration.

[0044] For containerized scenarios, the configuration files are the Nacos YAML file and the value.yml file used by Helm orchestration.

[0045] For virtual machine scenarios, the configuration file is the bootstrap.yml configuration file required to start each module, and the middleware configuration file uses Nginx's ngnix.conf file.

[0046] After the configuration of the information required for the application is completed, the application is deployed from the operation center deployment service center. Figure 2As shown, the specific steps are in the next step.

[0047] 3). Automated independent deployment. There are two scenarios. See the diagram for independent application startup. Figure 3 , one is for containerization and orchestration, and the other is for starting independent virtual machines.

[0048] Containerization: Package applications and dependencies into containers to ensure consistency and portability across different environments; containers can use Docker.

[0049] Orchestration tools: Use orchestration tools to manage the deployment, expansion, and operation of containers to improve system reliability and scalability; Kubernetes can be used as the orchestration tool.

[0050] For containerization and orchestration, you can use the application management package helm to start services. Save the designed application release image. Then, create a template file using helm charts, enter the name of the running service image to be deployed, and start the service using the command "helm install."

[0051] To start virtual machines, we use Ansible to automate operations and maintenance, enabling independent deployment of standalone applications. First, configure the basic Ansible environment and control nodes in the deployment center. Create an Ansible Playbook file to manage these, and create a virtual machine startup module to manage the virtual machines. This method is well-established, but file host information and other information must be dynamically adjusted based on configuration center parameters. Next, deploy the application service for the low-code standalone service. Enter the middleware (MariaDB, Minio, Nginx, Nacos) and application service module information specific to the low-code platform. Finally, configure the Ansible Inventory file and run the Playbook to automatically start and deploy the service.

[0052] Here's a brief example of the Ansible code file for the Nginx middleware used in this method. The example file is named deploy_nginx.yml. Based on the Nginx service's operational requirements, the corresponding tasks are divided into three subtasks. The first step is to install Nginx. The second step is to configure Nginx. You can pre-configure the nginx.conf file included in the system installation package, copy it to different hosts, and set the appropriate file permissions. The third step is to start the Nginx service.

[0053] Example 2: This example provides a working method for a low-code development platform that supports automated independent deployment, including the following steps:

[0054] First, build an independent operation center to configure the environment of the operation state service; export the dependent components, menus, and view data when publishing the design state application;

[0055] Use Helm technology to manage Kubernetes applications for cloud environments, create and start running microservices;

[0056] Use Ansible services to automate operation and maintenance of virtual machines, automatically start remote virtual machines, or deploy running application services.

[0057] 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. A low-code development platform that supports automated independent deployment, characterized in that: include: Microservice architecture, operation center and automated independent deployment modules; The microservice architecture includes independent user management modules, gateway service modules, form design modules, data storage modules, API management modules, and process engine modules. The microservice architecture separates different functions and independently deploys and maintains each service. The operation center uses configuration files or environment variables to manage different deployment environments, uses a template system to define deployment configurations, supports automatic generation of configuration files for different environments, and allows the same set of code to be flexibly deployed in different environments. Automated independent deployment module, using the application management package helm to start services for containerization and orchestration; Use Ansible to automate the operation and maintenance of virtual machines to start independent applications and support independent deployment; The steps to start the service using the application management package helm include: publishing and saving the designed application image, then writing the template file through helm chart, and passing in the name of the running service image to be deployed, and starting the service through "helminstall" naming; The specific steps for using Ansible to automate operations and maintenance to start independent applications and support independent deployment include: first, configure the basic Ansible environment and control nodes in the running deployment center; create an Ansible Playbook file to manage, and create a virtual machine startup module to manage the virtual machine. The file host information is dynamically adjusted according to the configuration center parameters; then deploy application services for low-code independent services, write middleware and application service module information for the low-code platform, and finally configure the Ansible Inventory file and run Playbooks, and the service can be automatically started and deployed.

2. A low-code development platform supporting automated independent deployment as claimed in claim 1, characterized in that: The microservice architecture uses traditional programming languages ​​and frameworks, VUE3 is used on the front end, Java + Spring Boot is used on the back end, data storage is convenient, and the database is selected according to needs. The front-end and back-end interactions use the APIs provided by each microservice, including RESTful interfaces, and JSON is used for data exchange. Nacos is used as a service discovery tool to manage the dynamic registration and discovery of microservices, and the load balancer Nginx is used to distribute requests.

3. A low-code development platform supporting automated independent deployment as claimed in claim 1, characterized in that: The environment of the operation center includes host management, data source management, Redis management, Minio management, and Nacos management. Each environment selects the host, data source, Redis configuration, and static information according to actual needs, and persists the environment information after the selection is completed, and generates different configuration information according to the selected deployment scenario type.

4. A low-code development platform supporting automated independent deployment as claimed in claim 1, characterized in that: For containerized scenarios, the configuration files of the operation center are the Nacos YAML file and value.yml used by helm orchestration.

5. A low-code development platform supporting automated independent deployment as claimed in claim 1, characterized in that: For the virtual machine scenario, the operation center uses the bootstrap.yml configuration file required to start each module, and the middleware configuration file uses the ngnix.conf file of Nginx.

6. A low-code development platform supporting automated independent deployment as claimed in claim 1, characterized in that: Automates containerization of independently deployed modules, packaging applications and dependencies into containers to ensure consistency and portability in different environments.

7. A low-code development platform supporting automated independent deployment as claimed in claim 1, characterized in that: The automated standalone deployment module uses the orchestration tool Kubernetes to manage the deployment, scaling, and operation of containers.

8. A method for operating a low-code development platform supporting automated independent deployment as claimed in any one of claims 1 to 7, characterized in that the steps include: First, build an independent operation center to configure the environment for running services; Export the dependent components, menus, and view data when publishing the design state application; Use Helm technology to manage Kubernetes applications for cloud environments, create and start running microservices; Use Ansible services to automate the operation and maintenance of virtual machines, automatically start remote virtual machines, or deploy running application services.

Images