Software change processing method and device, computer equipment and storage medium

Abstract

The invention discloses a software change processing method and device, computer equipment and a storage medium, belongs to the technical field of software engineering, and is applied to a software delivery scene. According to the method, the software change event is continuously monitored, fine analysis and structured processing on the change log are combined, and under the support of the unified software asset dependency relationship graph, accurate topology analysis on the change influence range is realized, so that upstream and downstream software assets involved in the change can be accurately identified, and the change accuracy is improved. And automatically matching a most suitable change processing strategy based on the influence range, and driving a corresponding change processing executor to carry out targeted processing on the change content. By means of the technical means, on-demand and granularity-based processing of software change is achieved, unnecessary construction and deployment operations are reduced, the overall execution time of software change processing is shortened, consumption of computing resources and network resources is reduced, and therefore the efficiency, stability and safety of the software delivery process are overall improved.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of software engineering, and particularly relates to a software change processing method and device, computer equipment and a storage medium. BACKGROUND

[0002] In today's fast iteration software development environment, CI / CD pipeline has become the core infrastructure to ensure high-quality and efficient delivery of software. However, with the evolution of application architecture from monolithic to microservices, the scale and complexity of software systems have increased dramatically, posing great challenges to traditional CI / CD practices.

[0003] Most existing CI / CD processes use full processing mode, that is, once there is a change in the code base, the entire application will be triggered for complete construction, execution of all test cases, and deployment of the entire application package or all microservices. This mode has significant drawbacks, such as: Low efficiency and resource waste: Full construction and testing takes a very long time, especially in large projects or microservice clusters, consuming a large amount of computing resources and time cost.

[0004] Long feedback cycle: Developers need to wait for the entire pipeline to complete before receiving feedback, significantly slowing down development iterations.

[0005] High deployment risk: Full deployment means that a large number of unchanged components will be pushed to production environment every time, and any minor, undetected compatibility issues can cause system-level failures, with large rollback scope and high cost.

[0006] Lack of precision: Existing technologies lack intelligent analysis capabilities for code change content, and cannot distinguish between infrastructure scripts, public library components, or business service modifications, resulting in "one-size-fits-all" full processing and inability to achieve precise optimization.

[0007] Therefore, developing a unified framework to collaboratively manage full-link, multi-granularity incremental software change operations from code to deployment has become a technical problem to be solved. SUMMARY

[0008] The purpose of the embodiments of the present application is to propose a software change processing method, device, computer equipment and storage medium to develop a unified framework to collaboratively manage full-link, multi-granularity incremental software change operations from code to deployment.

[0009] To solve the above technical problems, the embodiments of the present application provide a software change processing method, which adopts the following technical solutions: A software change processing method, comprising: Continuously monitoring change events of a data source and obtaining change logs of the data source; The change log is parsed to obtain metadata of the change set, wherein the metadata of the change set at least includes a file change path and a data change type; Topological analysis is performed based on the metadata of the change set and a preset software asset dependency graph to determine an upstream and downstream range affected by the change event; A matched change processing strategy is determined based on the upstream and downstream range; According to the matched change processing strategy, a corresponding change processing executor is called to perform software change processing, and a change processing result is output.

[0010] To solve the above technical problems, the embodiment of the present application further provides a software change processing device, which adopts the technical scheme as follows: A software change processing device comprises: A change monitoring module is configured to continuously monitor a change event of a data source and obtain a change log of the data source; A change analysis module is configured to parse the change log to obtain metadata of a change set, wherein the metadata of the change set at least includes a file change path and a data change type; A topological analysis module is configured to perform topological analysis based on the metadata of the change set and a preset software asset dependency graph to determine an upstream and downstream range affected by the change event; A change strategy module is configured to determine a matched change processing strategy based on the upstream and downstream range; A change processing module is configured to call a corresponding change processing executor to perform software change processing according to the matched change processing strategy, and output a change processing result.

[0011] To solve the above technical problems, the embodiment of the present application further provides a computer device, which adopts the technical scheme as follows: A computer device comprises a memory and a processor, wherein the memory stores computer readable instructions, and the processor executes the computer readable instructions to realize the steps of the software change processing method according to any one of the above.

[0012] To solve the above technical problems, the embodiment of the present application further provides a computer readable storage medium, which adopts the technical scheme as follows: A computer readable storage medium stores computer readable instructions, and the computer readable instructions are executed by a processor to realize the steps of the software change processing method according to any one of the above.

[0013] Compared with the prior art, the embodiment of the present application has the following beneficial effects: This application discloses a software change processing method, apparatus, computer equipment, and storage medium, belonging to the field of software engineering technology and applied to software delivery scenarios. By continuously monitoring software change events and combining refined analysis and structured processing of change logs, supported by a unified software asset dependency graph, this application achieves precise topological analysis of the scope of change impact. This allows for accurate identification of the upstream and downstream software assets involved in the change, automatically matching the most suitable change processing strategy based on the scope of impact, and driving the corresponding change processing executor to handle the change content in a targeted manner. This avoids the full build, full test, or full deployment methods commonly used in traditional software delivery processes. Through the above technical means, this application achieves on-demand and granular processing of software changes, effectively reducing unnecessary build and deployment operations, significantly shortening the overall execution time of software change processing, and reducing the consumption of computing and network resources, thereby improving the overall efficiency, stability, and security of the software delivery process. Attached Figure Description

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

[0015] Figure 1 An exemplary system architecture diagram is shown, in which this application can be applied; Figure 2 A flowchart illustrating one embodiment of the software change processing method according to this application is shown; Figure 3 It shows Figure 2 A flowchart of an embodiment of step S203; Figure 4 A schematic diagram of the structure of one embodiment of the software change processing apparatus according to this application is shown; Figure 5 It shows Figure 4 A schematic diagram of a embodiment of the topology analysis module 403; Figure 6 A schematic diagram of the structure of one embodiment of a computer device according to this application is shown. Detailed Implementation

[0016] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein in the specification of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application; the terms "comprising" and "having," and any variations thereof, in the specification, claims, and foregoing drawings of this application, are intended to cover non-exclusive inclusion. The terms "first," "second," etc., in the specification, claims, or foregoing drawings of this application are used to distinguish different objects, not to describe a particular order.

[0017] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0018] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0019] like Figure 1 As shown, system architecture 100 may include terminal device 101, network 102, and server 103. Terminal device 101 may be a laptop 1011, tablet 1012, or mobile phone 1013. Network 102 is used as a medium to provide a communication link between terminal device 101 and server 103. Network 102 may include various connection types, such as wired, wireless communication links, or fiber optic cables.

[0020] Users can use terminal device 101 to interact with server 103 via network 102 to receive or send messages, etc. Various communication client applications can be installed on terminal device 101, such as web browser applications, shopping applications, search applications, instant messaging tools, email clients, social media platform software, etc.

[0021] Terminal device 101 can be various electronic devices with a display screen and support web browsing. In addition to laptops 1011, tablets 1012, or mobile phones 1013, terminal device 101 can also be an e-book reader, an MP3 player (Moving Picture Experts Group Audio Layer III), an MP4 player (Moving Picture Experts Group Audio Layer IV), a laptop computer, and a desktop computer, etc.

[0022] Server 103 can be a server that provides various services, such as a backend server that provides support for the pages displayed on terminal device 101.

[0023] It should be noted that the software change processing method provided in this application embodiment is generally executed by a server / terminal device, and correspondingly, the software change processing device is generally set in the server / terminal device.

[0024] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative; the system can have any number of terminal devices, networks, and servers depending on implementation needs.

[0025] Continue to refer to Figure 2 A flowchart illustrating an embodiment of a software change processing method according to this application is shown. The software change processing method includes the following steps: S201 continuously monitors change events of the data source and obtains the change log of the data source; Specifically, the system deploys a change awareness module to continuously monitor one or more data sources to detect change events related to software assets in real time. These data sources can include, but are not limited to, version control systems, artifact repositories, image repositories, or configuration management systems. The change awareness module receives change notifications through event subscriptions, webhook callbacks, polling scans, or message queues. When operations such as commits, merges, pushes, artifact updates, or configuration changes occur in a data source, the data source generates a corresponding change event, which is captured by the change awareness module. Upon receiving a change event, the system extracts the change log information associated with that event from the event payload. This change log records the basic data of the change. The change log may include the time of the change, the change source identifier, the operator identifier, the change object identifier, and a list of files or resources involved in the change. In this way, the system can continuously and stably acquire raw log data reflecting changes in the state of software assets without interfering with existing development or delivery processes.

[0026] S202, parse the change log to obtain the metadata of the change set, wherein the metadata of the change set includes at least the file change path and the data change type; Specifically, after obtaining the change log, the system calls the parsing module to perform structured parsing processing on the change log. The parsing module first identifies the format of the change log and, based on the different log sources, uses corresponding parsing rules to split the log content and extract fields. Then, the parsing module extracts information related to the changed files from the change log, forming a list of changed files, and parses each change record one by one. For each changed file, the system reads its corresponding file path information and performs normalization processing on the file path, such as standardizing path separators, eliminating relative path representations, and parsing symbolic links or path aliases, to ensure consistency of path information during processing. Simultaneously, the system identifies the data change type corresponding to each changed file based on the operation type recorded in the change log. The data change type can include addition, modification, deletion, or renaming. The parsing module associates the file change path with the corresponding data change type and encapsulates the parsed information into a structured change set metadata object, enabling the change set metadata to be directly called and processed by the analysis module in a unified data structure format.

[0027] S203, based on the metadata of the change set and the preset software asset dependency graph, perform topology analysis to determine the upstream and downstream scope affected by the change event; Specifically, the system utilizes a pre-constructed software asset dependency graph to perform topology analysis on change set metadata. First, based on the file change paths in the change set metadata, the system performs a mapping operation in the software asset dependency graph to determine the software asset nodes corresponding to those paths. These software asset nodes can represent projects, components, libraries, services, or other logical units. After determining the starting node, the system uses this node as the starting point for topology analysis and performs graph traversal operations based on the dependency edges defined in the dependency graph. The traversal operation can extend upstream and downstream according to the dependency direction, identifying other nodes that depend on the starting node and nodes that are depended upon by the starting node. During the traversal, the system can control the traversal range according to preset traversal depth, dependency propagation rules, or node type restrictions. By traversing directly and indirectly dependent nodes layer by layer, the system can identify multiple software asset nodes that may be affected by this change and aggregate these nodes into a set of upstream and downstream nodes representing the scope of the change event's impact.

[0028] S204, Determine the matching change handling strategy based on the upstream and downstream scope; Specifically, after obtaining the upstream and downstream scope of the impact of the change event, the system first analyzes the upstream and downstream node sets, extracting key information, including the number of nodes, node type distribution, dependency layer depth, and dependency complexity. Based on this information, the system constructs an impact feature description for strategy matching. Subsequently, the system matches the impact feature description with a pre-defined change handling strategy rule base. The strategy rule base predefines various change handling strategies and their applicable conditions. Different strategies correspond to different processing granularities and processing methods; for example, different strategy rules are set for script-type changes, package-type changes, component-level changes, or microservice-level changes. Based on the rule matching results, the system automatically selects the target change handling strategy that matches the current change event. When multiple candidate strategies exist, the system filters or combines strategies based on priority or constraints, ultimately forming a strategy decision result to drive the execution phase.

[0029] S205: Based on the matched change handling strategy, call the corresponding change handling executor to perform software change handling and output the change handling result.

[0030] Specifically, after determining the target change handling strategy, the system transforms the strategy result into executable scheduling instructions through a unified scheduling module. The scheduling module selects the corresponding target executor from a pre-defined set of change handling executors based on the processing granularity and type defined in the strategy. These change handling executors may include script change handling executors, whole package change handling executors, component change handling executors, or microservice change handling executors, etc. The scheduling module issues execution instructions to the target executor, which include change set metadata, upstream and downstream scope information, and strategy constraints. Upon receiving the instructions, the target executor completes the corresponding software change handling operation according to its own execution logic. During execution, the executor reports its execution status and intermediate results back to the scheduling module. After execution is complete, the system organizes and encapsulates the results returned by the executor, generates a unified format change handling result, and outputs this result to the upper-layer system, storage module, or display module.

[0031] In one specific embodiment of this application, the data change type is taken as an addition, the corresponding change processing strategy is an incremental processing strategy, and the corresponding change processing executors include script incremental executors, whole package incremental executors, component incremental executors, and microservice incremental executors, wherein: Script incremental executors focus on handling infrastructure-as-code changes, enabling differential execution; package incremental executors leverage the layered nature of container images or packages to rebuild and push only the changed layers; component incremental executors, in monolithic repositories or multi-module projects, only build and test the affected modules; and microservice incremental executors combine service meshes and release strategies to achieve smooth deployment of changed services.

[0032] Specifically, when the data change type is "new", the script incremental executor first parses the path of the new script file in the change set metadata. It then performs a static check on the script content using Infrastructure as Code (IaC) syntax rules to confirm the syntactic validity and resource definition completeness of the new script. Subsequently, based on a preset baseline script version, it uses a comparison algorithm to identify differences between the new script and existing scripts in the baseline version, eliminating duplicate or redundant resource definitions and extracting only the newly added resource configuration blocks or execution logic. During the execution phase, the script incremental executor calls the differential execution interface of the corresponding IaC tool, deploying or configuring only the identified new resource blocks. This avoids a full redeployment of existing infrastructure resources, reducing execution time and minimizing interference with the runtime environment. After execution, the script incremental executor records the identifier, configuration parameters, deployment status, and execution time of the new resource in the execution result information.

[0033] When faced with new data changes, the full-package incremental executor first analyzes the package or container image context to which the new file belongs in the change set metadata. For container image scenarios, the executor determines the new file's hierarchical position in the image build context based on its path. Then, based on the instructions in the Dockerfile or other build files, it determines whether the new file will trigger changes to the base image layer or intermediate layers. If the new file is located in a separate new layer, the executor only builds the new layer containing the new file and reuses the unchanged underlying image layer, generating an incrementally updated image layer sequence. For traditional packages, the executor identifies the package structure path corresponding to the new file, only packages the new file to the corresponding package directory, and updates the file list and version information in the package metadata, avoiding repackaging and signing the entire package. During the push phase, the full-package incremental executor pushes only the newly added or changed image layer data or package fragments through the incremental upload interface of the artifact repository, significantly reducing the amount of data transmitted over the network.

[0034] For newly added data changes, the component incremental executor first locates the code module or component unit to which the new file belongs based on the file change path in the change set metadata. Combining this with a pre-defined software asset dependency graph, it analyzes the component unit's position in the project architecture and its directly dependent parent and child modules. If the new file belongs to a completely new component module, the executor creates a new component build context, collects the required dependency libraries and configuration files, and generates an independent component build task. If the new file is an extension of an existing component, it only updates the component's source file list and build script. During the build and testing phases, the component incremental executor only triggers the compilation, unit testing, and integration testing processes for the new component and its directly dependent components, skipping other unaffected components. After the tests pass, the executor packages the new component into an independent artifact and updates the component version number and dependency information to the component registry.

[0035] When the microservice incremental executor processes new data changes, it first determines whether the new file belongs to a new microservice instance or a new functional module of an existing microservice. If it is a new microservice instance, the executor generates the deployment configuration file, service discovery rules, and network policies for the microservice based on the service definition information (such as service name, port, registry address, etc.) in the change set metadata and a preset service mesh configuration template. Subsequently, through the service mesh control plane interface, the instance information of the new microservice is registered with the service registry, and initial traffic routing rules are configured to ensure that the new service only receives a preset proportion of test traffic or internal traffic. During deployment, the executor adopts a blue-green deployment or canary release strategy, first starting the new microservice instance in an isolated environment to perform health checks and basic function verification. After the instance is running stably, the traffic weight is gradually adjusted to smoothly switch actual traffic to the new instance. At the same time, the executor monitors key indicators such as the response time and error rate of the new service in real time. If an anomaly occurs, it immediately triggers a traffic rollback to the original service path (if it exists) or suspends the release process.

[0036] The core of this application is to construct an intelligent change decision-making hub and a set of collaborative, multi-granularity incremental executors. This system monitors data sources such as version control systems, uses dependency graphs to intelligently analyze the impact scope of change sets, automatically determines whether a change belongs to the script, package, component, or microservice granularity, and then drives the corresponding incremental executors (script incremental executor, package incremental executor, component incremental executor, and microservice incremental executor) to complete precise build and incremental extraction tasks. Finally, a unified scheduling module ensures the coordination and reliability of the entire process.

[0037] Furthermore, the steps of parsing the change log to obtain the metadata of the change set specifically include: Extract the original record information of the change events from the change log. The original record information includes at least the change commit identifier, change timestamp, and list of changed files. The original record information is parsed item by item to obtain the file change path corresponding to the changed file; Obtain the operation type information of the change event, and identify the change behavior of the changed file based on the operation type information to determine the data change type. The data change type includes at least addition, modification and deletion. The file change path is associated with the data change type and encapsulated to generate a structured change set, and the metadata of the change set is obtained.

[0038] Specifically, the system first preprocesses the raw change logs using a log parsing engine, removing redundant characters, standardizing the time format (e.g., converting to UTC timestamps), and verifying log integrity. For change commit identifiers, the system extracts a unique hash value generated by the version control system (e.g., Git's Commit ID) as a globally unique identifier for the change; change timestamps are accurate to the millisecond level to ensure the accuracy of the change order. During the extraction of the changed file list, the system filters out empty files, temporary files, or files marked as ignored (e.g., according to rules defined in .gitignore), retaining only valid file records related to software assets. Subsequently, for file change paths, the system uses a path normalization algorithm to uniformly convert path formats from different operating systems (e.g., Windows' backslashes and Linux's forward slashes) into a standard format, and processes symbolic links or shortcuts in the path using a symbolic link resolver to ensure that the physical location pointed to by the path is unique. For change behavior identification, the system establishes an operation type mapping table, converting the original operation codes returned by the data source (such as SVN's "add", "modify", "delete" or Git's "M", "A", "D") into unified data change type enumeration values. Complex operations (such as file renaming) are handled specially, comparing the file paths and content hashes before and after the change to determine if it belongs to a "rename + modify" combination. Finally, the system uses structured data formats such as JSON or Protocol Buffers to encapsulate the file change path array, the corresponding data change type array, and metadata fields such as change commit identifiers and timestamps into a changeset object. Digital signatures are used to ensure the integrity of the metadata during transmission and storage, preventing tampering or damage.

[0039] Further, please refer to Figure 3 The steps involved in determining the upstream and downstream scope of a change event's impact, based on the change set's metadata and a pre-defined software asset dependency graph, include: S301, Based on the file change path, perform node mapping in the software asset dependency graph to determine the software asset node corresponding to the file change path, wherein the software asset node includes at least one of the following: project, component, library or microservice node; S302, taking the software asset node as the starting node, and performing a graph traversal operation based on the dependency edges defined in the software asset dependency graph to obtain the first-level upstream and downstream node set that has a direct dependency relationship with the starting node; S303, Based on obtaining the first-level upstream and downstream node set, continue to perform multi-level topological traversal according to the preset traversal depth to determine the multi-level upstream and downstream node set that has an indirect dependency relationship with the starting node. S304 summarizes and deduplicates the first-level upstream and downstream node sets and the multi-level upstream and downstream node sets to generate upstream and downstream node range results that represent the impact range of the change event.

[0040] Specifically, in S301, the system performs fine-grained parsing of file change paths in the change set metadata. For example, the path " / projectA / components / serviceB / src / utils / tool.py" is broken down into a hierarchical structure including project (projectA), component (serviceB), source code directory (src / utils), and specific file (tool.py). Then, based on the preset mapping rules of the software asset dependency graph, the file paths are precisely matched with node attributes (such as asset paths and resource identifiers) in the graph. If a file path directly corresponds to the core code file of a component, it is mapped to that component node; if the file belongs to a public function of a base library, it is mapped to the corresponding library node. For shared files across nodes, the system determines a unique mapping node through path priority rules (such as project-level paths taking precedence over global library paths), ensuring the accuracy of the starting node location.

[0041] Upon entering S302, the system uses the mapped software asset nodes as the center and performs a bidirectional breadth-first traversal based on the directed dependency edges defined in the graph. For example, if the starting node is component serviceB (downstream dependency direction), it traverses the API gateway node and front-end application node that directly depend on serviceB; if the starting node depends on library libC (upstream dependency direction), it traverses the libC node that serviceB directly depends on and its configuration center node. During the traversal, the system records the dependency types (e.g., compile-time dependencies, runtime dependencies, configuration dependencies) and dependency strengths (e.g., strong dependencies, weak dependencies) between nodes in real time. For node combinations with circular dependencies (e.g., serviceB and serviceD depend on each other), the system avoids repeated traversal by marking visited nodes and records circular dependencies as a special feature.

[0042] During the multi-level traversal phase of S303, the system dynamically adjusts its traversal behavior based on preset parameters. If the preset traversal depth is 3 levels, it traverses the first, second, and third level nodes sequentially, starting from the initial node. For example, the first level downstream node of the initial node serviceB is the API gateway, the second level is the mobile application, and the third level is the third-party integration service. Simultaneously, the system filters irrelevant nodes based on node type, such as excluding non-production environment nodes like document nodes and test case nodes; and terminates downstream propagation for weakly dependent nodes (such as optional plugins) according to dependency propagation rules. During traversal, the system monitors the current depth in real time using a dependency level counter, automatically stopping when a preset threshold is reached or when a leaf node (with no downstream dependencies) is reached.

[0043] In the S304 phase, the system first performs a deduplication operation on the node set collected through multi-level traversal, removing duplicates by using unique node identifiers (such as UUIDs). For example, a common configuration node that is depended on by multiple upstream nodes is only retained once. Subsequently, the deduplicated node set undergoes a structured analysis: statistics are presented by node type (e.g., component nodes account for 60%, service nodes for 30%, library nodes for 10%), by dependency level (e.g., 15 nodes in level 1, 8 in level 2, and 3 in level 3), and by dependency complexity (calculated based on node in-degree / out-degree and dependency chain length). Finally, a list of upstream and downstream node ranges is generated, containing fields such as node ID, type, level, dependency direction, dependency type, and risk level. A visualization engine is then used to draw an impact topology map, visually demonstrating the propagation path and extent of the change event.

[0044] Furthermore, the steps of using software asset nodes as the starting node, and performing graph traversal operations based on the dependency edges defined in the software asset dependency graph to obtain the first-level upstream and downstream node set that has a direct dependency relationship with the starting node, specifically include: In the software asset dependency graph, read the dependency edges directly connected to the starting node and identify the direction attribute of each dependency edge to distinguish upstream and downstream dependencies. Based on the direction attribute of the dependency edge, determine the set of upstream nodes and the set of downstream nodes that have a direct dependency relationship with the starting node. The downstream node represents the software asset that depends on the starting node, and the upstream node represents the software asset that the starting node depends on. The upstream and downstream node sets are categorized and organized to generate a first-level upstream and downstream node set that has a direct dependency on the starting node.

[0045] Specifically, the system first loads the adjacent edge data of the starting node through the graph query interface. Each dependency edge includes the source node ID, target node ID, direction identifier (e.g., "→" indicates upstream to downstream, "←" indicates downstream to upstream), dependency type label (e.g., "COMPILE", "RUNTIME", "CONFIG"), and edge weight value (representing the degree of dependency). For direction attribute identification, the system adopts a bidirectional edge resolution mechanism: if the source node in the edge record is the starting node and the direction identifier is "→", then the target node is a downstream dependency of the starting node (i.e., the downstream node depends on the starting node); if the source node is another node and the direction identifier points to the starting node ("←"), then the source node is an upstream dependency of the starting node (i.e., the starting node depends on the upstream node). For example, if the starting node is "Component A" and there is an edge record (Component A→API Gateway, RUNTIME, 0.8), then "API Gateway" is a downstream node; if there is an edge record (Base Library B←Component A, COMPILE, 0.9), then "Base Library B" is an upstream node.

[0046] After determining the upstream and downstream node sets, the system categorizes and organizes them according to dependency type. The upstream node set is sorted by dependency necessity, prioritizing strong dependencies (such as basic libraries required at compile time) and filtering out weakly dependent optional components. The downstream node set is categorized by business impact scope, such as core business nodes (payment services), supporting business nodes (log services), and auxiliary nodes (monitoring plugins). Simultaneously, the system adds metadata tags to each node, including the project it belongs to, the person in charge, the most recent change time, and historical fault records. The final first-level upstream and downstream node set is stored in a structured list format, containing fields such as node ID, name, type, dependency direction, dependency type, weight value, and risk level. A directed graph preview is generated using a dependency visualization component, clearly displaying the network of relationships between the starting node and directly dependent nodes.

[0047] Furthermore, based on obtaining the first-level upstream and downstream node set, and according to a preset traversal depth, the process continues to perform multi-level topological traversal to determine the multi-level upstream and downstream node sets that have indirect dependencies on the starting node. This specifically includes: Based on the preset traversal depth parameter, initialize the level counter of the multi-level topology traversal, and set the upstream and downstream node set of the first level as the initial node set of the current traversal level. Given the initial set of nodes in the current traversal layer, obtain the set of candidate nodes in the next layer that have direct dependencies on the nodes in the current traversal layer, according to the dependency edges defined in the software asset dependency graph. The next layer of candidate nodes is deduplicated and loop detected, filtering out nodes that have been traversed or have formed closed-loop dependencies. If the level counter has not reached the preset traversal depth, the candidate node set of the next level is merged into the multi-level upstream and downstream node set, and the current traversal level node set is updated. The above steps are repeated until the topological traversal of the preset traversal depth is completed, and the multi-level upstream and downstream node set with indirect dependencies is obtained.

[0048] Specifically, the preset traversal depth parameter can be configured by the system administrator according to the business scenario. For example, the core transaction system is set to 3 layers (to strictly control the scope of influence), and the internal management system is set to 5 layers (to allow for wider dependency propagation). The default value is 3 layers. The level counter is initialized to 1 (corresponding to the set of upstream and downstream nodes in the first layer) and increments with each traversal level. The initial node set of the current traversal layer contains all valid nodes in the upstream and downstream nodes of the first layer (weak dependencies or non-production nodes have been filtered out).

[0049] After entering the next candidate node acquisition stage, the system executes the same bidirectional dependency traversal logic as the starting node for each node in the current traversal layer: taking the upstream node "Basic Library B" as an example, it traverses its directly upstream "Compiler Component" and directly downstream "Component C"; taking the downstream node "API Gateway" as an example, it traverses its directly downstream "Mobile Application" and directly upstream "Authentication Service". During the traversal, the system synchronously collects the dependency types between nodes (such as "Basic Library B → Component C" being a runtime dependency with a weight value of 0.7) and path metadata (such as dependency chain length and intermediate nodes traversed).

[0050] The deduplication of the candidate node set for the next layer is handled using a hash table based on node UUIDs. Nodes already existing in multiple upstream and downstream node sets or in the current traversal layer are directly filtered out. Cycle detection is achieved by maintaining a "visited node stack." If a candidate node already appears in the current traversal path (e.g., "Component A → API Gateway → Component A"), the system determines it as a circular dependency, automatically terminates further traversal of that path, and records the circular node pair and the length of the dependency chain as abnormal dependency characteristics. For non-cyclic candidate nodes, the system further checks whether they belong to a preset "traversal forbidden zone" (e.g., database cluster nodes, immutable third-party services). If they do, they are marked as "terminated nodes" and not included in the next layer of traversal.

[0051] When the level counter has not reached the preset depth (e.g., the current level is 2, and the preset depth is 3), the system merges the deduplicated candidate node set of the next level into the multi-level upstream and downstream node set, increments the level counter by 1, sets the candidate node set as the new current traversal level node set, and repeats the traversal of the next level. If the current level node set is empty during the traversal (e.g., there are no downstream dependent nodes), the traversal is terminated early, and the actual traversal depth is recorded. For example, if the preset depth is 5 levels, but the candidate node set is empty after the 3rd level traversal, the system will eventually generate a multi-level upstream and downstream node set containing nodes from levels 1 to 3, and note in the result "Traversal terminated early due to no valid dependent nodes". After the traversal is completed, the system groups the multi-level node set by level and calculates the average dependency strength (mean edge weight) and fault propagation probability (prediction model trained based on historical fault data) of nodes at each level.

[0052] Furthermore, the steps for determining a matching change handling strategy based on the upstream and downstream scope specifically include: Based on the distribution of node types, number of nodes, and dependency hierarchy information in the upstream and downstream scope, the impact characteristics of change events are evaluated, and impact assessment results for strategy matching are generated. The impact assessment results are matched with the preset change handling strategy rule base, and the target change handling strategy corresponding to the change event is determined based on the matching results. The change handling strategy includes at least one or a combination of script-level, package-level, component-level and microservice-level handling strategies. The determined target change handling strategy is encapsulated in a structured manner to form a set of change handling strategies that includes processing granularity, execution order, and constraints.

[0053] Specifically, in the impact characteristic assessment phase, the system first performs multi-dimensional quantitative analysis of the metadata in the results of upstream and downstream node scope. Regarding node type distribution, it statistically analyzes the proportion of each category, such as project nodes, component nodes, library nodes, and microservice nodes. For example, when the proportion of component nodes exceeds 60% and the proportion of microservice nodes is less than 10%, it is initially determined that the impact of the change is concentrated in internal code modules. The number of nodes is constructed by calculating the total number of nodes, the number of core business nodes (such as nodes involved in transactions and payments), and the number of high-risk nodes (nodes with ≥3 historical failures) to build a scale feature vector. For dependency hierarchy information, it extracts the maximum traversal depth, average number of levels, and the entropy value of the node distribution at each level. A higher entropy value indicates a more dispersed distribution of the impact across levels. Based on the above analysis, the system uses a weighted scoring method to generate impact assessment results. The weight coefficients are dynamically adjusted according to the importance of the business domain (e.g., in the financial business domain, the weight of core business nodes is 0.4, and non-core nodes are 0.1). The final output includes an assessment report containing the impact level (low / medium / high / severe), impact scale (small / medium / large / very large), and risk tendency (functional risk / performance risk / security risk).

[0054] During the strategy matching phase, the system performs multi-condition matching between the impact assessment results and the pre-defined change handling strategy rule base. The rule base is stored using a decision tree structure, with the root node representing the impact level and branch nodes representing the impact scale, node type proportion, and risk tendency, respectively. For example, when the impact assessment result is "Impact Level: High, Impact Scale: Large, Component Node Proportion: 75%, Risk Tendency: Functional Risk," the system matches the rule "Execute Component-Level Full Testing + Canary Release Strategy" along the decision tree path. For ambiguous scenarios that cross rule boundaries (such as impact levels at the medium-high threshold), the system initiates a fuzzy inference mechanism, making a secondary decision by comprehensively considering the strategy execution effects (success rate, rollback rate) of similar historical change cases. The change handling strategy rule base supports dynamic updates. Administrators can add rules (such as adding a "Service Mesh Traffic Splitting Strategy" for scenarios where microservice node proportion exceeds 60%) or adjust rule parameters (such as modifying the canary release traffic ratio threshold) through the configuration interface.

[0055] During the strategy encapsulation phase, the system breaks down the matched target change handling strategy into an executable sequence of atomic operations. Taking the "component-level full-scale testing + canary release strategy" as an example, the atomic operations include: triggering component unit tests (specifying test case set ID), scheduling integration test environment resources (CPU / memory quota), automatic review of test reports (pass rate threshold ≥ 95%), selection of production environment canary nodes (filtered according to geographical distribution uniformity), initial configuration of traffic weights (5% of traffic imported into the new version), real-time collection of monitoring metrics (response time, error rate), traffic gradient increase (increase by 15% every 30 minutes), and triggering conditions for full switchover or rollback (if the error rate is <0.1% for 5 consecutive minutes, continue to increase; if >0.5%, rollback). The system adds execution order identifiers (such as pre-operation, parallel operation, post-operation) and constraints (such as terminating subsequent operations if the test pass rate does not meet the target) to each atomic operation, and generates a structured change handling strategy set containing strategy ID, strategy name, operation sequence, execution parameters, timeout mechanism, and contingency plan, which is stored in JSON format and synchronized to the change execution engine. In addition, the strategy set includes a visual flowchart that marks key decision-making nodes (such as test review points and traffic switching points) and their corresponding manual approval steps.

[0056] Furthermore, the steps of invoking the corresponding change processing executor to perform software change processing according to the matched change processing strategy and outputting the change processing results specifically include: Obtain the processing granularity information in the change handling strategy, and determine the target change handling executor that matches the processing granularity information from the preset set of change handling executors. The change handling executor includes at least script change handling executors, whole package change handling executors, component change handling executors, and microservice change handling executors. The unified scheduling command sends an execution command containing change set metadata, upstream and downstream scope information and policy constraints to the target change processing executor to trigger the target change processing executor to perform the corresponding software change processing operation. During the execution of the target change processing executor, execution status information and execution result information are collected in real time, and when an anomaly occurs, a preset retry, rollback or interruption processing mechanism is triggered according to the policy constraints. After the target change processing executor completes its execution, it summarizes and encapsulates the execution result information, generates the change processing result, and outputs the change processing result to the display component or visualization component of the upper-level system.

[0057] Specifically, the granularity of processing is directly related to the executor type selection: when the policy's processing granularity is "script level," the system matches a script change processing executor (supporting batch execution and version control of Shell / Python / Ansible scripts); "package level" corresponds to a package change processing executor (integrating Maven / Gradle packaging processes and artifact repository management); "component level" calls a component change processing executor (supporting hot-swapping of components based on OSGi or microkernel architectures); and "microservice level" activates a microservice change processing executor (interfacing with the Kubernetes API to implement Pod rolling updates and traffic management). For combined policies (such as "component-level testing + microservice-level deployment"), the system uses an executor coordination scheduling module to achieve serial / parallel orchestration of multiple executors.

[0058] During the instruction issuance phase, the unified scheduling instructions adopt a standardized protocol format, including basic fields (change ID, policy set ID, execution priority), change set metadata (code branch name, version number, change description MD5), upstream and downstream scope information (multi-level node set JSON, affected scope topology URL), and policy constraints (such as "test environment execution timeout threshold 30 minutes" and "production environment rollback trigger delay 5 minutes"). Taking the microservice change processing executor as an example, after receiving the instruction, it first parses the Kubernetes resource description file (Deployment / StatefulSet configuration), generates a canary deployment configuration based on the traffic weight parameters in the policy set (such as initial 5% traffic), calls the kubectl apply command to create a new version Pod, and configures traffic routing rules through ServiceMesh (such as Istio). During execution, the system collects real-time status through the executor's built-in monitoring agent: the script executor monitors the command return code, output log line count, and execution time; the microservice executor collects Pod ready probe status, container CPU utilization, service QPS, and error rate metrics.

[0059] The exception handling mechanism responds in tiers based on severity: minor exceptions (such as single-node script execution timeout) trigger local retries (maximum 3 times, with exponential backoff between retries); moderate exceptions (such as 10% of test nodes failing) execute branch switching within the strategy (such as switching from "parallel testing" to "serial testing"); severe exceptions (such as a sudden increase in the error rate of core business nodes exceeding a threshold) immediately initiate a rollback process, with the microservice executor calling the `kubectl rollout undo` command to restore the old version, and simultaneously notifying upstream and downstream dependent nodes to synchronize their execution status via a message queue. Interruption handling is only triggered when a "data consistency risk" is detected (such as database transaction rollback failure), freezing all change operations and generating a manual intervention work order, along with an exception stack log and a snapshot of the situation.

[0060] Upon completion, the results summary includes three parts: basic execution results (start time, end time, total time, number of successful nodes / number of failed nodes), key indicator comparisons (response time difference before and after the change, resource utilization change rate, test case pass rate), and impact scope verification results (automatic smoke testing confirms normal functionality of upstream and downstream nodes). The results are encapsulated as structured objects, synchronously stored in the change audit database (meeting SOX compliance requirements), and pushed to the upper-level visualization platform. The execution process is displayed as a timeline chart, with color coding indicating the status of each stage (green for success, yellow for warning, and red for failure). It also supports one-click export of a PDF change report, including execution details, anomaly analysis, and improvement suggestions. For continuous integration scenarios, the change processing results are callbackd to platforms such as GitLab / Jenkins via WebHook, triggering the build or deployment process.

[0061] In this embodiment, the software change processing method runs on an electronic device (e.g., Figure 1 The server shown can receive instructions or acquire data via wired or wireless connection. It should be noted that the aforementioned wireless connection methods may include, but are not limited to, 3G / 4G connections, WiFi connections, Bluetooth connections, WiMAX connections, Zigbee connections, UWB (ultra-wideband) connections, and other currently known or future wireless connection methods.

[0062] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing related hardware through computer-readable instructions. These computer-readable instructions can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, optical disk, or read-only memory (ROM), or random access memory (RAM).

[0063] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0064] Further reference Figure 4 As a response to the above Figure 2 To implement the method shown, this application provides an embodiment of a software change processing apparatus, which is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0065] like Figure 4 As shown, the software change processing device 400 described in this embodiment includes: The change monitoring module 401 is used to continuously monitor change events of the data source and obtain the change log of the data source; The change parsing module 402 is used to parse the change log and obtain the metadata of the change set. The metadata of the change set includes at least the file change path and the data change type. Topology analysis module 403 is used to perform topology analysis based on the metadata of the change set and the preset software asset dependency graph to determine the upstream and downstream scope affected by the change event. The change strategy module 404 is used to determine the matching change handling strategy based on the upstream and downstream scope; The change processing module 405 is used to call the corresponding change processing executor to perform software change processing according to the matched change processing strategy, and output the change processing results.

[0066] Furthermore, the modification of the parsing module 402 specifically includes: The original information unit is used to extract the original record information of change events from the change log. The original record information includes at least the change commit identifier, change timestamp, and list of changed files. The item-by-item parsing unit is used to parse the original record information item by item to obtain the file change path corresponding to the changed file; The behavior recognition unit is used to acquire the operation type information of the change event, and to identify the change behavior of the changed file based on the operation type information to determine the data change type. The data change type includes at least addition, modification and deletion. The associated encapsulation unit is used to associate and encapsulate file change paths with data change types, generate structured change sets, and obtain metadata of the change sets.

[0067] Further, please refer to Figure 5 The topology analysis module 403 specifically includes: The node mapping unit 501 is used to perform node mapping in the software asset dependency graph based on the file change path, and determine the software asset node corresponding to the file change path. The software asset node includes at least one of the following: project, component, library or microservice node. The graph traversal unit 502 is used to take the software asset node as the starting node, perform graph traversal operation according to the dependency relationship edges defined in the software asset dependency relationship graph, and obtain the first layer of upstream and downstream node set that has a direct dependency relationship with the starting node. The topology traversal unit 503 is used to continue multi-level topology traversal according to a preset traversal depth after obtaining the first-level upstream and downstream node set, and to determine the multi-level upstream and downstream node set that has an indirect dependency relationship with the starting node. The node aggregation unit 504 is used to aggregate and deduplicate the first-level upstream and downstream node sets and the multi-level upstream and downstream node sets to generate upstream and downstream node range results that represent the impact range of the change event.

[0068] Furthermore, graph traversal unit 502 specifically includes: The dependency reading subunit is used to read the dependency edges directly connected to the starting node in the software asset dependency graph, and identify the direction attribute of each dependency edge to distinguish upstream dependencies from downstream dependencies. The upstream and downstream node determination sub-unit is used to determine the set of upstream nodes and the set of downstream nodes that have a direct dependency relationship with the starting node based on the direction attribute of the dependency relationship edge. The downstream node represents the software asset that depends on the starting node, and the upstream node represents the software asset that is depended on by the starting node. The classification and organization subunit is used to classify and organize the upstream node set and the downstream node set to generate the first-level upstream and downstream node set that has a direct dependency on the starting node.

[0069] Furthermore, the topology traversal unit 503 specifically includes: The counter initialization subunit is used to initialize the level counter of multi-level topology traversal based on the preset traversal depth parameter, and set the upstream and downstream node set of the first level as the initial node set of the current traversal level. The candidate node sub-unit is used to obtain the next layer of candidate nodes that have direct dependencies on the nodes of the current traversal layer, based on the initial node set of the current traversal layer and according to the dependency edges defined in the software asset dependency graph. The node deduplication subunit is used to perform deduplication and loop detection on the candidate node set of the next layer, filtering out nodes that have been traversed or have formed closed loop dependencies. The loop traversal sub-unit is used to merge the candidate node set of the next level into the multi-level upstream and downstream node set when the level counter has not reached the preset traversal depth, and update the node set of the current traversal level. The above steps are repeated until the topological traversal of the preset traversal depth is completed, and the multi-level upstream and downstream node set of indirect dependency relationship is obtained.

[0070] Furthermore, the change strategy module 404 specifically includes: The impact assessment unit is used to assess the impact characteristics of change events based on the distribution of node types, number of nodes, and dependency hierarchy information in the upstream and downstream scope, and generate impact assessment results for strategy matching. The strategy matching unit is used to match the impact assessment results with the preset change handling strategy rule base, and determine the target change handling strategy corresponding to the change event based on the matching results. The change handling strategy includes at least one or a combination of script-level, package-level, component-level and microservice-level handling strategies. The structured encapsulation unit is used to encapsulate the determined target change handling strategy in a structured manner, forming a set of change handling strategies that includes processing granularity, execution order, and constraints.

[0071] Furthermore, the change processing module 405 specifically includes: The executor determination unit is used to obtain the processing granularity information in the change processing strategy and determine the target change processing executor that matches the processing granularity information from the preset change processing executor set. The change processing executor includes at least script change processing executors, whole package change processing executors, component change processing executors and microservice change processing executors. The execution instruction unit is used to issue execution instructions containing change set metadata, upstream and downstream scope information and policy constraints to the target change processing executor through unified scheduling instructions, so as to trigger the target change processing executor to perform the corresponding software change processing operation. The status acquisition unit is used to collect execution status information and execution result information in real time during the execution of the target change processing executor, and to trigger the preset retry, rollback or interruption processing mechanism according to the policy constraints when an abnormality occurs. The result aggregation unit is used to aggregate and encapsulate the execution result information after the target change processing executor has completed execution, generate change processing results, and output the change processing results to the display component or visualization component of the upper-level system.

[0072] To address the aforementioned technical problems, embodiments of this application also provide a computer device. Please refer to [link / reference needed]. Figure 6 , Figure 6 This is a basic structural block diagram of the computer device in this embodiment.

[0073] The computer device 6 includes a memory 61, a processor 62, and a network interface 63 that are interconnected via a system bus. It should be noted that only the computer device 6 with memory 61, processor 62, and network interface 63 is shown in the figure; however, it should be understood that it is not required to implement all the components shown, and more or fewer components can be implemented alternatively. Those skilled in the art will understand that the computer device described here is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0074] The computer device can be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device can interact with the user via a keyboard, mouse, remote control, touchpad, or voice control.

[0075] The memory 61 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 61 may be an internal storage unit of the computer device 6, such as the hard disk or memory of the computer device 6. In other embodiments, the memory 61 may also be an external storage device of the computer device 6, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 6. Of course, the memory 61 may also include both the internal storage unit and its external storage device of the computer device 6. In this embodiment, the memory 61 is typically used to store the operating system and various application software installed on the computer device 6, such as computer-readable instructions for software change processing methods. In addition, the memory 61 can also be used to temporarily store various types of data that have been output or will be output.

[0076] In some embodiments, the processor 62 may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip. The processor 62 is typically used to control the overall operation of the computer device 6. In this embodiment, the processor 62 is used to execute computer-readable instructions stored in the memory 61 or to process data, such as executing computer-readable instructions for the software change processing method.

[0077] The network interface 63 may include a wireless network interface or a wired network interface, which is typically used to establish communication connections between the computer device 6 and other electronic devices.

[0078] This application also provides an embodiment, namely, a computer device including a memory and a processor, wherein the memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the software change processing method described above.

[0079] This application also provides another embodiment, namely, providing a computer-readable storage medium storing computer-readable instructions that can be executed by at least one processor to cause the at least one processor to perform the steps of the software change processing method described above.

[0080] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0081] Obviously, the embodiments described above are only some embodiments of this application, not all embodiments. The accompanying drawings show preferred embodiments of this application, but do not limit the patent scope of this application. This application can be implemented in many different forms; rather, the purpose of providing these embodiments is to provide a more thorough and comprehensive understanding of the disclosure of this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this application's specification and drawings, directly or indirectly applied to other related technical fields, are similarly within the scope of patent protection of this application.

Claims

1. A software change processing method, characterized in that, include: Continuously monitor change events of the data source and obtain the change log of the data source; The change log is parsed to obtain the metadata of the change set, wherein the metadata of the change set includes at least the file change path and the data change type; Based on the metadata of the change set and the preset software asset dependency graph, a topology analysis is performed to determine the upstream and downstream scope affected by the change event; A matching change handling strategy is determined based on the upstream and downstream scope; According to the matched change handling strategy, the corresponding change handling executor is invoked to perform software change handling and output the change handling result.

2. The software change processing method as described in claim 1, characterized in that, The step of parsing the change log to obtain the metadata of the change set specifically includes: Extract the original record information of the change event from the change log, wherein the original record information includes at least the change commit identifier, the change timestamp, and the list of changed files; The original record information is parsed item by item to obtain the file change path corresponding to the changed file; Obtain the operation type information of the change event, and identify the change behavior of the changed file based on the operation type information to determine the data change type, wherein the data change type includes at least addition, modification and deletion; The file change path is associated and encapsulated with the data change type to generate a structured change set, and the metadata of the change set is obtained.

3. The software change processing method as described in claim 1, characterized in that, The step of performing topology analysis based on the metadata of the change set and a preset software asset dependency graph to determine the upstream and downstream scope affected by the change event specifically includes: Based on the file change path, node mapping is performed in the software asset dependency graph to determine the software asset node corresponding to the file change path, wherein the software asset node includes at least one of project, component, library or microservice node; Using the software asset node as the starting node, perform a graph traversal operation based on the dependency edges defined in the software asset dependency graph to obtain the first-level upstream and downstream node set that has a direct dependency relationship with the starting node; Based on the first layer of upstream and downstream node set, multi-level topology traversal is performed according to the preset traversal depth to determine the multi-level upstream and downstream node set that has an indirect dependency relationship with the starting node. The upstream and downstream node sets of the first layer and the upstream and downstream node sets of the multi-layer are summarized and deduplicated to generate the upstream and downstream node range results that characterize the impact range of the change event.

4. The software change processing method as described in claim 3, characterized in that, The step of using the software asset node as the starting node, performing a graph traversal operation based on the dependency edges defined in the software asset dependency graph, and obtaining the first-level upstream and downstream node set that has a direct dependency relationship with the starting node specifically includes: In the software asset dependency graph, the dependency edges directly connected to the starting node are read, and the direction attribute of each dependency edge is identified to distinguish upstream dependencies from downstream dependencies. Based on the direction attribute of the dependency edge, determine the set of upstream nodes and the set of downstream nodes that have a direct dependency relationship with the starting node, where the downstream node represents the software asset that depends on the starting node, and the upstream node represents the software asset that is depended on by the starting node. The upstream node set and the downstream node set are classified and organized to generate a first-layer upstream and downstream node set that directly depends on the starting node.

5. The software change processing method as described in claim 3, characterized in that, The step of determining the multi-level upstream and downstream node set that has an indirect dependency relationship with the starting node, based on the first-level upstream and downstream node set, by continuing to perform multi-level topological traversal according to a preset traversal depth, specifically includes: Based on the preset traversal depth parameter, initialize the level counter of the multi-level topology traversal, and set the upstream and downstream node set of the first level as the initial node set of the current traversal level. For the initial set of nodes in the current traversal layer, according to the dependency edges defined in the software asset dependency graph, obtain the set of candidate nodes for the next layer that have direct dependencies on the nodes in the current traversal layer; The next-level candidate node set is deduplicated and loop detected to filter out nodes that have been traversed or have formed closed-loop dependencies. When the level counter has not reached the preset traversal depth, the next level candidate node set is merged into the multi-level upstream and downstream node set, and the current traversal level node set is updated. The above steps are repeated until the topological traversal of the preset traversal depth is completed, and the multi-level upstream and downstream node set of the indirect dependency relationship is obtained.

6. The software change processing method as described in claim 1, characterized in that, The step of determining a matching change handling strategy based on the upstream and downstream scope specifically includes: Based on the distribution of node types, number of nodes, and dependency hierarchy information in the upstream and downstream range, the impact characteristics of the change event are evaluated, and an impact evaluation result for strategy matching is generated. The impact assessment results are matched with a preset change handling strategy rule base, and the target change handling strategy corresponding to the change event is determined based on the matching results. The change handling strategy includes at least one or a combination of script-level, package-level, component-level and microservice-level handling strategies. The determined target change handling strategy is structured and encapsulated to form a set of change handling strategies that includes processing granularity, execution order, and constraints.

7. The software change processing method as described in claim 1, characterized in that, The step of invoking the corresponding change processing executor to perform software change processing according to the matched change processing strategy and outputting the change processing result specifically includes: Obtain the processing granularity information in the change processing strategy, and determine the target change processing executor that matches the processing granularity information from the preset set of change processing executors. The change processing executor includes at least script change processing executors, whole package change processing executors, component change processing executors and microservice change processing executors. A unified scheduling instruction is used to issue an execution instruction containing change set metadata, upstream and downstream scope information, and policy constraints to the target change processing executor, thereby triggering the target change processing executor to perform the corresponding software change processing operation. During the execution of the target change processing executor, execution status information and execution result information are collected in real time, and when an abnormality occurs, a preset retry, rollback or interruption processing mechanism is triggered according to the policy constraints. After the target change processing executor completes its execution, the execution result information is summarized and encapsulated to generate the change processing result, and the change processing result is output to the display component or visualization component of the upper-layer system.

8. A software change processing device, characterized in that, include: The change monitoring module is used to continuously monitor change events of the data source and obtain the change log of the data source; The change parsing module is used to parse the change log and obtain the metadata of the change set, wherein the metadata of the change set includes at least the file change path and the data change type; The topology analysis module is used to perform topology analysis based on the metadata of the change set and a preset software asset dependency graph to determine the upstream and downstream scope affected by the change event. The change strategy module is used to determine a matching change processing strategy based on the upstream and downstream scope; The change processing module is used to call the corresponding change processing executor to perform software change processing according to the matched change processing strategy, and output the change processing result.

9. A computer device, characterized in that, The system includes a memory and a processor, wherein the memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the software change processing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the software change processing method as described in any one of claims 1 to 7.

Images