WO2019028992A1 - 多模块版本依赖关系构建方法、装置、服务器和存储介质 - Google Patents

多模块版本依赖关系构建方法、装置、服务器和存储介质 Download PDF

Info

Publication number
WO2019028992A1
WO2019028992A1 PCT/CN2017/104629 CN2017104629W WO2019028992A1 WO 2019028992 A1 WO2019028992 A1 WO 2019028992A1 CN 2017104629 W CN2017104629 W CN 2017104629W WO 2019028992 A1 WO2019028992 A1 WO 2019028992A1
Authority
WO
WIPO (PCT)
Prior art keywords
version
module
dependency
directed edge
modification
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2017/104629
Other languages
English (en)
French (fr)
Inventor
张玉强
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
OneConnect Financial Technology Co Ltd Shanghai
Original Assignee
OneConnect Financial Technology Co Ltd Shanghai
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by OneConnect Financial Technology Co Ltd Shanghai filed Critical OneConnect Financial Technology Co Ltd Shanghai
Publication of WO2019028992A1 publication Critical patent/WO2019028992A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management

Definitions

  • the present application relates to the field of computer technology, and in particular, to a multi-module version dependency construction method, apparatus, server, and storage medium.
  • APP applications In order to continuously meet the needs of the market and users, APP applications also need to be continuously upgraded to enhance the performance of the APP by continuously adding new features and modules. Inevitably, there will be dependencies between different functional modules. For example, the implementation of the function of the A module needs to call the interface of the B module, and the A module depends on the B module. When the module is upgraded, it is very likely that the active or passively associated code program changes, which may cause the other modules of the associated module to be paralyzed, that is, the interface does not match, and the functions do not match.
  • a multi-module version dependency construction method comprising:
  • version information uploaded by a plurality of module terminals, where the version information includes a module version identifier, a dependency relationship with a module version identifier of another module, and dependency detail information corresponding to the dependency relationship;
  • Each module is an independent node, and each of the independent nodes includes at least one child node, and each of the child nodes corresponds to one of the module version identifiers, and the dependency relationship between the module version identifiers is a directed edge.
  • the build version depends on the network map, wherein the directed edge associates the corresponding dependency detail information;
  • a multi-module version dependency building device comprising:
  • An information receiving module configured to receive version information uploaded by a plurality of module terminals, where the version information includes a module version identifier, a dependency relationship with a module version identifier of another module, and dependency detail information corresponding to the dependency relationship;
  • each module is an independent node
  • each of the independent nodes includes at least one child node
  • each of the child nodes corresponds to one of the module version identifiers, and is identified by the module version.
  • the dependency relationship is a version dependent network graph for the directed edge, wherein the directed edge associates the corresponding dependency detail information;
  • a dynamic monitoring module configured to monitor a version update dynamics issued by the module terminal, and extract version revision description information carried in the version update dynamics
  • Relying on the detailed information searching module configured to determine, in the version dependent network map, an independent node that dynamically corresponds to the version update, find all the directed edges connected to the independent node, and obtain the searched Dependency details corresponding to the side;
  • a policy generation module configured to generate a directed edge modification policy by comparing the obtained dependency detail information with the version modification description information
  • Relying on a network map update and push module configured to update the version dependent network map according to the directed edge modification policy, and push the updated version dependent network map to the module terminal related to the current modification.
  • a server comprising a memory and a processor, the memory storing computer readable instructions, the computer readable instructions being executed by the processor such that the processor performs the following steps:
  • version information uploaded by a plurality of module terminals, where the version information includes a module version identifier, a dependency relationship with a module version identifier of another module, and dependency detail information corresponding to the dependency relationship;
  • Each module is an independent node, and each of the independent nodes includes at least one child node, and each of the child nodes corresponds to one of the module version identifiers, and the dependency relationship between the module version identifiers is a directed edge.
  • the build version depends on the network map, wherein the directed edge associates the corresponding dependency detail information;
  • One or more computer readable non-volatile storage media storing computer readable instructions, when executed by one or more processors, cause one or more processors to perform the steps of:
  • version information uploaded by a plurality of module terminals, where the version information includes a module version identifier, a dependency relationship with a module version identifier of another module, and dependency detail information corresponding to the dependency relationship;
  • Each module is an independent node, and each of the independent nodes includes at least one child node, and each of the child nodes corresponds to one of the module version identifiers, and the dependency relationship between the module version identifiers is a directed edge.
  • the build version depends on the network map, wherein the directed edge associates the corresponding dependency detail information;
  • 1 is an application environment diagram of a multi-module version dependency construction method in an embodiment
  • FIG. 2 is a schematic diagram showing the internal structure of a server in an embodiment
  • FIG. 3 is a flow chart of a method for constructing a multi-module version dependency in an embodiment
  • FIG. 4 is a schematic diagram of a version dependent network diagram in an embodiment
  • FIG. 5 is a flow chart of a method for constructing a multi-module version dependency relationship in another embodiment
  • FIG. 6 is a schematic diagram of an independent node in an embodiment
  • FIG. 7 is a structural block diagram of a multi-module version dependency relationship constructing apparatus in an embodiment
  • FIG. 8 is a structural block diagram of a multi-module version dependency relationship constructing apparatus in another embodiment
  • FIG. 9 is a structural block diagram of a multi-module version dependency relationship constructing apparatus in still another embodiment.
  • FIG. 10 is a structural block diagram of a multi-module version dependency relationship constructing apparatus in still another embodiment.
  • an application environment diagram of a multi-module version dependency construction method includes a module terminal 110 and a server 120.
  • Module terminal 110 can communicate with server 120 over a network.
  • the module terminal 110 may be at least one of a smartphone, a tablet, and a notebook, but is not limited thereto.
  • the server 120 may be an independent physical server or a server cluster composed of a plurality of physical servers.
  • a server includes a processor coupled via a system bus, a non-volatile storage medium, an internal memory, and a network interface.
  • the non-volatile storage medium of the server 120 stores an operating system and computer executable instructions for implementing a multi-module version dependency construction method applicable to the server 120 when executed by the processor.
  • This processor is used to provide computing and control capabilities to support the operation of the entire server.
  • the internal memory in the server 120 provides an environment for the operation of the operating system and computer executable instructions in the non-volatile storage medium, the network interface of the server 120 being used for End 110 performs network communication.
  • FIG. 2 is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the server to which the solution of the present application is applied.
  • the specific server may It includes more or fewer components than those shown in the figures, or some components are combined, or have different component arrangements.
  • FIG. 3 is a schematic flow chart of a method according to an embodiment of the present application. It should be understood that although the various steps in the flowchart of FIG. 3 are sequentially displayed as indicated by the arrows, these steps are not necessarily performed in the order indicated by the arrows. Except as explicitly stated herein, the execution of these steps is not strictly limited, and may be performed in other sequences. Moreover, at least some of the steps in FIG. 3 may include a plurality of sub-steps or stages, which are not necessarily performed at the same time, but may be executed at different times, and the order of execution thereof is not necessarily This may be performed in sequence, but may be performed alternately or alternately with other steps or at least a portion of the sub-steps or stages of the other steps.
  • a multi-module version dependency construction method is provided.
  • the method is applied to the server shown in FIG. 2 as an example, and specifically includes the following steps:
  • Step S202 Receive version information uploaded by a plurality of module terminals, where the version information includes a module version identifier, a dependency relationship with a module version identifier of another module, and dependency detail information corresponding to the dependency relationship.
  • the embodiment relates to a multi-module version dependency construction method for managing each module version upgrade of a multi-module APP system, and the essence thereof is to construct a visual version-dependent network diagram.
  • the APP system includes a plurality of modules, each of which is compiled independently, and each module corresponds to one module terminal.
  • the module terminal is used to count the version information of the corresponding module, and upload the statistical version information to the server.
  • the version information here includes the module version identifiers that the module has published at the historical moment, the dependencies between each module version and other module versions, and the dependency details.
  • the above module version identifier includes the module identifier and version number, such as A1.0, A for module A, and 1.0 for version number.
  • the dependency between different module versions is the calling relationship between different modules.
  • A1.0 calls one or more function interfaces of B1.0 (such as payment interface) when implementing the corresponding function of the module
  • A1.0 depends on B1.0, and the called interface is between two modules. Associated interface.
  • Dependent on detailed information that is, detailed record of dependency information between two module versions with dependencies, including dependent content (such as associated interfaces), dependent content on active relying parties (such as A1.0 above) and passive relying parties Any description of the positional relationship between the versions of each module, such as the position description in B1.0 above.
  • Step S204 Each module is an independent node, each independent node includes at least one child node, each child node corresponds to a module version identifier, and a dependency-dependent network diagram is constructed for the directed edge by the dependency relationship between the module version identifiers. Wherein, the directed edge associates the corresponding dependency detail information.
  • the server first constructs a corresponding independent node for each module according to the version information of each module received, and constructs a child node for multiple module versions under the module, such as A1.0, A1.1, A2.0. Then, according to the dependency relationship between each module version, a directed edge is generated, and the directed edge connects two mutually dependent module versions, and the directed edge arrow points to the active relying party, for example, A1.0 ⁇ B1.0 indicates that B1.0 depends on A1. .0. Finally, the generated directed edges are associated with the corresponding detail information, such as the directed edge between A1.0 and B1.0, and the dependency details information between A1.0 and B1.0 is associated, thereby completing the version dependent network.
  • the construction of the graph is shown in Figure 4. It should be noted that the dependencies between versions are not limited to those shown in the figure, and all reasonable dependencies can be displayed in the form of a version-dependent network diagram in the above manner.
  • the dependency details corresponding to the directed edge will be displayed.
  • Step S206 Monitor the version update dynamics issued by the module terminal, and extract the version modification description information carried in the version update dynamics.
  • the server dynamically monitors the version update of each module terminal and dynamically obtains the version modification description information according to the version update of the module terminal.
  • the server can obtain the version update dynamics of the module terminal in the following two ways. One is that the server grasps the version modification document of the module terminal periodically updated according to the set path, and parses the document to obtain Take the version modification description information. The second is that the server obtains the version update dynamic uploaded by the module terminal to obtain the corresponding version modification description information.
  • the version modification description information includes a description of the modification of the existing version and a description of the new version of the release.
  • the corresponding version modification content includes the modified module version identifier, the modified content, and the modification description.
  • the corresponding version modification description information is a modified version and a modified description of the new version relative to the closest historical version, and a description of the added function and the added function.
  • Step S208 Determine, in the version dependent network map, an independent node that dynamically corresponds to the version update, find all directed edges connected to the independent node, and obtain dependency detail information corresponding to the directed directed edge.
  • the server may determine the module for which the version update dynamic is determined by extracting the module update identifier of the release version update, or modify the description information according to the version and modify the modified version identifier related to the description information, such as A1.2, and further confirm the obtained version.
  • Update the module for which the dynamic is targeted and then locate the corresponding independent node in the version dependent network graph.
  • the server obtains all directed edges elicited by the independent node and dependency details corresponding to the directed edges.
  • the module terminal A issues a version update dynamic about the module A, such as modifying the module version A1.1 or releasing the upgrade version A1.2.
  • the module that the server locates is the A module.
  • the B2.0 depends on the directed edge of A1.1, C1. .0 and C1.2 depend on the directed edges of A1.1.
  • the directed edge of the connection it can be confirmed that the module having the associated relationship with the current version update has the module B and the module C.
  • Step S210 Compare the acquired dependency detail information with the version modification description information to generate a directed edge modification policy.
  • the version modification description information is sequentially compared with the dependent detail information of each directed edge connected by the independent node, to determine whether the modification involved in the modification description information has a modification to the original dependent portion, and if so, according to the comparison.
  • deleting the directed edge information or modifying the dependent detail information corresponding to the existing directed edge, or deleting one or more existing directed edges according to the comparison result modify the dependency details information corresponding to other directed edges. For example, if the modification deletes the call to the associated interface, the corresponding directed edge and its corresponding dependency detail information are deleted.
  • the modified B2.0 removes the call to the original associated interface of module A1.1, and deletes the directed edge between B2.0 and A1.1. And delete the dependency details corresponding to the directed edge. Modifying the strategy also includes generating new directed edges.
  • the modified module version involves modification of the dependent part
  • the corresponding dependency of the directed edge is unstable.
  • the function of the active relying party may not be related to the dependent part. achieve. That is, the dependency relationship cannot guarantee the normal operation of the module function, and the reminder information is sent to the corresponding module terminal, and the reminder information includes the modified description information of the current modification and the related information of the directed edge identifier.
  • module terminal A modifies module A1.1 and modifies the associated interface a called by module C1.0.
  • the modification is recorded in the version modification description information.
  • version modification description information is compared with the related information of the directed edge between A1.1 and C1.0, it is confirmed that the dependent partial modification occurs, and then A1.1 is performed.
  • the directed edge between C1.0 and C1.0 is identified and the corresponding modified description is associated with the directed edge.
  • the C module terminal receives the updated version depending on the network map, it can click the directed edge of the identifier to know the interface mismatch caused by the modification, and timely handle the corresponding processing.
  • the server will further determine whether the deprecated modification will affect other modules, and make corresponding modification strategies through information comparison until the entire version depends on the network map to reach a stable state.
  • the corresponding A module terminal can also know the interface mismatch caused by the dependency in this modification in time, so as to further confirm the modification.
  • Step S212 Update the version dependent network map according to the directed edge modification policy, and push the updated version dependent network map to the module terminal related to the current modification.
  • the server compares the obtained dependency details with the version involved in this release update. Modify the description information to confirm whether it is necessary to modify the existing directed edge or whether to add a new directed edge to generate a modification policy according to the comparison result, and update the version dependent network map according to the modification policy.
  • the updated version relies on the network map to be pushed to the relevant module terminal display.
  • the related module terminal here includes a module terminal that releases the version update dynamics and other module terminals associated with the current modification, and the module terminals associated with the version update of the A module are the module terminal B and the module terminal C.
  • the dependent version information in the version dependency information and the dependency information in the version dependency graph are used to determine the change of the dependency relationship caused by the current version upgrade or the generation of the new directed edge to continuously update the visual version dependency.
  • the relationship diagram is displayed, and the updated version dependency map is pushed to the module terminal that is associated with the update, so that the corresponding module terminal can know the version change of the associated module in a timely and clear manner, and the corresponding time is made accordingly. Confirmation and processing.
  • the automatic management of the dependencies between the modules is realized, the management efficiency is higher, the linkage real-time between the modules is stronger, and the mismatch caused by the dependencies is largely less.
  • step S210 after comparing the acquired dependency detail information and the version modification description information to generate the directed edge modification policy, further comprising step S211: modifying the generated directed edge modification strategy Pushing to the module terminal that releases the version update dynamics, so that the module terminal confirms the generated directed edge modification policy; after receiving the determination instruction sent by the module terminal, performing step S212: modifying the version update network according to the directed edge Figure and push the updated version dependent network map to the module terminal associated with this modification.
  • increasing the confirmation link of the module terminal may make the modification of the version-dependent network map more reliable, and increase the reliability of the generated version-dependent network diagram.
  • the version update dynamically includes a change dynamic of an existing version or an update version release dynamic, wherein the upgrade version release dynamic includes an upgrade version identifier.
  • the update dynamics of the module terminal acquired by the server is dynamic for the upgrade version
  • the method for dynamically updating the build version according to the version update depends on the network map: determining the dynamic corresponding to the upgrade version release in the version dependency network map An independent node, and add a child node corresponding to the upgrade version identifier at the determined independent node.
  • the version modification description information corresponding to the dynamic version of the upgrade version is compared with the dependent detail information of the directed edge connected to the independent node, and if the modification does not involve the modification of the related dependent part, the low version dependency is It can be copied to the higher version of the release. If the C module releases C2.0, C2.0 does not modify the dependency of C1.0 on A1.1. C2.0 also calls the associated interface in A1.1, then C2.0 and A1.1. There is also the same dependency as C1.0. The directed edges between C1.0 and A1.1 and the corresponding dependency details can be copied to C2.0. In one embodiment, a lower version of the directed edge that repeats with the higher version of the directed edge may also be deleted to simplify the dependency network map.
  • the directional is directional.
  • the side and the corresponding dependency details are deleted.
  • the update of the version dependent network map is only to add a new child node.
  • the version upgrade description information includes an improved description of the new version relative to the closest historical version, a connection edge can be generated between the new version and the closest historical version, and an association relationship between the connection edge and the improved description is established.
  • a corresponding improved description is displayed, as shown in FIG.
  • the version of each module is continuously upgraded, and the version of the built-in version depends on the network map.
  • the version between the server and the module terminal depends on the transmission and storage of the network map. Both occupy large resources, and it is time-consuming and laborious for the module terminal to find the dependencies related to itself in the huge version dependency network diagram. In this embodiment, the above problem is solved.
  • the dependency subgraph of each module is generated according to the updated version dependency network diagram, and the generated dependency subgraph is pushed to the corresponding The module terminal display, wherein the generated module dependency subgraph includes an independent node corresponding to the module, a separate node directly connected to the independent node, and a directed edge of the independent node and the directly connected independent node and the directed edges Corresponding dependency details.
  • the dependency graph of the module may further include an independent node spaced apart from the independent node of the corresponding module, the number of independent nodes being no more than a set number of independent nodes.
  • the number of independent nodes is not more than one, including the directly connected independent nodes (the number of intervals is 0) and the independent nodes connected to the directly connected independent nodes (the number of intervals is 1).
  • the module related to the update is confirmed, only the dependency sub-graph of the related module is generated, and the generated dependency sub-map is pushed to the corresponding The relevant module in the terminal.
  • a multi-module version dependency construction apparatus includes:
  • the information receiving module 302 is configured to receive version information uploaded by the plurality of module terminals, where the version information includes a module version identifier, a dependency relationship with the module version identifier of the other module, and dependency detail information corresponding to the dependency relationship.
  • the network diagram construction module 304 is configured to use each module as an independent node, each independent node includes at least one child node, each child node corresponds to a module version identifier, and the dependency relationship between the module version identifiers is a directed edge.
  • the build version relies on a network map in which the directed edges are associated with corresponding dependency details.
  • the dynamic monitoring module 306 is configured to monitor the version update dynamics issued by the module terminal, and extract version revision description information carried in the version update dynamics.
  • the dependency detail information searching module 308 is configured to determine, in the version dependent network map, an independent node that dynamically corresponds to the version update, find all directed edges connected to the independent node, and obtain dependency detail information corresponding to the directed directed edge.
  • the modification policy generation module 310 is configured to generate a directed edge modification policy by comparing the obtained dependency detail information with the version modification description information.
  • the network map update and push module 312 is configured to modify the version dependent network map according to the directed edge modification and push the updated version dependent network map to the module terminal related to the current modification.
  • the multi-module version dependency relationship building device further includes:
  • the terminal confirmation module 311 is configured to push the generated directed edge modification policy to the module terminal that releases the version update dynamic, so that the module terminal confirms the generated directed edge modification policy.
  • the network map update and push module 312 After receiving the determination command sent by the module terminal, the network map update and push module 312 is entered.
  • the multi-module version dependency relationship building device further includes:
  • the upgrade version sub-node adding module 402 is configured to determine whether the version modification description information carries the upgrade version identifier, and if yes, add the child node corresponding to the upgrade version identifier to the corresponding independent node in the version dependency network diagram.
  • the modification policy generation module 310 is further configured to compare the version modification description information with the dependency detail information corresponding to each directed edge of the search, and determine whether the current modification involves recording in the dependency detail information.
  • Dependent part of the modification if it is, according to the comparison result delete the existing directed edge or modify the existing directed edge corresponding to the details of the information; and determine whether the modification of the existing directed edge makes the existing directed edge corresponding to the dependence The relationship is unstable, and if so, the reminder information is sent to the module terminal corresponding to the unstable directed edge;
  • a new directed edge and corresponding dependency details are generated based on the comparison result.
  • the multi-module version dependency construction apparatus further includes: a dependency sub-graph generation module 502, configured to generate a dependency sub-graph of each module according to the version dependency map, and generate The dependency subgraph is pushed to the corresponding module terminal display.
  • a dependency sub-graph generation module 502 configured to generate a dependency sub-graph of each module according to the version dependency map, and generate The dependency subgraph is pushed to the corresponding module terminal display.
  • a server comprising a memory and a processor, wherein the memory stores computer readable instructions, and when the computer readable instructions are executed by the processor, the processor performs the following steps: receiving a plurality of module terminal uploads Version information, the version information includes the module version identifier, the dependency relationship with the module version identifier of other modules, and the dependency detail letter corresponding to the dependency relationship.
  • Each module is an independent node, each independent node includes at least one child node, each child node corresponds to a module version identifier, and a dependency-dependent network diagram is constructed for the directed edge by the dependency relationship between the module version identifiers, wherein And the related details information of the directed edge association; monitoring the version update dynamics issued by the terminal, extracting the version modification description information carried in the version update dynamic; determining the independent node corresponding to the version update dynamic in the version dependent network map, searching and All the directed edges connected to the independent node and obtain the dependency details information corresponding to the directed directed edge; compare the obtained dependency detail information and the version modification description information to generate a directed edge modification strategy; and modify the policy update version according to the directed edge Depends on the network map and pushes the updated version dependent network map to the module terminal associated with this modification.
  • the processor after comparing the acquired dependency detail information and the version modification description information to generate a directed edge modification policy, the processor further performs the following steps:
  • the processor further performs the following steps: determining whether the version modification description information carries the upgrade version identifier, and if yes, adding the child node corresponding to the upgrade version identifier to the corresponding independent node in the version dependency network diagram .
  • the step of comparing the acquired dependency detail information and the version modification description information performed by the processor to generate the directed edge modification policy includes:
  • the version modification description information is sequentially compared with the dependency detail information corresponding to each directed edge of the search, and it is determined whether the modification involves modification of the dependent portion recorded in the dependency detail information, and if so, the deletion is already performed according to the comparison result.
  • the module terminal sends the reminder information; according to the comparison result, a new directed edge and corresponding dependency detail information are generated.
  • the processor further performs the steps of: generating a dependency subgraph of each module based on the version dependency graph and pushing the generated dependency subgraph to the corresponding module terminal display.
  • one or more computer readable non-volatile storage media having computer readable instructions, when executed by one or more processors, causing one or more processors The following steps are performed: receiving version information uploaded by multiple module terminals, where the version information includes a module version identifier, a dependency relationship with a module version identifier of another module, and dependency detail information corresponding to the dependency relationship; each module is an independent node.
  • Each of the independent nodes includes at least one child node, and each child node corresponds to a module version identifier, and a version dependent network map is constructed for the directed edge by the dependency relationship between the module version identifiers, wherein the directed edge association corresponds to the corresponding dependency information.
  • the processor after comparing the acquired dependency detail information and the version modification description information to generate a directed edge modification policy, the processor further performs the following steps:
  • the processor further performs the following steps: determining whether the version modification description information carries the upgrade version identifier, and if yes, adding the child node corresponding to the upgrade version identifier to the corresponding independent node in the version dependency network diagram .
  • the step of comparing the acquired dependency detail information and the version modification description information performed by the processor to generate the directed edge modification policy includes:
  • the version modification description information is sequentially compared with the dependency detail information corresponding to each directed edge of the search, and it is determined whether the modification involves modification of the dependent portion recorded in the dependency detail information, and if so, the deletion is already performed according to the comparison result.
  • a new directed edge and corresponding dependency details are generated based on the comparison result.
  • the processor further performs the steps of: generating a dependency subgraph of each module based on the version dependency graph and pushing the generated dependency subgraph to the corresponding module terminal display.
  • the storage medium may be a non-volatile storage medium such as a magnetic disk, an optical disk, or a read-only memory (ROM).

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

一种多模块版本依赖关系构建方法，包括：接收多个模块终端上传的版本信息；以每个模块为独立节点，每个独立节点中包括至少一个子节点，以模块版本标识之间的依赖关系为有向边构建版本依赖网络图，其中，有向边关联对应的依赖详情信息；监测模块终端发布的版本更新动态，提取版本修改描述信息；在版本依赖网络图中确定与版本更新动态对应的独立节点，查找与独立节点所连接的所有有向边的依赖详情信息；对比获取的依赖详情信息与版本修改描述信息，生成有向边修改策略；根据有向边修改策略更新版本依赖网络图，并将更新的版本依赖网络图推送至模块终端。

Description

多模块版本依赖关系构建方法、装置、服务器和存储介质
本申请要求于2017年8月9日提交中国专利局、申请号为2017106748397、发明名称为“多模块版本依赖关系构建方法、装置、服务器和存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及计算机技术领域，特别是涉及一种多模块版本依赖关系构建方法、装置、服务器和存储介质。
背景技术
随着移动互联网的发展以及人们对互联网便捷生活的强烈需求，越来越多的APP应用而生。为能够不断满足市场和用户需求，APP应用也需要不断的升级以通过不断的添加新功能新模块提升APP的使用性能。不可避免的，不同的功能模块之间会存在依赖关系，如A模块的功能的实现需要调用B模块的接口，则A模块依赖B模块。在模块升级时，很可能会出现主动关联或者被动关联的代码程序发生变更，进而导致连带的其他模块的功能瘫痪，即出现接口不匹配，功能不匹配等问题。
传统的解决版本升级时因为依赖关系导致的不匹配隐患的方式多采用由变更责任人对通知相应的模块开发人员或者运维人员进行相应的更改和调试。这种人工线下通知的方式，尤其是当APP系统比较庞大时，存在效率低、升级管理换乱，可靠性差等问题。
发明内容
基于此，有必要提供一种多模块版本依赖关系构建方法、装置、服务器和存储介质。
一种多模块版本依赖关系构建方法，所述方法包括：
接收多个模块终端上传的版本信息，所述版本信息包括模块版本标识、与其他模块的模块版本标识之间的依赖关系以及所述依赖关系对应的依赖详情信息；
以每个模块为独立节点，每个所述独立节点中包括至少一个子节点，每个所述子节点对应一个所述模块版本标识，以所述模块版本标识之间的依赖关系为有向边构建版本依赖网络图，其中，所述有向边关联对应的所述依赖详情信息；
监测所述模块终端发布的版本更新动态，提取所述版本更新动态中携带的版本修改描述信息；
在所述版本依赖网络图中确定与所述版本更新动态对应的独立节点，查找与所述独立节点所连接的所有所述有向边并获取查找的所述有向边对应的依赖详情信息；
对比获取的所述依赖详情信息与所述版本修改描述信息，生成有向边修改策略；及
根据所述有向边修改策略更新所述版本依赖网络图，并将更新的所述版本依赖网络图推送至与本次修改相关的所述模块终端。
一种多模块版本依赖关系构建装置，所述装置包括：
信息接收模块，用于接收多个模块终端上传的版本信息，所述版本信息包括模块版本标识、与其他模块的模块版本标识之间的依赖关系以及所述依赖关系对应的依赖详情信息；
依赖网络图构建模块，用于以每个模块为独立节点，每个所述独立节点中包括至少一个子节点，每个所述子节点对应一个所述模块版本标识，以所述模块版本标识之间的依赖关系为有向边构建版本依赖网络图，其中，所述有向边关联对应的所述依赖详情信息；
动态监听模块，用于监测所述模块终端发布的版本更新动态，提取所述版本更新动态中携带的版本修改描述信息；
依赖详情信息查找模块，用于在所述版本依赖网络图中确定与所述版本更新动态对应的独立节点，查找与所述独立节点所连接的所有所述有向边并获取查找的所述有向边对应的依赖详情信息；
修改策略生成模块，用于对比获取的所述依赖详情信息与所述版本修改描述信息生成有向边修改策略；及
依赖网络图更新和推送模块，用于根据所述有向边修改策略更新所述版本依赖网络图，并将更新的所述版本依赖网络图推送至与本次修改相关的所述模块终端。
一种服务器，包括存储器和处理器，所述存储器中储存有计算机可读指令，所述计算机可读指令被所述处理器执行时，使得所述处理器执行以下步骤：
接收多个模块终端上传的版本信息，所述版本信息包括模块版本标识、与其他模块的模块版本标识之间的依赖关系以及所述依赖关系对应的依赖详情信息；
以每个模块为独立节点，每个所述独立节点中包括至少一个子节点，每个所述子节点对应一个所述模块版本标识，以所述模块版本标识之间的依赖关系为有向边构建版本依赖网络图，其中，所述有向边关联对应的所述依赖详情信息；
监测所述模块终端发布的版本更新动态，提取所述版本更新动态中携带的版本修改描述信息；
在所述版本依赖网络图中确定与所述版本更新动态对应的独立节点，查找与所述独立节点所连接的所有所述有向边并获取查找的所述有向边对应的依赖详情信息；
对比获取的所述依赖详情信息与所述版本修改描述信息，生成有向边修改策略；及
根据所述有向边修改策略更新所述版本依赖网络图，并将更新的所述版本依赖网络图推送至与本次修改相关的所述模块终端。
一个或多个存储有计算机可读指令的计算机可读非易失性存储介质，计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行以下步骤：
接收多个模块终端上传的版本信息，所述版本信息包括模块版本标识、与其他模块的模块版本标识之间的依赖关系以及所述依赖关系对应的依赖详情信息；
以每个模块为独立节点，每个所述独立节点中包括至少一个子节点，每个所述子节点对应一个所述模块版本标识，以所述模块版本标识之间的依赖关系为有向边构建版本依赖网络图，其中，所述有向边关联对应的所述依赖详情信息；
监测所述模块终端发布的版本更新动态，提取所述版本更新动态中携带的版本修改描述信息；
在所述版本依赖网络图中确定与所述版本更新动态对应的独立节点，查找与所述独立节点所连接的所有所述有向边并获取查找的所述有向边对应的依赖详情信息；
对比获取的所述依赖详情信息与所述版本修改描述信息，生成有向边修改策略；及
根据所述有向边修改策略更新所述版本依赖网络图，并将更新的所述版本依赖网络图推送至与本次修改相关的所述模块终端。
本申请的一个或多个实施例的细节在下面的附图和描述中提出。本申请的其它特征和优点将从说明书、附图以及权利要求书变得明显。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。
图1为一个实施例中多模块版本依赖关系构建方法的应用环境图；
图2为一个实施例中服务器的内部结构示意图；
图3为一个实施例中多模块版本依赖关系构建方法的流程图；
图4为一个实施例中版本依赖网路图的示意图；
图5为另一个实施例中多模块版本依赖关系构建方法的流程图；
图6为一个实施例中独立节点的示意图；
图7为一个实施例中多模块版本依赖关系构建装置的结构框图；
图8为另一个实施例中多模块版本依赖关系构建装置的结构框图；
图9为又一个实施例中多模块版本依赖关系构建装置的结构框图；及
图10为再一个实施例中多模块版本依赖关系构建装置的结构框图。
具体实施方式
为了使本申请的技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。
如图1所示，在一个实施例中，提供了一种多模块版本依赖关系构建方法的应用环境图，该应用环境图包括模块终端110和服务器120。模块终端110可通过网络与服务器120通信。模块终端110可以是智能手机、平板电脑、笔记本电脑中的至少一种，但并不局限于此。服务器120可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群。
如图2所示，在一个实施例中，提供了一种服务器，该服务器120包括通过系统总线连接的处理器、非易失性存储介质、内存储器和网络接口。其中，该服务器120的非易失性存储介质存储有操作系统和计算机可执行指令，该计算机可执行指令被处理器执行时用于实现适用于服务器120的一种多模块版本依赖关系构建方法。该处理器用于提供计算和控制能力，支撑整个服务器的运行。服务器120中的内存储器为非易失性存储介质中的操作系统和计算机可执行指令的运行提供环境，该服务器120的网络接口用于与模块终 端110进行网络通信。
本领域技术人员可以理解，图2中示出的服务器的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的服务器的限定，具体的服务器可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
图3为本申请一个实施例的方法的流程示意图。应该理解的是，虽然图3的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，图3中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
如图3所示，在一个实施例中，提供了一种多模块版本依赖关系构建方法，该方法以应用到如图2所示的服务器中为例进行说明，具体包括如下步骤：
步骤S202：接收多个模块终端上传的版本信息，版本信息包括模块版本标识、与其他模块的模块版本标识之间的依赖关系以及依赖关系对应的依赖详情信息。
本实施例涉及的是用于管理多模块APP系统的各模块版本升级时所涉及的多模块版本依赖关系构建方法，其实质是构建可视化的版本依赖网络图。
APP系统包括多个模块，每个模块独立进行编译，每个模块对应一个模块终端。该模块终端用于统计相应模块的版本信息，并将统计的版本信息上传至服务器。这里的版本信息包括该模块在历史时刻所发布过的模块版本标识，每个模块版本与其他模块版本之间的依赖关系以及依赖详情信息。
上述的模块版本标识包括模块标识和版本号，如A1.0，A代表模块A，1.0代表为版本号。不同模块版本之间的依赖关系为不同模块间的调用关系， 如库调用(人脸识别库调用)、配置调用、接口调用等。如A1.0在实现模块的相应功能时调用了B1.0的一个或者多个功能接口(如支付接口)，则A1.0依赖B1.0，被调用的接口即为两个模块之间的关联接口。依赖详情信息即详细记录的具有依赖关系的两个模块版本之间的依赖信息，包括依赖的内容(如关联的接口)，依赖内容在主动依赖方(如上述的A1.0)和被动依赖方(如上述的B1.0)中的位置描述等任何能够描述量各模块版本之间的依赖关系的信息。
步骤S204：以每个模块为独立节点，每个独立节点中包括至少一个子节点，每个子节点对应一个模块版本标识，以模块版本标识之间的依赖关系为有向边构建版本依赖网络图，其中，有向边关联对应的依赖详情信息。
服务器根据接收的各模块的版本信息，首先，为每个模块构建一个对应的独立节点，为模块下的多个模块版本，如A1.0，A1.1，A2.0等构建子节点。然后根据各模块版本间的依赖关系生成有向边，有向边连接两个相互依赖的模块版本，有向边的箭头指向主动依赖方，如A1.0→B1.0表示B1.0依赖A1.0。最后，使生成的有向边关联对应的依赖详情信息，如A1.0→B1.0之间的有向边关联A1.0和B1.0之间的依赖详情信息，进而完成了版本依赖网络图的构建，如图4所示。需要说明的是，各版本之间的依赖关系不限于图示所示，所有合理的依赖关系均可以通过上述方式以版本依赖网络图的形式显示出来。
在一个实施例中，如图4所示，当版本依赖网络图中的有向边被触发时，将显示该有向边对应的依赖详情信息。
步骤S206：监测模块终端发布的版本更新动态，提取版本更新动态中携带的版本修改描述信息。
服务器对各模块终端的版本更新动态进行监控并根据模块终端的版本更新动态获取版本修改描述信息。
服务器可通过如下两种方式获取模块终端的版本更新动态。其一是服务器按照设定的路径抓紧模块终端定时更新的版本修改文档，解析该文档以获 取版本修改描述信息。其二是服务器获取模块终端上传的版本更新动态，以获取到相应的版本修改描述信息。
版本修改描述信息包括对已有版本的修改的描述和发布的新版本的描述。当为对已有版本的修改时，对应的版本修改内容包括修改的模块版本标识、修改的内容以及修改描述。当为新版本发布时，对应的版本修改描述信息为新版本相对比最接近的历史版本的修改内容和修改描述，以及增加的功能和增加功能的描述。
步骤S208：在版本依赖网络图中确定与版本更新动态对应的独立节点，查找与独立节点所连接的所有有向边并获取查找的有向边对应的依赖详情信息。
服务器可通过提取发布版本更新动态的模块终端标识确定该版本更新动态所针对的模块，或者根据版本修改描述信息以及修改描述信息涉及到的修改版本标识如A1.2，也可以进一步确认获取的版本更新动态所针对的模块，进而在版本依赖网络图中定位到相应的独立节点。服务器获取由该独立节点引出的所有有向边以及这些有向边所对应的依赖详情信息。
举例来说，如图4所示，模块终端A发布了关于模块A的版本更新动态，如对模块版本A1.1进行了修改或者试发布了升级版本A1.2。根据获取的版本更新动态，服务器定位到的模块为A模块，由图示可知与A模块这一独立节点连接的有向边有三条，包括B2.0依赖于A1.1的有向边、C1.0和C1.2依赖于A1.1的有向边。根据连接的有向边可确认与本次版本更新具有连带关系的模块有模块B和模块C。
步骤S210：对比获取的依赖详情信息与版本修改描述信息，生成有向边修改策略。
具体的，将版本修改描述信息依次与独立节点连接的每个有向边的依赖详情信息进行对比，以判断修改描述信息中涉及的修改是否有对原有依赖部分的修改，若是，则根据对比结果删除已有所述有向边或修改已有所述有向边对应的依赖详情信息，或者根据对比结果删除一个或者多个已有有向边， 同时修改其他有向边对应的依赖详情信息。例如，若修改删除了对关联接口的调用，则删除相应的有向边和其对应的依赖详情信息。若图4所示，对B2.0进行了修改，修改后的B2.0去除了对模块A1.1原有的关联接口的调用，则删除B2.0与A1.1之间的有向边，同时删除该有向边对应的依赖详情信息。修改策略还包括生成新的有向边。
在对已有有向边进行修改后，需要判断修改是否造成了依赖关系的不稳定。若修改的模块版本涉及对依赖部分的修改，造成了相应的有向边所对应的依赖关系不稳定，如被动依赖方修改了关联接口的调用地址，导致主动依赖方的涉及依赖部分的功能无法实现。即该依赖关系不能保证模块功能的正常运行，则向相应的模块终端发送提醒信息，该提醒信息中带有本次修改的修改描述信息和所涉及的有向边标识等信息。在另一个实施例中，还可以对由于修改导致的不稳定的有向边进行标识，如修改相关有向边的颜色或者加粗有向边。举例来说，模块终端A对模块A1.1进行了修改，修改了模块C1.0调用的关联接口a。版本修改描述信息中记录了该修改，当版本修改描述信息与A1.1和C1.0之间的有向边的依赖详情信息进行比对时，确认发生了依赖部分修改，则对A1.1和C1.0之间的有向边进行标识，并将相应的修改描述与该有向边进行关联。当C模块终端接收到更新后的版本依赖网络图时即可通过点击该标识的有向边获知本次修改所造成的接口不匹配问题，以及时做出相应的处理。如模块终端C发布对模块C1.0的弃用指令，根据该弃用指令在版本依赖网络图中删除该模块版本对应的子节点，继而删除该不稳定的有向边。同样的，服务器也会进一步判断该弃用修改是否会连带影响其他模块，并通过信息比对做出相应的修改策略，直至整个版本依赖网络图达到稳定的状态。相应的A模块终端也可以及时获知本次修改由于依赖关系造成的接口不匹配问题，以便进一步对修改进行斟酌确认。
步骤S212：根据有向边修改策略更新版本依赖网络图，并将更新的版本依赖网络图推送至与本次修改相关的模块终端。
服务器通过对比获取的依赖详情信息与本次版本更新动态中涉及的版本 修改描述信息，确认是否需要对现有的有向边进行修改或者是否需要增加新的有向边，以根据对比结果生成修改策略，并按照修改策略对版本依赖网络图进行更新。并将更新的版本依赖网路图推送至相关的模块终端显示。这里的相关的模块终端包括发布版本更新动态的模块终端以及与本次修改相关联的其他模块终端，如A模块的版本更新相关联的模块终端为模块终端B和模块终端C。
本实施例中，通过监测到的版本升级信息与版本依赖关系图中相关的依赖信息判断当前版本升级所带来的依赖关系的变更或者新的有向边的生成，以不断更新可视化的版本依赖关系图，并将更新的版本依赖关系图推送至与本次更新具有连带关系的模块终端，以使相应的模块终端能够及时清晰的获知具有关联的模块的版本更改情况，第一时间做出相应的确认和处理。本实施例中实现了对模块间的依赖关系的自动化的管理，管理效率更高，模块间的联动实时性更强，能够在很大程度上较少由于依赖关系导致的不匹配隐患。
在一个实施例中，如图5所示，在步骤S210：在对比获取的依赖详情信息与版本修改描述信息，生成有向边修改策略之后，还包括步骤S211：将生成的有向边修改策略推送至发布版本更新动态的模块终端，以使模块终端对生成的有向边修改策略进行确认；当接收到模块终端发送的确定指令后，执行步骤S212：根据有向边修改策略更新版本依赖网络图，并将更新的版本依赖网络图推送至与本次修改相关的模块终端。
本实施例中，增加模块终端的确认环节，可使对版本依赖网络图的修改更加可靠，增加了生成的版本依赖网络图的可靠性。
在一个实施例中，版本更新动态包括已有版本的更改动态或者升级版本发布动态，其中升级版本发布动态包括升级版本标识。当服务器获取的模块终端的更新动态为升级版本发布动态时，根据版本更新动态更新构建的版本依赖网络图的方法为：在版本依赖网络图中确定与该升级版本发布动态对应 的独立节点，并在确定的独立节点处增加与升级版本标识对应的子节点。根据升级版本发布动态中的版本升级描述信息获取该升级版本标识对应的子节点的依赖关系，并生成依赖关系对应的有向边。
还可以是，将该升级版本发布动态对应的版本修改描述信息与所属独立节点相连接的有向边的依赖详情信息进行对比，若修改未涉及对相关依赖部分的修改，则低版本的依赖关系可以复制到该发布的高版本上面来。如C模块发布了C2.0，C2.0并未对C1.0对于A1.1的依赖部分进行修改，C2.0同样调用了A1.1中的关联接口，则C2.0与A1.1也存在与C1.0相同的依赖关系，C1.0与A1.1之间的有向边和对应的依赖详情信息可复制到C2.0上面来。在一个实施例中，还可以删除与高版本的有向边重复的低版本的有向边，以简化依赖关系网络图。如对A1.1和C1.0之间的有向边和相应的依赖详情信息进行删除，或者虚化处理，当有向边被虚化的时间超过设定阈值，则对虚化的有向边和相应的依赖详情信息进行删除。
在另一个实施例中，若该升级模块版本不涉及任何新的依赖关系，即没有产生新的调用关系，则对版本依赖网络图的更新仅为增加新的子节点即可。版本升级描述信息包括新版本相对于最接近的历史版本的改进描述，可在新版本与最接近的历史版本之间生成连接边，并建立该连接边与改进描述之间的关联关系。当该连接边被触发时，则显示相应的改进描述，如图6所示。通过这种添加子节点和改进描述的方式，即使新添加的子节点不存在依赖关系，将其加入至依赖网络图中也可使各模块能够及时了解其他模块的版本演进情况，以便利用新的升级版本促进自身模块的版本升级，建立新的依赖关系，不断优化APP功能。
在一个实施例中，随着各模块规模的扩大，各模块版本的不断升级，构建的版本依赖网络图也会越来越庞大，导致服务器和模块终端之间的版本依赖网络图的传输和存储都占用较大的资源，模块终端在庞大的版本依赖网络图中查找与自身相关的依赖关系也会费时费力。本实施例中为解决上述问题 采用如下方式，即在每次根据有向边修改策略更新版本依赖网络图后，根据更新的版本依赖关系网络图生成每个模块的依赖关系子图，并将生成得依赖关系子图推送至相应的模块终端显示，其中，生成的模块的依赖关系子图包括该模块对应的独立节点、与该独立节点直接连接独立节点以及独立节点与这些直接连接的独立节点的有向边和这些有向边对应的依赖关系详情。
在另一个实施例中，模块的依赖关系子图还可以包括与对应模块的独立节点间隔独立节点的数量不大于设定数量的独立节点。如间隔独立节点的数量不大于1个，包括直接连接的独立节点(间隔数量为0)和与直接连接的独立节点连接的独立节点(间隔数量为1)。
在一个实施例中，在根据有向边修改策略更新版本依赖网络图后，确认与本次更新相关的模块，仅生成相关模块的依赖关系子图，并将生成的依赖关系子图推送至对应的相关模块终端中。
在一个实施例中，如图7所示，提供了一种多模块版本依赖关系构建装置，装置包括：
信息接收模块302，用于接收多个模块终端上传的版本信息，版本信息包括模块版本标识、与其他模块的模块版本标识之间的依赖关系以及依赖关系对应的依赖详情信息。
依赖网络图构建模块304，用于以每个模块为独立节点，每个独立节点中包括至少一个子节点，每个子节点对应一个模块版本标识，以模块版本标识之间的依赖关系为有向边构建版本依赖网络图，其中，有向边关联对应的依赖详情信息。
动态监听模块306，用于监测模块终端发布的版本更新动态，提取版本更新动态中携带的版本修改描述信息。
依赖详情信息查找模块308，用于在版本依赖网络图中确定与版本更新动态对应的独立节点，查找与独立节点所连接的所有有向边并获取查找的有向边对应的依赖详情信息。
修改策略生成模块310，用于对比获取的依赖详情信息与版本修改描述信息生成有向边修改策略。
依赖网络图更新和推送模块312，用于根据有向边修改策略更新版本依赖网络图，并将更新的版本依赖网络图推送至与本次修改相关的模块终端。
在一个实施例中，如图8所示，多模块版本依赖关系构建装置还包括：
终端确认模块311，用于将生成的有向边修改策略推送至发布版本更新动态的模块终端，以使模块终端对生成的有向边修改策略进行确认。
当接收到模块终端发送的确定指令后，进入网络图更新和推送模块312。
在一个实施例中，如图9所示，多模块版本依赖关系构建装置还包括：
升级版本子节点增加模块402，用于判断版本修改描述信息中是否携带有升级版本标识，若是，则在版本依赖关系网络图中相应的独立节点处增加与升级版本标识对应的子节点。
在一个实施例中，修改策略生成模块310，还用于依次将版本修改描述信息与查找的每个有向边对应的依赖详情信息进行对比，判断本次修改是否涉及对依赖详情信息中记录的依赖部分的修改，若是，则根据对比结果删除已有有向边或修改已有有向边对应的依赖详情信息；并判断对已有有向边的修改是否使已有有向边对应的依赖关系不稳定，若是，则向不稳定的有向边对应的模块终端发送提醒信息；
根据对比结果生成新的有向边以及对应的依赖详情信息。
在一个实施例中，如图10所示，多模块版本依赖关系构建装置还包括：依赖关系子图生成模块502，用于根据版本依赖关系图生成每个模块的依赖关系子图，并将生成的依赖关系子图推送至相应的模块终端显示。
在一个实施例中，提供了一种服务器，包括存储器和处理器，存储器中储存有计算机可读指令，计算机可读指令被处理器执行时，使得处理器执行以下步骤：接收多个模块终端上传的版本信息，版本信息包括模块版本标识、与其他模块的模块版本标识之间的依赖关系以及依赖关系对应的依赖详情信 息；以每个模块为独立节点，每个独立节点中包括至少一个子节点，每个子节点对应一个模块版本标识，以模块版本标识之间的依赖关系为有向边构建版本依赖网络图，其中，有向边关联对应的依赖详情信息；监测模块终端发布的版本更新动态，提取版本更新动态中携带的版本修改描述信息；在版本依赖网络图中确定与版本更新动态对应的独立节点，查找与独立节点所连接的所有有向边并获取查找的有向边对应的依赖详情信息；对比获取的依赖详情信息与版本修改描述信息，生成有向边修改策略；及根据有向边修改策略更新版本依赖网络图，并将更新的版本依赖网络图推送至与本次修改相关的模块终端。
在一个实施例中，处理器在对比获取的依赖详情信息与版本修改描述信息，生成有向边修改策略的步骤之后，还执行如下步骤：
将生成的有向边修改策略推送至发布版本更新动态的模块终端，以使模块终端对有向边修改策略进行确认；及
当接收到模块终端发送的确定指令后，执行根据有向边修改策略更新版本依赖网络图，并将更新的版本依赖网络图推送至与本次修改相关的模块终端的步骤。
在一个实施例中，处理器还执行如下步骤：判断版本修改描述信息中是否携带有升级版本标识，若是，则在版本依赖关系网络图中相应的独立节点处增加与升级版本标识对应的子节点。
在一个实施例中，处理器执行的对比获取的依赖详情信息与版本修改描述信息，生成有向边修改策略的步骤包括：
依次将版本修改描述信息与查找的每个有向边对应的依赖详情信息进行对比，判断本次修改是否涉及对依赖详情信息中记录的依赖部分的修改，若是，则根据对比结果删除已有有向边或修改已有有向边对应的依赖详情信息；并判断对已有有向边的修改是否使已有有向边对应的依赖关系不稳定，若是，则向不稳定的有向边对应的模块终端发送提醒信息；根据对比结果生成新的有向边以及对应的依赖详情信息。
在一个实施例中，处理器还执行如下步骤：根据版本依赖关系图生成每个模块的依赖关系子图，并将生成的依赖关系子图推送至相应的模块终端显示。
在一个实施例中，提供了一个或多个存储有计算机可读指令的计算机可读非易失性存储介质，计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行以下步骤：接收多个模块终端上传的版本信息，版本信息包括模块版本标识、与其他模块的模块版本标识之间的依赖关系以及依赖关系对应的依赖详情信息；以每个模块为独立节点，每个独立节点中包括至少一个子节点，每个子节点对应一个模块版本标识，以模块版本标识之间的依赖关系为有向边构建版本依赖网络图，其中，有向边关联对应的依赖详情信息；监测模块终端发布的版本更新动态，提取版本更新动态中携带的版本修改描述信息；在版本依赖网络图中确定与版本更新动态对应的独立节点，查找与独立节点所连接的所有有向边并获取查找的有向边对应的依赖详情信息；对比获取的依赖详情信息与版本修改描述信息，生成有向边修改策略；及根据有向边修改策略更新版本依赖网络图，并将更新的版本依赖网络图推送至与本次修改相关的模块终端。
在一个实施例中，处理器在对比获取的依赖详情信息与版本修改描述信息，生成有向边修改策略的步骤之后，还执行如下步骤：
将生成的有向边修改策略推送至发布版本更新动态的模块终端，以使模块终端对有向边修改策略进行确认；及
当接收到模块终端发送的确定指令后，执行根据有向边修改策略更新版本依赖网络图，并将更新的版本依赖网络图推送至与本次修改相关的模块终端的步骤。
在一个实施例中，处理器还执行如下步骤：判断版本修改描述信息中是否携带有升级版本标识，若是，则在版本依赖关系网络图中相应的独立节点处增加与升级版本标识对应的子节点。
在一个实施例中，处理器执行的对比获取的依赖详情信息与版本修改描述信息，生成有向边修改策略的步骤包括：
依次将版本修改描述信息与查找的每个有向边对应的依赖详情信息进行对比，判断本次修改是否涉及对依赖详情信息中记录的依赖部分的修改，若是，则根据对比结果删除已有有向边或修改已有有向边对应的依赖详情信息；并判断对已有有向边的修改是否使已有有向边对应的依赖关系不稳定，若是，则向不稳定的有向边对应的模块终端发送提醒信息；
根据对比结果生成新的有向边以及对应的依赖详情信息。
在一个实施例中，处理器还执行如下步骤：根据版本依赖关系图生成每个模块的依赖关系子图，并将生成的依赖关系子图推送至相应的模块终端显示。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，前述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)等非易失性存储介质等。
以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
以上实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (20)

  1. 一种多模块版本依赖关系构建方法，包括：
    接收多个模块终端上传的版本信息，所述版本信息包括模块版本标识、与其他模块的模块版本标识之间的依赖关系以及所述依赖关系对应的依赖详情信息；
    以每个模块为独立节点，每个所述独立节点中包括至少一个子节点，每个所述子节点对应一个所述模块版本标识，以所述模块版本标识之间的依赖关系为有向边构建版本依赖网络图，其中，所述有向边关联对应的所述依赖详情信息；
    监测所述模块终端发布的版本更新动态，提取所述版本更新动态中携带的版本修改描述信息；
    在所述版本依赖网络图中确定与所述版本更新动态对应的独立节点，查找与所述独立节点所连接的所有所述有向边并获取查找的所述有向边对应的依赖详情信息；
    对比获取的所述依赖详情信息与所述版本修改描述信息，生成有向边修改策略；及
    根据所述有向边修改策略更新所述版本依赖网络图，并将更新的所述版本依赖网络图推送至与本次修改相关的所述模块终端。
  2. 根据权利要求1所述的方法，其特征在于，在所述对比获取的所述依赖详情信息与所述版本修改描述信息，生成有向边修改策略之后，还包括：
    将生成的所述有向边修改策略推送至发布所述版本更新动态的所述模块终端，以使所述模块终端对所述有向边修改策略进行确认；及
    当接收到所述模块终端发送的确定指令后，执行所述根据所述有向边修改策略更新所述版本依赖网络图，并将更新的所述版本依赖网络图推送至与本次修改相关的所述模块终端的步骤。
  3. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    判断所述版本修改描述信息中是否携带有升级版本标识，若是，则在所 述版本依赖关系网络图中相应的所述独立节点处增加与所述升级版本标识对应的子节点。
  4. 根据权利要求1所述的方法，其特征在于，所述对比获取的所述依赖详情信息与所述版本修改描述信息，生成有向边修改策略包括：
    依次将所述版本修改描述信息与查找的每个所述有向边对应的所述依赖详情信息进行对比，判断本次修改是否涉及对所述依赖详情信息中记录的依赖部分的修改，若是，则根据对比结果删除已有所述有向边或修改已有所述有向边对应的依赖详情信息；并判断对已有有向边的修改是否使所述已有所述有向边对应的依赖关系不稳定，若是，则向不稳定的所述有向边对应的所述模块终端发送提醒信息；
    根据对比结果生成新的有向边以及对应的依赖详情信息。
  5. 根据权利要求1所述的方法，其特征在于，所述方法还包括：根据所述版本依赖关系图生成每个模块的依赖关系子图，并将生成的所述依赖关系子图推送至相应的所述模块终端显示。
  6. 一种多模块版本依赖关系构建装置，包括：
    信息接收模块，用于接收多个模块终端上传的版本信息，所述版本信息包括模块版本标识、与其他模块的模块版本标识之间的依赖关系以及所述依赖关系对应的依赖详情信息；
    依赖网络图构建模块，用于以每个模块为独立节点，每个所述独立节点中包括至少一个子节点，每个所述子节点对应一个所述模块版本标识，以所述模块版本标识之间的依赖关系为有向边构建版本依赖网络图，其中，所述有向边关联对应的所述依赖详情信息；
    动态监听模块，用于监测所述模块终端发布的版本更新动态，提取所述版本更新动态中携带的版本修改描述信息；
    依赖详情信息查找模块，用于在所述版本依赖网络图中确定与所述版本更新动态对应的独立节点，查找与所述独立节点所连接的所有所述有向边并获取查找的所述有向边对应的依赖详情信息；
    修改策略生成模块，用于对比获取的所述依赖详情信息与所述版本修改描述信息生成有向边修改策略；及
    依赖网络图更新和推送模块，用于根据所述有向边修改策略更新所述版本依赖网络图，并将更新的所述版本依赖网络图推送至与本次修改相关的所述模块终端。
  7. 根据权利要求6所述的装置，其特征在于，还包括：
    终端确认模块，用于将生成的有向边修改策略推送至发布版本更新动态的模块终端，以使模块终端对生成的有向边修改策略进行确认。
  8. 根据权利要求6所述的装置，其特征在于，还包括：
    升级版本子节点增加模块，用于判断所述版本修改描述信息中是否携带有升级版本标识，若是，则在所述版本依赖关系网络图中相应的所述独立节点处增加与所述升级版本标识对应的子节点。
  9. 根据权利要求6所述的装置，其特征在于，所述修改策略生成模块，还用于依次将所述版本修改描述信息与查找的每个所述有向边对应的所述依赖详情信息进行对比，判断本次修改是否涉及对所述依赖详情信息中记录的依赖部分的修改，若是，则根据对比结果删除已有所述有向边或修改已有所述有向边对应的依赖详情信息；并判断对已有有向边的修改是否使所述已有所述有向边对应的依赖关系不稳定，若是，则向不稳定的所述有向边对应的所述模块终端发送提醒信息；
    根据对比结果生成新的有向边以及对应的依赖详情信息。
  10. 根据权利要求6所述的装置，其特征在于，还包括：
    依赖关系子图生成模块，用于根据版本依赖关系图生成每个模块的依赖关系子图，并将生成的依赖关系子图推送至相应的模块终端显示。
  11. 一种服务器，包括存储器和处理器，所述存储器中储存有计算机可读指令，所述计算机可读指令被所述处理器执行时，使得所述处理器执行以下步骤：
    接收多个模块终端上传的版本信息，所述版本信息包括模块版本标识、与其他模块的模块版本标识之间的依赖关系以及所述依赖关系对应的依赖详情信息；
    以每个模块为独立节点，每个所述独立节点中包括至少一个子节点，每个所述子节点对应一个所述模块版本标识，以所述模块版本标识之间的依赖关系为有向边构建版本依赖网络图，其中，所述有向边关联对应的所述依赖详情信息；
    监测所述模块终端发布的版本更新动态，提取所述版本更新动态中携带的版本修改描述信息；
    在所述版本依赖网络图中确定与所述版本更新动态对应的独立节点，查找与所述独立节点所连接的所有所述有向边并获取查找的所述有向边对应的依赖详情信息；
    对比获取的所述依赖详情信息与所述版本修改描述信息，生成有向边修改策略；及
    根据所述有向边修改策略更新所述版本依赖网络图，并将更新的所述版本依赖网络图推送至与本次修改相关的所述模块终端。
  12. 根据权利要求11所述的服务器，其特征在于，所述处理器执行所述计算机可读指令时还执行以下步骤：
    将生成的所述有向边修改策略推送至发布所述版本更新动态的所述模块终端，以使所述模块终端对所述有向边修改策略进行确认；及
    当接收到所述模块终端发送的确定指令后，执行所述根据所述有向边修改策略更新所述版本依赖网络图，并将更新的所述版本依赖网络图推送至与本次修改相关的所述模块终端的步骤。
  13. 根据权利要求11所述的服务器，其特征在于，所述处理器执行所述计算机可读指令时还执行以下步骤：判断所述版本修改描述信息中是否携带有升级版本标识，若是，则在所述版本依赖关系网络图中相应的所述独立节点处增加与所述升级版本标识对应的子节点。
  14. 根据权利要求11所述的服务器，其特征在于，所述处理器执行所述计算机可读指令时还执行以下步骤：依次将所述版本修改描述信息与查找的每个所述有向边对应的所述依赖详情信息进行对比，判断本次修改是否涉及对所述依赖详情信息中记录的依赖部分的修改，若是，则根据对比结果删除已有所述有向边或修改已有所述有向边对应的依赖详情信息；并判断对已有有向边的修改是否使所述已有所述有向边对应的依赖关系不稳定，若是，则向不稳定的所述有向边对应的所述模块终端发送提醒信息；
    根据对比结果生成新的有向边以及对应的依赖详情信息。
  15. 根据权利要求11所述的服务器，其特征在于，所述处理器执行所述计算机可读指令时还执行以下步骤：
    根据所述版本依赖关系图生成每个模块的依赖关系子图，并将生成的所述依赖关系子图推送至相应的所述模块终端显示。
  16. 一个或多个存储有计算机可读指令的计算机可读非易失性存储介质，计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行以下步骤：
    接收多个模块终端上传的版本信息，所述版本信息包括模块版本标识、与其他模块的模块版本标识之间的依赖关系以及所述依赖关系对应的依赖详情信息；
    以每个模块为独立节点，每个所述独立节点中包括至少一个子节点，每个所述子节点对应一个所述模块版本标识，以所述模块版本标识之间的依赖关系为有向边构建版本依赖网络图，其中，所述有向边关联对应的所述依赖详情信息；
    监测所述模块终端发布的版本更新动态，提取所述版本更新动态中携带的版本修改描述信息；
    在所述版本依赖网络图中确定与所述版本更新动态对应的独立节点，查找与所述独立节点所连接的所有所述有向边并获取查找的所述有向边对应的依赖详情信息；
    对比获取的所述依赖详情信息与所述版本修改描述信息，生成有向边修改策略；及
    根据所述有向边修改策略更新所述版本依赖网络图，并将更新的所述版本依赖网络图推送至与本次修改相关的所述模块终端。
  17. 根据权利要求16所述的存储介质，其特征在于，所述计算机可读指令被所述处理器执行时还执行以下步骤：
    将生成的所述有向边修改策略推送至发布所述版本更新动态的所述模块终端，以使所述模块终端对所述有向边修改策略进行确认；及
    当接收到所述模块终端发送的确定指令后，执行所述根据所述有向边修改策略更新所述版本依赖网络图，并将更新的所述版本依赖网络图推送至与本次修改相关的所述模块终端的步骤。
  18. 根据权利要求16所述的存储介质，其特征在于，所述计算机可读指令被所述处理器执行时还执行以下步骤：
    判断所述版本修改描述信息中是否携带有升级版本标识，若是，则在所述版本依赖关系网络图中相应的所述独立节点处增加与所述升级版本标识对应的子节点。
  19. 根据权利要求16所述的存储介质，其特征在于，所述计算机可读指令被所述处理器执行时还执行以下步骤：
    依次将所述版本修改描述信息与查找的每个所述有向边对应的所述依赖详情信息进行对比，判断本次修改是否涉及对所述依赖详情信息中记录的依赖部分的修改，若是，则根据对比结果删除已有所述有向边或修改已有所述有向边对应的依赖详情信息；并判断对已有有向边的修改是否使所述已有所述有向边对应的依赖关系不稳定，若是，则向不稳定的所述有向边对应的所述模块终端发送提醒信息；
    根据对比结果生成新的有向边以及对应的依赖详情信息。
  20. 根据权利要求16所述的存储介质，其特征在于，所述计算机可读指令被所述处理器执行时还执行以下步骤：
    根据所述版本依赖关系图生成每个模块的依赖关系子图，并将生成的所述依赖关系子图推送至相应的所述模块终端显示。
PCT/CN2017/104629 2017-08-09 2017-09-29 多模块版本依赖关系构建方法、装置、服务器和存储介质 Ceased WO2019028992A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710674839.7A CN107678776A (zh) 2017-08-09 2017-08-09 多模块版本依赖关系构建方法、装置、服务器和存储介质
CN201710674839.7 2017-08-09

Publications (1)

Publication Number Publication Date
WO2019028992A1 true WO2019028992A1 (zh) 2019-02-14

Family

ID=61135167

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/104629 Ceased WO2019028992A1 (zh) 2017-08-09 2017-09-29 多模块版本依赖关系构建方法、装置、服务器和存储介质

Country Status (2)

Country Link
CN (1) CN107678776A (zh)
WO (1) WO2019028992A1 (zh)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111142931A (zh) * 2020-01-02 2020-05-12 中国银行股份有限公司 一种基线信息确定方法、装置、服务器及存储介质
CN111522579A (zh) * 2020-06-22 2020-08-11 上海通联金融服务有限公司 一种版本环境进程检测方法、设备及存储介质
CN115480817A (zh) * 2022-09-14 2022-12-16 浪潮通用软件有限公司 基于应用开发平台的依赖引用关系图构建方法及系统
CN116204225A (zh) * 2023-03-14 2023-06-02 中国邮政储蓄银行股份有限公司 技术平台的打包发布方法、装置和技术平台的开发系统
CN117112011A (zh) * 2023-08-16 2023-11-24 北京冠群信息技术股份有限公司 一种版本管理方法及装置
US12192062B2 (en) 2022-08-26 2025-01-07 Cisco Technology, Inc. Methods for implementing time-travelling networks using extensions to graph databases

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108363587B (zh) * 2018-03-07 2022-02-01 平安普惠企业管理有限公司 应用程序运行监控方法、装置、计算机设备和存储介质
CN109117143A (zh) * 2018-06-11 2019-01-01 阿里巴巴集团控股有限公司 一种应用部署方法及系统
US10873604B1 (en) * 2018-06-19 2020-12-22 Architecture Technology Corporation Methods and systems for reconfiguring network devices
CN109144980A (zh) * 2018-08-21 2019-01-04 成都四方伟业软件股份有限公司 元数据管理方法、装置及电子设备
CN109241672A (zh) * 2018-10-15 2019-01-18 中冶赛迪技术研究中心有限公司 一种物流仿真软件的模型版本升级系统及方法
CN110162477B (zh) * 2019-05-28 2022-11-22 山东财经大学 一种第三方库版本升级的异常自动调试系统及方法
CN110704062A (zh) * 2019-09-27 2020-01-17 天津五八到家科技有限公司 依赖管理方法、数据获取方法、装置及设备
CN111090835B (zh) * 2019-12-06 2022-04-19 支付宝(杭州)信息技术有限公司 一种文件衍生图的构建方法及装置
CN111176723B (zh) * 2019-12-31 2020-11-06 上海道客网络科技有限公司 基于服务网格和链路版本的服务多版本发布系统与方法
CN111274271A (zh) * 2020-01-13 2020-06-12 北京奇艺世纪科技有限公司 一种信息管理装置、方法、电子设备及存储介质
CN111399898B (zh) * 2020-03-04 2023-09-05 平安科技（深圳）有限公司 多模块系统代码版本的管理方法、装置和计算机设备
CN114090032B (zh) * 2020-08-05 2024-08-16 福建天泉教育科技有限公司 一种通过即时通讯工具进行版本更新消息推送的方法及系统
CN112286545B (zh) * 2020-09-21 2023-05-05 长沙市到家悠享网络科技有限公司 数据更新方法、装置、设备和存储介质
CN112256318B (zh) * 2020-10-26 2022-12-27 上海云轴信息科技有限公司 一种用于依赖产品的构建方法及设备
CN112363756B (zh) * 2020-12-04 2022-06-21 四川长虹电器股份有限公司 一种可动态切换bom版本的方法
CN112632957A (zh) * 2020-12-18 2021-04-09 湖南特能博世科技有限公司 电力图纸管理方法、装置、终端设备及服务器
CN112947896B (zh) * 2021-03-26 2023-10-27 中国航空无线电电子研究所 一种基于有向图的组件依赖分析方法
CN114003269A (zh) * 2021-10-22 2022-02-01 挂号网（杭州）科技有限公司 组件处理方法、装置、电子设备及存储介质
CN115695219A (zh) * 2022-10-28 2023-02-03 河北幸福消费金融股份有限公司 Mock平台管理系统、方法、设备和存储介质
CN115630201A (zh) * 2022-11-08 2023-01-20 中国银行股份有限公司 系统组件关联关系分析方法及装置
CN115794196B (zh) * 2023-02-13 2023-06-30 中科南京软件技术研究院 EdgeX的关键软件识别方法、装置、设备及存储介质
CN120723223B (zh) * 2025-05-16 2026-03-13 仁众智能科技(苏州)有限公司 基于流程组件实现可视化工作流的配置自动化管理方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104765620A (zh) * 2014-01-02 2015-07-08 国际商业机器公司 一种程序模块部署的方法和系统
US20150227363A1 (en) * 2014-02-13 2015-08-13 Linkedln Corporation Systems and methods for software dependency management
CN106648563A (zh) * 2015-10-30 2017-05-10 阿里巴巴集团控股有限公司 应用程序中共享模块的依赖解耦处理方法和装置
CN106874031A (zh) * 2017-01-03 2017-06-20 青岛海信电器股份有限公司 一种终端设备系统程序的启动方法及装置

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10157172B2 (en) * 2008-08-27 2018-12-18 International Business Machines Corporation Property dependency visualization
CN102109991A (zh) * 2010-07-30 2011-06-29 兰雨晴 软件包依赖关系建模方法
CN102073582A (zh) * 2010-07-30 2011-05-25 兰雨晴 基于冲突的软件包依赖关系检查方法
CN102880466B (zh) * 2012-09-04 2016-03-16 中标软件有限公司 一种Linux操作系统软件包依赖关系检测方法
CN106371838B (zh) * 2016-08-31 2019-10-18 福建联迪商用设备有限公司 一种维护软件包依赖关系的方法及系统
CN106886410B (zh) * 2017-01-06 2018-06-19 深圳云天励飞技术有限公司 一种软件版本管理系统
CN106970788B (zh) * 2017-02-24 2018-08-07 中国人民解放军海军大连舰艇学院 一种基于时态的对象依赖关系发现方法和系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104765620A (zh) * 2014-01-02 2015-07-08 国际商业机器公司 一种程序模块部署的方法和系统
US20150227363A1 (en) * 2014-02-13 2015-08-13 Linkedln Corporation Systems and methods for software dependency management
CN106648563A (zh) * 2015-10-30 2017-05-10 阿里巴巴集团控股有限公司 应用程序中共享模块的依赖解耦处理方法和装置
CN106874031A (zh) * 2017-01-03 2017-06-20 青岛海信电器股份有限公司 一种终端设备系统程序的启动方法及装置

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111142931A (zh) * 2020-01-02 2020-05-12 中国银行股份有限公司 一种基线信息确定方法、装置、服务器及存储介质
CN111142931B (zh) * 2020-01-02 2023-03-21 中国银行股份有限公司 一种基线信息确定方法、装置、服务器及存储介质
CN111522579A (zh) * 2020-06-22 2020-08-11 上海通联金融服务有限公司 一种版本环境进程检测方法、设备及存储介质
US12192062B2 (en) 2022-08-26 2025-01-07 Cisco Technology, Inc. Methods for implementing time-travelling networks using extensions to graph databases
CN115480817A (zh) * 2022-09-14 2022-12-16 浪潮通用软件有限公司 基于应用开发平台的依赖引用关系图构建方法及系统
CN116204225A (zh) * 2023-03-14 2023-06-02 中国邮政储蓄银行股份有限公司 技术平台的打包发布方法、装置和技术平台的开发系统
CN117112011A (zh) * 2023-08-16 2023-11-24 北京冠群信息技术股份有限公司 一种版本管理方法及装置

Also Published As

Publication number Publication date
CN107678776A (zh) 2018-02-09

Similar Documents

Publication Publication Date Title
WO2019028992A1 (zh) 多模块版本依赖关系构建方法、装置、服务器和存储介质
US10776104B2 (en) Systems and methods for tracking configuration file changes
CN105740048B (zh) 一种镜像管理方法、装置及系统
US9229701B2 (en) Local store data versioning
CN106888233B (zh) 数据更新系统及方法
US11159390B2 (en) Systems and methods for service-aware mapping of a system infrastructure
CN112685499B (zh) 一种工作业务流的流程数据同步方法、装置及设备
WO2017143844A1 (zh) 数据操作方法和数据管理服务器
CN102413022A (zh) 一种应用调试方法和系统
US12073263B1 (en) Dynamic processing of API requests
CN103475721B (zh) 一种数字资产更新系统的数字资产更新方法
CN114610509B (zh) 调用参数处理方法、系统、设备、存储介质及产品
CN116627928B (zh) 数据库迁移方法、装置、设备和存储介质
CN108536447B (zh) 运维管理方法
CN107729421B (zh) 存储过程的执行方法、装置及存储介质
CN117931813A (zh) 一种湖仓元数据变更确定方法、装置、设备、介质
CN113439418A (zh) 更改资源状态的方法、系统、终端及存储介质
CN112711466B (zh) 悬挂事务巡检方法和装置、电子设备和存储介质
US11153388B2 (en) Workflow engine framework for cross-domain extension
CN106126313A (zh) 一种基于Ambari集成Solr的方法及服务器
CN117354321B (zh) 业务数据的镜像方法和装置、存储介质和电子装置
CN119128006B (zh) 一种面向分布式链路追踪框架的数字对象查询方法
US11816424B2 (en) Conditional save of draft enabled business objects
CN116150163B (zh) 信息提示方法、装置、设备、存储介质及产品
CN113760314B (zh) 页面模块的控制方法、装置、电子设备和存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17921379

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 25.06.2020)

122 Ep: pct application non-entry in european phase

Ref document number: 17921379

Country of ref document: EP

Kind code of ref document: A1