Business application deployment method and device, equipment and storage medium

Abstract

The invention discloses a business application deployment method and device, equipment and a storage medium, and the method comprises the steps: receiving a description file of a business application, the description file being used for describing the business application and at least one technical component on which the business application depends; analyzing the description file, and constructing a dependency relationship model between the business application and each technical component according to an analysis result; carrying out compatibility verification on the dependency relationship model based on a preset compatibility rule base; when the compatibility verification is passed, packaging the business application and each technical component to generate an application deployment unit; and in response to the deployment task triggering operation, calling an application deployment unit to deploy the business application. According to the application, the business application and the technical component can be packaged into the application deployment unit before deployment, the version and configuration are verified in advance by means of the dependency relationship model and the compatibility rule base, and only the unit needs to be called in the deployment stage, so that the cross-environment consistency is improved while the application deployment complexity is reduced.

Description

Technical Field

[0001] This application relates to the field of application deployment technology, and in particular to a business application deployment method, apparatus, device and storage medium. Background Technology

[0002] With the development of cloud-native and microservice architectures, application system deployment models have gradually migrated from physical machines and virtual machines to containerized environments. Current mainstream container technologies (such as Docker and Kubernetes) primarily encapsulate single applications or services, offering advantages in ease of deployment and runtime environment isolation. However, in complex distributed application systems, in addition to core business applications, they often rely on multiple technical components such as databases, message queues, and caching to work together.

[0003] In the traditional approach, while Platform as a Service (PaaS) or container-based application platforms (such as Beanstalk, TSF, etc.) can enable rapid deployment of business applications, they still lack the ability to uniformly encapsulate and manage the underlying technical components and their dependencies. Users need to manually handle the deployment, configuration and version coordination of each component, which limits the overall deployment efficiency of the application and makes it difficult to ensure consistency across environments. Summary of the Invention

[0004] The main purpose of this application is to provide a business application deployment method, apparatus, device and storage medium, which aims to solve the technical problem that the existing application deployment methods do not encapsulate the underlying technical components enough, and users still need to handle the deployment and configuration of components themselves, resulting in the inability to guarantee overall efficiency and consistency.

[0005] To achieve the above objectives, this application proposes a business application deployment method, the method comprising: Receive a description file for a business application, the description file being used to describe the business application and at least one technical component that the business application depends on; The description file is parsed, and a dependency model between the business application and each of the technical components is constructed based on the parsing results; The dependency model is validated for compatibility based on a pre-defined compatibility rule base. Once the compatibility verification is passed, the business application and each of the technical components are encapsulated to generate an application deployment unit; In response to the deployment task trigger operation, the application deployment unit is invoked to deploy the business application.

[0006] In one embodiment, the step of parsing the description file and constructing a dependency model between the business application and each of the technical components based on the parsing results includes: The application information of the business application and the component information of each of the technical components are extracted from the description file; The association between the business application and each of the technical components is determined based on the application information and the component information. The association includes at least: component startup order, component invocation relationship and component application binding relationship. A directed dependency graph is generated based on the aforementioned relationships, and the directed dependency graph is determined as the dependency relationship model between the business application and each of the aforementioned technical components.

[0007] In one embodiment, the step of performing compatibility verification on the dependency model based on a preset compatibility rule base includes: The combination of technology component versions to be verified is determined based on the dependency model. The combination of the technical component versions is matched with the rule entries in the preset compatibility rule base to obtain the matching result. The compatibility rule base includes preset incompatible version combination rules and minimum version constraint rules. Perform a compatibility check based on the matching results.

[0008] In one embodiment, the step of performing compatibility verification based on the matching result includes: When the preset incompatible version combination rule and / or minimum version constraint rule are matched, the compatibility check is deemed to have failed. If no match is found between the preset incompatible version combination rule and the minimum version constraint rule, the compatibility check is deemed to have passed.

[0009] In one embodiment, the step of encapsulating the business application and each of the technical components to generate an application deployment unit when the compatibility verification passes includes: Initialize the basic encapsulation environment based on the configuration information of the business application; Based on the dependency model, each of the technical components is instantiated in the basic encapsulation environment to obtain technical component instances; The business code corresponding to the business application is deployed to the basic encapsulation environment, and the business code is bound to each of the technical component instances; The basic encapsulation environment, which includes the instances of the technical components and the business code, is packaged as a whole to generate an application deployment unit.

[0010] In one embodiment, after the step of generating the application deployment unit, the method further includes: Store the application deployment unit in a preset image repository; Accordingly, the step of invoking the application deployment unit to deploy the business application in response to the deployment task triggering operation includes: Listen for trigger operations associated with the aforementioned business application; When the triggering operation meets the preset deployment task triggering conditions, the triggering operation is determined to be a deployment task triggering operation, and the corresponding application deployment unit is pulled from the preset image repository; In a serverless operating environment, a business application runtime instance is created based on the application deployment unit to execute the business application.

[0011] In one embodiment, the step of receiving the description file of the service application includes: Display a configuration interface to the user so that the user can create or import the current description file based on the configuration interface; The current description file is format-validated, and if the format validation passes, the current description file is determined as the description file for the business application.

[0012] Furthermore, to achieve the above objectives, this application also proposes a business application deployment apparatus, the apparatus comprising: The file import module is used to receive a description file of a business application, wherein the description file describes the business application and at least one technical component that the business application depends on. The dependency resolution module is used to parse the description file and construct a dependency relationship model between the business application and each of the technical components based on the parsing results. The model verification module is used to perform compatibility verification on the dependency relationship model based on a preset compatibility rule base; The encapsulation module is used to encapsulate the business application and each of the technical components when the compatibility verification is passed, and generate an application deployment unit. The deployment module is used to call the application deployment unit to deploy the business application in response to the deployment task trigger operation.

[0013] In addition, to achieve the above objectives, this application also proposes a business application deployment device, the device comprising: a memory, a processor, and a business application deployment program stored on the memory and executable on the processor, the business application deployment program being configured to implement the steps of the business application deployment method described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a business application deployment program is stored, and when the business application deployment program is executed by a processor, it implements the steps of the business application deployment method described above.

[0015] This application discloses a method for deploying a business application, comprising: receiving a description file of a business application, the description file describing the business application and at least one technical component that the business application depends on; parsing the description file and constructing a dependency model between the business application and each technical component based on the parsing result; performing compatibility verification on the dependency model based on a preset compatibility rule base; when the compatibility verification passes, encapsulating the business application and each technical component to generate an application deployment unit; and in response to a deployment task trigger operation, calling the application deployment unit to deploy the business application.

[0016] Because this application encapsulates the business application and its necessary technical components into an application deployment unit before deployment, and completes the pre-verification of version and configuration through a dependency model and compatibility rule base, the deployment phase only needs to call this unit, thereby eliminating the steps of manually installing and aligning parameters one by one in the existing method, reducing the deployment error rate and complexity. At the same time, since the same deployment unit is used in development, testing and production environments, environmental differences are eliminated. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating the first embodiment of the business application deployment method of this application; Figure 2 This is a flowchart illustrating the second embodiment of the business application deployment method of this application; Figure 3 This is a flowchart illustrating the third embodiment of the business application deployment method of this application; Figure 4 This is a schematic diagram illustrating the entire process of deploying the business applications of this application; Figure 5 This is a schematic diagram of the module structure of the business application deployment device of this application; Figure 6 A schematic diagram of the structure of the equipment deployed for the business applications of this application.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0023] This application provides a method for deploying a business application, referencing... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the business application deployment method of this application. In this embodiment, the method includes: steps S10~S50: Step S10: Receive a description file of a business application, the description file being used to describe the business application and at least one technical component that the business application depends on.

[0024] It should be noted that the executing entity in this embodiment can be a computing electronic device with data processing, network communication, and program execution functions, such as a computer, mainframe computer, system server, etc., or other aPaaS management terminal device that can access the Application Platform as a Service (aPaaS) system. The following uses a business application deployment device (referred to as "system") that accesses the aPaaS system as an example to describe this embodiment and the following embodiments.

[0025] Understandably, business applications can be core software entities that need to be deployed and run, such as order processing services, data analytics microservices, or scheduled report generation services; their essence can be executable program code. Technical components can be external infrastructure services that support the operation of business applications, such as data persistence components, caching components, message communication components, and other middleware.

[0026] The description file can be a text file using a structured data format (YAML, JSON), which can be declarative and defines the specific business logic of the business application as well as the component information of the technical components it requires.

[0027] It should be understood that the description file may include metadata about the business application, such as the type of input program, the code storage location or entry point, and the resources required for operation; it may also include component information of the technical components that the business application depends on, such as component type (e.g., database, message queue, cache, middleware), specific version number, and key configuration parameters (database name, connection pool size, caching strategy, etc.); it may also include the triggering rules of scheduled tasks (e.g., Cron expressions, event triggering conditions) and a description of the dependency relationship between the business application and technical components.

[0028] Furthermore, to specifically illustrate how the system obtains the description file of the business application, step S10 specifically includes: steps S101~S102: Step S101: Display the configuration interface to the user so that the user can create or import the current description file based on the configuration interface.

[0029] It should be understood that the configuration interface serves as the interface through which the system interacts with the user. This interface can be divided into multiple logical areas to guide the user in creating the description files corresponding to the business application. These logical areas may include: an application basic information area, a technical component addition area, a component configuration area, a dependency definition area, and an advanced rules area.

[0030] In the application basic information area, users can fill in the application name, runtime environment (such as Java 11, Python 3.9), code repository address / upload entry, startup command, etc.

[0031] The technical component addition area provides an "Add Component" button, allowing users to select the required component type from a pre-built component library (such as database, cache, message queue, etc.).

[0032] The component configuration area displays configuration forms for the aforementioned added technical components. For example, when a user adds a "MySQL" component, the interface can dynamically expand the corresponding configuration form, including: version selection: a drop-down menu provides selectable versions (8.0, 5.7, etc.); parameter configuration: input boxes are used to fill in the database name, character set, root password, storage size, performance parameters, etc.

[0033] The dependency definition area can display the components and applications that the user has added in a graphical or list format, and provide ways for the user to define the startup order or dependencies (e.g., by connecting lines or setting a "Wait for components to be ready" checkbox).

[0034] The advanced rules section can be used to configure, for example, triggering rules for scheduled tasks (Cron expressions).

[0035] In practice, users fill in and select information through the configuration interface, and the system automatically generates a compliant description file (YAML / JSON) in the background. Alternatively, users can export an existing description file from another system and submit it directly to the system through the "Upload" or "Paste YAML / JSON" function provided on the configuration interface.

[0036] Step S102: Perform format verification on the current description file, and determine the current description file as the description file of the business application when the format verification passes.

[0037] It should be noted that upon receiving the description file, the system can first perform syntax and structural format validation on the description file to ensure that the description file can be correctly parsed subsequently.

[0038] Format validation can be implemented from various dimensions, including syntactic correctness, structural integrity, data type matching, and mandatory field checking.

[0039] Syntactic correctness checks for errors in YAML / JSON syntax, such as incorrect indentation, missing quotes, mismatched parentheses, and the use of illegal characters. Structural integrity checks for the existence of necessary top-level fields. For example, based on the system's predefined schema, it checks if the file contains necessary root nodes such as application and components. Data type matching checks if the field value types are as expected, preventing users from mistakenly entering strings as numbers. For example, the version field should be a string, the memory field should be a number, and the enabled field should be a boolean value. Required field checks ensure that all fields marked "required" have values ​​provided. For example, if a MySQL component is added, its version field must be filled in.

[0040] In its implementation, the system can load a predefined JSON Schema or similar schema definition file to validate the format of the currently imported description file. If validation passes, the aforementioned description file is designated as the description file for the business application and stored in the system's temporary cache. If validation fails, detailed error information is returned to the configuration interface to prompt the user to correct the error. This avoids sending incorrectly formatted files to a complex parsing and encapsulation engine, thereby preventing internal engine anomalies, resource waste, or unpredictable results that might occur due to parsing failures, ensuring the stability and efficiency of the core processing flow.

[0041] Step S20: Parse the description file and construct a dependency model between the business application and each of the technical components based on the parsing results.

[0042] It should be noted that a pre-configured encapsulation engine can be set up within the system. This encapsulation engine can integrate multiple collaborative working units to perform parsing operations on the description file.

[0043] The aforementioned collaborative work units may include: a syntax parser, which can be used to read YAML / JSON description files and convert them into structured objects in memory; and a semantic analyzer, which can be used to perform semantic analysis and recognition on the aforementioned structured objects, for example, to identify that the structured object mysql represents a MySQL database and redis represents a caching service. The dependency extractor can be used to extract explicit or implicit dependencies from structured objects. For example, if a business application's configuration item has a `datasource.url` value that points to the service name of the `mysql` component, the dependency extractor can establish a "application depends on MySQL" relationship. The model builder can construct an internal graph data model, i.e., a dependency model, from the extracted entities (applications, technology components) and relationships (dependencies, connections).

[0044] It should also be noted that in this dependency model, the nodes can be business applications or technical components, the edges can be the connections / dependencies between nodes, and the edges can also be assigned weights (such as startup order).

[0045] In practical implementation, the system can read the syntax and structure of the description file through the encapsulation engine, convert it from text format into internally processable data objects (such as abstract syntax trees or structured objects), and finally obtain the logical relationships between all entities (application and technical components) declared in the description file, thereby constructing a dependency model that reflects the logical relationships between all entities.

[0046] Step S30: Perform compatibility verification on the dependency model based on the preset compatibility rule base.

[0047] It should be noted that the preset compatibility rule base can be a predefined knowledge base independent of the specific description file. It can store constraints and rules about the collaborative work between technical components, such as incompatible version combination rules, known conflict combination rules, and minimum version constraint rules.

[0048] Understandably, the aforementioned encapsulation engine can also integrate collaborative work units capable of performing version compatibility detection. Thus, the system can use the encapsulation engine to compare and logically judge the specific component types and version combinations extracted from the aforementioned dependency model (e.g., a business application using Spring Boot 2.5.4, depending on MySQL 8.0.26 and Redis 6.2.5) with entries in a preset compatibility rule base to perform compatibility detection, thereby discovering and intercepting potential runtime conflicts before encapsulation.

[0049] Step S40: When the compatibility verification passes, the business application and each of the technical components are encapsulated to generate an application deployment unit.

[0050] It should be noted that the aforementioned encapsulation engine can also integrate collaborative work units capable of performing encapsulation operations. Upon successful compatibility verification, the system can use the encapsulation engine to uniformly encapsulate the business application and its dependent technical components, generating an immutable image file, i.e., the application deployment unit.

[0051] It should be understood that the encapsulation engine can pre-create a standardized basic runtime environment, and then install, configure and initialize each technical component in the basic runtime environment according to the order and configuration determined by the dependency model. Then, the program code and configuration files of the business application are also deployed to the above-mentioned basic runtime environment to associate with the technical components therein, thereby obtaining a complete environment containing all the installed, configured and interconnected business applications and their technical components.

[0052] Finally, the complete environment described above can be solidified into an immutable image file using container technology (such as Docker commit), thus obtaining the application deployment unit.

[0053] It should also be noted that once the application deployment unit is generated, the versions and configuration information of its internal technical components cannot be modified, and the application deployment unit can be pushed to the image repository for subsequent deployment.

[0054] Step S50: In response to the deployment task trigger operation, the application deployment unit is invoked to deploy the business application.

[0055] It should be noted that the deployment task can be triggered manually by the user (e.g., the user selects the business application and clicks "Deploy" in the system's deployment interface) or automatically (e.g., by a scheduled Cron expression in the system or by the CI / CD pipeline).

[0056] It should be understood that when the system detects that the triggering conditions of the scheduled task are met, it can pull the corresponding application deployment unit as needed, and then create and start one or more running instances based on the application deployment unit in the initial running environment provided by the system to achieve the deployment of the application.

[0057] This embodiment encapsulates the business application and its necessary technical components into an application deployment unit before deployment, and uses a dependency model and compatibility rule base to perform pre-verification of version and configuration. During the deployment phase, only this unit needs to be called, thereby eliminating the steps of manually installing and aligning parameters one by one in the existing method, reducing the deployment error rate and complexity. At the same time, since the same deployment unit is used in development, testing and production environments, environmental differences are eliminated.

[0058] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 , Figure 2 This is a flowchart illustrating the second embodiment of the business application deployment method of this application.

[0059] In this embodiment, to specifically illustrate how to construct the dependency model, step S20 specifically includes: steps S201~S203: Step S201: Extract the application information of the business application and the component information of each of the technical components from the description file.

[0060] It should be noted that the application information of a business application can be all configuration metadata related to the business application itself in the description file, which may include: identity identifiers, such as application name and unique ID; runtime specifications, such as the base image type and resource requirements (CPU, memory quota) required by the business application; program body information, such as source code repository address, Git branch / tag, or storage path of uploaded program packages (such as JAR, WAR files); startup instructions, such as startup commands and parameters within a container; configuration data, such as the content of the business application's own configuration file or connection information templates for external services; and triggering rules, such as Cron expressions or event triggering conditions if the business application is a scheduled task.

[0061] The component information of a technical component can be the configuration metadata defined in the description file for each technical component (such as MySQL, Redis, Kafka), which may include: component identifier, such as component type (type such as MySQL, Redis), instance name, etc.; version specification, i.e. the version number required by the technical component, such as 8.0.2; configuration parameters, i.e. the detailed configuration required for the technical component to run, and the configuration parameters may be different for different technical components.

[0062] For example, for MySQL, configuration parameters may include the database name, character set, root password, port number, InnoDB buffer pool size, etc.; for Redis, configuration parameters may include password, persistence strategy, maximum memory limit, etc.; for Kafka, configuration parameters may include topic name, number of partitions, replication factor, etc.

[0063] In the specific implementation, the system uses the encapsulation engine to parse the description file, which yields the application information and component information mentioned above, enabling subsequent determination of the dependencies between business applications and technical components.

[0064] Step S202: Determine the association between the business application and each of the technical components based on the application information and the component information.

[0065] It should be noted that the above relationships may include: component startup order, component call relationship, and component application binding relationship.

[0066] The component startup order refers to the order in which the various technical component service processes are started. Users can explicitly specify the component startup order directly in the description file using fields such as `depends_on`, or the encapsulation engine can infer it based on general knowledge or rules.

[0067] For example, database migration tool components (such as Flyway) need to run after the database components have started and completed initialization, and before the main business application starts. The business application can typically start after all the basic components are ready.

[0068] Component call relationships can be service calls or data flow relationships between technical components. The encapsulation engine can determine this through the component configuration parameters of each technical component. For example, if the configuration parameters of technical component A reference the service location of technical component B, then the relationship of "A calls B" can be deduced; or it can be determined according to a pre-set industry-standard pattern.

[0069] Component application binding relationships can be strong dependency connections between business applications and specific technical component instances. The encapsulation engine can analyze the application configuration template extracted from the application information, identify variable placeholders in the template, and then search for matches in the component information of each technical component to determine the technical component that can provide the specific variable values ​​corresponding to the aforementioned variable placeholders. When a match is successful, a binding relationship is established between the business application and the matched technical component.

[0070] Step S203: Generate a directed dependency graph based on the aforementioned relationships, and determine the directed dependency graph as the dependency relationship model between the business application and each of the aforementioned technical components.

[0071] It should be noted that this directed dependency graph can include nodes and directed edges. Nodes can be business application nodes or technical component nodes, and directed edges can represent the relationship from the dependent node to the dependent node. The edges can be labeled with the type of relationship (such as "startup dependency" or "data binding") and attributes (such as the timeout for waiting for the dependent node to be healthy).

[0072] For example, if a business application node has an edge pointing to a MySQL node, it means that the business application depends on MySQL; if a database migration tool node has an edge pointing to a MySQL node, and a business application node also has an edge pointing to a database migration tool node, then a dependency chain can be formed. A directed dependency graph can include one or more dependency chains as described above.

[0073] It should also be noted that this directed dependency graph is a dependency model that reflects the relationship (especially the dependency relationship) between business applications and various technical components. It can be used to guide the encapsulation engine to perform compatibility verification and integrated encapsulation.

[0074] The process of constructing the dependency model described above includes: extracting business application information and information on each technical component from the description file, determining the relationships between them, and generating a directed dependency graph to construct an accurate dependency model. This achieves automated and structured parsing of complex dependencies between applications and multiple components, avoiding omissions and inconsistencies from manual analysis. It provides an accurate and unambiguous basis for subsequent compatibility checks and integrated encapsulation, ensuring the correctness and reliability of the dependency topology within the deployment unit.

[0075] Furthermore, to illustrate in detail how to implement compatibility verification, step S30 specifically includes: steps S301~S303: Step S301: Determine the combination of technology component versions to be verified based on the dependency model.

[0076] It should be understood that the system uses an encapsulation engine to traverse the nodes of each technical component in the above dependency model, thereby determining the corresponding component type (such as MySQL, Redis) and specific version number (such as 8.0.2, 6.2.5) from the component information corresponding to each node.

[0077] In practice, the <type, version> pairs corresponding to the above technical components can be summarized to form a list of version combinations to be checked, i.e., technical component version combinations, which can serve as the basic unit for subsequent rule matching.

[0078] For example, for a system that includes MySQL, Redis and applications, the combination of technology component versions can be represented as: [(MySQL, 8.0.28), (MySQL, 6.2.5)].

[0079] Step S302: Match the combination of the technical component versions with the rule entries in the preset compatibility rule library to obtain the matching result. The compatibility rule library includes preset incompatible version combination rules and minimum version constraint rules.

[0080] It should be understood that the preset compatibility rule base can be an independently stored, structured knowledge base that is predefined and maintained by the platform or community. This preset compatibility rule base can store several rule entries, such as incompatible version combination rules, known conflict combination rules, and minimum version constraint rules, etc., and each rule corresponds to a clear logical judgment condition.

[0081] Among them, incompatible version rules and known conflict rules can be set based on known issues in official announcements, extensive community experience, or unstable interaction between specific versions verified by laboratory test data; minimum version constraint rules can be dependency requirements declared in the official documentation of upstream software. For example, business applications may require the connected technical components to support a specific protocol, which is only available when the component version number of the technical component is greater than the specific version number.

[0082] In its implementation, the system can use an encapsulation engine to combine the aforementioned technical component versions as query conditions, search and match them in a preset compatibility rule base, and obtain the query results. These results may indicate that a rule entry has been matched or that no rule entry has been matched.

[0083] Step S303: Perform compatibility verification based on the matching results.

[0084] It should be noted that the matching result can include either: matching at least one rule, or not matching any rule.

[0085] It should be understood that when a combination of technical component versions matches an incompatible combination rule or a known conflict rule, it can be determined that the combination of technical component versions has triggered a known conflict.

[0086] For example, if an incompatible combination rule or a known conflict rule requires "a connection problem exists between Redis version 6.0 and MySQL version 5.6," and the current version combination contains Redis version 6.0 and MySQL version 5.6, then a conflict can be identified, meaning the compatibility check fails.

[0087] When a combination of technology component versions matches a minimum version constraint rule, at least one technology component in the combination has a version number lower than the minimum version required by its dependents.

[0088] For example, if the minimum version constraint rule requires "the application framework needs MySQL >= 5.8", but the MySQL version in the current version combination is 5.6, then it can be determined that the constraint is not met, i.e., the compatibility check fails.

[0089] It should also be understood that when the combination of technical component versions does not match the incompatible version combination rule, the known conflict combination rule, or the minimum version constraint rule, it can be determined that there are no known version issues in the rules covered by the preset compatibility rule base, that is, the compatibility verification is passed and the subsequent encapsulation operation can be performed.

[0090] In a specific implementation, if the aforementioned combination of technical component versions matches the preset incompatible version combination rule and / or minimum version constraint rule, the compatibility check is determined to have failed; if the combination of technical component versions does not match the preset incompatible version combination rule and minimum version constraint rule, the compatibility check is determined to have passed.

[0091] This embodiment extracts business application information and information about each technical component from the description file, determines the relationships between them, and generates a directed dependency graph to construct an accurate dependency model. This achieves automated and structured parsing of complex dependencies between applications and multiple components, avoiding omissions and inconsistencies from manual analysis. It provides accurate and unambiguous execution basis for subsequent compatibility verification and integrated encapsulation, ensuring the correctness and reliability of the dependency topology within the deployment unit. Furthermore, before encapsulation, it automatically performs incompatibility matching and minimum version constraint checks on the version combinations of the technical components to be encapsulated based on a preset compatibility rule base, and determines whether the verification passes based on the matching results. This proactively identifies and intercepts known version conflicts and missing dependencies between components during the build phase, ensuring the collaborative working capability of components within the integrated encapsulation unit from the source. It effectively avoids runtime failures after deployment caused by implicit compatibility issues, improving the inherent quality of the deployment unit and the reliability of cross-environment operation.

[0092] Based on the first and second embodiments of this application, in the third embodiment of this application, the content that is the same as or similar to that in embodiments one and two above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 , Figure 3 This is a flowchart illustrating the third embodiment of the business application deployment method of this application.

[0093] In this embodiment, to specifically illustrate how to achieve integrated encapsulation of business applications and technical components, step S40 specifically includes: steps S401~S404: Step S401: Initialize the basic encapsulation environment according to the configuration information of the business application.

[0094] It should be noted that this configuration information can be information related to the runtime environment base extracted from the application information in the description file. For example, if the business application is a Java program, the configuration information can be a base operating system image environment that requires a JRE; if the business application is a Python program, the configuration information can be an image environment that requires a Python interpreter.

[0095] It should be understood that the system can use the packaging engine in conjunction with the image environment required in the aforementioned configuration information to create a blank temporary container instance as the basic packaging environment.

[0096] Step S402: Instantiate each of the technical components in the basic encapsulation environment according to the dependency model to obtain technical component instances.

[0097] Understandably, the execution list for instantiating technical components can be determined based on the dependency model. This execution list includes the instantiation order of each technical component and the configuration parameters of each technical component.

[0098] In its implementation, the system can use the encapsulation engine to instantiate each technical component sequentially according to the instantiation order and configuration parameters described above, thereby obtaining technical component instances. These technical component instances run within the aforementioned basic encapsulation environment and can implement the corresponding service functions.

[0099] Step S403: Deploy the business code corresponding to the business application to the basic encapsulation environment, and bind the business code to each of the technical component instances.

[0100] It should be understood that the business code corresponding to the business application (such as a compiled JAR package, Python script file, etc., which contains the configuration data of the business application) can be copied or downloaded to a specified directory of the basic encapsulation environment, thereby completing the deployment of the business code in the environment.

[0101] In practical implementation, the system can use the encapsulation engine to locate the specific location of the business code in the aforementioned basic encapsulation environment; and based on the component application binding relationship determined in the dependency model, replace the placeholders or template variables in the configuration data of the business application that point to external services with the actual access endpoints of the technical component instances within the environment, thereby configuring the business application to communicate and interact only with the technical component instances within the basic encapsulation environment, and realizing the binding of the business application and the technical components within the encapsulation environment.

[0102] Step S404: Package the basic encapsulation environment containing the technical component instances and the business code as a whole to generate an application deployment unit.

[0103] It should be understood that once all technical components have been instantiated and the business code has been deployed and bound, the encapsulation engine can invoke the commit command of the underlying container runtime (such as Docker). In response to this commit command, the system can freeze the entire state of the currently running container instance and save it as a brand new, read-only container image.

[0104] It should also be noted that the aforementioned read-only container image serves as the application deployment unit for that application. Internally, it contains a complete software stack, from the operating system layer and middleware layer to the business application layer, with each layer pre-configured and properly connected. Furthermore, this application deployment unit does not support dynamic modification during runtime, thus ensuring cross-environment consistency when deploying the business application in different environments.

[0105] Furthermore, after step S404, the following steps are also included: Step S405: Store the application deployment unit in a preset image repository.

[0106] It should be noted that this preset image repository can be a centralized system storage area used to store and manage container images.

[0107] In its implementation, the system can use the encapsulation engine to upload the application deployment units to the repository and associate the application deployment units with the corresponding task identifiers and version information, thereby achieving persistent and versioned management of the application deployment units, enabling them to be distributed and retrieved at any time.

[0108] Accordingly, step S50 specifically includes: steps S501~S503: Step S501: Listen for trigger operations associated with the business application.

[0109] Step S502: When the triggering operation meets the preset deployment task triggering conditions, determine that the triggering operation is a deployment task triggering operation, and pull the corresponding application deployment unit from the preset image repository.

[0110] It should be noted that the system can continuously monitor events from the deployment interface, time scheduler, or event bus through the scheduler to enable trigger operation listening.

[0111] Understandably, the preset deployment task trigger conditions can be: the user clicks the deployment button on the deployment interface (manual trigger condition); the time scheduler determines that the current time has reached the scheduled time in the Cron expression of the scheduled task (scheduled trigger condition); and events such as code repository push (Git Webhook) and API calls issued by other systems (event trigger conditions).

[0112] Specifically, the scheduler can match the detected triggering operations with the above conditions. When a match is successful, the corresponding triggering operation is determined as a valid deployment task triggering operation, triggering the subsequent pull and execution process. Then, the scheduler can send a call request to the preset image repository based on the application name and version tag specified in the aforementioned triggering operation (such as my-app:v1.0.0), downloading the corresponding application deployment unit to the host or serverless environment where it will be run as determined in the triggering operation.

[0113] Step S503: In a serverless operating environment, create a business application running instance based on the application deployment unit to execute the business application.

[0114] It should be understood that a serverless runtime environment can be a computing environment that is pre-associated with the system, such as AWS Lambda, Alibaba Cloud Function Compute, or Knative based on Kubernetes, which provides on-demand resource allocation, automatic elastic scaling, and billing based on actual usage.

[0115] It should be noted that this serverless runtime environment can create and start a new container instance based on the pulled application deployment unit. Since the application deployment unit encapsulates the business application and its dependent technical components such as databases, caches, and message queues, the internal technical component services such as MySQL and Redis can be automatically started after the container starts. Finally, after all technical components are ready, the business application process can be automatically started to run and process requests or execute tasks.

[0116] In addition, for business applications that only execute scheduled tasks, the entire container instance can be automatically destroyed to release resources after the scheduled task is completed; for business applications that execute persistent tasks, the container instance can continue to run.

[0117] Furthermore, this can be referenced here. Figure 4 This document describes the entire process of deploying the business applications described in this application using the aPaaS system. Figure 4 This is a schematic diagram illustrating the entire process of deploying the business applications of this application.

[0118] Depend on Figure 4 As can be seen, firstly, the system can accept business description files created or imported by users based on the interactive interface (configuration interface). These business description files describe the business application and at least one technical component it depends on, such as a database (DB), message queue (MQ), cache, or middleware.

[0119] Next, the system can use a pre-configured encapsulation engine to parse the dependencies of the aforementioned business description files; after parsing, it can perform compatibility verification on the dependency model using a pre-configured compatibility rule base; after the compatibility verification is passed, the business application and each technical component are encapsulated (immutable image packaging) to generate an application deployment unit; then the application deployment unit is pushed to the image repository to associate the application deployment unit with the corresponding task identifier and version information, thereby realizing the persistent storage and version management of the application deployment unit.

[0120] Finally, the system can continuously monitor the triggering operations in the system through the scheduler. When the triggering operation meets the preset deployment task triggering conditions, the corresponding application deployment unit can be pulled from the preset image repository to create a business application running instance to execute the business application.

[0121] This application's method provides an interactive interface through the aPaaS management terminal to receive or generate unified description files describing business applications and technical components. Its embedded encapsulation engine performs dependency resolution and immutable image packaging, generating an integrated application deployment unit stored in an image repository. Finally, based on trigger conditions, the unit is retrieved and a running instance is created. This ensures complete consistency of deployment entities across development, testing, and production environments, fundamentally eliminating system failures caused by environmental differences. Furthermore, users only need to describe the expected state using declarative files, eliminating the need for manual configuration of databases, caches, message queues, and other technical components, achieving true one-click deployment and greatly simplifying deployment operations. In addition, when business applications or technical components require version upgrades, this can be accomplished by replacing the entire deployment unit, eliminating the need for complex manual dependency adaptation and configuration adjustments, significantly improving upgrade efficiency and saving maintenance costs.

[0122] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the business application deployment method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0123] This application also provides a business application deployment device. Please refer to... Figure 5 , Figure 5 This is a schematic diagram of the module structure of the business application deployment device of this application. The device includes: The file import module 501 is used to receive a description file of a business application, wherein the description file describes the business application and at least one technical component that the business application depends on. The dependency resolution module 502 is used to parse the description file and construct a dependency relationship model between the business application and each of the technical components based on the resolution result. The model verification module 503 is used to perform compatibility verification on the dependency relationship model based on a preset compatibility rule base. The encapsulation module 504 is used to encapsulate the business application and each of the technical components when the compatibility verification is passed, and generate an application deployment unit. The deployment module 505 is used to call the application deployment unit to deploy the business application in response to the deployment task trigger operation.

[0124] This embodiment of the system encapsulates the business application and its necessary technical components into an application deployment unit before deployment, and uses a dependency model and compatibility rule base to perform pre-verification of version and configuration. During the deployment phase, only this unit needs to be called, thereby eliminating the steps of manually installing and aligning parameters one by one in the existing method, reducing the deployment error rate and complexity. At the same time, since the same deployment unit is used in development, testing and production environments, environmental differences are eliminated.

[0125] This application also provides a business application deployment device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to execute the business application deployment method in Embodiment 1 above.

[0126] The following is for reference. Figure 6 , Figure 6 This is a schematic diagram of the structure of the service application deployment device in this application. The service application deployment device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, personal digital assistants (PDAs), tablet computers (PADs), portable media players (PMPs), etc., as well as fixed terminals such as digital TVs, desktop computers, etc. Figure 6 The business application deployment device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0127] like Figure 6As shown, the business application deployment device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the business application deployment device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the business application deployment device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows business application deployment devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0128] The business application deployment device provided in this application, employing the business application deployment method described in the above embodiments, can solve the technical problems of business application deployment. Compared with the prior art, the beneficial effects of the business application deployment device provided in this application are the same as those of the business application deployment method described in the above embodiments, and other technical features of the business application deployment device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0129] This application also provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the business application deployment method in the above embodiments.

[0130] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0131] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described business application deployment method, and is able to solve the technical problems of the business application deployment method. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the business application deployment method provided in the above embodiments, and will not be repeated here.

[0132] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other elements in the process, method, article, or system that includes that element.

[0133] The above embodiment numbers are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments. They are only some embodiments of this application and do not limit the scope of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included within the protection scope of this application.

Claims

1. A method for deploying a business application, characterized in that, The method includes: Receive a description file for a business application, the description file being used to describe the business application and at least one technical component that the business application depends on; The description file is parsed, and a dependency model between the business application and each of the technical components is constructed based on the parsing results; The dependency model is validated for compatibility based on a pre-defined compatibility rule base. Once the compatibility verification is passed, the business application and each of the technical components are encapsulated to generate an application deployment unit; In response to the deployment task trigger operation, the application deployment unit is invoked to deploy the business application.

2. The method as described in claim 1, characterized in that, The step of parsing the description file and constructing a dependency model between the business application and each of the technical components based on the parsing results includes: The application information of the business application and the component information of each of the technical components are extracted from the description file; The association between the business application and each of the technical components is determined based on the application information and the component information. The association includes at least: component startup order, component calling relationship and component application binding relationship. A directed dependency graph is generated based on the aforementioned relationships, and the directed dependency graph is determined as the dependency relationship model between the business application and each of the aforementioned technical components.

3. The method as described in claim 1, characterized in that, The step of performing compatibility verification on the dependency model based on a preset compatibility rule base includes: The combination of technology component versions to be verified is determined based on the dependency model. The combination of the technical component versions is matched with the rule entries in the preset compatibility rule base to obtain the matching result. The compatibility rule base includes preset incompatible version combination rules and minimum version constraint rules. Perform a compatibility check based on the matching results.

4. The method as described in claim 3, characterized in that, The step of performing compatibility verification based on the matching result includes: When the preset incompatible version combination rule and / or minimum version constraint rule are matched, the compatibility check is deemed to have failed. If no match is found between the preset incompatible version combination rule and the minimum version constraint rule, the compatibility check is deemed to have passed.

5. The method as described in claim 3, characterized in that, The step of encapsulating the business application and each of the technical components to generate an application deployment unit when the compatibility verification is passed includes: Initialize the basic encapsulation environment based on the configuration information of the business application; Based on the dependency model, each of the technical components is instantiated in the basic encapsulation environment to obtain technical component instances; The business code corresponding to the business application is deployed to the basic encapsulation environment, and the business code is bound to each of the technical component instances; The basic encapsulation environment, which includes the instances of the technical components and the business code, is packaged as a whole to generate an application deployment unit.

6. The method as described in claim 5, characterized in that, Following the step of generating the application deployment unit, the method further includes: Store the application deployment unit in a preset image repository; Accordingly, the step of invoking the application deployment unit to deploy the business application in response to the deployment task triggering operation includes: Listen for trigger operations associated with the aforementioned business application; When the triggering operation meets the preset deployment task triggering conditions, the triggering operation is determined to be a deployment task triggering operation, and the corresponding application deployment unit is pulled from the preset image repository; In a serverless operating environment, a business application runtime instance is created based on the application deployment unit to execute the business application.

7. The method as described in claim 1, characterized in that, The step of receiving the description file of the service application includes: Display a configuration interface to the user so that the user can create or import the current description file based on the configuration interface; The current description file is format-validated, and if the format validation passes, the current description file is determined as the description file for the business application.

8. A business application deployment device, characterized in that, The device includes: The file import module is used to receive a description file of a business application, wherein the description file describes the business application and at least one technical component that the business application depends on. The dependency resolution module is used to parse the description file and construct a dependency relationship model between the business application and each of the technical components based on the parsing results. The model verification module is used to perform compatibility verification on the dependency relationship model based on a preset compatibility rule base; The encapsulation module is used to encapsulate the business application and each of the technical components when the compatibility verification is passed, and generate an application deployment unit. The deployment module is used to call the application deployment unit to deploy the business application in response to the deployment task trigger operation.

9. A business application deployment device, characterized in that, The device includes: a memory, a processor, and a business application deployment program stored on the memory and executable on the processor, the business application deployment program being configured to implement the steps of the business application deployment method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and the storage medium stores a business application deployment program. When the business application deployment program is executed by a processor, it implements the steps of the business application deployment method as described in any one of claims 1 to 7.

Images