Incremental package generation method, system, device, storage medium and product

Abstract

Embodiments of the present application provide a kind of incremental package generation method, system, device, storage medium and product. By obtaining current version information and target version information, determine the upgrade incremental total package corresponding to version difference module according to current version information and target version information;Obtain historical fault data, determine the historical upgrade failure probability corresponding to each preset fault category in historical fault data;In the case where historical upgrade failure probability exceeds preset failure probability threshold, the upgrade data corresponding to preset fault category in upgrade incremental total package is split into multiple fine-grained incremental sub-packets according to fault subcategory in preset fault category;Generate upgrade plan based on the dependency relationship between each version difference module, send fine-grained incremental sub-packet to client, so that client upgrades corresponding version difference module based on upgrade plan and fine-grained incremental sub-packet.According to the method provided in the embodiments of the present application, the system stability and upgrade efficiency are improved.

Description

Technical Field

[0001] This application belongs to the field of data processing technology, and in particular relates to an incremental packet generation method, system, device, storage medium and product. Background Technology

[0002] In existing technologies, incremental rollback upgrades are a common method in software or system upgrade processes. It refers to updating the changed parts and, in the event of upgrade failure or anomalies, reverting the system state to the stable version before the upgrade to ensure system continuity and stability. It is often used in production environments with high availability and low downtime, and has achieved efficient deployment and fault recovery by comparing the differences between the old and new versions.

[0003] During incremental rollback upgrades, the upgrade package still needs to be transmitted in its entirety, which makes it difficult to adapt to the download efficiency of set-top boxes in low-bandwidth environments. The generation of upgrade packages depends on fixed version differences, making it difficult to achieve dynamic incremental construction based on real-time fault modules. In the process of fixing mobile terminal upgrade anomalies, it relies on preset difference files in the incremental package to achieve anomaly detection and repair, making it difficult to achieve dynamic incremental construction for temporary runtime faults. Set-top box system version upgrades suffer from problems such as large upgrade package size, low download efficiency, and high risk of upgrade failure. Summary of the Invention

[0004] This application provides an incremental package generation method, system, apparatus, storage medium, and product that can improve download efficiency and reduce the risk of upgrade failure.

[0005] In a first aspect, embodiments of this application provide an incremental packet generation method, the method comprising: Obtain current version information and target version information, and determine the total upgrade increment package corresponding to the version difference module based on the current version information and target version information; Acquire historical fault data and determine the historical upgrade failure probability corresponding to each preset fault category in the historical fault data; If the historical upgrade failure probability exceeds the preset failure probability threshold, the upgrade data corresponding to the preset fault category in the upgrade incremental package will be split into multiple fine-grained incremental sub-packages according to the fault sub-categories in the preset fault category. An upgrade plan is generated based on the dependencies between the different modules in each version. Fine-grained incremental sub-packages are then sent to the client so that the client can upgrade the corresponding different modules based on the upgrade plan and the fine-grained incremental sub-packages.

[0006] Secondly, embodiments of this application provide an incremental package generation system, the system comprising: On the server side, it is applied to incremental package generation methods such as those in the first aspect; The client is used to receive fine-grained incremental sub-packages from the server, upgrade the version difference modules based on the fine-grained incremental sub-packages, and report the upgrade results and fault logs to the server.

[0007] Thirdly, embodiments of this application provide an incremental packet generation apparatus, the apparatus comprising: The difference module is used to obtain the current version information and the target version information, and determine the upgrade increment package corresponding to the version difference module based on the current version information and the target version information; The acquisition module is used to acquire historical fault data and determine the historical upgrade failure probability corresponding to each preset fault category in the historical fault data. The splitting module is used to split the upgrade data corresponding to the preset fault category in the upgrade incremental package into multiple fine-grained incremental sub-packages according to the fault sub-categories in the preset fault category when the historical upgrade failure probability exceeds the preset failure probability threshold. The upgrade module generates an upgrade plan based on the dependencies between different version modules, and sends fine-grained incremental sub-packages to the client so that the client can upgrade the corresponding version difference modules based on the upgrade plan and the fine-grained incremental sub-packages.

[0008] Fourthly, embodiments of this application provide a terminal device, the device including: a processor, and a memory storing computer program instructions; the processor reads and executes the computer program instructions to implement the incremental packet generation method as described in the first aspect.

[0009] Fifthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the incremental packet generation method of the first aspect.

[0010] Sixthly, embodiments of this application provide a computer program product, including a computer program, which, when executed, implements the incremental package generation method as described in the first aspect.

[0011] The incremental package generation method, system, device, storage medium, and product of this application embodiment obtain current version information and target version information, determine the upgrade incremental package corresponding to the version difference module based on the current version information and target version information, thereby determining the difference data between the versions to be upgraded, obtaining historical fault data, determining the historical upgrade failure probability corresponding to each preset fault category in the historical fault data, and being able to determine the historical upgrade failure probability corresponding to the fault categories that exist and may occur during the current upgrade process, and taking countermeasures based on the historical upgrade failure probability. When the historical upgrade failure probability exceeds the preset failure probability threshold, the upgrade data corresponding to the preset fault category in the upgrade incremental package is split into multiple fine-grained incremental sub-packages according to the fault sub-categories in the preset fault category, which can reduce the transmission bandwidth occupation and upgrade time. An upgrade plan is generated according to the dependency relationship between each version difference module, and the fine-grained incremental sub-packages are sent to the client so that the client can upgrade the corresponding version difference module based on the upgrade plan and the fine-grained incremental sub-packages, realizing an efficient, safe, and reliable software upgrade process, and improving system stability, upgrade efficiency, and maintenance efficiency. Attached Figure Description

[0012] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a flowchart illustrating an incremental packet generation method provided in an embodiment of this application; Figure 2 This application provides an incremental package generation system. Figure 3 This is another incremental package generation method provided in the embodiments of this application; Figure 4 This is a schematic diagram of an incremental packet generation device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a terminal device provided in an embodiment of this application. Detailed Implementation

[0014] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0015] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0016] It should be noted that the acquisition, storage, use, and processing of data in this application embodiment all comply with the relevant provisions of national laws and regulations.

[0017] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0018] In existing technologies, incremental rollback upgrade refers to updating only the changed parts during software or system upgrades, and in the event of upgrade failure or anomalies, the system state can be rolled back to the stable version before the upgrade to ensure system continuity and stability. It is often used in production environments that require high availability and low downtime, and achieves efficient deployment and fault recovery by comparing the differences between the old and new versions.

[0019] Currently, common methods in the field of incremental rollback upgrades include generating incremental packages based on version difference comparison, performing incremental updates based on file difference algorithms, performing system recovery based on full rollback, performing upgrade transmission based on breakpoint resume, performing segmented upgrades based on modularization, and performing fault location and repair based on log analysis.

[0020] This method involves obtaining the upgrade package from the master server and sending it to the server to be upgraded, guiding it to perform environmental parameter checks. Based on the check results, the upgrade type is dynamically determined, including in-situ hot upgrade, rolling hot upgrade, rolling cold upgrade, and cold upgrade, thus matching the most suitable upgrade strategy. Furthermore, this method can perform differentiated processing in the case of concurrent upgrades across multiple servers, ensuring that each server can independently choose the optimal path based on its own circumstances. During the upgrade task execution, scheduling order control, failure retry mechanisms, and pause / resume functions are used to handle abnormal situations during the upgrade process, enhancing system stability and fault tolerance, thereby improving upgrade efficiency and increasing the reliability and controllability of server upgrades.

[0021] The developer can also generate an upgrade package, including compiled files and their corresponding verification files, and upload it to the server. Upon receiving the upgrade package, the server first unpacks and verifies it to ensure the integrity and reliability of the compiled files. Then, it generates multiple incremental upgrade packages for different existing versions. Each incremental package includes an incremental file and corresponding encrypted verification information. After receiving the download information, the client can match the appropriate incremental package based on its own version information and verify the validity of the incremental file through decryption and verification mechanisms. This ensures the security and reliability of the upgrade process, preventing tampering of the upgrade content during transmission, reducing the upgrade package size, improving upgrade efficiency and network resource utilization, and making it suitable for various software system scenarios requiring frequent version updates.

[0022] If abnormal files are encountered during the upgrade process, the abnormal file path can be recorded to the system upgrade error list and the upgrade can be skipped and continued. After the upgrade is completed, the list is uploaded to the server. The server extracts the corresponding files from the new version full package according to the list to generate a repair package. The client periodically accesses the server to obtain the download address of the repair package, downloads it, and performs a second upgrade to replace the abnormal files, thereby achieving accurate repair of abnormal files, ensuring the continuity of the upgrade process, improving the success rate of terminal upgrades and user experience.

[0023] However, in the aforementioned existing technologies, the upgrade package still needs to be transmitted in its entirety, making it difficult to adapt to the download efficiency of set-top boxes in low-bandwidth environments. It also cannot dynamically generate incremental packages based on specific faulty modules, resulting in coarse-grained rollback after upgrade failure, affecting the efficiency of restoring local system functions. Alternatively, the upgrade package generation depends on fixed version differences, making it difficult to achieve dynamic incremental construction based on real-time faulty modules. Furthermore, it lacks an intelligent identification and isolation mechanism for local failures during the upgrade process, causing rollback operations to still rely on overall version reversion, affecting the efficiency of restoring local system functions. Or, during upgrade anomalies, it relies on preset difference files within the incremental package for anomaly detection and repair, making it difficult to achieve dynamic incremental construction for temporary runtime faults. Simultaneously, the repair execution phase mainly relies on the overall processing of the manifest file, failing to accurately identify and isolate potential local repair failures during the upgrade process, resulting in the need to replace the entire repair package, potentially affecting the efficiency of restoring local system functions.

[0024] In summary, to address the issues of large package sizes, low download efficiency, and high risk of upgrade failure in existing set-top box system upgrade technologies, there is an urgent need for a mechanism that can automatically generate ultra-fine-grained incremental upgrade packages on the server side based on real-time monitoring of failed upgrade modules during the upgrade process and the actual types of faults that occur during system operation after the upgrade (such as network, playback, launcher, etc.). This would improve transmission efficiency and success rate during the upgrade process. Simultaneously, the set-top box side needs to intelligently identify and isolate locally failed modules during the upgrade process, and support rolling back only those modules to reduce the impact on system functionality caused by overall version rollback. This would ensure system stability, response speed, and operational efficiency during and after the upgrade process, and enable breakpoint resume upgrade capability.

[0025] To address the problems in the prior art, embodiments of this application provide an incremental packet generation method, system, apparatus, storage medium, and product.

[0026] The incremental package generation method provided in the embodiments of this application will be introduced first below.

[0027] Figure 1 A flowchart illustrating an embodiment of the incremental package generation method provided in this application is shown. Figure 1 As shown, the method may include the following steps: S101: Obtain the current version information and target version information, and determine the upgrade increment package corresponding to the version difference module based on the current version information and target version information.

[0028] Specifically, the system obtains the current version information reported by the set-top box and determines the target version information to be updated. The current version information can be provided by the version database maintained by the server, including metadata such as major version number, minor version number, patch number, data of multiple modules, hash values ​​of each module, and dependency graph between modules.

[0029] In addition, the upgrade increment package corresponding to the version difference module is determined based on the current version information and the target version information. The upgrade increment package includes modules whose content or data has changed, but does not include the complete files of modules that have not been modified. It can be understood as the collection of all content to be updated involved in this upgrade.

[0030] This application embodiment determines the upgrade increment total package corresponding to the version difference module by comparing the current version information and the target version information. This can accurately determine the scope that needs to be updated, reduce the transmission of the full package, improve transmission efficiency, and reduce bandwidth usage.

[0031] S102: Obtain historical fault data and determine the historical upgrade failure probability corresponding to each preset fault category in the historical fault data.

[0032] Specifically, historical fault data can be obtained from the upgrade log database. The historical fault data includes the number of failures of each module in previous upgrades, the error codes of the failures, the timestamps of the faults, and the preset fault categories or subcategories to which the faults belong.

[0033] In addition, statistical analysis is performed on historical fault data to determine the probability of historical upgrade failures in the historical fault data according to preset fault categories. The preset fault categories include network connection faults, audio and video playback faults, desktop launcher faults, etc.

[0034] The probability of historical upgrade failures can be determined using the following formula: ; Where P(failure|m) represents the historical upgrade failure probability under the condition of module m corresponding to the preset fault category, count(m,failure) represents the historical fault data of module m, and count(m) represents the total number of times module m has been upgraded.

[0035] That is, the historical upgrade failure probability of module m = the number of times the module failed / the total number of upgrades for the module.

[0036] The embodiments of this application determine the probability of historical upgrade failure according to preset fault categories, thereby quantifying the risk of upgrade failure during the upgrade process for data of different preset fault categories.

[0037] S103: If the historical upgrade failure probability exceeds the preset failure probability threshold, the upgrade data corresponding to the preset fault category in the upgrade incremental package will be split into multiple fine-grained incremental sub-packages according to the fault sub-categories in the preset fault category.

[0038] Specifically, if the historical upgrade failure probability exceeds the preset failure probability threshold, it indicates that the preset fault category has a high risk of occurrence in historical upgrades and also has a high risk of occurrence in this upgrade. The corresponding upgrade incremental package is then split into multiple fine-grained incremental sub-packages according to the fault sub-categories in the preset fault category. Each fine-grained incremental sub-package corresponds to a different sub-function or code segment, and the fine-grained incremental sub-packages maintain clear boundaries and do not overlap with each other.

[0039] For example, the preset failure probability threshold can be 0.3. That is, if the historical upgrade failure probability of a certain preset fault category exceeds 0.3, it means that the preset fault category has a high risk of occurrence during the upgrade process and will be split into fine-grained incremental sub-packages, which can be split at the function level.

[0040] This application embodiment breaks down high-risk modules into fine-grained incremental sub-packages, which can limit upgrade risks to smaller units. In the event of an abnormal installation of a fine-grained incremental sub-package, only its corresponding sub-function will be affected, and the entire module upgrade will not fail, thus reducing the scope of the fault impact.

[0041] S104: Generate an upgrade plan based on the dependencies between different modules in each version, and send fine-grained incremental sub-packages to the client so that the client can upgrade the corresponding different modules in the version based on the upgrade plan and the fine-grained incremental sub-packages.

[0042] Specifically, after the split is completed, it is necessary to determine the dependencies between the different modules of each version. These dependencies can be extracted from the source code using static code analysis tools such as Doxygen or Graphviz. After extracting the dependencies, they can be stored in a graph structure.

[0043] For example, if module B calls an interface provided by module A, module A should be upgraded before module B.

[0044] In addition, an upgrade plan is generated based on dependencies, which specifies the order in which each fine-grained incremental sub-package is distributed and the sequential upgrade logic during the client's upgrade process.

[0045] In addition, fine-grained incremental sub-packages and upgrade plans are sent to the client so that the client can install each fine-grained incremental sub-package in the order of upgrades in the upgrade plan, thereby completing the upgrade of the corresponding version difference modules.

[0046] Furthermore, all data involved in the embodiments of this application are stored in a structured format, such as JSON or XML. For example, the dependencies between modules are represented by a graph structure, with nodes representing module names and edges representing dependencies. Fault logs (i.e., the source of historical fault data) are stored in key-value pairs, for example: {"module":"A","error_code":"403","timestamp":"YYYY-MM-DDTHH:MM:SSZ"} indicates that module A encountered a fault during the upgrade process, with fault code 403 and fault timestamp YYYY-MM-DDTHH:MM:SSZ.

[0047] Data cleaning, which involves removing duplicate records, invalid timestamps, and incomplete log entries, can be achieved by using regular expressions to match standard error code formats (such as HTTP status codes and system error codes) and filtering out non-standard error codes.

[0048] The data can also be normalized, that is, the module names reported by different clients are unified into standardized names, such as unifying "mod_A" and "ModuleA" into "ModuleA".

[0049] The data can also be dimensionality reduced by performing cluster analysis on historical upgrade records to extract the accuracy of high-frequency fault modules and common error types, which can be used to optimize incremental package generation strategies.

[0050] This application's embodiments generate an upgrade plan according to dependencies to ensure that version-difference modules are loaded and upgraded sequentially during the upgrade process. The upgrade of the client system is completed through fine-grained incremental sub-packages and upgrade plans, reducing the amount of data and the probability of failure in a single update.

[0051] This application embodiment generates an upgrade incremental package by comparing version difference modules, reducing the size of the transmitted file. It calculates the failure probability based on historical fault data and identifies high-risk modules, which are then split into fine-grained incremental sub-packages according to fault sub-categories, reducing the data volume of a single sub-package, reducing transmission bandwidth usage and upgrade time. At the same time, it generates an upgrade plan based on module dependencies, reducing cascading failures caused by improper upgrade order, improving transmission efficiency, and enhancing upgrade efficiency and compatibility.

[0052] In some embodiments, after sending the fine-grained incremental subpackage to the client so that the client can upgrade the corresponding version difference module based on the upgrade plan and the fine-grained incremental subpackage, the method further includes: Receive the upgrade results returned by the client based on the upgrade of each fine-grained incremental sub-package; If the upgrade fails, retrieve the fault log sent by the client. The fault log includes the sub-packet name, error code, and error timestamp of the fine-grained incremental sub-packet. The fault logs are weighted and fused based on a pre-defined rule engine and a machine learning model to obtain the target fault category corresponding to the fault logs.

[0053] Specifically, the client upgrades the corresponding version difference module according to the fine-grained incremental sub-packages and upgrade plan. During this process, the client returns the upgrade results based on each fine-grained incremental sub-package, including success and failure statuses.

[0054] If the upgrade fails, the server retrieves the fault logs sent by the client. The server receives the upgrade result after the client completes the upgrade of each module. The fault logs include the sub-package name, error code, and error timestamp of the fine-grained incremental sub-package.

[0055] Among them, the sub-packet name is used as a unique identifier for fine-grained incremental sub-packets, the error code can be determined according to the preset encoding rules, and the error timestamp indicates the exact time when the fault occurred.

[0056] Furthermore, a weighted fusion analysis of fault logs can be performed using a rule engine and a machine learning model to determine the target fault category corresponding to the fault log. The rule engine pre-stores judgment rules to identify common error types. For example, an error code of 403 is judged as insufficient permissions, and an error code of 500 is judged as an internal service exception. The rule engine score is determined by the total number of rules and the number of matching rules, which can be expressed as the following formula: Rule engine score = number of matching rules / total number of rules. When the error code completely matches the preset rules, the score is 1.0. For example, the error code "403" matches the "insufficient permissions" rule and gets 1.0 points. When the error code partially matches or matches within the error code range, the rule engine score is adjusted according to the degree of matching.

[0057] The machine learning model can utilize a long short-term memory network architecture, which is a machine learning model that has been trained on a large amount of historical fault log text. Its input is the fault log text, and its output is a preset fault category. The Softmax probability in the long short-term memory network can be used as the score of the machine learning model.

[0058] The input is a vectorized representation of the log text, and the output is the predicted probability (0-1) of the corresponding preset fault category. Softmax is a function that converts the neural network output into a probability distribution.

[0059] The outputs of the rule engine and the machine learning model are weighted and fused to obtain the target fault category. The weighted fusion method can be a dynamic weighted fusion algorithm, as shown in the following formula: Final score = Rule engine score × 0.6 + Machine learning score × 0.4; The rule engine score is the confidence score of the rule engine for the preset fault category (range 0-1), the machine learning model score is the prediction probability of the machine learning model for the preset fault category (range 0-1), and the final score is the weighted fusion score (range 0-1). 0.6 is the weight of the rule engine score, and 0.4 is the weight of the machine learning model score. The ratio of 0.6:0.4 has been proven to be an effective balance point in engineering practice, and its value can be adjusted as needed.

[0060] If the final score is not less than the preset category score threshold (e.g., 0.7), the preset fault category is determined as the target fault category; otherwise, it is determined as an "unknown fault." 0.7 is a commonly used threshold in machine learning classification tasks, and its value can be adjusted as needed.

[0061] The embodiments of this application identify modules that fail to upgrade during the upgrade process and automatically detect modules that malfunction after the upgrade is completed, thereby improving the level of automation and optimizing subsequent processes.

[0062] In some embodiments, after performing weighted fusion analysis on the fault logs based on a preset rule engine and a machine learning model to obtain the target fault category corresponding to the fault logs, the method further includes: Based on the target fault category and sub-package name, determine the corresponding version difference module in the current version information; Retrieve complete module data for the version difference modules in the current version information; Generate a rollback package based on complete module data; The rollback package is sent to the client so that the client can perform a rollback operation on the failed version difference module.

[0063] Specifically, the corresponding version difference module is determined in the current version information based on the target fault category and sub-packet name. For example, if the target fault category is a network connection type fault, and the sub-packet name of the fine-grained incremental sub-packet is net_stack_tcp_timeout_patch, this sub-packet name is mapped to a specific module in the current version information to determine the version difference module where the fine-grained incremental sub-packet resides.

[0064] Additionally, obtain the complete module data of the version difference modules in the current version information. The current version information refers to the version that the client was running stably before this upgrade began, and the complete module data of the version difference modules can be obtained from the server-side database.

[0065] In addition, a rollback package is generated based on the complete module data. The rollback package can also include a rollback identifier to inform the client that this operation is a rollback operation rather than a regular upgrade operation.

[0066] In addition, a rollback packet is sent to the client so that after receiving the rollback packet, the client performs a rollback operation on the version difference modules that failed, while other modules remain unchanged.

[0067] Furthermore, after the client completes the rollback operation, the server can receive a rollback success status from the client and update the target version information to a partial rollback status on the server side.

[0068] In this application embodiment, during the upgrade process, only the version difference modules that have failed are rolled back, without affecting other modules that have been successfully upgraded. This reduces the risk of the entire system crashing or losing functionality due to local failures, and improves stability. At the same time, the rollback mechanism can be triggered without manual intervention during the generation of the rollback package and the triggering of the rollback mechanism, which improves the level of intelligence and automation in the upgrade process.

[0069] In some embodiments, obtaining current version information and target version information, and determining the total upgrade increment package corresponding to the version difference module based on the current version information and target version information, includes: Get the first hash value set of each module in the current version information, and get the second hash value set of each module in the target version information; Modules with different hash values ​​in the first hash value set and the second hash value set are identified as version difference modules; The upgrade incremental master package is generated based on the version difference module.

[0070] Specifically, the first hash value set of each module in the current version information is obtained, and the second hash value set of each module in the target version information is obtained. The hash value can be obtained by SHA-256 operation. The granularity of the module division in the first hash value set and the second hash value set is consistent. Therefore, the version difference module can be determined by comparing the first hash value set and the second hash value set.

[0071] Furthermore, the hash values ​​of the same module in the first hash value set and the second hash value set are compared. Modules with different hash values ​​in the first hash value set and the second hash value set are identified as version-difference modules. Version-difference modules can be determined by the following formula: ; Where M represents the set of all modules, m represents a specific module, mcurrent represents the module in the current version information, mtarget represents the module in the target version information, and H() represents the hash function. That is, the set of version difference modules is all modules whose hash values ​​are different in the current version information and the target version information.

[0072] In addition, an upgrade incremental package can be generated based on the version difference modules. Corresponding upgrade incremental data can be generated for each version difference module, and the upgrade incremental data can be packaged separately and their collection can be determined as the upgrade incremental package.

[0073] This application embodiment only transmits data corresponding to modules with version differences, reducing the bandwidth occupied by transmission. It can also split and roll back for individual modules or even fine-grained incremental sub-packets corresponding to modules. By comparing hash values, it reduces comparison consumption and improves upgrade efficiency.

[0074] In some embodiments, after sending the fine-grained incremental subpackage to the client so that the client can upgrade the corresponding version difference module based on the upgrade plan and the fine-grained incremental subpackage, the method further includes: After the upgrade is completed, identify all fault data in the modules with differences between the upgraded versions; Based on all fault data, update historical fault data to update the historical upgrade failure probability.

[0075] Specifically, after the client completes the upgrade of all module differences according to the upgrade plan and fine-grained incremental sub-packages, all fault data of all upgrade version difference modules during this upgrade process are determined.

[0076] In addition, based on all fault data, historical fault data and corresponding fault logs are updated, thereby updating the input data of the preset rule engine and machine learning model, and optimizing the generation strategy of subsequent upgrade incremental master packages and fine-grained incremental sub-packages.

[0077] Furthermore, after the upgrade is completed, the upgrade status of all modules can be summarized, and an upgrade report can be generated based on the upgrade status. The upgrade report can mark the successful modules, failed modules, and rollback modules during the upgrade process.

[0078] This application embodiment maintains the real-time nature of historical fault data by summarizing all fault data and updating it to historical fault data, thereby ensuring the accuracy of historical upgrade failure probabilities. It can optimize the generation strategy of fine-grained incremental sub-packages, making them more targeted and improving upgrade efficiency.

[0079] In some embodiments, after acquiring historical fault data and determining the historical upgrade failure probability corresponding to each preset fault category in the historical fault data, the method further includes: If the historical upgrade failure probability does not exceed the preset failure probability threshold, the upgrade incremental package is divided into multiple coarse-grained incremental sub-packages according to the preset fault categories, and each coarse-grained incremental sub-package corresponds to a preset fault category. Send coarse-grained incremental sub-packages to the client so that the client can upgrade the corresponding version difference module based on the coarse-grained incremental sub-packages.

[0080] Specifically, after the server completes the analysis of historical fault data, if the historical upgrade failure probability does not exceed the preset failure probability threshold, the total upgrade incremental package is split into multiple coarse-grained incremental sub-packages according to the preset fault categories. For example, if the preset failure probability threshold is 0.3, the historical upgrade failure probability of the audio and video playback fault category is 0.05. Therefore, the audio and video playback fault category rarely occurs in the historical upgrade process and belongs to the low-risk category. The coarse-grained incremental sub-packages can be incremental data at the module level or subsystem level, and their granularity is larger than that of the fine-grained incremental sub-packages.

[0081] In addition, coarse-grained incremental sub-packages are sent to the client. Since there are usually no cross dependencies between coarse-grained sub-packages, they do not need to be installed one by one according to strict dependencies. Instead, they can be upgraded in parallel or in any order, so that the client can upgrade the corresponding version difference modules according to the coarse-grained incremental sub-packages.

[0082] In this application embodiment, for low-risk fault categories, the client upgrades the corresponding version difference module through coarse-grained incremental sub-packages, reducing network request overhead, improving upgrade throughput, and maintaining the stability and traceability of the upgrade process.

[0083] Figure 2 This application provides an incremental package generation system, such as... Figure 2 As shown, the system includes a server 210 and a client 220.

[0084] Server 210, used in applications such as Figure 1 The incremental package upgrade method based on fault identification is shown below; Client 220 is used to receive fine-grained incremental sub-packages from the server, upgrade the version difference modules based on the fine-grained incremental sub-packages, and report the upgrade results and fault logs to the server.

[0085] Furthermore, the server 210 and client 220 can communicate via HTTP / HTTPS protocols to ensure the security and reliability of data transmission. Before upgrading, the client 220 sends a request to the server 210 to obtain the list of incremental packages (including coarse-grained and fine-grained incremental sub-packages) and the upgrade plan. During the upgrade process, the client 220 periodically pushes module status to the server 210. After the upgrade is completed, the client 220 uploads an overall status report of this upgrade.

[0086] The server 210 may include a version management module, an incremental package generation module, a version database, a historical fault database, a fault analysis module, and a rollback control module.

[0087] The version management module is used to store and manage metadata for all released versions, including version number, module hash value, dependencies, etc.

[0088] The incremental package generation module is used to generate fine-grained incremental sub-packages based on the differences between the current version information and the target version information, combined with historical fault data.

[0089] The version database is used to store data information for each version, and the historical fault database is used to store historical fault data.

[0090] The fault analysis module is used to receive fault logs uploaded by the client, analyze the error types, frequencies and impact ranges in the fault logs, and optimize the generation strategy of fine-grained incremental sub-packages.

[0091] The rollback control module is used to trigger the rollback process after detecting that the upgrade of a version difference module has failed. It only rolls back the version difference module that failed to upgrade and does not affect other modules.

[0092] The client 220 may include an upgrade execution module, a status feedback module, a set-top box system, a status monitor, and a fault detection module.

[0093] The upgrade execution module is used to execute upgrade operations in the order of dependencies between modules, and supports breakpoint resumption and retry mechanisms.

[0094] The status feedback module is used to send the upgrade results to the server after each version difference module upgrade is completed.

[0095] The set-top box system is the application scenario of the system, and the status monitor is used to monitor the upgrade status of the different modules in each version.

[0096] The fault detection module is used to monitor the running status of the version difference module in real time during the upgrade process, detect anomalies and report error codes.

[0097] Figure 3 This is another incremental package generation method provided in the embodiments of this application, which can be applied to, for example... Figure 2 The fault identification incremental package generation system shown is as follows: Figure 3 As shown, it includes client 310, server 320, version database 330, historical fault data 340 and upgrade report 350, and can be divided into three stages: upgrade preparation stage, upgrade execution stage and upgrade completion stage.

[0098] Specifically, in Phase One, the upgrade preparation phase: 1. Client 310 sends the current version number (i.e., current version information) to server 320; 2. On the server side, query version database 330 (320) to determine the target version and the corresponding list of incremental packages.

[0099] 3. Server-side analysis results based on version differences; 4. Send a request to historical fault data 340 to obtain historical fault data; 5. Based on the fault analysis results returned by historical fault data 340, generate fine-grained incremental sub-packages. For example, if module A frequently fails in the historical records, it is split into three sub-modules A1, A2, and A3, and fine-grained incremental sub-packages are generated for each. 6. The server 320 sends the list of incremental packages and the upgrade order to the client 310, and the client 310 begins to prepare the upgrade environment.

[0100] Phase Two, during the upgrade execution phase: 7. Client 310 loads and executes incremental packages one by one in the order provided by server 320; 8. After each module upgrade is completed, client 310 sends an upgrade success status to server 320.

[0101] 9. If a module upgrade fails, the client 310 immediately stops the upgrade of subsequent modules and reports the error code and log information to the server 320. The client 310 starts and executes the fault detection mechanism, which can identify problems such as inability to play or inability to enter the Launcher, and feeds back to the server 320. 10. After receiving the failure status, the server-side 320 calls the fault identification algorithm to determine the failed module; 11. Generate a rollback package and send it to client 310; 12. Client 310 performs a rollback operation on the failed module; 13. After the client 310 completes the rollback, it sends a "rollback successful" status to the server 320; 14. The server-side 320 update status is "partial rollback"; Phase 3, during the upgrade completion phase: 15. Server-side 320 summarizes the upgrade status of all modules; 16. Generate upgrade report 350, which includes successful modules, failed modules, rollback modules, etc. 17. Server 320 updates historical fault data based on the fault data from this upgrade, in order to update the input data for the fault prediction model; 18. Optimize the generation strategy for subsequent incremental packages.

[0102] This application embodiment generates ultra-fine-grained incremental packets on the server side according to preset fault categories, transmitting only the parts that actually need updating. This reduces the problems of large full-packet size and slow download speed, thereby improving the upgrade speed and user experience. During the upgrade process, if a module fails to upgrade, only that module is rolled back, without affecting other successfully upgraded modules. This reduces the risk of the entire system crashing or malfunctioning due to local faults, ensuring the stable operation of the system during the upgrade process. It can identify modules that fail to upgrade during the upgrade process and automatically detect faulty modules after the upgrade is completed. The incremental packet generation or rollback mechanism can be triggered without manual intervention, improving the intelligence and automation of the upgrade process. Combined with the breakpoint resume mechanism, even if the upgrade is interrupted, it can continue to resume from the last interrupted position, further ensuring the continuity and integrity of the upgrade process and improving the overall system robustness and user experience.

[0103] Figure 4 This is a schematic diagram of an incremental packet generation device provided in an embodiment of this application. Figure 4 As shown, the incremental package generation device may include a difference module 410, an acquisition module 420, a splitting module 430, and an upgrade module 440.

[0104] The difference module 410 is used to obtain the current version information and the target version information, and to determine the upgrade increment package corresponding to the version difference module based on the current version information and the target version information. The acquisition module 420 is used to acquire historical fault data and determine the historical upgrade failure probability corresponding to each preset fault category in the historical fault data. The splitting module 430 is used to split the upgrade data corresponding to the preset fault category in the upgrade incremental package into multiple fine-grained incremental sub-packages according to the fault sub-categories in the preset fault category when the historical upgrade failure probability exceeds the preset failure probability threshold. Upgrade module 440 is used to generate an upgrade plan based on the dependencies between version difference modules, and send fine-grained incremental sub-packages to the client so that the client can upgrade the corresponding version difference modules based on the upgrade plan and fine-grained incremental sub-packages.

[0105] In some embodiments, after sending the fine-grained incremental sub-package to the client so that the client can upgrade the corresponding version difference module based on the upgrade plan and the fine-grained incremental sub-package, the upgrade module 440 is further configured to: Receive the upgrade results returned by the client based on the upgrade of each fine-grained incremental sub-package; If the upgrade fails, retrieve the fault log sent by the client. The fault log includes the sub-packet name, error code, and error timestamp of the fine-grained incremental sub-packet. The fault logs are weighted and fused based on a pre-defined rule engine and a machine learning model to obtain the target fault category corresponding to the fault logs.

[0106] In some embodiments, after the upgrade module 440 performs weighted fusion analysis on the fault logs based on a preset rule engine and a machine learning model to obtain the target fault category corresponding to the fault logs, it is further configured to: Based on the target fault category and sub-package name, determine the corresponding version difference module in the current version information; Retrieve complete module data for the version difference modules in the current version information; Generate a rollback package based on complete module data; The rollback package is sent to the client so that the client can perform a rollback operation on the failed version difference module.

[0107] In some embodiments, the difference module 410 obtains current version information and target version information, and determines the upgrade incremental total package corresponding to the version difference module based on the current version information and target version information, for the purpose of: Get the first hash value set of each module in the current version information, and get the second hash value set of each module in the target version information; Modules with different hash values ​​in the first hash value set and the second hash value set are identified as version difference modules; The upgrade incremental master package is generated based on the version difference module.

[0108] In some embodiments, after sending the fine-grained incremental sub-package to the client so that the client can upgrade the corresponding version difference module based on the upgrade plan and the fine-grained incremental sub-package, the upgrade module 440 is further configured to: After the upgrade is completed, identify all fault data in the modules with differences between the upgraded versions; Based on all fault data, update historical fault data to update the historical upgrade failure probability.

[0109] In some embodiments, after acquiring historical fault data and determining the historical upgrade failure probability corresponding to each preset fault category in the historical fault data, the acquisition module 420 is further configured to: If the historical upgrade failure probability does not exceed the preset failure probability threshold, the upgrade incremental package is divided into multiple coarse-grained incremental sub-packages according to the preset fault categories, and each coarse-grained incremental sub-package corresponds to a preset fault category. Send coarse-grained incremental sub-packages to the client so that the client can upgrade the corresponding version difference module based on the coarse-grained incremental sub-packages.

[0110] Figure 5 A schematic diagram of the hardware structure of the terminal device provided in an embodiment of this application is shown.

[0111] The terminal device may include a processor 501 and a memory 502 storing computer program instructions.

[0112] Specifically, the processor 501 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0113] Memory 502 may include mass storage for data or instructions. For example, and not limitingly, memory 502 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. In one instance, memory 502 may include removable or non-removable (or fixed) media, or memory 502 may be non-volatile solid-state storage. Memory 502 may be internal or external to the integrated gateway disaster recovery device.

[0114] In one instance, memory 502 may be read-only memory (ROM). In one instance, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically rewritable ROM (EAROM), or flash memory, or a combination of two or more of these.

[0115] Memory 502 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Therefore, generally, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to the first aspect of this disclosure.

[0116] The processor 501 reads and executes computer program instructions stored in the memory 502 to achieve... Figure 1The incremental packet generation method in the illustrated embodiment.

[0117] In one example, the terminal device may also include a communication interface 503 and a bus 504. Wherein, for example... Figure 5 As shown, the processor 501, memory 502, and communication interface 503 are connected through bus 504 and complete communication with each other.

[0118] The communication interface 503 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0119] Bus 504 includes hardware, software, or both, that couples components of an online data traffic metering device together. For example, and not as a limitation, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 504 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0120] Furthermore, in conjunction with the incremental packet generation methods in the above embodiments, this application embodiment can provide a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when executed by a processor, these computer program instructions implement any of the incremental packet generation methods in the above embodiments.

[0121] This application also provides a computer program product, including a computer program that, when executed by a processor, implements any of the incremental package generation methods described above.

[0122] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0123] The functional blocks shown in the above-described structural diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, read-only memory (ROM), flash memory, erasable read-only memory (EROM), floppy disks, compact disc read-only memory (CD-ROM), optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0124] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0125] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in 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, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0126] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A method for generating incremental packets, characterized in that, include: Obtain current version information and target version information, and determine the total upgrade incremental package corresponding to the version difference module based on the current version information and the target version information; Acquire historical fault data and determine the historical upgrade failure probability corresponding to each preset fault category in the historical fault data; If the historical upgrade failure probability exceeds a preset failure probability threshold, the upgrade data corresponding to the preset fault category in the upgrade incremental package will be split into multiple fine-grained incremental sub-packages according to the fault sub-categories in the preset fault category. An upgrade plan is generated based on the dependencies between the version difference modules, and the fine-grained incremental subpackage is sent to the client so that the client can upgrade the corresponding version difference module based on the upgrade plan and the fine-grained incremental subpackage.

2. The method according to claim 1, characterized in that, After sending the fine-grained incremental subpackage to the client so that the client can upgrade the corresponding version difference module based on the upgrade plan and the fine-grained incremental subpackage, the method further includes: Receive the upgrade results returned by the client based on the upgrade of each of the fine-grained incremental sub-packages; If the upgrade result is a failure, obtain the fault log sent by the client, wherein the fault log includes the sub-packet name, error code, and error timestamp of the fine-grained incremental sub-packet; The fault logs are weighted and fused based on a preset rule engine and a machine learning model to obtain the target fault category corresponding to the fault logs.

3. The method according to claim 2, characterized in that, After performing weighted fusion analysis on the fault logs based on a preset rule engine and machine learning model to obtain the target fault category corresponding to the fault logs, the method further includes: Based on the target fault category and the sub-package name, the corresponding version difference module is determined in the current version information; Obtain the complete module data of the version difference module in the current version information; Generate a rollback package based on the complete module data; The rollback packet is sent to the client so that the client can perform a rollback operation on the version difference module in the failed state.

4. The method according to claim 1, characterized in that, The step of obtaining the current version information and the target version information, and determining the total upgrade increment package corresponding to the version difference module based on the current version information and the target version information, includes: Obtain the first hash value set of each module in the current version information, and obtain the second hash value set of each module in the target version information; The modules whose hash values ​​differ in the first hash value set and the second hash value set are identified as version difference modules; The upgrade incremental master package is generated based on the version difference module.

5. The method according to claim 1, characterized in that, After sending the fine-grained incremental subpackage to the client so that the client can upgrade the corresponding version difference module based on the upgrade plan and the fine-grained incremental subpackage, the method further includes: After the upgrade is completed, identify all fault data in the upgraded version difference modules; Based on all the aforementioned fault data, the historical fault data is updated to update the historical upgrade failure probability.

6. The method according to claim 1, characterized in that, After acquiring historical fault data and determining the historical upgrade failure probability corresponding to each preset fault category in the historical fault data, the method further includes: If the historical upgrade failure probability does not exceed the preset failure probability threshold, the upgrade incremental package is divided into multiple coarse-grained incremental sub-packages according to the preset fault category, and each coarse-grained incremental sub-package corresponds to one preset fault category. The coarse-grained incremental sub-package is sent to the client so that the client can upgrade the corresponding version difference module based on the coarse-grained incremental sub-package.

7. An incremental packet generation system, characterized in that, The system includes: The server-side application is used in the incremental packet generation method as described in any one of claims 1-6; The client is used to receive the fine-grained incremental sub-packages sent by the server, upgrade the version difference module based on the fine-grained incremental sub-packages, and report the upgrade results and fault logs to the server.

8. An incremental packet generation apparatus, characterized in that, The device includes: The difference module is used to obtain the current version information and the target version information, and determine the upgrade incremental total package corresponding to the version difference module based on the current version information and the target version information. The acquisition module is used to acquire historical fault data and determine the historical upgrade failure probability corresponding to each preset fault category in the historical fault data; The splitting module is used to split the upgrade data corresponding to the preset fault category in the total upgrade incremental package into multiple fine-grained incremental sub-packages according to the fault sub-categories in the preset fault category when the historical upgrade failure probability exceeds a preset failure probability threshold. An upgrade module is used to generate an upgrade plan based on the dependencies between the version difference modules, and send the fine-grained incremental sub-package to the client so that the client can upgrade the corresponding version difference module based on the upgrade plan and the fine-grained incremental sub-package.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, implement the incremental packet generation method as described in any one of claims 1-7.

10. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the incremental package generation method as described in any one of claims 1-7.

Images