Software system updating method, product, equipment and storage medium

Abstract

The invention discloses a software system updating method, a product, equipment and a storage medium, and relates to the technical field of computers, and the software system updating method comprises the following steps: carrying out hierarchical division on a software system in advance to obtain a plurality of logic layers, and creating warehouse branches corresponding to the logic layers in a remote storage library in a remote version management system, according to the method, the version increment upgrade package used for logic layer updating is stored, and therefore when it is monitored that software system updating needs to be carried out, increment upgrade can be carried out on the corresponding logic layer on the basis of the version increment upgrade package, sent by the far-end storage library, of the target warehouse branch corresponding to the current to-be-updated logic layer. According to the method and the device, the business software system is divided into the plurality of logic layers, and independent updating is carried out when each logic layer has an updating requirement, so that the updating complexity can be reduced, the updating efficiency is improved, the reliability and continuity of software system upgrading are ensured, and the system stability and availability of a user are further ensured.

Description

Technical Field

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

[0002] With the rapid development of digital technology, the complexity and functional diversity of software systems are also increasing, which also brings new challenges to software version management and updates. The traditional full update method usually requires users to download the entire program package to their devices and then install it to complete the update. This method not only takes up a lot of network bandwidth and storage resources, but also requires users to wait for a long time, resulting in a decrease in user experience and the risk of data loss, which affects 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.

[0003] At present, the incremental update method has changed the file system structure and system startup and version update management methods of the traditional operating system. It not only supports incremental updates of the operating system, but also realizes atomic upgrades and rollback functions. However, this method updates the entire operating system when performing incremental updates. Due to the large number of operating system components, the update frequency of different components may be different; in addition, when building a complex business software system, the operating system is only used as the infrastructure part of the entire technology stack. In addition to the operating system, the system also contains key components such as databases, middleware, and business software. These components together constitute a multi-layered software architecture. 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 the middleware may affect multiple services that depend on it. This dependency relationship may cause the update operation to trigger a chain reaction, 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 efficiency of updates, and ensure the reliability and continuity of software system upgrades, thereby ensuring the stability and availability of the user's system. The specific scheme is as follows:

[0005] In a first aspect, the present application discloses a software system update method, which is applied to an immutable operating system located at a client, comprising:

[0006] When an update is detected in a remote repository in a remote version management system, an upgrade package acquisition request for a target repository branch is sent to the remote repository; the target repository branch is a repository branch that stores the corresponding version incremental upgrade package when the remote repository detects a version update in any logical layer of the target software system;

[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, the target software system is restarted and the inactive partition is converted to an active partition to perform an incremental upgrade on any logical layer using the version incremental upgrade package in the active partition.

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

[0010] The present application also provides an electronic device, comprising a processor and a memory; wherein the processor implements the aforementioned software system update method when executing a computer program stored in the memory.

[0011] The present application also provides a computer-readable storage medium for storing a computer program; wherein the computer program implements the aforementioned software system update method when executed by a processor.

[0012] Through this application, the software system is hierarchically divided in advance to obtain multiple logical layers, and a warehouse branch corresponding to each logical layer is created in the remote repository in the remote version management system to save the incremental version upgrade package for updating the logical layer. Specifically, when the remote repository is monitored to be updated, an upgrade package acquisition request for the target warehouse branch corresponding to the current logical layer to be updated is first sent to the remote repository, and after receiving the incremental version upgrade package, it is directly pulled to the corresponding logical layer in the local inactive partition, and then the software system is restarted, and the inactive partition is converted to an active partition to use the incremental version upgrade package to incrementally upgrade the corresponding logical layer. This application divides the business software system into multiple logical layers and independently updates each logical layer when there is an update requirement, which can reduce the complexity of the update and improve the efficiency of the update. In addition, by managing the software system in layers and independently updating each layer, the reliability and continuity of the software system upgrade can be ensured, thereby ensuring the stability and availability of the user's system. Thereby solving the problems of bandwidth waste and long update time caused by the update of the business software system, as well as the compatibility problem after the business software system is updated. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0014] Figure 1 A flowchart of a software system updating method disclosed in this application;

[0015] Figure 2 A block diagram of a specific software system update system disclosed in this application;

[0016] Figure 3 A flowchart of a specific software system updating method disclosed in this application;

[0017] Figure 4 A specific dependency acquisition flow chart disclosed in this application;

[0018] Figure 5 This is a flow chart of a specific software system updating method disclosed in this application. DETAILED DESCRIPTION

[0019] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

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

[0021] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below in conjunction with the accompanying drawings and specific implementation methods.

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

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

[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 at the client, and the immutable operating system is connected to the remote version management system through a network, and the remote version management system includes a remote repository for managing the software version of each logical layer of the business software. In addition, the immutable operating system also includes a software system for running user 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 stability and availability of the user's system, before the software system is updated, a multi-level and flexible update framework is constructed for the software system, including a layered design of the immutable operating system and the remote version management system, specifically including: hierarchical division of the target software system to obtain multiple logical layers; the multiple logical layers include the core layer, library layer, middleware layer, application layer and configuration layer; and multiple logical layers are created in each business system partition located in the immutable operating system. For details, see Figure 2 As shown, the business software system is divided into multiple logical layers including the core layer, library layer, middleware layer, application layer and configuration layer, and each layer contains a series of related files and directories; then, the above multiple logical layers are created 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 an active partition and the other is an inactive partition. By default, the business system partition A can be set as the active partition.

[0026] The core layer is the foundation of the entire system architecture, 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, changes to the core layer are extremely limited and the update cycle is long, thereby ensuring system stability and security. When updating this layer, you 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 common dependencies.

[0028] The middleware layer is located above the core layer. Its function is to realize the communication, data flow and business logic coordination between different application components, such as database connection pool, messaging system and API (Application Programming Interface) management. Compared with the core layer and library layer, the middleware layer may experience more frequent updates and iterations in order to introduce new features, improve performance or optimize services.

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

[0030] The configuration layer is responsible for managing the environment settings and parameter configuration of the entire software system, and ensuring that the system can be flexibly configured and adjusted according to different business needs and environments, for example, managing application startup parameters, environment variables, etc. 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 actual conditions.

[0031] Also, see Figure 2As shown, the remote version management system includes two units, namely, a repository management unit and a dependency management unit; wherein the repository management unit includes a remote repository, and the remote repository contains multiple repository branches; the repository branch is a branch created for each logical layer using the file system of the immutable operating system as a version control system tree, and using the version control system tree; the version control system tree is a distributed version control system, which supports incremental download and rollback; the dependency management unit includes a dependency graph, which is used to track the first dependency relationship between each logical layer based on the dependency graph, and to determine whether other logical layers related to any logical layer meet the version requirements based on the first dependency relationship, and if so, the version information of the corresponding target repository branch is updated. In this embodiment, two functional units are pre-created in the remote version management system, namely, a repository management unit and a dependency management unit; wherein the repository management unit has a remote repository including multiple repository branches, and the multiple repository branches are the same in number as 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 process of creating each warehouse branch is as follows: the file system of the immutable operating system is used as the version control system tree, and then the version control system tree is used to create corresponding branches for each logical layer. Each warehouse branch can manage the update of the corresponding logical layer. It should be pointed out that the version control system tree is a distributed version control system that supports incremental download and rollback operations. This method not only ensures that different types of files are logically isolated in their own storage layers (i.e., warehouse branches), but also enables each logical layer to be updated and managed independently. In addition, supporting incremental updates and rollback functions and layering the software system can reduce the complexity of software system updates, while making rollback 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 dependencies between layers and ensure the compatibility and stability of each layer during the update process. In addition, the unit includes a pre-created dependency graph and an efficient dependency resolution mechanism to ensure that the dependencies between the various levels are effectively managed when performing layered incremental updates and to avoid compatibility issues 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 the 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 dependencies between the various logical layers. If so, subsequent update operations will be performed, that is, the version information of the corresponding target warehouse branch will be updated to prevent compatibility issues caused by the update.

[0033] In a specific implementation, it may also include: if other logical layers related to any logical layer do not meet the version requirements, responding according to a preset strategy through a dependency management unit; the preset strategy includes generating alarm prompt information for other logical layers that do not meet the requirements. For example, if the versions of other logical layers related to the current logical layer to be updated are inconsistent, an alarm prompt information about other logical layers that do not meet the requirements is generated through the dependency management unit, thereby reminding the corresponding user using the client to perform corresponding processing according to the alarm prompt information, so as to solve the version inconsistency problem, and continue to execute the subsequent software system update process after solving the inconsistency problem.

[0034] In another specific implementation, it may also include: if other logical layers related to any logical layer do not meet the version requirements, the dependency management unit automatically selects the latest compatible version to perform version updates on other logical layers, and performs version compatibility detection after the version update. In this embodiment, if other logical layers related to the current logical layer to be updated do not meet the version requirements, the dependency management unit automatically selects the latest compatible version, and uses the latest compatible version to perform version updates on other dependent logical layers, and then performs version compatibility detection after the version update, and if the versions are consistent or compatible, the subsequent software system update process continues.

[0035] It should be pointed out that the management process of the dependency management unit occurs after the remote repository is updated, but before the software system is actually updated. This design can put risks in front of the scenes. When updating the remote repository, compatibility analysis can be done in advance. If there are compatibility issues in other dependent logic layers, they can be resolved in advance, either by modifying the current logic layer or by updating other dependent logic layers. If compatibility issues are resolved when the actual software system is updated, incompatibility may occur, causing the system to roll back to the previous version.

[0036] Specifically, the process of constructing a dependency graph may include: obtaining metadata of each logical layer to obtain hierarchical metadata information; the hierarchical metadata information includes the layer identifier corresponding to each logical layer, and the system components and the version numbers of the system components contained in each logical layer; obtaining the second dependency relationship between each software package in the system component and other software packages, and constructing a structured data format based on the second dependency relationship and the hierarchical metadata information; treating each software package in the system component as a node in the graph, 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 of names and version numbers of other software packages that the node depends on; traversing the structured data format, and adding the key value of the corresponding software package to the hash adjacency table 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 include dependency issues, when collecting hierarchical metadata, only the metadata information of the core layer, middleware layer, and application layer can be systematically collected, and in the process of collecting, a unique identifier is assigned to each logical layer, such as a logical layer ID (Identity document, unique code), and the specific system components and their version numbers contained in each logical layer are recorded in detail. After collecting the hierarchical metadata information of each logical layer, the dependency resolution tool provided by the operating system can be used to scan the dependencies between the open source software packages and other software packages in the system components, and then a structured data format, such as a data structure in JSON (JavaScript Object Notation) format, can be constructed based on the dependencies and the hierarchical metadata information.

[0037] It should be pointed out that for business-related software packages or other types of system components built by users themselves, their dependencies need to be defined manually.

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

[0039] Finally, traverse the data structure in JSON format. For a single software package, first traverse its dependencies, which are obtained from the data structure in JSON format. For each identified dependency, the name of the corresponding software package and its version number can be added to the hash adjacency list to generate a dependency graph. It should be pointed out that the dependency graph is a directed graph. Each node in the graph represents a software package, and each node points to the directed edges of other software packages it depends on. The 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] From the above dependency graph, we can see that other software that software A depends on includes software B, software C, software Z and software H; other software that software B depends on includes software D, software C, software V and software L.

[0045] Specifically, respectively obtaining the second dependency relationship between each software package and other software packages in the system component, and constructing a structured data format based on the second dependency relationship and the hierarchical metadata information, may include: representing the hierarchical metadata information according to a preset data structure to obtain the metadata information after representation; respectively obtaining the second dependency relationship between each software package and other software packages in the system component, and constructing a structured data format based on the second dependency relationship and the metadata information after representation. In this embodiment, the hierarchical metadata information may be represented according to a preset data structure to obtain the metadata information after representation, and then the dependency relationship between each software package and other software packages in the system component may be respectively obtained, and then a structured data format may be constructed based on the obtained dependency relationship and the metadata information after representation. By representing the hierarchical metadata information according to the preset data structure, the hierarchical metadata information may be conveniently managed, and the processing of data in the subsequent update process may be facilitated.

[0046] In a specific embodiment, the hierarchical metadata information is represented according to a preset data structure to obtain the represented metadata information, which 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 a key-value pair, 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 the data structure of the key-value pair, 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 may also be used to represent the hierarchical metadata information.

[0047] Specifically, judging whether other logical layers related to any logical layer meet the version requirements based on the first dependency relationship, and if so, updating the version information of the corresponding target warehouse branch, may include: determining other system components that any current logical layer depends on based on the first dependency relationship, and searching for the names and version numbers of the software packages corresponding to the other system components in the 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; judging whether the first package name and the second package name, and the corresponding first package version number and the second package version number match; if the first package name and the second package name, and the corresponding first package version number and the second package version number match, then incrementally updating the version information of the corresponding target warehouse branch. In this embodiment, in order to ensure that the software system can properly handle the dependencies between layers during the update process, before the software system is updated, the dependency resolution mechanism located in the remote version management system can be used to identify and verify other logical layers that any logical layer to be updated depends on, thereby ensuring that all dependency conditions are met. Specifically, before any logical layer is incrementally updated, the dependency graph can be scanned through the dependency resolution mechanism, and then other system components that any current logical layer depends on can be determined based on the scanned dependencies, and the names and version numbers of the software packages corresponding to the other dependent system components can be searched in a structured data format. Then, the names and version numbers of the searched software packages can be compared with the names and version numbers of other system components that any logical layer to be updated depends on. If the two match, it indicates that the two versions are compatible and there is no compatibility issue. At this time, the version information of the corresponding target repository branch can be incrementally updated.

[0048] Specifically, each software package in the system component is taken as a node in the graph, and a unique key value is assigned to each node, which may include: taking each software package in the system component located in each logical layer as a node in the graph, and assigning a unique key value to each node of 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 of names and version numbers of other software packages that the node depends on; accordingly, based on the identified dependencies, the key value of the corresponding software package is added to the hash adjacency table to generate a dependency graph, which may specifically include: based on the identified dependencies, the key value of the software package in the corresponding logical layer is added to the hash adjacency table to obtain the inter-layer dependency graph corresponding to each logical layer. In this embodiment, considering the complexity of the operating system and the improvement of the efficiency of dependency search, an inter-layer dependency graph can be constructed, and the inter-layer dependency graph is a dependency graph constructed for each layer to show the dependency relationship of the software packages in the layer. It should be pointed out that the inter-layer dependency graph shows all dependencies of the software packages in this layer, including cross-layer dependencies. Specifically, each software package in the system component of each logical layer can be taken as a node in the graph, and a unique key value can be assigned to each node of the logical layer; the key in the key value contains the level of the current logical layer and the name of the system component, and the value is a list of names and version numbers of other software packages that the current node depends on; further, the structured data format (such as a data structure in JSON format) can be traversed, and then the key values ​​of the software packages in the corresponding logical layer are added to the hash adjacency table based on the identified dependencies, so as to obtain the inter-layer dependency graph corresponding to each logical layer. By constructing an inter-layer dependency graph for each logical layer, not only can the dependency relationship between all software package nodes in each logical layer be intuitively displayed, the dependency management is facilitated, and the complexity of the dependency relationship between software packages is reduced, thereby improving the efficiency of dependency search, and further improving the efficiency of software system updates. In addition, the present application divides the entire software system into multiple layers, each layer is updated separately, and by constructing an inter-layer dependency graph, dynamically analyzing and identifying the relationship between the layers, the dependency relationship is automatically identified when executing the software system update, ensuring the security and stability of the update process. In addition, by managing the software system in layers and updating each layer independently, the software system management can be made more convenient.

[0049] In this embodiment, after constructing Figure 2 After the update framework shown, when the remote repository in the remote version management system is detected to be updated, an upgrade package acquisition request for the target repository branch to be updated can be sent to the remote repository. The target repository branch is the repository branch that stores the corresponding version increment upgrade package (i.e., the data to be updated) when the remote repository detects that any logical layer of the target software system has been updated.

[0050] Step S12: after receiving the version increment upgrade package pushed by the remote repository, the version increment upgrade package is pulled into the corresponding logical 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 logical layer in the local inactive partition. Figure 2 In the corresponding configuration layer in business system partition B.

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

[0053] In this embodiment, when it is detected that business software related to any logical layer to be updated, such as word software, ppt software, Excel software, etc. in the office software system, needs to be upgraded, the office software system is restarted, and the inactive partition (business system partition B) is converted to an active partition, so that the version incremental upgrade package in the active partition can be used to incrementally upgrade any logical layer to be updated, and the system is the new version.

[0054] In a specific embodiment, see Figure 3 As shown, the entire software system can be updated by following the steps below:

[0055] Step S21: When an update requirement for any logical layer in the target software system is detected, an update package for the target logical layer is generated, and a list of components to be updated is generated at the same time. The update package can be obtained by the developer by packaging the update data of the corresponding logical layer, and no processing is done on other logical layers, that is, other layers remain unchanged. Through this layered update method, it is possible to ensure that each part of the system is updated independently, thereby improving flexibility and maintainability, and at the same time, reducing update risks, because only one layer 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 dependencies related to the update package. Specifically, in the remote version management system, a dependency graph is constructed for each level, and the dependency graph shows in detail the dependencies of the software package at this level, including cross-layer dependencies. In the process of traversing the dependency graph, the dependencies of each component are checked one by one, and in the traversal process, other components on which the update package depends are identified, and then the current version number of the dependency is searched in the data structure obtained based on the metadata information, and compared with the dependency of the software version to be updated. If there is no dependency problem, the update package is submitted to the remote repository.

[0057] For details, see Figure 4 As shown, step S22 can be implemented by following the steps below:

[0058] Step S201: Acquire the update package related information in step S21, including the software package list in the update package, other software packages that each software package depends on, the version numbers of the other software packages that it depends on, and the level of the software package.

[0059] Step S202: traverse the software package list obtained in step S201, and for each software package, query the dependency relationship from the collected hierarchical metadata information list. It should be noted that for the dependency check of the update package, it is not necessary to traverse the dependency graph, and a preliminary search can be performed directly in the hierarchical metadata information list. If the dependency relationship is satisfied, it can be directly determined that the update package has no dependency problem.

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

[0061] Step S204: outputting the items whose dependencies are not satisfied, including the software package and other software packages that it depends on and their version numbers.

[0062] Step S205: Determine whether the software package list has been traversed, if so, proceed to step S206; if not, return to step S202.

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

[0064] Step S23: Resolve dependency conflicts according to the dependency analysis, recheck the dependency relationship, and finally submit the update package without dependency issues to the remote repository. Specifically, if there is a dependency conflict, the software package with dependency issues in the system will be updated, generally by performing a version upgrade. After the upgrade, the dependencies of this version need to be rechecked. At this time, the dependency graph needs to be traversed to confirm that the dependency relationship can meet the conditions.

[0065] It should be pointed out that the detection method of this step (step S23) is different from that of the previous step (step S22). The difference is that step S22 directly detects the dependency relationship of the software package that needs to be updated. This action does not need to traverse the dependency graph, but only needs to find the hierarchical metadata information list. If it is satisfied, there is no need to perform complex dependency graph traversal operations. Only when the dependency is not satisfied, the dependency confirmation operation is performed. Only at this time will the dependency relationship represented by the dependency graph be checked. This is done level by level to 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 and identify the network idle period. When the local network meets the conditions (is in the network idle period), the incremental update package is pulled to the inactive partition.

[0067] Step S25: In response to the update requirement of the software system, the software system is restarted, and the inactive partition is converted into an active partition, thereby completing the update of the software system.

[0068] It can be seen that the embodiment of the present application pre-divided the software system into layers to obtain multiple logical layers, and created a warehouse branch corresponding to each logical layer in the remote repository in the remote version management system to save the incremental version upgrade package for updating the logical layer. Specifically, when the remote repository is monitored to be updated, the upgrade package acquisition request for the target warehouse branch corresponding to the current logical layer to be updated is first sent to the remote repository, and after receiving the incremental version upgrade package, it is directly pulled to the corresponding logical layer in the local inactive partition, and then the software system is restarted, and the inactive partition is converted to an active partition to use the incremental version upgrade package to incrementally upgrade the corresponding logical layer. The embodiment of the present application divides the business software system into multiple logical layers and independently updates each logical layer when there is an update requirement, which can reduce the complexity of the update and improve the efficiency of the update. In addition, by managing the software system in layers and independently updating each layer, the reliability and continuity of the software system upgrade can be ensured, thereby ensuring the stability and availability of the user's system. Thereby solving the problems of bandwidth waste and long update time caused by the update of the business software system, as well as the compatibility problem after the business software system is updated.

[0069] The present application embodiment discloses a specific software system update method, which is applied to an immutable operating system located at a client, see 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, it is determined whether the current local network bandwidth meets the preset bandwidth condition.

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

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

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

[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 can be 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 warehouse branches in the remote repository, and there is an association relationship, such as when the data in any warehouse branch is pushed to the local repository, the local repository will cache the updated data in the storage space corresponding to any warehouse branch.

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

[0077] For a more specific processing procedure of the above step S34, reference may be made to the corresponding contents disclosed in the above embodiments, which will not be described in detail here.

[0078] It can be seen that the embodiment of the present application uses an incremental update method to update the software system, thereby shortening the update time and improving the update efficiency. At the same time, when there is a problem with the updated version, it can be rolled back to the old version. In addition, before updating the software system, the present application detects the current local network bandwidth, thereby solving the problems of bandwidth waste and long update time caused by the update of the software system. In addition, by managing the software system in layers and updating each logical layer independently, the problem of complex traditional incremental updates is solved.

[0079] The embodiments of the present application also provide a software system updating device. The description of the features in the embodiments corresponding to the process recovery device can refer to the relevant description of the embodiments corresponding to the process recovery method, which will not be repeated here.

[0080] An embodiment of the present application further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any of the above-mentioned software system updating method embodiments.

[0081] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above-mentioned software system updating method embodiments when running.

[0082] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk.

[0083] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any one of the above-mentioned software system updating method embodiments are implemented.

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

[0085] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0086] The above is a detailed introduction to a software system update method, product, device and storage medium provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and core idea of ​​the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the present application.

Claims

1. A software system updating method, characterized in that: Applied to the immutable operating system located on the client, including: When an update is detected in a remote repository in a remote version management system, a request for obtaining an upgrade package for a target repository branch is sent to the remote repository; the target repository branch is a repository branch that stores the corresponding version incremental upgrade package when the remote repository detects a version update in any logical layer of the target software system; After receiving the version incremental upgrade package pushed by the remote repository, the version incremental upgrade package is pulled into the corresponding logical layer in the local inactive partition; When it is detected that the business software related to any of the logical layers needs to be upgraded, the target software system is restarted, and the inactive partition is converted to an active partition, so as to perform an incremental upgrade on any of the logical layers using the version incremental upgrade package in the active partition.

2. The software system updating method according to claim 1, characterized in that: Also includes: 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; The multiple logical layers are respectively created in each business system partition located in the immutable operating system.

3. The software system updating method according to claim 2, characterized in that: The remote version management system includes: a repository management unit and a dependency management unit; The repository management unit includes the remote repository, and the remote repository includes a plurality of repository branches; the repository branches are branches created for each of the logical layers using the file system of the immutable operating system as a version control system tree, and 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, which is used to track the first dependency relationship between each of the logical layers based on the dependency graph, and to determine whether other logical layers related to any of the logical layers meet the version requirements based on the first dependency relationship. If so, the version information of the corresponding target warehouse branch is updated.

4. The software system updating method according to claim 3, characterized in that: Also includes: If other logic layers related to any of the logic layers do not meet the version requirement, responding according to a preset strategy through the dependency management unit; The preset strategy includes generating warning prompt information for the version of the other logical layer not meeting the requirements.

5. The software system updating method according to claim 3, characterized in that: Also includes: If other logic layers related to any of the logic layers do not meet the version requirements, the dependency management unit automatically selects the latest compatible version to perform version updates on the other logic layers, and performs version compatibility detection after the version update.

6. The software system updating method according to claim 3, characterized in that: The process of constructing the dependency graph includes: The metadata of each of the logical layers is obtained respectively to obtain hierarchical metadata information; the hierarchical metadata information includes a layer identifier corresponding to each of the logical layers, and a system component included in each of the logical layers and a version number of the system component; Respectively obtaining second dependency relationships between each software package in the system component and other software packages, and constructing a structured data format based on the second dependency relationship and the hierarchical metadata information; Treat each software package in the system component 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 of names and version numbers of other software packages that the node depends on; The structured data format is traversed, and the key values ​​of the corresponding software packages are added to a hash adjacency table based on the identified dependencies to generate a dependency graph.

7. The software system updating method according to claim 6, characterized in that: The obtaining of the second dependency relationship between each software package and other software packages in the system component respectively, and constructing a structured data format based on the second dependency relationship and the hierarchical metadata information, includes: Representing the hierarchical metadata information according to a preset data structure to obtain represented metadata information; The second dependency relationships between each software package and other software packages in the system component are respectively obtained, and a structured data format is constructed based on the second dependency relationships and the post-representation metadata information.

8. The software system updating method according to claim 7, characterized in that: The step of representing the hierarchical metadata information according to a preset data structure to obtain represented metadata information includes: The hierarchical metadata information is represented according to a dictionary data structure to obtain represented 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.

9. The software system updating method according to claim 6, characterized in that: The determining, based on the first dependency relationship, whether other logic layers related to any of the logic layers meet the version requirement, and if so, updating the version information of the corresponding target warehouse branch, includes: Determine other system components that any of the current logic layers depends on based on the first dependency relationship, and search the structured data format for names and version numbers of software packages corresponding to the other system components to obtain a first package name and a first package version number; Obtain the name and version number of the other system components currently described, and obtain the second package name and the second package version number; Determine whether the first package name and the second package name, and the corresponding first package version number and the second package version number match; If the first package name and the second package name, and the corresponding first package version number and the second package version number match, the version information of the corresponding target repository branch is incrementally updated.

10. The software system updating method according to claim 6, characterized in that: The method of treating each software package in the system component as a node in a graph and assigning a unique key value to each node includes: Each software package in the system component located in each logical layer is respectively regarded as a node in the graph, and a unique key value is assigned to each node of the corresponding logical layer; the key in the key value includes the level of the logical layer and the name of the system component, and the value is a list including the names and version numbers of other software packages that the node depends on; Accordingly, the step of adding the key value of the corresponding software package to a hash adjacency table based on the identified dependencies to generate a dependency graph includes: Based on the identified dependencies, the key values ​​of the software packages in the corresponding logic layers are added to a hash adjacency table to obtain an inter-layer dependency graph corresponding to each logic layer.

11. The software system updating method according to any one of claims 1 to 10, characterized in that: When it is detected that a remote repository in the remote version management system is updated, sending an upgrade package acquisition request for a target repository branch to the remote repository includes: When an update is detected in a remote repository in a remote version management system, it is determined whether the current local network bandwidth meets a preset bandwidth condition; If the local network bandwidth meets the preset bandwidth condition, an upgrade package acquisition request for the target warehouse branch is sent to the remote repository.

12. The software system updating method according to claim 11, characterized in that: Pulling the version incremental upgrade package to the corresponding logic layer in the local inactive partition includes: The version incremental upgrade package is 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; the local repository and the remote repository have the same hierarchical structure and directory structure.

13. An electronic device, characterized in that: include: Memory for storing computer programs; A processor, configured to implement the steps of the software system updating method as claimed in any one of claims 1 to 12 when executing the computer program.

14. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the software system updating method according to any one of claims 1 to 12.

15. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the software system updating method according to any one of claims 1 to 12 are implemented.

Images