A Software System Update Method, Product, Device, and Storage Medium

Abstract

The present application discloses a software system update method, product, device, and storage medium, relating to the field of computer technologies. It includes: hierarchically partitioning a software system in advance to obtain multiple logical layers, and creating repository branches corresponding to each logical layer in a remote repository of a remote version management system to store version incremental upgrade packages for updating the logical layers. In this way, when it is detected that a software system update is required, the corresponding logical layer can be incrementally upgraded based on the version incremental upgrade package sent by the remote repository for the target repository branch corresponding to the currently to-be-updated logical layer. By dividing the business software system into multiple logical layers and performing independent updates when there are update requirements for each logical layer, the present application can reduce the complexity of updates, improve the update efficiency, and ensure the reliability and continuity of software system upgrades, thereby guaranteeing the system stability and availability for users.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular, to a software system update method, product, device, and storage medium. Background Art

[0002] With the rapid development of digital technology, the complexity of software systems and the diversity of functions are also increasing continuously, which also brings new challenges to software version management and updates. In the process of software system updates using traditional full-update methods, it is usually necessary for users to download the entire program package to their devices and then install it to complete the update. This method not only occupies a large amount of network bandwidth and storage resources but also requires users to wait for a long time, resulting in a reduction in user experience and the risk of data loss, thus affecting the stability and availability of the system. Therefore, how to efficiently and securely update software systems under current architectures such as cloud computing, containerization, and microservices is an urgent problem to be solved currently.

[0003] Currently, the incremental update-based method has changed the file system structure of traditional operating systems and the system startup and version update management methods. It not only supports the incremental update of operating systems but also realizes atomic upgrade and rollback functions. However, this method updates the entire operating system when performing incremental updates. Since there are many components in the operating system, the update frequencies of different components may vary; in addition, when building complex business software systems, the operating system only serves as the infrastructure part of the entire technology stack. In addition to the operating system, the system also includes key components such as databases, middleware, and business software. These components together constitute a multi-layer software architecture, and each layer may contain dependencies on other layers. In such an architecture, the complexity of the update process will increase significantly. For example, an update of middleware may affect multiple services that depend on it, and this dependency relationship may cause a chain reaction in the update operation, thereby affecting the stability of the entire system. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a software system update method, product, device, and storage medium, which can reduce the complexity of software system updates, improve the update efficiency, and ensure the reliability and continuity of software system upgrades, thereby guaranteeing the system stability and availability of users. The specific solutions are as follows:

[0005] In a first aspect, this application discloses a software system update method, which is applied to an immutable operating system located on the client side and includes:

[0006] When it is detected that the remote repository in the remote version management system has been updated, send a request to obtain an upgrade package for the target repository branch to the remote repository; the target repository branch is the repository branch that saves the corresponding version incremental upgrade package when the remote repository detects that any logical layer of the target software system has been updated.

[0007] After receiving the version incremental upgrade package pushed by the remote repository, pull the version incremental upgrade package to the corresponding logical layer in the local inactive partition.

[0008] When it is detected that the business software related to any logical layer needs to be upgraded, restart the target software system and convert the inactive partition into an active partition to perform incremental upgrade on any logical layer by using the version incremental upgrade package in the active partition.

[0009] This application also provides a computer program product, including a computer program, which implements the foregoing software system update method when executed by a processor.

[0010] This application also provides an electronic device, including a processor and a memory; wherein, when the processor executes the computer program saved in the memory, the foregoing software system update method is implemented.

[0011] This application also provides a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, the foregoing software system update method is implemented.

[0012] Through this application, the software system is hierarchically divided in advance to obtain multiple logical layers, and repository branches corresponding to each logical layer are created in the remote repository in the remote version management system to save the version incremental upgrade packages for logical layer updates. Specifically, when it is detected that the remote repository has been updated, first send a request to obtain an upgrade package for the target repository branch corresponding to the currently to-be-updated logical layer to the remote repository, and after receiving the version incremental upgrade package, directly pull it to the corresponding logical layer in the local inactive partition, then restart the software system and convert the inactive partition into an active partition to perform incremental upgrade on the corresponding logical layer by using the version incremental upgrade package. By dividing the business software system into multiple logical layers and performing independent updates when there are update requirements for each logical layer, this application can reduce the complexity of updates and improve the update efficiency. In addition, by hierarchically managing the software system and performing independent updates on each layer, the reliability and continuity of software system upgrades can be ensured, thereby guaranteeing the system stability and availability of users. Thus, problems such as bandwidth waste and long update time caused by business software system updates, as well as compatibility problems after business software system updates, are solved. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] To more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the accompanying drawings required in the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description are only the embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other accompanying drawings can also be obtained based on the provided drawings.

[0014] Figure 1 Flowchart of a software system update method disclosed in the present application;

[0015] Figure 2 Block diagram of a specific software system update system disclosed in the present application;

[0016] Figure 3 Flowchart of a specific software system update method disclosed in the present application;

[0017] Figure 4 Flowchart of a specific dependency acquisition disclosed in the present application;

[0018] Figure 5 Flowchart of a specific software system update method disclosed in the present application. Detailed implementation manners

[0019] The following will clearly and completely describe the technical solutions in the embodiments of the present application in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all embodiments. Based on the embodiments of the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the protection scope of the present application.

[0020] It should be noted that in the description of the present application, the terms "including", "comprising" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such a process, method, article or device. The terms "first", "second", etc. in the present application are used to distinguish similar objects, rather than to describe a specific order or sequence.

[0021] To enable those skilled in the art of the present technology to better understand the solution of the present application, the following will further elaborate on the present application in conjunction with the accompanying drawings and specific implementation manners.

[0022] An embodiment of the present application discloses a software system update method, which is applied to an immutable operating system located at the client side. Refer to Figure 1 As shown, the method includes:

[0023] Step S11: When it is detected that the remote repository in the remote version management system is updated, send a request for obtaining an upgrade package to the remote repository for the target repository branch; the target repository branch is the repository branch that saves the corresponding version incremental upgrade package when the remote repository detects that any logical layer of the target software system has a version update.

[0024] It should be noted that the software system update solution proposed in this application is applied to an immutable operating system (such as Windows system, Linux system, etc.) located on the client side, and this immutable operating system communicates with the remote version management system through a network. The remote version management system includes a remote repository for managing the software versions of each logical layer of the business software. In addition, the immutable operating system also includes a software system for running the user's business software.

[0025] In this embodiment, in order to facilitate the update and maintenance of the software system, optimize the update process, improve the efficiency and security of the update, and at the same time ensure the system stability and availability of the user, before the software system is updated, a multi-level and flexible update framework is constructed for the software system, including a hierarchical design for the immutable operating system and the remote version management system, specifically including: dividing the target software system into multiple logical layers; the multiple logical layers include a core layer, a library layer, a middleware layer, an application layer, and a configuration layer; creating multiple logical layers in each business system partition located in the immutable operating system. Specifically, as shown in Figure 2 As shown, the business software system is divided into multiple logical layers including a core layer, a library layer, a middleware layer, an application layer, and a configuration layer, and each layer contains a series of related files and directories; then, create the above multiple logical layers in the business system partition A and the business system partition B located in the immutable operating system. Among them, one of the business system partition A and the business system partition B is the active partition, and the other is the inactive partition. By default, the business system partition A can be set as the active partition.

[0026] Among them, the core layer is the basic foundation of the entire system architecture, specifically including core components such as the operating system kernel, underlying libraries, and drivers. This layer provides the necessary computing resources and environment for higher-level applications, including key functions such as CPU (Central Processing Unit) scheduling, memory management, data storage, and network communication. Considering the importance of this layer to system stability, the changes in the core layer are extremely limited and the update cycle is long, so as to ensure the stability and security of the system. When updating this layer, it must be very cautious to avoid affecting the normal operation of the system.

[0027] The library layer specifically includes components such as system services, tool libraries, and general dependencies.

[0028] The middleware layer is located above the core layer. The role of this layer is to implement communication between different application components, coordinate data flow and business logic, such as database connection pool, message passing system, and API (Application Programming Interface) management, etc.; compared with the core layer and the library layer, the middleware layer may experience more frequent updates and iterations, aiming to introduce new functions, improve performance or optimize services.

[0029] The application layer is the layer that directly interacts with users, specifically including user interfaces, front-end applications, and back-end logic, etc. This layer is responsible for handling user inputs, presenting data, and implementing business processes. Through this layer, users can directly experience the system functions. In order to respond to user feedback and new function requirements, the application layer may be frequently updated to provide a better user experience and adapt to market changes.

[0030] The configuration layer is responsible for managing the environment settings and parameter configurations of the entire software system, and ensuring that the system can be flexibly configured and adjusted according to different business requirements and environments. For example, it manages the startup parameters, environment variables, etc. of the application. In addition, the configuration layer allows users to make personalized settings to meet the needs of different users. The update frequency of the configuration layer depends on user behavior, so it is dynamic and needs to be adjusted according to the actual situation.

[0031] In addition, refer to Figure 2As shown in the figure, the remote version management system includes two units, namely, a repository management unit and a dependency management unit. Among them, the repository management unit includes a remote repository, and the remote repository contains multiple repository branches. The repository branches are created by taking the file system of the immutable operating system as the version control system tree and creating branches for each logical layer using the version control system tree. The version control system tree is a distributed version control system that supports incremental downloads and rollbacks. The dependency management unit includes a dependency graph, which is used to track the first dependency relationships between each logical layer based on the dependency graph and determine whether the other logical layers related to any logical layer meet the version requirements. If so, the version information of the corresponding target repository branch is updated. In this embodiment, two functional units are created in the remote version management system in advance, namely, a repository management unit and a dependency management unit. Among them, the repository management unit has a remote repository that includes multiple repository branches. The number of the multiple repository branches is the same as that of the multiple logical layers corresponding to the target software system, and there is an association relationship, namely, a core layer branch, a library layer branch, a middleware layer branch, an application layer branch, and a configuration layer branch. Specifically, the creation process of each repository branch is as follows: taking the file system of the immutable operating system as the version control system tree, and then creating corresponding branches for each logical layer using the version control system tree. Each repository branch can manage the updates of the corresponding logical layer. It should be noted that the version control system tree is a distributed version control system that supports incremental downloads and rollback operations. This method not only ensures that different types of files are logically isolated in their own storage layers (i.e., repository branches), but also enables each logical layer to be updated and managed independently. In addition, supporting incremental updates and rollback functions and stratifying the software system can reduce the complexity of software system updates, and at the same time make rollbacks and version management more flexible and simple.

[0032] In addition, the remote version management system also includes a dependency management unit, which is used to track the dependency relationships between layers to ensure the compatibility and stability of each layer during the update process. Moreover, this unit includes a pre-created dependency graph and an efficient dependency resolution mechanism, so as to ensure that the dependency relationships between each level are effectively managed during hierarchical incremental updates and avoid compatibility problems caused by updates. For example, when planning to update the branch where a certain logical layer is located, the dependency management unit will first scan the dependency graph, and then check whether the other logical layers on which this layer depends meet the version requirements (such as whether the version numbers of system components and / or software packages are the same, that is, whether they have the same version) based on the identified dependency relationships between each logical layer. If so, subsequent update operations will be performed, that is, the version information of the corresponding target repository branch will be updated, so as to prevent compatibility problems caused by updates.

[0033] In a specific embodiment, it may further include: if other logic layers related to any logic layer do not meet the version requirements, the dependency management unit responds according to a preset policy; the preset policy includes generating an alarm prompt message indicating that the version of other logic layers does not meet the requirements. For example, if the versions of other logic layers related to the logic layer to be updated currently are inconsistent, the dependency management unit generates an alarm prompt message indicating that the versions of other logic layers do not meet the requirements, so as to remind the corresponding user using the client to perform corresponding processing according to the alarm prompt message, so as to solve the problem of version inconsistency and continue to execute the subsequent software system update process after solving the inconsistency problem.

[0034] In another specific embodiment, it may further include: if other logic layers related to any logic layer do not meet the version requirements, the dependency management unit automatically selects the latest compatible version to update the versions of other logic layers, and performs version compatibility detection after the version update. In this embodiment, if other logic layers related to the logic layer to be updated currently do not meet the version requirements, the dependency management unit can automatically select the latest compatible version, use the latest compatible version to update the versions of other dependent logic layers, and then perform version compatibility detection after the version update. If the versions are the same or compatible, the subsequent software system update process is continued.

[0035] It should be noted that the management process of the dependency management unit occurs after the remote repository is updated but before the software system is actually updated. Such a design can bring forward the risk. When updating the remote repository, compatibility analysis is performed in advance. If there are compatibility problems with other dependent logic layers, they are solved in advance, either by modifying this logic layer or by updating other dependent logic layers. If the compatibility problem is solved during the actual software system update, it may result in incompatibility and cause the system to roll back to the previous version.

[0036] Specifically, the process of constructing a dependency graph may specifically include: obtaining the metadata of each logical layer respectively to obtain hierarchical metadata information; the hierarchical metadata information includes the layer identifiers corresponding to each logical layer, as well as the system components and the version numbers of the system components included in each logical layer; obtaining the second dependencies between each software package and other software packages in the system components respectively, and constructing a structured data format based on the second dependencies and the hierarchical metadata information; taking each software package in the system components as a node in the graph respectively, and assigning a unique key value to each node; the key in the key value is the name of the system component, and the value is a list containing the names and version numbers of the other software packages on which the node depends; traversing the structured data format, and adding the key values of the corresponding software packages to the hash adjacency list based on the identified dependencies to generate a dependency graph. For example, considering that the configuration layer mainly involves business and system-related configurations and does not contain dependency problems, when collecting hierarchical metadata, only the metadata information of the core layer, middleware layer, and application layer can be systematically collected, and during the collection process, a unique identifier is assigned to each logical layer, such as the logical layer ID (Identity document, unique encoding), and the specific system components and their version numbers included in each logical layer are recorded in detail. After collecting the hierarchical metadata information of each logical layer, further, the dependency relationship between the open-source software packages and other software packages in the system components can be scanned through the dependency resolution tool provided by the operating system, and then a structured data format, such as a JSON (JavaScript Object Notation) format data structure, is constructed based on the dependency relationship and the hierarchical metadata information.

[0037] It should be noted that for the business-related software packages or other types of system components constructed by users themselves, their dependency relationships need to be defined manually.

[0038] Further, create a hash adjacency list and construct a dependency graph based on the hash adjacency list. Specifically, each software package in the system components can be taken as a node in the graph first, and a unique key value is assigned to each node, where the key in the key value is the name of the system component, and the value is a list that stores the names and version numbers of the other software packages on which each software package in the component depends.

[0039] Finally, traverse the JSON format data structure. For a single software package, first traverse its dependency relationship, which is obtained from the JSON format data structure. For each identified dependency, the name and version number of the corresponding software package can be added to the hash adjacency list, thereby generating a dependency graph. It should be noted that the dependency graph is a directed graph, where each node in the graph represents a software package, and each node points to the directed edge of the other software packages it depends on. A specific example of the dependency graph is as follows:

[0040] Software A: [B, C, Z, H];

[0041] Software B: [D, C, V, L];

[0042] Software C: [E, F, G];

[0043] Software D: [A, F, O].

[0044] As can be seen from the above dependency graph, the other software that Software A depends on includes Software B, Software C, Software Z, and Software H; the other software that Software B depends on includes Software D, Software C, Software V, and Software L.

[0045] Specifically, the second dependency relationships between each software package in the system components and other software packages are obtained respectively, and a structured data format is constructed based on the second dependency relationships and the hierarchical metadata information. This may include: representing the hierarchical metadata information according to a preset data structure to obtain the represented metadata information; obtaining the second dependency relationships between each software package in the system components and other software packages respectively, and constructing a structured data format based on the second dependency relationships and the represented metadata information. In this embodiment, the hierarchical metadata information can be represented according to a preset data structure to obtain the represented metadata information, and then the dependency relationships between each software package in the system components and other software packages are obtained respectively, and a structured data format is constructed based on the obtained dependency relationships and the represented metadata information. By representing the hierarchical metadata information according to a preset data structure, it is convenient to manage the hierarchical metadata information and is beneficial to data processing in subsequent update processes.

[0046] In a specific embodiment, representing the hierarchical metadata information according to a preset data structure to obtain the represented metadata information may specifically include: representing the hierarchical metadata information according to a dictionary data structure to obtain the represented metadata information; the dictionary data structure is a data structure based on key-value pairs, where the key in the key-value pair is the name of the software package, and the value in the key-value pair is the version number of the corresponding software package. That is, the hierarchical metadata information is represented based on a data structure of key-value pairs. For example, package_versions = { "LibA": "1.2.3", "LibB": "2.1.0", "LibC": "3.0.1"}. Of course, other data structures similar to the dictionary data structure can also be used to represent the hierarchical metadata information.

[0047] Specifically, based on the first dependency relationship, it is determined whether other logical layers related to any logical layer meet the version requirements. If so, the version information of the corresponding target repository branch can be updated, which may include: determining other system components on which any current logical layer depends based on the first dependency relationship, and searching for the names and version numbers of software packages corresponding to other system components in a structured data format to obtain the first package name and the first package version number; obtaining the names and version numbers of the current other system components to obtain the second package name and the second package version number; determining whether the first package name matches the second package name, and whether the corresponding first package version number matches the second package version number; if the first package name matches the second package name, and the corresponding first package version number matches the second package version number, an incremental update is performed on the version information of the corresponding target repository branch. In this embodiment, in order to ensure that the software system can properly handle the inter-layer dependency relationship during the update process, before updating the software system, the dependency resolution mechanism located in the remote version management system can be used to identify and verify other logical layers on which any current logical layer to be updated depends, so as to ensure that all dependency conditions are met. Specifically, before performing an incremental update on any logical layer, the dependency graph can be scanned through the dependency resolution mechanism, and then based on the scanned dependencies, other system components on which any current logical layer depends are determined, and the names and version numbers of software packages corresponding to the other system components on which the dependency depends are searched in a structured data format, and then the names and version numbers of the searched software packages are compared with the names and version numbers of other system components on which any logical layer to be updated depends. If the two match, it indicates that the two versions are compatible and there are no compatibility issues. At this time, an incremental update can be performed on the version information of the corresponding target repository branch.

[0048] Specifically, each software package in the system components is regarded as a node in the graph, and a unique key value is assigned to each node, which may include: regarding each software package in the system components located in each logical layer as a node in the graph, and assigning a unique key value to each node in the corresponding logical layer; the key in the key value includes the level where the logical layer is located and the name of the system component, and the value is a list containing the names and version numbers of other software packages on which the node depends; correspondingly, based on the identified dependencies, the key values of the corresponding software packages are added to the hash adjacency list to generate a dependency graph, which may specifically include: adding the key values of the software packages in the corresponding logical layer to the hash adjacency list based on the identified dependencies to obtain the inter-layer dependency graphs corresponding to each logical layer. In this embodiment, considering the complexity of the operating system and the improvement of the dependency relationship search efficiency, an inter-layer dependency graph can be constructed. The inter-layer dependency graph is a dependency graph constructed for each level to show the dependency relationships of the software packages within that level. It should be noted that the inter-layer dependency graph shows all the dependency relationships of the software packages within this level, including cross-layer dependency relationships. Specifically, each software package within the system components in each logical layer can be regarded as a node in the graph, and a unique key value is assigned to each node in that logical layer; the key in the key value includes the level where the current logical layer is located and the name of the system component, and the value is a list containing the names and version numbers of other software packages on which the current node depends; further, a structured data format (such as a JSON data structure) can be traversed, and then the key values of the software packages in the corresponding logical layer are added to the hash adjacency list based on the identified dependencies, so as to obtain the inter-layer dependency graphs corresponding to each logical layer. By constructing inter-layer dependency graphs for each logical layer, not only can the dependency relationships between all software package nodes in each logical layer be intuitively shown, facilitating the management of dependency relationships, reducing the complexity of the dependency relationships between software packages, thereby improving the dependency relationship search efficiency, and further improving the software system update efficiency. Moreover, in this application, the entire software system is divided into multiple layers, each layer is updated separately, and by constructing inter-layer dependency graphs, the relationships between layers are dynamically analyzed and identified, so that the dependency relationships are automatically identified during the software system update, ensuring the security and stability of the update process. In addition, by hierarchically managing the software system and independently updating each layer, the software system management becomes more convenient.

[0049] In this embodiment, after constructing the update framework as shown in Figure 2 When it is detected that the remote repository in the remote version management system has been updated, a request for obtaining an upgrade package for the target repository branch to be updated can be sent to the remote repository first. Among them, the target repository branch is the repository branch that saves the corresponding version incremental upgrade package (i.e., the data to be updated) when any logical layer of the target software system is detected to have a version update in the remote repository.

[0050] Step S12: After receiving the version incremental upgrade package pushed by the remote repository, pull the version incremental upgrade package to the corresponding logic layer in the local inactive partition.

[0051] In this embodiment, after receiving the version incremental upgrade package pushed by the remote repository, it can be pulled to the corresponding logic layer in the local inactive partition. For example, pull the version incremental upgrade package to Figure 2 the corresponding configuration layer in the business system partition B.

[0052] Step S13: When it is detected that the business software related to any logic layer needs to be upgraded, restart the target software system and convert the inactive partition into an active partition, so as to perform incremental upgrade on any logic layer by using the version incremental upgrade package in the active partition.

[0053] In this embodiment, when it is detected that the business software related to any logic layer to be updated currently, such as word software, ppt software, Excel software, etc. in the office software system needs to be upgraded, restart the office software system and convert the inactive partition (business system partition B) into an active partition, so as to perform incremental upgrade on any logic layer to be updated currently by using the version incremental upgrade package in this active partition, and the system is the new version.

[0054] In a specific implementation manner, as shown in Figure 3 the following steps can be used to implement the update of the entire software system:

[0055] Step S21: When an update requirement for any logic layer in the target software system is detected, generate an update package for the target logic layer and generate a list of components to be updated at the same time. The update package can be obtained by the developer after packing the update data of the corresponding logic layer, and no processing is performed on other logic layers, that is, other levels remain unchanged. Through this layered update method, it can ensure that each part of the system is updated independently, thereby improving flexibility and maintainability. At the same time, the update risk is reduced because only one level is updated each time, rather than the entire system.

[0056] Step S22: According to the dependency resolution mechanism, traverse the dependency graph and check all dependencies in the dependency graph to identify all dependency relationships related to the update package. Specifically, in the remote version management system, a dependency graph is constructed for each level. The dependency graph details the dependency relationships of the software packages at this level, including cross-level dependency relationships. During the process of traversing the dependency graph, the dependencies of each component will be checked one by one, and during the traversal process, other components on which the update package depends will be identified, and then the current version number of the dependency will be searched in the data structure obtained based on the metadata information and compared with the dependencies of the software version to be updated. If there is no dependency problem, the update package will be submitted to the remote repository.

[0057] Specifically, refer to Figure 4 shown below. Step S22 can be implemented according to the following steps:

[0058] Step S201: Obtain the information related to the update package in step S21, specifically including the list of software packages in the update package, the other software packages on which each software package depends, the version numbers of the other software packages on which it depends, and the level where the software package is located.

[0059] Step S202: Traverse the list of software packages obtained in step S201. For each software package, the dependency relationship can be queried from the collected list of hierarchical metadata information. It should be noted that for the dependency check of the update package, there is no need to traverse the dependency graph. A preliminary search can be directly performed in the list of hierarchical metadata information. If the dependency relationship is satisfied, it can be directly determined that there is no dependency problem with the update package.

[0060] Step S203: Compare the version numbers of the other software packages on which each software package depends with the version numbers of the queried software packages to determine whether the dependency relationship is satisfied. If it is satisfied, go to step S204; if not, go to S205.

[0061] Step S204: Output the items where the dependency relationship is not satisfied, including the software package and the other software packages on which it depends and their version numbers.

[0062] Step S205: Determine whether the traversal of the list of software packages is completed. If so, go to step S206; if not, return to step S202.

[0063] Step S206: Submit the update package to the remote repository.

[0064] Step S23: Resolve the dependency conflicts according to the dependency analysis situation, re-check the dependency relationship, and finally submit the update package without dependency problems to the remote repository. Specifically, if there are conflicts in the dependency relationship, update the software packages with dependency problems in the system. Generally, it is a version upgrade process. After the upgrade, it is necessary to re-check the dependencies of this version. At this time, it is necessary to traverse the dependency graph to confirm that the dependency relationship can meet the conditions.

[0065] It should be noted that the detection methods of this step (step S23) and the previous step (step S22) are different. The difference is that step S22 directly detects the dependency relationship of the software packages to be updated. This action does not require traversing the dependency graph. It only needs to search the list of hierarchical metadata information. If it is satisfied, there is no need to perform a complex dependency graph traversal operation. Only when the dependency is not satisfied, the dependency confirmation operation is performed. At this time, the dependency relationship represented by the dependency graph will be checked. Proceeding step by step in this way can avoid wasting search time.

[0066] Step S24: When the client detects a version update request for the software system, it can first detect the network bandwidth, identify the network idle period, and when the local network meets the condition (being in the network idle period), pull the incremental update package to the inactive partition.

[0067] Step S25: In response to the update requirement of the software system, restart the software system and convert the inactive partition into an active partition, thus completing the update of the software system.

[0068] It can be seen that in the embodiment of the present application, the software system is hierarchically divided in advance to obtain multiple logical layers, and repository branches corresponding to each logical layer are created in the remote repository in the remote version management system to store the version incremental upgrade packages for the update of the logical layer. Specifically, when it is detected that the remote repository is updated, first send a request to obtain the upgrade package for the target repository branch corresponding to the currently to-be-updated logical layer to the remote repository, and after receiving the version incremental upgrade package, directly pull it to the corresponding logical layer in the local inactive partition, then restart the software system and convert the inactive partition into an active partition to perform incremental upgrade on the corresponding logical layer by using the version incremental upgrade package. In the embodiment of the present application, by dividing the business software system into multiple logical layers and performing independent updates when there are update requirements for each logical layer, the complexity of the update can be reduced and the update efficiency can be improved. In addition, by performing hierarchical management on the software system and performing independent updates on each layer, the reliability and continuity of the software system upgrade can be ensured, thereby guaranteeing the system stability and availability of the user. Thus, the problems such as bandwidth waste and long update time caused by the update of the business software system, and the compatibility problem after the update of the business software system are solved.

[0069] The embodiment of the present application discloses a specific software system update method, which is applied to an immutable operating system located at the client. Refer to Figure 5 as shown, the method includes:

[0070] Step S31: When it is detected that the remote repository in the remote version management system is updated, determine whether the current local network bandwidth meets the preset bandwidth condition.

[0071] In this embodiment, when it is detected that the remote repository in the remote version management system is updated, the usage of the current network bandwidth can be detected first to determine whether the current local network bandwidth meets the preset bandwidth condition. For example, check whether the current local network bandwidth is in the network idle period.

[0072] Step S32: If the local network bandwidth meets the preset bandwidth condition, send a request to the remote repository to obtain an upgrade package for the target repository branch; the target repository branch is the repository branch that saves the corresponding version incremental upgrade package when the remote repository detects a version update in any logical layer of the target software system.

[0073] In this embodiment, if the current local network bandwidth is in a network idle period, send a request to the remote repository to obtain an upgrade package for the target repository branch.

[0074] Step S33: After receiving the version incremental upgrade package pushed by the remote repository, cache the version incremental upgrade package in the corresponding storage space of the local repository, and pull the version incremental upgrade package from the corresponding storage space of the local repository to the corresponding logical layer in the local inactive partition; the local repository and the remote repository have the same hierarchical structure and directory structure.

[0075] In this embodiment, after receiving the version incremental upgrade package pushed by the remote repository, it can be cached in the corresponding storage space of the local repository, and the version incremental upgrade package is pulled from the corresponding storage space of the local repository to the corresponding logical layer in the local inactive partition; it should be noted that the local repository and the remote repository have the same hierarchical structure and directory structure. For example, the number of storage spaces in the local repository is the same as the number of all repository branches in the remote repository, and there is an association relationship. For example, when the data in any repository branch is pushed to the local repository, the local repository will cache the updated data in the storage space corresponding to any repository branch.

[0076] Step S34: When it is detected that the business software related to any logical layer needs to be upgraded, restart the target software system, and convert the inactive partition to an active partition to perform incremental upgrade on any logical layer by using the version incremental upgrade package in the active partition.

[0077] Among them, for a more specific processing process of the above step S34, reference can be made to the corresponding content disclosed in the foregoing embodiments, and details will not be elaborated here.

[0078] It can be seen that the embodiment of the present application updates the software system in an incremental update manner, thereby shortening the update time, improving the update efficiency, and at the same time, when there are problems with the updated version, it can be rolled back to the old version. Moreover, before updating the software system, the present application detects the current local network bandwidth, thereby solving problems such as bandwidth waste and long update time caused by the update of the software system. In addition, by performing hierarchical management on the software system and independently updating each logical layer, the problem of complex traditional incremental updates is solved.

[0079] Embodiments of the present application also provide a software system update device. For the descriptions of the features in the corresponding embodiments of the process recovery device, reference can be made to the relevant descriptions in the corresponding embodiments of the process recovery method, which will not be elaborated here one by one.

[0080] Embodiments of the present application also provide an electronic device, including a memory and a processor. A computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any of the above embodiments of the software system update method.

[0081] Embodiments of the present application also provide a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps in any of the above embodiments of the software system update method when running.

[0082] In an exemplary embodiment, the above computer-readable storage medium may include, but is not limited to: various media such as USB flash drives, read-only memories (ROMs for short), random access memories (RAMs for short), mobile hard disks, magnetic disks, or optical discs that can store computer programs.

[0083] Embodiments of the present application also provide a computer program product. The above computer program product includes a computer program, and when the computer program is executed by a processor, the steps in any of the above embodiments of the software system update method are implemented.

[0084] Embodiments of the present application also provide another computer program product, including a non-volatile computer-readable storage medium. The non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above embodiments of the software system update method are implemented.

[0085] Those skilled in the art can further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described according to their functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present application.

[0086] The above has introduced in detail a software system update method, product, device, and storage medium provided by this application. Specific examples are used in this article to elaborate on the principle and implementation manner of this application. The description of the above embodiments is only used to help understand the method and its core idea of this application. It should be noted that for those of ordinary skill in the art, without departing from the principle of this application, several improvements and modifications can still be made to this application, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. A software system update method, characterized in that, Applied to an immutable operating system located on a client, including: When it is detected that the remote repository in the remote version management system is updated, send a request for obtaining an upgrade package for the target repository branch to the remote repository; the target repository branch is the repository branch that saves the corresponding version incremental upgrade package when the remote repository detects that any logical layer of the target software system has a version update; When the version incremental upgrade package pushed by the remote repository is received, pull the version incremental upgrade package to the corresponding logical layer in the local inactive partition; When it is detected that the business software related to any logical layer needs to be upgraded, restart the target software system and convert the inactive partition into an active partition to perform incremental upgrade on any logical layer by using the version incremental upgrade package in the active partition; The method further includes: dividing the target software system into multiple logical layers including a core layer, a library layer, a middleware layer, an application layer, and a configuration layer; creating the multiple logical layers in each business system partition of the immutable operating system respectively; The remote version management system includes: a repository management unit and a dependency management unit; The repository management unit includes a remote repository containing multiple repository branches; the repository branch is a branch created for each logical layer by using the file system of the immutable operating system as a version control system tree; the version control system tree is a distributed version control system that supports incremental download and rollback; The dependency management unit includes a dependency graph for tracking the first dependency relationship between each logical layer based on the dependency graph, and judging whether other logical layers related to any logical layer meet the version requirements based on the first dependency relationship. If so, update the version information of the corresponding target repository branch.

2. The software system update method according to claim 1, wherein It further includes: If other logical layers related to any logical layer do not meet the version requirements, respond according to a preset policy through the dependency management unit; The preset policy includes generating an alarm prompt message indicating that the version of the other logical layer does not meet the requirements.

3. The software system update method according to claim 1, wherein It further includes: If other logical layers related to any logical layer do not meet the version requirements, automatically select the latest compatible version through the dependency management unit to update the version of the other logical layer, and perform version compatibility detection after the version update.

4. The software system update method according to claim 1, wherein The construction process of the dependency graph includes: Obtain the metadata of each logical layer respectively to obtain hierarchical metadata information; the hierarchical metadata information includes the layer identifier corresponding to each logical layer, as well as the system components included in each logical layer and the version numbers of the system components; Obtain the second dependency relationship between each software package in the system components and other software packages respectively, and construct a structured data format based on the second dependency relationship and the hierarchical metadata information; Take each software package in the system components as a node in the graph, and assign a unique key value to each node; the key in the key value is the name of the system component, and the value is a list containing the names and version numbers of other software packages on which the node depends. Traverse the structured data format and add the key values of the corresponding software packages to the hash adjacency list based on the identified dependencies to generate a dependency graph.

5. The software system update method according to claim 4, wherein The steps of separately obtaining the second dependency relationships between each software package in the system components and other software packages and constructing a structured data format based on the second dependency relationships and the hierarchical metadata information include: Represent the hierarchical metadata information according to a preset data structure to obtain the represented post-metadata information; Separate obtain the second dependency relationships between each software package in the system components and other software packages, and construct a structured data format based on the second dependency relationships and the represented post-metadata information.

6. The software system update method according to claim 5, wherein The step of representing the hierarchical metadata information according to a preset data structure to obtain the represented post-metadata information includes: Represent the hierarchical metadata information according to a dictionary data structure to obtain the represented post-metadata information; the dictionary data structure is a data structure based on key-value pairs, the key in the key-value pair is the name of the software package, and the value in the key-value pair is the version number of the corresponding software package.

7. The software system update method according to claim 4, wherein Based on the first dependency relationship, determine whether other logical layers related to any one of the logical layers meet the version requirements. If so, update the version information of the corresponding target repository branch, including: Based on the first dependency relationship, determine other system components on which the current any one of the logical layers depends, and search for the name and version number of the software package corresponding to the other system components in the structured data format to obtain the first package name and the first package version number; Obtain the name and version number of the current other system components to obtain the second package name and the second package version number; Determine whether the first package name matches the second package name, and whether the corresponding first package version number matches the second package version number; If the first package name matches the second package name, and the corresponding first package version number matches the second package version number, incrementally update the version information of the corresponding target repository branch.

8. The software system update method according to claim 4, wherein The step of taking each software package in the system components as a node in the graph and assigning a unique key value to each node includes: Take each software package in the system components located in each logical layer as a node in the graph, and assign a unique key value to each node in the corresponding logical layer; the key in the key value includes the level where the logical layer is located and the name of the system component, and the value is a list containing the names and version numbers of other software packages on which the node depends; Correspondingly, the step of adding the key values of the corresponding software packages to the hash adjacency list based on the identified dependencies to generate a dependency graph includes: Based on the identified dependencies, add the key values of the software packages in the corresponding logical layer to the hash adjacency list to obtain the inter-layer dependency graphs corresponding to each logical layer.

9. The software system update method according to any one of claims 1 to 8, characterized in that When it is monitored that the remote repository in the remote version management system is updated, send a request for obtaining an upgrade package for the target repository branch to the remote repository, including: When it is detected that the remote repository in the remote version management system is updated, determine whether the current local network bandwidth meets the preset bandwidth condition; If the local network bandwidth meets the preset bandwidth condition, send a request to obtain an upgrade package for the target repository branch to the remote repository.

10. The software system update method according to claim 9, wherein The step of pulling the version incremental upgrade package to the corresponding logic layer in the local inactive partition includes: Caching the version incremental upgrade package in the corresponding storage space of the local repository, and pulling the version incremental upgrade package from the corresponding storage space of the local repository to the corresponding logic layer in the local inactive partition; the local repository has the same hierarchical structure and directory structure as the remote repository.

11. An electronic device, characterized in that, Including: A memory for storing a computer program; A processor for implementing the steps of the software system update method according to any one of claims 1 to 10 when executing the computer program.

12. A computer-readable storage medium, characterized in that, A computer program is stored in the computer-readable storage medium, wherein the computer program implements the steps of the software system update method according to any one of claims 1 to 10 when executed by a processor.

13. A computer program product, comprising a computer program, characterized in that, The computer program implements the steps of the software system update method according to any one of claims 1 to 10 when executed by a processor.

Images