Modular development lifecycle management method, system, and apparatus based on hot updates

By verifying and predicting algorithms in an isolated environment to determine the minimum impact time, the modular development lifecycle is managed automatically, solving the problem of low automation in existing technologies and achieving efficient and reliable module updates.

CN121233155BActive Publication Date: 2026-04-21CHENGDU DACHENG JUNTU TECH CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
CHENGDU DACHENG JUNTU TECH CO LTD
Filing Date
2025-12-03
Publication Date
2026-04-21

AI Technical Summary

Technical Problem

The existing modular development lifecycle management based on hot updates has a low degree of automation, requires a lot of manual operation, and makes the update process cumbersome and error-prone. In addition, the hot update deployment process is not tightly integrated with the continuous integration and continuous delivery processes.

Method used

By dynamically loading and verifying the target module in a preset isolated environment, and using a prediction algorithm to determine the minimum impact time for automated updates based on the module's call data and dependency data, hot updates and registration of the module are achieved.

Benefits of technology

It improves the automation level of modular development lifecycle management, reduces manual operations, optimizes module update time, and reduces the impact on system stability.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121233155B_ABST
    Figure CN121233155B_ABST
Patent Text Reader

Abstract

This application discloses a method, system, and device for modular development lifecycle management based on hot updates. The method includes: dynamically loading and verifying the target module in a preset isolated environment in response to detecting a target module in a module repository; registering the target module in the target system when it passes verification; obtaining the target functional module corresponding to the target module in the target system based on the target module and the target system; obtaining the call data and / or dependency data of the target functional module based on the target functional module; obtaining the target time based on the call data and / or dependency data of the target functional module using a preset prediction algorithm; and loading the target module into the target system to replace the original module used by the target functional module based on the target time. This solves the problem of low automation and significant manual operation required in existing hot-update-based modular development lifecycle management technologies.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of software development technology, and in particular to a modular development lifecycle management method, system and device based on hot updates. Background Technology

[0002] With the continuous development of modern software development, hot updates and modular development have become important technical means to improve development efficiency and reduce maintenance costs. Hot updates allow developers to dynamically update certain modules or functions in a program without restarting the application, which is significant for improving system stability and user experience. Modular development, by breaking down an application into multiple independent modules, makes the development, testing, deployment, and maintenance of each module more flexible and efficient. The combination of these technologies has significantly optimized many aspects of the development lifecycle. However, despite the many benefits brought by hot updates and modular development, the level of automation in existing solutions remains low, leading to some problems in development and operation.

[0003] In current hot update and modular development solutions, the hot update process often relies on manual operation, requiring developers to manually manage module versions, dependencies, and update strategies. This approach not only increases the possibility of human error but also makes each update process tedious and prone to mistakes. Furthermore, the hot update deployment process is not fully integrated with continuous integration and continuous delivery (CI / CD) processes, resulting in a lack of complete automation. In some cases, developers still need to intervene manually for each update, wasting significant time and effort. Summary of the Invention

[0004] This invention provides a method, system, and device for modular development lifecycle management based on hot updates, and offers a more automated modular development lifecycle management solution based on hot updates. It at least solves the problem that existing modular development lifecycle management based on hot updates requires a large amount of manual operation and has a low degree of automation.

[0005] This application provides a modular development lifecycle management method based on hot updates, including:

[0006] In response to the detection of a target module in the module repository, the target module is dynamically loaded and verified in a preset isolation environment, and the target module is configured as a newly uploaded module in the module repository;

[0007] When the target module passes verification, the target module is registered to the target system;

[0008] Based on the target module and the target system, obtain the target functional module in the target system that corresponds to the target module;

[0009] Based on the target functional module, obtain the call data and / or dependency data of the target functional module;

[0010] Based on the call data and / or dependency data of the target functional module, a target time is obtained based on a preset prediction algorithm. The target time is configured as the time during which the target functional module has the least impact on the target system within the update period specified by the target module.

[0011] Based on the target time, the target module is loaded into the target system to replace the original module used by the target functional module.

[0012] Optionally, before the step of dynamically loading the target module in a preset isolated environment and verifying the target module in response to detecting the presence of a target module in the module repository, the method further includes:

[0013] In response to receiving a module upload request from the module repository, obtain the name and digital signature of the module to be uploaded;

[0014] The module to be uploaded is verified based on its name and digital signature.

[0015] When the module to be uploaded passes verification, it is allowed to be uploaded to the module repository as a target module.

[0016] Optionally, the step of verifying the module to be uploaded based on its name and digital signature includes:

[0017] Based on the name of the module to be uploaded, obtain the first functional module corresponding to the name of the module to be uploaded;

[0018] Based on the digital signature of the module to be uploaded, a second functional module corresponding to the digital signature of the module to be uploaded is obtained. The digital signature is configured to be generated during the development of the module to be uploaded based on the module template selected by the module to be uploaded.

[0019] The verification is performed based on the first functional module and the second functional module. The module to be uploaded passes the verification only if the first functional module and the second functional module are the same module.

[0020] Optionally, obtaining the call data and / or dependency data of the target functional module based on the target functional module includes:

[0021] Based on the target functional module, obtain the log data of the target functional module;

[0022] Based on the log data of the target functional module, obtain the call data and / or dependency data of the target functional module.

[0023] Optionally, obtaining the target time based on the call data and / or dependency data of the target functional module, using a preset prediction algorithm, includes:

[0024] Based on the call data of the target functional module, and using a preset prediction algorithm, the first call prediction data of the target functional module within the specified update period of the target module is obtained;

[0025] Based on the dependency data of the target functional module, and using a preset prediction algorithm, the second call prediction data of the associated modules of the target functional module within the update period specified by the target module is obtained.

[0026] The target time is obtained based on the first call prediction data and the second call prediction data.

[0027] Optionally, obtaining the target time based on the first call prediction data and the second call prediction data includes:

[0028] The first weight is obtained based on the total number of calls to the target functional module;

[0029] The second weight is obtained based on the total number of calls to the associated modules of the target functional module;

[0030] Based on the first call prediction data, the first weight of the second call prediction data, and the second weight, a target time is obtained based on a sliding time window, wherein the duration of the sliding time window is not less than the time required to load the target module into the target system.

[0031] Optionally, based on the first call prediction data, the first weight of the second call prediction data, and the second weight, a target time is obtained using a sliding time window, including:

[0032] Based on the first call prediction data, the first weight of the second call prediction data, and the second weight, the total weight within each sliding time window is calculated based on the sliding time window.

[0033] The target time window is the time window in which the total weight within the sliding time window meets the preset conditions.

[0034] Obtain the target time based on the start time of the target time window.

[0035] Optionally, after the step of loading the target module into the target system to replace the target functional module according to the target time, the method further includes:

[0036] Based on the call data and / or dependency data of the target functional module, obtain the original stability index of the target functional module;

[0037] The target stability index of the target module is obtained based on the call data and / or dependency data of the target module;

[0038] Based on the original stability index and the target stability index, determine whether a rollback is necessary.

[0039] On the other hand, a modular development lifecycle management system based on hot updates includes a module management platform and a module repository;

[0040] The module management platform is configured as follows:

[0041] In response to the detection of a target module in the module repository, the target module is dynamically loaded and verified in a preset isolation environment, and the target module is configured as a newly uploaded module in the module repository;

[0042] When the target module passes verification, the target module is registered to the target system;

[0043] Based on the target module and the target system, obtain the target functional module in the target system that corresponds to the target module;

[0044] Based on the target functional module, obtain the call data and / or dependency data of the target functional module;

[0045] Based on the call data and / or dependency data of the target functional module, a target time is obtained based on a preset prediction algorithm. The target time is configured as the time during which the target functional module has the least impact on the target system within the update period specified by the target module.

[0046] Based on the target time, load the target module into the target system to replace the original module used by the target functional module;

[0047] The module repository is configured as follows:

[0048] Modules that receive and store data uploaded by users or other devices.

[0049] In another aspect, embodiments of this application also provide an apparatus including a memory and a processor, wherein the memory stores a computer program and the processor executes the computer program to implement the above-described method.

[0050] In another aspect, embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein a processor executes the computer program to implement the above-described method.

[0051] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0052] This invention discloses a modular development lifecycle management method, system, and device based on hot updates. The method includes: responding to the detection of a target module in a module repository; dynamically loading and verifying the target module in a preset isolated environment; configuring the target module as a newly uploaded module in the module repository; registering the target module in a target system when it passes verification; obtaining a target functional module corresponding to the target module in the target system based on the target module and the target system; obtaining the call data and / or dependency data of the target functional module based on the target functional module; obtaining a target time based on the call data and / or dependency data of the target functional module using a preset prediction algorithm; the target time being configured as the time within the update period specified by the target module where the target functional module has the least impact on the target system; and loading the target module into the target system to replace the original module used by the target functional module based on the target time. This invention solves the problem of low automation and extensive manual operation required in existing modular development lifecycle management based on hot updates. Attached Figure Description

[0053] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. In all the drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn to scale.

[0054] Figure 1 This is a flowchart illustrating a modular development lifecycle management method based on hot updates in this application.

[0055] Figure 2 This is a schematic diagram of the structure of one of the devices in this application;

[0056] The diagram is labeled as follows: 101-Processor, 102-Communication bus, 103-Network interface, 104-User interface, 105-Memory.

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

[0058] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present application.

[0059] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0060] Example 1

[0061] like Figure 1 As shown, a modular development lifecycle management method based on hot updates includes:

[0062] S1. In response to the detection of a target module in the module repository, dynamically load the target module in a preset isolation environment and verify the target module.

[0063] Specifically, the target module is configured as the module newly uploaded to the module repository.

[0064] In this embodiment, the main purpose of this step is to identify the target modules that the target system needs to load and hot-update. First, a detection mechanism is needed to monitor newly uploaded modules in the module repository. This detection mechanism can be a periodic scan or a real-time trigger via a webhook when a module is uploaded. After a new module is discovered, it is loaded into an isolated environment, usually a sandbox environment, which is independent of the actual production system, in order to verify it.

[0065] Optionally, the isolation environment can be the isolation environment corresponding to the target system, or it can be an isolation environment shared by multiple systems including the target system.

[0066] Specifically, verification can include: analyzing the structure, dependencies, and coding standards of the module code; running unit tests; checking the module's performance; and checking for potential security vulnerabilities.

[0067] S2. When the target module passes verification, register the target module into the target system.

[0068] In this embodiment, the registration process typically includes:

[0069] Module metadata recording: Record the module's metadata, such as version, dependencies, and feature descriptions, into the system's module registry.

[0070] Interface matching: Confirm the compatibility of the target module with the existing modules in the target system to ensure that it can replace or work together normally;

[0071] Version management: If the target module is an update to an existing module, the system needs to track its version number to ensure that the system maintains appropriate version control.

[0072] S3. Based on the target module and the target system, obtain the target functional module in the target system that corresponds to the target module.

[0073] In this embodiment, the main purpose of this step is to obtain the target functional module corresponding to the target module in the target system through the name or description of the target module.

[0074] S4. Based on the target functional module, obtain the call data and / or dependency data of the target functional module.

[0075] In this embodiment, the main purpose of this step is to obtain the interface information of the target functional module being called by other modules through the logs of the target functional module, analyze the data flow, and confirm which modules or system components will be affected by the target module; by obtaining the dependency chain of the target system, analyze the dependency data of the target functional module, obtain its relationship with other modules, and ensure that the introduction of the target module will not disrupt the existing dependency chain.

[0076] S5. Based on the call data and / or dependency data of the target functional module, obtain the target time using a preset prediction algorithm.

[0077] Specifically, the target time is configured as the time within the update period specified by the target module when the target functional module has the least impact on the target system.

[0078] In this embodiment, the main purpose of this step is to use a prediction algorithm to calculate an optimal update time period based on factors such as historical data, system load, and peak business periods. This time period should be a period with low system load and low user activity, so as to minimize the impact of the update on the system. The prediction algorithm can predict the optimal update time based on data such as traffic prediction, user activity, and system logs.

[0079] S6. Based on the target time, load the target module into the target system to replace the original module used by the target functional module.

[0080] In this embodiment, the main purpose of this step is to load the target module into the production environment within the selected target time period.

[0081] After the replacement is completed, the target module is tested and monitored to ensure that the new module runs normally and has no performance issues, errors or security vulnerabilities.

[0082] By adopting the above solution, hot updates of modules are achieved by automatically pulling target modules from the module library. At the same time, the impact of module updates on the stable operation of the system can be reduced. This solves the problem that existing technologies based on hot updates require a lot of manual operation and have a low degree of automation in the modular development lifecycle management.

[0083] Example 2

[0084] This embodiment, based on Embodiment 1, provides a modular development lifecycle management method based on hot updates, including:

[0085] S1. In response to the detection of a target module in the module repository, dynamically load the target module in a preset isolation environment and verify the target module.

[0086] Specifically, the target module is configured as the module newly uploaded to the module repository.

[0087] Optionally, before the step of dynamically loading the target module in a preset isolated environment and verifying the target module in response to detecting the presence of the target module in the module repository, the method further includes:

[0088] In response to receiving a module upload request from the module repository, obtain the name and digital signature of the module to be uploaded;

[0089] The module to be uploaded is verified based on its name and digital signature;

[0090] When the module to be uploaded passes the verification, it is allowed to be uploaded to the module repository as the target module.

[0091] Optionally, the module to be uploaded can be verified based on its name and digital signature, including:

[0092] Based on the name of the module to be uploaded, obtain the first functional module corresponding to the name of the module to be uploaded;

[0093] Based on the digital signature of the module to be uploaded, obtain the second functional module corresponding to the digital signature of the module to be uploaded. The digital signature is configured to be generated during the development of the module to be uploaded based on the module template selected by the module to be uploaded.

[0094] The verification is performed based on the first functional module and the second functional module. The module to be uploaded will pass the verification only if the first functional module and the second functional module are the same module.

[0095] Specifically, all standard-compliant modules are developed in a pre-defined isolated environment. The development process relies solely on predefined interfaces. When developing a target module, the user first needs to select the corresponding functional module. Then, the corresponding interface is loaded based on the functional module of the target module. After development is complete, a digital signature is generated for the target module based on the functional module selected by the user.

[0096] Specifically, Mock or Stub techniques are used to handle external dependencies during the development process.

[0097] S2. When the target module passes verification, register the target module into the target system.

[0098] S3. Based on the target module and the target system, obtain the target functional module in the target system that corresponds to the target module.

[0099] Optionally, the target functional module corresponding to the target module in the target system can be obtained through semantic versioning, the name of the target module, or a description of other target modules.

[0100] S4. Based on the target functional module, obtain the call data and / or dependency data of the target functional module.

[0101] Optionally, based on the target functional module, obtain the call data and / or dependency data of the target functional module, including:

[0102] Based on the target functional module, obtain the log data of the target functional module;

[0103] Based on the log data of the target functional module, obtain the call data and / or dependency data of the target functional module.

[0104] S5. Based on the call data and / or dependency data of the target functional module, obtain the target time using a preset prediction algorithm.

[0105] Specifically, the target time is configured as the time within the update period specified by the target module when the target functional module has the least impact on the target system.

[0106] Optionally, based on the call data and / or dependency data of the target functional module, and using a preset prediction algorithm, the target time is obtained, including:

[0107] Based on the call data of the target functional module, and using a preset prediction algorithm, the first call prediction data of the target functional module within the specified update period of the target module is obtained.

[0108] Based on the dependency data of the target functional module, and using a preset prediction algorithm, the second call prediction data of the related modules of the target functional module within the specified update period of the target module is obtained.

[0109] The target time is obtained based on the prediction data from the first and second calls.

[0110] Optionally, the target time is obtained based on the first call prediction data and the second call prediction data, including:

[0111] The first weight is determined based on the total number of calls to the target functional module;

[0112] The second weight is obtained based on the total number of calls to the associated modules of the target functional module;

[0113] Based on the first call prediction data, the second call prediction data, the first weight, and the second weight, the target time is obtained based on a sliding time window. The duration of the sliding time window is not less than the time required to load the target module into the target system.

[0114] Optionally, based on the first call prediction data, the second call prediction data, the first weight, and the second weight, and using a sliding time window, the target time is obtained, including:

[0115] Based on the first call prediction data, the second call prediction data, the first weight, and the second weight, the total weight within each sliding time window is calculated based on the sliding time window.

[0116] The target time window is the time window in which the total weight within the sliding time window meets the preset conditions.

[0117] Obtain the target time based on the start time of the target time window.

[0118] Specifically, the first and second call prediction data are discrete time series data. The unit time is determined according to the time required to load the target module into the target system. For example, when the time required to load the target module into the target system is tens of minutes, the unit time is 1 minute. When the time required to load the target module into the target system is several hours, the unit time is 10 minutes, 15 minutes, or 30 minutes, etc.

[0119] Specifically, based on the total number of calls to the target functional module Q 1. Total number of calls to the associated modules of the target functional module Q2, obtain the first weight as P 1 =Q 1 / Q 总 The second weight is P 2 =Q 1 / Q 总 ;

[0120] Q 总 =a*Q 1 +b*Q 2, a and b All are empirical constants;

[0121] Based on the first and second weights mentioned above, from any time... t Start Time Window W t Total weight in P t = X t *P 1 +Y t * P 2, of which X t For time window W t The first call to predict the value of the data. Y t For time window W t The second call predicts the data value. Within this data set, the smallest time window is selected to obtain the corresponding time. t As the target time.

[0122] Optionally, based on the call data and / or dependency data of the target functional module, and using a preset prediction algorithm, the target time is obtained, including:

[0123] Based on the call data of the target functional module, and using a preset prediction algorithm, the first call prediction data of the target functional module within the specified update period of the target module is obtained.

[0124] Based on the dependency data of the target functional module, and using a preset prediction algorithm, the second call prediction data of the related modules of the target functional module within the specified update period of the target module is obtained.

[0125] Based on the first and second call prediction data and a sliding time window, the target time is obtained. The duration of the sliding time window is not less than the time required to load the target module into the target system.

[0126] Optionally, the target time is obtained based on the first call prediction data and the second call prediction data, including:

[0127] Based on the first call prediction data and the second call prediction data, and using a sliding time window, calculate the sum of the first call prediction data and the second call prediction data within each sliding time window;

[0128] The target time window is the time window that minimizes the sum of the first and second call prediction data within the sliding time window.

[0129] Obtain the target time based on the start time of the target time window.

[0130] S6. Based on the target time, load the target module into the target system to replace the original module used by the target functional module.

[0131] Optionally, after the step of loading the target module into the target system to replace the target functional module according to the target time, the method further includes:

[0132] Based on the call data and / or dependency data of the target functional module, obtain the original stability index of the target functional module;

[0133] Obtain the target stability index of the target module based on the call data and / or dependency data of the target module;

[0134] Determine whether a rollback is necessary based on the original stability metrics and the target stability metrics.

[0135] Optionally, based on the original stability metrics and the target stability metrics, determine whether a rollback is needed, including:

[0136] When the stability index of the target module is lower than the preset threshold, roll back to the original module that the target module replaced.

[0137] When the stability represented by the target stability index is lower than the stability represented by the original stability index, roll back to the original module that the target module replaced.

[0138] By adopting the above scheme and managing the access of the module repository, the reliability of the scheme is improved. At the same time, the optimized method for obtaining module update time minimizes the impact of module updates on the system. This further solves the problem that existing technologies based on hot updates require a lot of manual operation and have a low degree of automation in the modular development lifecycle management.

[0139] Example 3

[0140] Based on Embodiments 1 and 2, this embodiment provides a modular development lifecycle management system based on hot updates, including a module management platform and a module repository.

[0141] The module management platform is configured as follows:

[0142] In response to the detection of a target module in the module repository, the target module is dynamically loaded and verified in a preset isolation environment. The target module is then configured as a newly uploaded module in the module repository.

[0143] When the target module passes verification, the target module is registered to the target system;

[0144] Based on the target module and the target system, obtain the target functional module in the target system that corresponds to the target module;

[0145] Based on the target functional module, obtain the call data and / or dependency data of the target functional module;

[0146] Based on the call data and / or dependency data of the target functional module, and using a preset prediction algorithm, the target time is obtained. The target time is configured as the time within the update period specified by the target module when the target functional module has the least impact on the target system.

[0147] Based on the target time, load the target module into the target system to replace the original module used by the target functional module;

[0148] The module repository is configured as follows:

[0149] Modules that receive and store data uploaded by users or other devices.

[0150] Optionally, before the step of dynamically loading the target module in a preset isolated environment and verifying the target module in response to detecting the presence of the target module in the module repository, the method further includes:

[0151] In response to receiving a module upload request from the module repository, obtain the name and digital signature of the module to be uploaded;

[0152] The module to be uploaded is verified based on its name and digital signature;

[0153] When the module to be uploaded passes the verification, it is allowed to be uploaded to the module repository as the target module.

[0154] Optionally, the module to be uploaded can be verified based on its name and digital signature, including:

[0155] Based on the name of the module to be uploaded, obtain the first functional module corresponding to the name of the module to be uploaded;

[0156] Based on the digital signature of the module to be uploaded, obtain the second functional module corresponding to the digital signature of the module to be uploaded. The digital signature is configured to be generated during the development of the module to be uploaded based on the module template selected by the module to be uploaded.

[0157] The verification is performed based on the first functional module and the second functional module. The module to be uploaded will pass the verification only if the first functional module and the second functional module are the same module.

[0158] Optionally, based on the target functional module, obtain the call data and / or dependency data of the target functional module, including:

[0159] Based on the target functional module, obtain the log data of the target functional module;

[0160] Based on the log data of the target functional module, obtain the call data and / or dependency data of the target functional module.

[0161] Optionally, based on the call data and / or dependency data of the target functional module, and using a preset prediction algorithm, the target time is obtained, including:

[0162] Based on the call data of the target functional module, and using a preset prediction algorithm, the first call prediction data of the target functional module within the specified update period of the target module is obtained.

[0163] Based on the dependency data of the target functional module, and using a preset prediction algorithm, the second call prediction data of the related modules of the target functional module within the specified update period of the target module is obtained.

[0164] The target time is obtained based on the prediction data from the first and second calls.

[0165] Optionally, the target time is obtained based on the first call prediction data and the second call prediction data, including:

[0166] The first weight is determined based on the total number of calls to the target functional module;

[0167] The second weight is obtained based on the total number of calls to the associated modules of the target functional module;

[0168] Based on the first call prediction data, the second call prediction data, the first weight, and the second weight, the target time is obtained based on a sliding time window. The duration of the sliding time window is not less than the time required to load the target module into the target system.

[0169] Optionally, based on the first call prediction data, the second call prediction data, the first weight, and the second weight, and using a sliding time window, the target time is obtained, including:

[0170] Based on the first call prediction data, the second call prediction data, the first weight, and the second weight, the total weight within each sliding time window is calculated based on the sliding time window.

[0171] The target time window is the time window in which the total weight within the sliding time window meets the preset conditions.

[0172] Obtain the target time based on the start time of the target time window.

[0173] Optionally, after the step of loading the target module into the target system to replace the target functional module according to the target time, the method further includes:

[0174] Based on the call data and / or dependency data of the target functional module, obtain the original stability index of the target functional module;

[0175] Obtain the target stability index of the target module based on the call data and / or dependency data of the target module;

[0176] Determine whether a rollback is necessary based on the original stability metrics and the target stability metrics.

[0177] Example 4

[0178] This embodiment provides a device including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement any of the methods described above.

[0179] Specifically, such as Figure 2 As shown, Figure 2This is a schematic diagram of the device structure of the hardware operating environment involved in the embodiments of this application. The device is an electronic device and may include: a processor 101, such as a central processing unit (CPU), a communication bus 102, a user interface 104, a network interface 103, and a memory 105. The communication bus 102 is used to realize the connection and communication between these components. The user interface 104 may include a display screen and an input unit such as a keyboard. Optionally, the user interface 104 may also include a standard wired interface and a wireless interface. The network interface 103 may optionally include a standard wired interface and a wireless interface (such as a Wi-Fi interface). The memory 105 may be a storage device independent of the aforementioned processor 101. The memory 105 may be a high-speed random access memory (RAM) or a stable non-volatile memory (NVM), such as at least one disk storage device. The processor 101 may be a general-purpose processor, including a central processing unit, a network processor, etc., or it may be a digital signal processor, an application-specific integrated circuit, a field-programmable gate array or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component.

[0180] Those skilled in the art will understand that the appendix Figure 2 The structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0181] like Figure 2 As shown, the memory 105, which serves as a storage medium, may include an operating system, a network communication module, a user interface module, and an application for implementing a modular development lifecycle management method based on hot updates.

[0182] exist Figure 2 In the electronic device shown, the network interface 103 is mainly used for data communication with the network server; the user interface 104 is mainly used for data interaction with the user; the processor 101 and the memory 105 in this application can be set in the electronic device, and the electronic device can call the application stored in the memory 105 through the processor 101 to implement a modular development lifecycle management method based on hot update to implement the above method.

[0183] Example 5

[0184] This embodiment provides a computer-readable storage medium on which a computer program is stored, and a processor executes the computer program to implement any of the methods described above.

[0185] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a device including one or any combination of the above-mentioned memories. The computer may be a variety of computing devices, including smart terminals and servers.

[0186] In the above embodiments of this disclosure, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0187] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between units or modules may be electrical or other forms.

[0188] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0189] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0190] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable non-volatile storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a non-volatile storage medium and includes several instructions to cause a device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this disclosure. The aforementioned non-volatile storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0191] The above are merely preferred embodiments of this disclosure. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this disclosure, and these improvements and modifications should also be considered within the scope of protection of this disclosure.

Claims

1. A modular development lifecycle management method based on hot updates, characterized in that, include: In response to the detection of a target module in the module repository, the target module is dynamically loaded and verified in a preset isolation environment, and the target module is configured as a newly uploaded module in the module repository; When the target module passes verification, the target module is registered to the target system; Based on the target module and the target system, obtain the target functional module in the target system that corresponds to the target module; Based on the target functional module, obtain the call data and dependency data of the target functional module; Based on the call data of the target functional module, and using a preset prediction algorithm, the first call prediction data of the target functional module within the specified update period of the target module is obtained; Based on the dependency data of the target functional module, and using a preset prediction algorithm, the second call prediction data of the associated modules of the target functional module within the update period specified by the target module is obtained. The first weight is obtained based on the total number of calls to the target functional module; The second weight is obtained based on the total number of calls to the associated modules of the target functional module; Based on the first call prediction data, the first weight of the second call prediction data, and the second weight, a target time is obtained based on a sliding time window. The duration of the sliding time window is not less than the time required to load the target module into the target system. The target time is configured as the time during which the target functional module has the least impact on the target system within the update period specified by the target module. Based on the target time, the target module is loaded into the target system to replace the original module used by the target functional module.

2. The modular development lifecycle management method based on hot updates according to claim 1, characterized in that, Before the step of dynamically loading the target module and verifying the target module in a preset isolated environment in response to detecting the presence of the target module in the module repository, the method further includes: In response to receiving a module upload request from the module repository, obtain the name and digital signature of the module to be uploaded; The module to be uploaded is verified based on its name and digital signature. When the module to be uploaded passes verification, it is allowed to be uploaded to the module repository as a target module.

3. The modular development lifecycle management method based on hot updates according to claim 2, characterized in that, The step of verifying the module to be uploaded based on its name and digital signature includes: Based on the name of the module to be uploaded, obtain the first functional module corresponding to the name of the module to be uploaded; Based on the digital signature of the module to be uploaded, a second functional module corresponding to the digital signature of the module to be uploaded is obtained. The digital signature is configured to be generated during the development of the module to be uploaded based on the module template selected by the module to be uploaded. The verification is performed based on the first functional module and the second functional module. The module to be uploaded passes the verification only if the first functional module and the second functional module are the same module.

4. The modular development lifecycle management method based on hot updates according to claim 1, characterized in that, The step of obtaining the call data and / or dependency data of the target functional module according to the target functional module includes: Based on the target functional module, obtain the log data of the target functional module; Based on the log data of the target functional module, obtain the call data and / or dependency data of the target functional module.

5. The modular development lifecycle management method based on hot updates according to claim 1, characterized in that, The step of obtaining the target time based on the first call prediction data, the first weight of the second call prediction data, and the second weight, using a sliding time window, includes: Based on the first call prediction data, the first weight of the second call prediction data, and the second weight, the total weight within each sliding time window is calculated based on the sliding time window. The target time window is the time window in which the total weight within the sliding time window meets the preset conditions. Obtain the target time based on the start time of the target time window.

6. The modular development lifecycle management method based on hot updates according to claim 1, characterized in that, After the step of loading the target module into the target system to replace the target functional module according to the target time, the method further includes: Based on the call data and / or dependency data of the target functional module, obtain the original stability index of the target functional module; The target stability index of the target module is obtained based on the call data and / or dependency data of the target module; Based on the original stability index and the target stability index, determine whether a rollback is necessary.

7. A modular development lifecycle management system based on hot updates, characterized in that, This includes a module management platform and a module repository; The module management platform is configured as follows: In response to the detection of a target module in the module repository, the target module is dynamically loaded and verified in a preset isolation environment, and the target module is configured as a newly uploaded module in the module repository; When the target module passes verification, the target module is registered to the target system; Based on the target module and the target system, obtain the target functional module in the target system that corresponds to the target module; Based on the target functional module, obtain the call data and dependency data of the target functional module; Based on the call data of the target functional module, and using a preset prediction algorithm, the first call prediction data of the target functional module within the specified update period of the target module is obtained; Based on the dependency data of the target functional module, and using a preset prediction algorithm, the second call prediction data of the associated modules of the target functional module within the update period specified by the target module is obtained. The first weight is obtained based on the total number of calls to the target functional module; The second weight is obtained based on the total number of calls to the associated modules of the target functional module; Based on the first call prediction data, the first weight of the second call prediction data, and the second weight, a target time is obtained based on a sliding time window. The duration of the sliding time window is not less than the time required to load the target module into the target system. The target time is configured as the time during which the target functional module has the least impact on the target system within the update period specified by the target module. Based on the target time, load the target module into the target system to replace the original module used by the target functional module; The module repository is configured as follows: Modules that receive and store data uploaded by users or other devices.

8. A device, characterized in that, The device includes a memory and a processor, wherein the memory stores a computer program and the processor executes the computer program to implement the method according to any one of claims 1-6.

Citation Information

Patent Citations

  • Artifact lifecycle management on a cloud computing system

    CN111819538A

  • Update time setting program, update time setting device, and update time setting method

    JP2023115953A