A schema-driven application management method, device, equipment and medium

Abstract

The application relates to the technical field of software development, in particular to a Schema-driven application management method and device, equipment and medium. In view of the problem that a Schema historical version cannot be traced due to being covered, an independent version number is generated for each saving, and correlation is established, so that each Schema version can be accurately located and traced back. In view of the problem of multi-environment data pollution, storage is respectively performed according to a target environment identifier, so that environment version chains are independent of each other. A structured version management mechanism provides a data basis for accurately obtaining a Schema version, and supports a full-automatic process from Schema configuration to code deployment. On this basis, the above version management mechanism provides accurate Schema data sources and version tracing capabilities for automatic parsing of component dependencies, thereby solving the problems of easy omission and inconsistent versions in manual maintenance of dependencies. Meanwhile, the mechanism also ensures that code generation and CI / CD triggering processes can obtain corresponding Schema versions for correct environments, and guarantees reliable execution of full-process automation.

Description

Technical Field

[0001] This application relates to the field of software development technology, and in particular to a schema-driven application management method, apparatus, device, and medium. Background Technology

[0002] Low-code platforms can significantly improve software development efficiency through visual configuration and automated code generation. Among them, the schema unique to low-code platforms is the core data that describes page structure, components and interactions.

[0003] Existing application management solutions include: 1. Traditional application management platforms, which provide basic application information management, but each stage is independent and requires manual intervention, lacking deep integration with schema data; 2. Existing low-code platforms, where schema management is independent of application management, code generation requires manual triggering and deployment, schemas in multiple environments lack isolation, and different environments share or overwrite the same data; 3. DevOps platforms, which focus on deployment and operation and maintenance, achieving automatic build and deployment through CI / CD, but have insufficient support for schema data management and cannot handle the schema-to-code conversion process.

[0004] The above solutions have at least the following drawbacks: schema data is separated from application management, only the latest version is saved, historical versions are overwritten, and the success rate of version tracing is low; the ability to manage schemas in multiple environments is insufficient, data pollution between environments is possible, and there are stability risks; code generation requires multiple manual steps, the process is cumbersome and prone to errors; application dependencies lack unified management, manual maintenance is prone to omissions or version inconsistencies; integration with external systems such as Git, CI / CD, and material platforms depends on manual operation, resulting in low automation. Summary of the Invention

[0005] To address the problems in the prior art, embodiments of this application provide a schema-driven application management method, apparatus, device, and medium for achieving independent version management of schema data in multiple environments and full-process automation from configuration to deployment, thereby improving the traceability, environmental isolation, and delivery efficiency of application management.

[0006] In a first aspect, embodiments of this application provide a schema-driven application management method, including: Receive a schema save request for the target application, the schema save request including page identifier, schema data and target environment identifier; Based on the page identifier and the target environment identifier, determine the current schema version number of the target application in the target environment; A new version number is generated based on the current schema version number, and the new version number includes a major version number, a minor version number, and a patch version number. The schema data is associated with the new version number and stored according to the target environment identifier; Save the association between the schema data and the target application, the page identifier, the new version number, and the target environment identifier.

[0007] This application achieves the following beneficial effects by receiving a save request containing a page identifier, schema data, and a target environment identifier; determining the current version number based on the page identifier and target environment identifier; generating a new version number containing a major version number, minor version number, and patch version number based on the current version number; associating schema data with the new version number and storing it separately according to the environment; and saving the association relationship between schema data and the target application, page identifier, new version number, and target environment identifier: Addressing the problem of untraceable overwritten schema historical versions, by generating an independent version number for each save and establishing an association, each schema version can be accurately located and traced back; addressing the problem of multi-environment data pollution, by storing it separately according to the target environment identifier, the version chains of each environment are made independent, eliminating interference between environments; furthermore, the structured version management mechanism provides a data foundation for subsequent accurate acquisition of schema versions by environment, supporting a fully automated process from schema configuration to code deployment, reducing manual intervention and deployment errors. Building upon this, the aforementioned version management mechanism provides accurate schema data sources and version traceability capabilities for automatic component dependency resolution. This enables dependency resolution to extract component reference information based on the correct schema version and link it with the material platform, thereby solving the problems of easy omissions and version inconsistencies in manual dependency maintenance. At the same time, this mechanism also ensures that code generation and CI / CD triggering processes can obtain the corresponding schema version for the correct environment, guaranteeing the reliable execution of the entire automated process.

[0008] In one possible implementation, generating a new version number based on the current schema version number includes: When the target environment identifier indicates a production environment, increment the minor version number by 1 and reset the patch version number to 0; When the target environment identifier represents a development environment or a test environment, increment the patch version number by 1.

[0009] In the above implementation, by distinguishing between the production environment and the development / testing environment based on the target environment identifier, different version number increment strategies are adopted. This allows version number changes in the production environment to reflect feature iterations (minor version number increment), while version number changes in the development / testing environment can reflect modification frequency (patch version number increment), thus achieving unified semantic management of version number meaning in different environments.

[0010] In one possible implementation, associating the schema data with the new version number and storing it according to the target environment identifier includes: The schema data is divided into a component mapping part, a component tree part, and other configuration parts according to a preset data structure; The split parts are stored in their respective data tables and associated with each part through a master record. The master record contains the page identifier, the new version number, and the target environment identifier. The page identifier is used to associate with the target application.

[0011] In the above implementation, by splitting the schema data into component mapping, component tree and other configuration parts and storing them separately, the read and write performance bottleneck caused by storing the complete schema data as a single large JSON field is avoided. This allows the component mapping part to be read directly without parsing the entire schema during subsequent dependency parsing. At the same time, by associating each part with the master record and recording the page identifier, version number and target environment identifier, the version management mechanism and the table-segmented storage structure are organically integrated.

[0012] In one possible implementation, after saving the association between the schema data and the target application, the page identifier, the new version number, and the target environment identifier, the method further includes: Receive a code generation request for the target application, the code generation request containing a target application identifier and a target environment identifier; Based on the target application identifier and the target environment identifier, obtain the schema data of the target application in the target environment.

[0013] In the above implementation, by receiving the code generation request after saving the schema association, and obtaining the schema data in the corresponding environment based on the target application identifier and the target environment identifier, the code generation process can accurately locate the schema version in the specified environment based on the association established during saving, ensuring that the schema data on which the subsequent code generation is based matches the target environment.

[0014] In one possible implementation, after obtaining the schema data of the target application in the target environment, the method further includes: Traverse the component mapping portion of the schema data and extract component reference information, which includes component identifier and component version requirements; The extracted component reference information is deduplicated; Send a query request to the material platform, the query request containing a list of deduplicated component identifiers; Receive the actual release information of each component returned by the material platform, wherein the actual release information includes the package name and package version corresponding to the component; Based on the component version requirements and the actual release information, generate the dependency configuration for the target application.

[0015] In the above implementation, component reference information is automatically extracted by traversing the component mapping part of the schema, and after deduplication, the actual release information of each component is queried from the material platform. Finally, the dependency configuration is automatically generated according to the component version requirements and the actual release information returned by the material platform, so that the generation of dependency configuration no longer depends on manual maintenance and avoids the problems of dependency omission and version inconsistency.

[0016] In one possible implementation, generating the dependency configuration for the target application includes: When the component version requirement indicates the use of the latest version, the package version returned by the material platform is determined as the dependent version; When the component version requires a specified version and the material platform has that version, the specified version will be determined as the dependent version; When the component version requires a specified version but the material platform does not have that version, use the latest version returned by the material platform and record the version difference prompt.

[0017] In the above implementation, by adopting corresponding version determination strategies according to different component version requirements (latest version, specified version, version mismatch), and recording difference prompts when versions mismatch, the selection of dependency versions can flexibly adapt to different version management needs, while providing developers with visual feedback on version differences.

[0018] In one possible implementation, after generating the dependency configuration for the target application, the method further includes: Identify the private component identifier in the component reference information; For components identified as private components, configure the component as an internal reference path.

[0019] In the above implementation, by identifying the private component identifier after generating the dependency configuration and configuring the private component as an internal reference path instead of adding it to the public dependency list, the generated dependency configuration can correctly handle the difference in referencing methods between internal self-developed components and public components, avoiding build failures caused by mistakenly installing private components as public npm packages.

[0020] In one possible implementation, after generating the dependency configuration, the method further includes: Based on the obtained schema data and the dependency configuration, the code generation engine is invoked to generate the source code of the target application; The generated source code is pushed to the target branch of the Git version control system associated with the target application; The build task of the continuous integration / continuous deployment system is triggered through the API interface. The build task contains information about the target branch and the target environment identifier.

[0021] In the above implementation, after generating the dependency configuration, the code generation engine is called to generate the source code, and the source code is automatically pushed to the target branch of the Git version control system. Then, the CI / CD system's build task is automatically triggered through the API interface, realizing the automation of the entire process from schema configuration to code generation, version control, and continuous integration, eliminating manual connection operations between each link.

[0022] In one possible implementation, after pushing the generated source code to the target branch of the Git version control system associated with the target application, the method further includes: Poll the build task status of the continuous integration / continuous deployment system; When the build task is completed, the deployment status flag of the target application is updated according to the build result.

[0023] In the above implementation, the build task status of the CI / CD system is polled after the code is pushed to the Git branch, and the deployment status flag is updated according to the build result after the build is completed. This allows users to know the deployment progress and results in real time without having to manually log in to the CI / CD system to check the build status, which further improves the automation level of the whole process and the user experience.

[0024] Secondly, embodiments of this application provide a schema-driven application management device, the device comprising: The request receiving unit is used to receive a schema saving request for the target application, wherein the schema saving request includes a page identifier, schema data and a target environment identifier; The version determination unit is used to determine the current schema version number of the target application in the target environment based on the page identifier and the target environment identifier; A version generation unit is used to generate a new version number based on the current schema version number, wherein the new version number includes a major version number, a minor version number, and a patch version number; An associated storage unit is used to associate the schema data with the new version number and store them separately according to the target environment identifier; it saves the association relationship between the schema data and the target application, the page identifier, the new version number and the target environment identifier.

[0025] Thirdly, embodiments of this application provide an electronic device, including a memory and a processor, wherein the memory stores a computer program that can run on the processor, and when the computer program is executed by the processor, it implements the method described in any one of the schema-driven application management methods of the first aspect.

[0026] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the method described in any one of the schema-driven application management methods of the first aspect.

[0027] The beneficial effects that the technical solutions in the second to fourth aspects can achieve are the same as those in the first aspect, and will not be repeated here. Attached Figure Description

[0028] Figure 1 A flowchart illustrating a schema-driven application management method provided in this application embodiment; Figure 2 A schematic diagram of a schema-driven application management device provided in this application embodiment; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Unless otherwise specified, the embodiments and features in the embodiments of this application can be arbitrarily combined with each other. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0030] The terms "first" and "second" in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising" and any variations thereof are intended to cover non-exclusive protection. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices. The term "multiple" in this application can mean at least two, for example, two, three, or more, and the embodiments of this application do not impose limitations.

[0031] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These embodiments should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description. It should be noted that in the embodiments of this application, certain existing industry solutions such as software, components, and models may be mentioned. These should be considered exemplary, intended only to illustrate the feasibility of implementing the technical solutions of this application, and do not imply that the applicant has already used or necessarily used such solutions.

[0032] The acquisition, transmission, storage, and use of data in this application all comply with the requirements of relevant national laws and regulations.

[0033] Before introducing the schema-driven application management method provided in the embodiments of this application, the technical background of the embodiments of this application will be described in detail below for ease of understanding.

[0034] Low-code platforms can significantly improve software development efficiency through visual configuration and automated code generation. Among them, the schema unique to low-code platforms is the core data that describes page structure, components and interactions.

[0035] Existing application management solutions include: 1. Traditional application management platforms, which provide basic application information management, but each stage is independent and requires manual intervention, lacking deep integration with schema data; 2. Existing low-code platforms, where schema management is independent of application management, code generation requires manual triggering and deployment, schemas in multiple environments lack isolation, and different environments share or overwrite the same data; 3. DevOps platforms, which focus on deployment and operation and maintenance, achieving automatic build and deployment through CI / CD, but have insufficient support for schema data management and cannot handle the schema-to-code conversion process.

[0036] The above solutions have at least the following drawbacks: schema data is separated from application management, only the latest version is saved, historical versions are overwritten, and the success rate of version tracing is low; the ability to manage schemas in multiple environments is insufficient, data pollution between environments is possible, and there are stability risks; code generation requires multiple manual steps, the process is cumbersome and prone to errors; application dependencies lack unified management, manual maintenance is prone to omissions or version inconsistencies; integration with external systems such as Git, CI / CD, and material platforms depends on manual operation, resulting in low automation.

[0037] Therefore, there is an urgent need for a schema-driven application management method to achieve independent version management of schema data in multiple environments and full-process automation from configuration to deployment, thereby improving the traceability, environment isolation and delivery efficiency of application management.

[0038] It should be noted that the methods described in the embodiments of this application can be executed by one or more computing devices (such as servers, terminal devices, or distributed systems). For ease of description, the entity executing the methods will be collectively referred to as the "system" below. The system implements the method steps described in the embodiments of this application by loading and executing a computer program.

[0039] The following is combined Figure 1 This application introduces a schema-driven application management method based on an embodiment of the present application.

[0040] refer to Figure 1 , Figure 1 An exemplary embodiment of this application provides a schema-driven application management method, which includes the following steps: Step S101: Receive a schema saving request for the target application.

[0041] The schema save request includes page identifiers, schema data, and target environment identifiers.

[0042] The page identifier is used to determine which page is currently being edited. The schema data is the latest page configuration data generated by the user in the visual editor by dragging and dropping components and configuration properties. The target environment identifier is used to indicate whether the current save operation is for the development environment (dev), the test environment (test), or the production environment (prod).

[0043] In real-world low-code platform use cases, an application typically contains multiple pages, each potentially at different development stages in different environments—for example, the homepage might be in a stable production version while undergoing refactoring in the development environment. Therefore, both page identifiers and environment identifiers are needed to jointly determine the current save context. Upon receiving a save request, the system first verifies the validity of the request parameters, including checking the existence of the page identifier, whether the schema data format conforms to the preset data protocol specifications, and whether the target environment identifier is an allowed environment value. Only after successful verification can the system proceed to subsequent steps.

[0044] Step S102: Determine the current schema version number of the target application in the target environment based on the page identifier and the target environment identifier.

[0045] The system uses the page identifier and the target environment identifier as joint query conditions to retrieve the latest saved schema version record of the page in the specified environment from the database.

[0046] Specifically, the system performs a query to find schema records that match the page identifier and the target environment identifier, and sorts them in descending order according to the combination of major version number, minor version number, and patch version number. The record with the highest ranking is selected as the current version. If the page has not saved any schema version in the specified environment, the current version number is empty.

[0047] By combining page identifiers with target environment identifiers as query criteria, the version chains of each environment are ensured to be independent of each other—the query results of the development environment will not be affected by the records saved in the test or production environments, thus avoiding data pollution between different environments.

[0048] In real-world applications, the version number of the same page may differ significantly in different environments: for example, the development environment may have iterated to version 0.3.5 (after multiple modifications), while the production environment remains at version 1.0.0 (stable version), without interfering with each other.

[0049] Step S103: Generate a new version number based on the current Schema version number.

[0050] The new version number includes the major version number, minor version number, and patch version number.

[0051] If the current version number retrieved in step S102 is empty (i.e., the first time it is saved), then the new version number is set to the preset initial version number (e.g., 0.0.1).

[0052] If the current version number exists, the system adopts a different version number increment strategy based on the target environment identifier: when the target environment identifier indicates a production environment, it means that this save corresponds to a feature iteration release. The system increments the minor version number of the current version number by 1, resets the patch version number to 0, and keeps the major version number unchanged. For example, if the current version number is 1.0.1, the new version number will be 1.1.0.

[0053] The logic behind this approach is that each release in the production environment typically represents a milestone in a feature iteration (the launch of a new feature). Increasing the minor version number reflects the accumulation of features, while resetting the patch version number to zero means that the patch count for that feature version starts again.

[0054] When the target environment identifier indicates a development or testing environment, it means that this save will contain changes made during the development process or for testing and verification. The system will only increment the patch version number by 1, while the major and minor version numbers will remain unchanged. For example, if the current version number is 0.3.5, the new version number will be 0.3.6.

[0055] Since save operations in development and testing environments are frequent and typically do not involve official releases, simply incrementing the patch version number is sufficient to meet the basic requirements for modification counting and version differentiation, without consuming minor version number resources. This differentiated version number generation strategy allows production environment version numbers to reflect feature iteration milestones, while development and testing environment version numbers reflect modification frequency, achieving unified semantic management of version number meaning across different environments.

[0056] In high-concurrency scenarios, multiple users may simultaneously save the schema of the same page within the same environment. The system implements concurrency conflict detection through database unique index constraints (a combination of page identifier, environment identifier, major version number, minor version number, and patch version number).

[0057] When two save requests arrive almost simultaneously, the system may generate the same new version number. However, the later-submitted request will trigger a unique index conflict exception when writing to the database. After catching this exception, the system automatically re-executes the version number query and generation logic, automatically increments the patch version number, and then re-attempts to write, thereby ensuring that each save request obtains a unique version number and no data is lost in concurrent scenarios.

[0058] Step S104: Associate the schema data with the new version number and store them according to the target environment identifier.

[0059] The system establishes an association between the schema data received in step S101 and the new version number generated in step S103, and then stores the data in the corresponding storage area according to the value of the target environment identifier.

[0060] In its implementation, the system first structurally splits the schema data: the component map (componentsMap) records the configuration information of each component used on the page, including the component's identifier, type, attribute settings, style configuration, event binding, etc. This part of the data will be specifically read during dependency resolution to extract component reference information; the component tree (componentsTree) records the hierarchical structure and nesting relationship of each component, including the parent-child relationship, sibling order, slot position, etc. This part of the data is used to determine the rendering order and layout structure of the components during code generation; the other configuration part (other) records the page's metadata information, including page name, page route, background settings, global style variables, API data source configuration, and other configuration information that does not belong to the component map and component tree.

[0061] The three parts of data are split and stored in their respective data tables. Then, a master record (component_schema table) is created. This master record stores the page identifier, the new version number (the major version number, minor version number, and patch version number are stored in their respective numeric fields), and the target environment identifier (tag field). It also records the identifiers of the three parts of data in the master table (mapId, treeId, otherId).

[0062] By using these three identifiers in the master record, the three parts of data that were previously stored separately are re-associated into a complete schema record. Data in each environment uses the same table partitioning structure during storage, but is distinguished by the environment identifier field in the master record, ensuring logical isolation between the data in different environments. This partitioned storage method offers significant performance advantages compared to storing the complete schema as a single JSON field: firstly, in dependency resolution scenarios, the system can directly read the componentsMap table without loading and parsing the entire schema's JSON data, greatly reducing I / O overhead and JSON parsing time; secondly, when only a portion of the configuration is modified, only the corresponding sub-table needs to be updated, without rewriting the entire dataset, improving update efficiency.

[0063] Step S105: Save the association between the schema data and the target application, page identifier, new version number, and target environment identifier.

[0064] After completing the splitting and storage of schema data, the system saves or updates the association between the target application and page identifier, new version number, and target environment identifier.

[0065] Specifically, the system stores the associated information, including the target application identifier (associated with the application through the page identifier), page identifier, new version number (major version number, minor version number, and patch version number), and target environment identifier, in the database, thereby establishing a precise mapping between schema data and the four dimensions of target application, page, version, and environment.

[0066] This association is the core data structure supporting the multi-environment version management mechanism of this application. On the one hand, it enables the rapid querying of all pages of the application and their corresponding schema versions in a specified environment based on the target application identifier and the target environment identifier, providing precise data location capabilities for the code generation process. On the other hand, through the combination of page identifier and version number, the system can accurately trace back to the schema configuration of any historical version, solving the problem of low version tracing success rate in existing technologies. In practical application scenarios, when a user needs to roll back to a certain historical version, the system can quickly locate the schema data of the corresponding version through this association, thereby realizing the version rollback operation.

[0067] In one alternative implementation, the system first needs to create the target application before receiving a schema save request for the target application. The system receives an application creation request, which includes the application name, application code, application description, and business module identifier.

[0068] The system validates request parameters: the application name is not empty, the application code is not empty and unique (no duplicate application codes exist in the database), and the business module corresponding to the business module identifier exists. After successful validation, the system constructs the application entity object, sets the application's basic information (name, code, description), establishes a foreign key relationship between the application and the business module through the business module identifier, and sets the creation and modification times to the current timestamp. The system uses TypeORM's insert method to persist the application entity to the database, transaction processing ensures data consistency, and exception handling captures and processes database errors, returning user-friendly prompts.

[0069] After successful application creation, the system returns the application ID and basic information. Subsequent schema saving operations will be associated with this application. By establishing the relationship between applications and business modules, the system supports a multi-tenant application isolation architecture—application data from different business modules is naturally isolated. Queries only require filtering by business module identifier; users of a particular module cannot see applications from other modules, providing a data foundation for subsequent access control, statistics, and billing. The `createTime` and `modifyTime` timestamp fields record the application's creation and last modification times, providing a complete timeline archive for data traceability and lifecycle management.

[0070] In one optional implementation, this application embodiment further includes a schema data acquisition step, used to receive a code generation request and acquire schema data.

[0071] Step S106: Receive a code generation request for the target application and obtain Schema data based on the target application identifier and the target environment identifier.

[0072] After saving the schema data and establishing the relationships, when a user needs to generate runnable source code from the schema configuration, the system receives a code generation request for the target application. This request includes the target application identifier and the target environment identifier. Using the target application identifier and the target environment identifier as query conditions, the system retrieves all page schema data for that application in the specified environment from the database. Because a precise relationship has been established between the target application, page, version, and environment in step S105, the system can accurately locate the schema version of each page in the target environment. If a page does not have a corresponding schema version in the target environment, the system performs fallback processing according to priority: it prioritizes using the schema of the target environment; if it does not exist, it uses the schema version of the production environment as a fallback, ensuring that the code generation process is not interrupted due to the lack of environment data for some pages.

[0073] In an alternative implementation, this application embodiment further includes a step of traversing the component mapping portion of the schema and resolving dependencies.

[0074] Step S107: Traverse the component mapping portion of the Schema data, extract component reference information, and generate dependency configuration.

[0075] After obtaining the complete schema data in the target environment, the system begins the dependency resolution process. First, the system iterates through the component mapping section (componentsMap) of each page's schema data, extracting component reference information from each component record. This includes at least the component identifier and the component version requirement. The component identifier uniquely identifies a component, and the component version requirement may be a specific version number (e.g., "1.2.3") or "latest" (indicating the latest version). Since the same component may be referenced multiple times in different locations on the same page, or repeatedly referenced on different pages, the system performs deduplication on the extracted component reference information—grouping it by component identifier and retaining only one record for each component to avoid sending duplicate query requests to the material platform later.

[0076] After deduplication is complete, the system constructs a query request containing a list of deduplicated component identifiers and sends this request to the material platform. The material platform is an internal system for unified management of component releases, storing metadata information for each component, including the component's corresponding npm package name, the latest version currently released, a list of historical versions, and the component type (public or private). The system receives the actual release information for each component from the material platform, which includes at least the component's corresponding package name and package version.

[0077] Subsequently, the system generates the dependency configuration for the target application based on the component version requirements and the actual release information returned by the material platform. Specifically: when the component version requirement is "latest", the system directly uses the latest version returned by the material platform as the dependency version; when the component version requirement specifies a specific version and the material platform has that version, the system uses the user-specified version; when the component version requirement specifies a specific version but the material platform does not have that version, the system uses the latest version returned by the material platform and records the version difference warning for developers to evaluate whether to upgrade later.

[0078] In one optional implementation, after generating the dependency configuration for the target application, a private component processing step is also included: the system identifies the private component identifier in the component reference information. For components identified as private components (i.e., components developed internally and not publicly released to the public npm repository), the system does not add them to the public dependency list in package.json, but instead configures them as internal reference paths—specifically, setting dependencyType to "Internal" and moduleName to the internal component path in the application configuration. In this way, the generated dependency configuration can correctly handle the differences in referencing methods between private and public components, avoiding build failures caused by mistakenly installing private components as public npm packages.

[0079] In one optional implementation, this application embodiment further includes the step of calling a code generation engine to generate source code and triggering a release process.

[0080] Step S108: Generate source code based on the obtained schema data and dependency configuration, and push it to the Git version control system to trigger the CI / CD build task.

[0081] After completing dependency resolution and generating dependency configurations, the system automatically triggers the code generation and deployment process. First, based on the schema data obtained in step S106 and the dependency configurations generated in step S107, the system calls the code generation engine to generate the complete source code of the target application.

[0082] The code generation engine reads the component tree portion of the schema to determine the page structure and component hierarchy, reads the component mapping portion to determine the specific configuration of each component, and combines the dependency configuration to generate project files containing complete dependency relationships, including page code files, package.json configuration files, project configuration files, etc.

[0083] In one optional implementation, the code generation engine supports two deployment strategies: ZIP package and disk deployment. The ZIP package method is suitable for scenarios where developers need to manually review or deploy offline—the system packages the generated complete project files into a ZIP archive, stores it in a temporary directory, and provides a download link for developers. The disk deployment method is suitable for automated deployment scenarios—the system directly writes the generated project files to a specified disk path and then automatically performs the following Git push operation.

[0084] Once the source code is generated, the system automatically performs a Git push operation: pushing the generated source code to the target branch of the Git version control system associated with the target application. Different environments correspond to different branches (e.g., the dev branch for the development environment, the test branch for the testing environment, and the master / main branch for the production environment). The system automatically selects the corresponding target branch based on the target environment identifier in the code generation request. The push operation automatically executes commands such as git add, git commit (the commit message includes the schema version number for easy tracking), and git push, requiring no manual operation from the user.

[0085] After a successful Git push, the system automatically triggers the build task of the continuous integration / continuous deployment system via the API interface.

[0086] Specifically, the system builds build parameters that include target branch information and target environment identifiers, and sends a build request to CI / CD systems such as Jenkins. After receiving the request, the CI / CD system pulls the latest code from the specified branch and performs operations such as dependency installation, code compilation, automated testing, application packaging, and deployment.

[0087] In one alternative implementation, after pushing the generated source code to the target branch of the Git version control system, this embodiment of the application further includes a step of polling the build task status of the continuous integration / continuous deployment system.

[0088] To provide users with real-time deployment progress updates, the system initiates a status polling process after triggering a CI / CD build task: periodically querying the CI / CD system for the build task status; when the build task is completed, updating the deployment status flag of the target application based on the build result (success or failure), and notifying the user of the build result. The entire process, from the user clicking "Build and Publish" to receiving the deployment result notification, achieves a fully automated closed loop.

[0089] Based on the foregoing description, in this embodiment of the application, a schema save request containing a page identifier, schema data, and a target environment identifier is received. The current version number is queried using the page identifier and the target environment identifier as joint conditions. A new version number is generated by adopting a differentiated version number increment strategy based on the different target environment identifiers (upgrading the minor version number and resetting the patch version number in the production environment, and only upgrading the patch version number in the development / test environment). The schema data is then split, associated with the new version number, and stored separately according to the environment. Finally, the association relationship between the target application, page identifier, new version number, and target environment identifier is saved.

[0090] In the embodiments of this application, the above technical solution achieves the following technical effects: First, in terms of version management, by generating an independent version number for each save and establishing a precise association mapping, each historical version can be accurately located and traced back, completely solving the problem of historical versions being overwritten and untraceable in existing technologies.

[0091] Secondly, in terms of environmental isolation, by storing and independently maintaining the version chain of each environment according to the target environment identifier, the schema data of the development environment, testing environment and production environment are completely isolated, eliminating the risk of data pollution between environments.

[0092] Third, in terms of automation, the structured associated version management mechanism provides a standardized data query interface and a reliable data source for the subsequent accurate acquisition of schema versions by environment, enabling the reliable implementation of full-process automation from schema configuration to code generation, Git push, and CI / CD triggering.

[0093] Fourth, in terms of dependency management, the precise schema version management mechanism provides the correct schema data source and complete version traceability capability for the automatic resolution of component dependencies. This enables the system to automatically extract component reference information based on the correct schema version and link with the material platform, solving the problems of easy omission and version inconsistency when manually maintaining dependencies.

[0094] Fifth, in terms of process reliability, this mechanism ensures that the code generation and CI / CD triggering processes can obtain the corresponding schema version for the correct environment, guaranteeing the reliable execution of the entire automated process and avoiding deployment errors caused by version confusion.

[0095] Based on the same inventive concept, embodiments of this application provide a schema-driven application management device, please refer to... Figure 2 The device includes: The request receiving unit 201 is used to receive a schema saving request for the target application. The schema saving request includes page identifier, schema data and target environment identifier.

[0096] Version determination unit 202 is used to determine the current schema version number of the target application in the target environment based on the page identifier and the target environment identifier.

[0097] Version generation unit 203 is used to generate a new version number based on the current schema version number. The new version number includes the major version number, minor version number, and patch version number.

[0098] The associated storage unit 204 is used to associate the schema data with the new version number and store them separately according to the target environment identifier; it saves the association relationship between the schema data and the target application, page identifier, new version number and target environment identifier.

[0099] The schema-driven application management device provided in this application embodiment has the same beneficial effects as the schema-driven application management method in the above embodiments, and will not be described in detail here.

[0100] Having introduced the schema-driven application management method and schema-driven application management device according to exemplary embodiments of this application, the electronic device provided according to embodiments of this application will now be described.

[0101] This application provides an electronic device that can implement the schema-driven application management method described above. Please refer to... Figure 3 The device includes a memory 301, a processor 302, and a bus 303.

[0102] The memory 301 is used to store computer programs executed by the processor 302. The memory 301 may mainly include a program storage area and a data storage area. The program storage area may store the operating system and programs required to run instant messaging functions, etc.; the data storage area may store various instant messaging information and operation instruction sets, etc.

[0103] Memory 301 may be volatile memory, such as random-access memory (RAM); memory 301 may also be non-volatile memory, such as read-only memory, flash memory, hard disk drive (HDD), or solid-state drive (SSD); or memory 301 may be any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto. Memory 301 may be a combination of the above-mentioned memories.

[0104] The processor 302 may include one or more central processing units (CPUs) or digital processing units, etc. The processor 302 is used to implement the schema-driven application management method described in the above embodiments when it invokes a computer program stored in the memory 301.

[0105] This application embodiment does not limit the specific connection medium between the memory 301 and the processor 302 described above. This application embodiment... Figure 3 The memory 301 and the processor 302 are connected via a bus 303, and the bus 303 is in Figure 3 The connections between other components are shown in thick lines only and are not intended to be limiting. Bus 303 can be divided into address bus, data bus, control bus, etc. For ease of illustration, Figure 3 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0106] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium. The computer program product includes computer program code, which, when executed on a computer, causes the computer to perform any of the schema-driven application management methods discussed above. Since the principle by which the above-described computer-readable storage medium solves the problem is similar to that of the schema-driven application management method, the implementation of the above-described computer-readable storage medium can be found in the implementation of the method; repeated details will not be elaborated further.

[0107] Based on the same inventive concept, this application also provides a computer program product, which includes computer program code. When the computer program code is run on a computer, it causes the computer to execute any of the schema-driven application management methods discussed above. Since the principle by which the above computer program product solves the problem is similar to that of the schema-driven application management method, the implementation of the above computer program product can refer to the implementation of the method, and repeated details will not be described again.

[0108] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0109] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0110] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0111] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of user-operated steps to be executed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1The steps of the function specified in one or more boxes.

[0112] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A schema-driven application management method, characterized in that, include: Receive a schema save request for the target application, the schema save request including page identifier, schema data and target environment identifier; Based on the page identifier and the target environment identifier, determine the current schema version number of the target application in the target environment; A new version number is generated based on the current schema version number, and the new version number includes a major version number, a minor version number, and a patch version number. Associate the schema data with the new version number and store them according to the target environment identifier; Save the association between the schema data and the target application, the page identifier, the new version number, and the target environment identifier.

2. The method according to claim 1, characterized in that, The step of generating a new version number based on the current schema version number includes: When the target environment identifier indicates a production environment, increment the minor version number by 1 and reset the patch version number to 0; When the target environment identifier represents a development environment or a test environment, increment the patch version number by 1.

3. The method according to claim 1, characterized in that, The step of associating the schema data with the new version number and storing it according to the target environment identifier includes: The schema data is divided into a component mapping part, a component tree part, and other configuration parts according to a preset data structure; The split parts are stored in their respective data tables and associated with each part through a master record. The master record contains the page identifier, the new version number, and the target environment identifier. The page identifier is used to associate with the target application.

4. The method according to claim 1, characterized in that, After saving the association between the schema data and the target application, the page identifier, the new version number, and the target environment identifier, the method further includes: Receive a code generation request for the target application, the code generation request containing a target application identifier and a target environment identifier; Based on the target application identifier and the target environment identifier, obtain the schema data of the target application in the target environment.

5. The method according to claim 4, characterized in that, After obtaining the schema data of the target application in the target environment, the method further includes: Traverse the component mapping portion of the schema data and extract component reference information, which includes component identifier and component version requirements; The extracted component reference information is deduplicated; Send a query request to the material platform, the query request containing a list of deduplicated component identifiers; Receive the actual release information of each component returned by the material platform, wherein the actual release information includes the package name and package version corresponding to the component; Based on the component version requirements and the actual release information, generate the dependency configuration for the target application.

6. The method according to claim 5, characterized in that, The dependency configuration for generating the target application includes: When the component version requirement indicates the use of the latest version, the package version returned by the material platform is determined as the dependent version; When the component version requires a specified version and the material platform has that version, the specified version will be determined as the dependent version; When the component version requires a specified version but the material platform does not have that version, use the latest version returned by the material platform and record the version difference prompt.

7. The method according to claim 5, characterized in that, After generating the dependency configuration for the target application, the process also includes: Identify the private component identifier in the component reference information; For components identified as private components, configure the component as an internal reference path.

8. The method according to claim 5, characterized in that, After generating the dependency configuration, the process also includes: Based on the obtained schema data and the dependency configuration, the code generation engine is invoked to generate the source code of the target application; The generated source code is pushed to the target branch of the Git version control system associated with the target application; The build task of the continuous integration / continuous deployment system is triggered through the API interface. The build task includes information about the target branch and the target environment identifier.

9. The method according to claim 8, characterized in that, After pushing the generated source code to the target branch of the Git version control system associated with the target application, the process further includes: Poll the build task status of the continuous integration / continuous deployment system; When the build task is completed, the deployment status flag of the target application is updated according to the build result.

10. A schema-driven application management device, characterized in that, The device includes: The request receiving unit is used to receive a schema saving request for the target application, wherein the schema saving request includes a page identifier, schema data and a target environment identifier; The version determination unit is used to determine the current schema version number of the target application in the target environment based on the page identifier and the target environment identifier; A version generation unit is used to generate a new version number based on the current schema version number, wherein the new version number includes a major version number, a minor version number, and a patch version number; An associated storage unit is used to associate the schema data with the new version number and store them separately according to the target environment identifier; it saves the association relationship between the schema data and the target application, the page identifier, the new version number and the target environment identifier.

Images