Static code analysis-based change influence automatic management and control method and system

Abstract

The invention discloses a change influence automatic management and control method and system based on static code analysis. The invention relates to the technical field of computers. Starting a static code analysis module, reading a source code of a specified service or a code library, and performing syntactic analysis and semantic analysis; the analysis result comprises classes, methods and calling relations in the service. Constructing a calling dependency graph in the service based on a result of the static code analysis; meanwhile, secondary cleaning is conducted on the static analysis data, and the calling relation between the services is recognized; similarly, constructing a calling dependency graph between the services, and storing the calling dependency graph in a graphic library; according to the method, code changes can be automatically detected and analyzed, the change report is rapidly generated, the influence range is rapidly analyzed, the change evaluation and processing time is greatly shortened, and the overall efficiency of change management is improved. Through comprehensive influence range analysis and dependency relationship carding, potential risks possibly brought by changes can be accurately identified.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, specifically to the field of static code analysis, and more particularly to a method and system for automatically managing and controlling the impact of changes based on static code analysis. Background Art

[0002] In typical software development iterations, code change analysis relies heavily on manual review and subjective evaluation by developers and their teams. This process is particularly cumbersome and prone to blind spots, especially in scenarios involving multiple business groups or complex call chains.

[0003] In today's development environment, systems often consist of multiple microservices, resulting in complex inter-code dependencies. However, existing analysis methods fail to effectively resolve dependencies across services, making it difficult to accurately track the impact of functional logic changes caused by code modifications. Specifically, this includes the inability to accurately identify which classes, methods, service entry points, and call topologies are affected by code changes, increasing the risk of system instability and potential failures.

[0004] Furthermore, within the continuous integration and continuous deployment (CI / CD) pipeline of development, testing, and release, there is a lack of a unified automated management and control mechanism to seamlessly integrate all aspects. Current point tools often only address local issues, making it difficult to achieve efficient collaboration and automated management across the board. This fragmented tool usage not only increases operational complexity but also limits the potential for overall process optimization, impacting the speed and quality of software delivery.

[0005] To this end, the present invention proposes a method and system for automated change impact management based on static code analysis. Summary of the Invention

[0006] In view of this, the present invention aims to provide a method and system for automated change impact management based on static code analysis to solve or alleviate the technical problems existing in the prior art, namely, how to implement full-link change analysis across services and form automated management and control of the entire R&D process, and to provide at least a beneficial option for this purpose. The technical solution of the present invention is implemented as follows:

[0007] First, an automated change impact management method based on static code analysis:

[0008] (1) Overview:

[0009] The present invention aims to achieve full-link change analysis across services and automated management and control of the entire R&D process by comprehensively using technical means such as static code analysis, call dependency construction, and Git-based method-level change comparison. First, through static code analysis, the syntax and semantics of the source code are deeply parsed, and a call dependency graph within and between services is constructed to provide developers with a clear view of the code structure and dependencies. Secondly, combined with the Git version control system, method-level change comparison is achieved to quickly locate change points and their potential impacts. At the same time, a tracking function is provided to help developers understand the call chain and dependencies of each method. Finally, the above functions are closely integrated with the publishing platform to form an automated process from initiating changes to detecting change methods, and then to analyzing the scope of impact, thereby achieving automated management and control of the entire R&D process.

[0010] (2) Technical solution:

[0011] To achieve the above technical objectives, upon receiving an activation instruction (triggering the execution of the solution through a command line, a graphical interface, or an API call, etc.), the present invention selects to execute the following operation steps.

[0012] 2.1 Step S1, static code analysis:

[0013] Start the static code analysis module, read the source code of the specified service or code library, and perform syntax analysis and semantic analysis; the analysis results include the classes, methods and their calling relationships within the service.

[0014] 2.1.1 Step S100, read source code:

[0015] Read source code files based on the service or code library path specified by the user. Preprocess the source code files, including parsing comments and handling include relationships.

[0016] 2.1.2 Step S101, syntax analysis:

[0017] Perform syntax analysis on the preprocessed source code and build an abstract syntax tree (AST); check for syntax errors in the code and generate an error report (if any).

[0018] 2.1.3 Step S102, semantic analysis:

[0019] Perform semantic analysis based on the abstract syntax tree to identify classes, methods, and variables; analyze the calling relationships between code elements, including method calls and property access; and generate semantic analysis results, including classes, methods, and their calling relationships within the service.

[0020] 2.1.3 Step S102: Storing Analysis Results

[0021] Store the semantic analysis results in a specified storage medium, such as a database or file, to provide data support for subsequent service-based dependency building and Git-based method-level change comparison.

[0022] 2.2 Step S2, call dependency construction within the service:

[0023] Based on the results of static code analysis, a call dependency graph within the service is constructed. At the same time, the static analysis data is cleaned twice to identify the call relationships between services. Similarly, a call dependency graph between services is constructed and stored in a graph library.

[0024] 2.2.1 Step S200: Load static code analysis results:

[0025] Load static code analysis result data from the storage medium; parse and process the data for subsequent use.

[0026] 2.2.2 Step S201: Build a service call dependency graph

[0027] Based on the results of static code analysis, the calling relationships between classes and methods within the service are identified; and a graph theory algorithm is used to construct a call dependency graph within the service.

[0028] 2.2.3 Step S202: Secondary Cleaning and Recognition Service Call Relationship

[0029] Perform secondary cleaning on static analysis data to filter out irrelevant or redundant information; identify the calling relationships between services, including remote calls and message passing; and build a calling dependency graph between services based on the calling relationships between services.

[0030] 2.2.4 Step S204: Store the call dependency graph:

[0031] Store the call dependency graphs within and between services in a graph library.

[0032] 2.3 Step S3, Git-based method-level change comparison:

[0033] When receiving an instruction to change a branch, the Git interface is called to obtain the code differences between different versions; a method-level change comparison is performed to generate a change report; based on the results of static code analysis, the call chain and dependency relationships of a specific method are queried based on the preset method-level call tracking function.

[0034] 2.3.1 Step S300, receiving a change branch instruction:

[0035] Listen for user-input branch change commands or triggering of automated scripts; obtain relevant information about the changed branch, including branch name and commit history.

[0036] 2.3.2 Step S301: Call the Git interface to obtain code differences

[0037] Use the interface or commands provided by Git to obtain the code differences between different versions; parse and process the code differences to extract method-level change information.

[0038] 2.3.3 Step S302, method-level change comparison:

[0039] Based on the extracted method-level change information, perform method-level change comparison; identify the types of changes that are added, modified, or / and deleted; and generate a method-level change report, including information on the change point and change type.

[0040] 2.3.4 Step S303: Call tracking and dependency query:

[0041] Generate call chain and dependency reports based on the call chain and dependency relationships of specific methods queried by users to help users understand the impact scope of changes; store method-level change reports and call relationships in designated storage media; provide data support for subsequent change impact scope analysis and result feedback and visualization; and at the same time, provide decision-making basis for the publishing platform.

[0042] 2.4 Step S4, Change Impact Scope Analysis:

[0043] Combine the results of inter-service call dependencies and method-level change comparison to analyze the impact of the change; generate an impact scope report, including the affected classes, methods, entry points, and call topology.

[0044] 2.4.1 Step S400: Analyze the call dependency and change information:

[0045] Combine method-level change information with the inter-service call dependency graph; trace the propagation path of the change in the call chain, identify the affected classes, methods, and entry points; and analyze the impact of the change on the overall system architecture and business processes;

[0046] 2.4.2 Step S401: Generate an impact range report:

[0047] Based on the analysis results, an impact scope report is generated, including the affected classes, methods, entry points, and call topology information; the impact scope report is stored in the designated storage medium; and the report is passed to the publishing platform and other related systems for subsequent use.

[0048] 2.5 Step S5, Automated Change Detection and Release Integration:

[0049] The system is pre-integrated with the release platform. When a new change branch is detected, the change detection process is automatically triggered. Method-level change comparison and impact analysis are performed, and a report is generated for the release platform. Based on the report, the release platform decides whether to proceed with the release or whether further testing and verification are required.

[0050] 2.5.1 Step S500: Detect new change branches:

[0051] Monitor the change events of the code repository and detect the emergence of new change branches; obtain detailed information about the change branches, including commit records and code differences.

[0052] When a new change branch is detected, the change detection process is automatically triggered.

[0053] 2.5.2 Step S501: Generate a report for use by the publishing platform:

[0054] Generate change detection report and impact scope report based on analysis results;

[0055] The publishing platform decides whether to publish the report based on the received report;

[0056] If further testing and verification is required, the corresponding testing process is triggered;

[0057] If the decision is to publish, the publishing operation will be executed and the publishing results will be fed back to the relevant systems and personnel.

[0058] 2.6 Step S6, Result Feedback and Visualization:

[0059] The analysis results are displayed visually in a graphical interface; developers can view the impact scope of the change or call dependency graph.

[0060] (3) Mechanisms for resolving technical issues:

[0061] 3.1 Mechanism Overview:

[0062] First, static code analysis techniques are used to deeply analyze the source code of a specific service or codebase. Based on the results of static code analysis, call dependency graphs are constructed within and between services. These dependency graphs graphically display the dependencies between code elements, providing developers with a clear view of the code structure. When instructions are received to change a branch, Git interfaces are called to obtain the code differences between different versions. Subsequently, method-level change comparisons are performed, generating detailed change reports to help developers quickly identify the change points.

[0063] Combined with the results of inter-service call dependencies and method-level change comparisons, the impact of the change is analyzed. This step generates an impact report that includes the affected classes, methods, entry points, and call topology, providing developers with a comprehensive change impact assessment.

[0064] By tightly integrating these functions with the release platform, an automated process is formed, from change initiation to change method detection and impact analysis. This automated control mechanism significantly reduces the risk of human error and vulnerabilities, improving the efficiency and quality of the R&D process.

[0065] 3.2 Detailed explanation of the principle:

[0066] Static code analysis is a technique that performs syntax and semantic checks on code without executing it. It identifies potential errors, vulnerabilities, and code smells by analyzing data structures such as the code's abstract syntax tree and control flow graph. Call dependency building is based on the reference and call relationships between code elements. By analyzing operations such as method calls and object instantiations in the code, a dependency graph between code elements is constructed. These dependency graphs help developers understand the structure and logic of the code.

[0067] Change detection and comparison are based on the commit history and diff algorithms of version control systems (such as Git). By comparing code differences between different versions, the files, lines, and methods that have changed are identified. This step is based on the internal mechanisms of the version control system and its diff algorithms. Impact analysis is based on the call dependency graph and the location of the change point. By analyzing the location and relationships of the code element where the change point is located in the call dependency graph, it is possible to infer which other code elements may be affected.

[0068] Automated control is based on workflow engines and automated scripting technology. By encapsulating functions like change analysis and impact analysis into automated scripts and integrating them with the release platform's workflow engine, automated control of the entire R&D process is achieved.

[0069] Secondly, changes based on static code analysis affect the automated control system:

[0070] like Figure 4 As shown, the system is used to implement the above-mentioned method and system for automated control of change impact based on static code analysis, which includes:

[0071] (1) A static code analysis module that reads the source code of a specified service or code base and performs syntax and semantic analysis: It receives instructions from the user or an automated script to initiate analysis. It outputs the analysis results to the service dependency building module and the Git-based method-level change comparison module.

[0072] (2) Based on the results of static code analysis, the service call dependency graph is constructed. The service call dependency construction module performs a secondary cleaning on the static analysis data to identify the call relationships between services. The call dependency graph between services is constructed and stored in the graph library.

[0073] (3) When receiving a branch change instruction, the Git-based method-level change comparison module calls the Git interface to obtain the code differences between different versions: it performs method-level change comparison and generates a change report. Based on the results of static code analysis, it provides method-level call tracking capabilities.

[0074] Receives branch change instructions from users or automated scripts. Calls the Git interface to obtain code differences. Outputs change reports to the Change Impact Analysis Module and the Result Feedback and Visualization Module. Interacts with the Static Code Analysis Module to obtain data required for method call tracing.

[0075] (4) Combined with the results of the inter-service call dependency and method-level change comparison, the change impact scope analysis module analyzes the impact scope of the change: generates an impact scope report, including the affected classes, methods, entry points and call topology.

[0076] Receives results from the service dependency building module and the Git-based method-level change comparison module. Outputs impact scope reports to the automated change detection and release integration module and the result feedback and visualization module.

[0077] (5) When a new change branch is detected, the automated change detection and release integration module automatically triggers the change detection process: the system is pre-integrated with the release platform. It performs method-level change comparison and impact scope analysis, and generates a report for use by the release platform.

[0078] Integrates with the release platform to receive branch change detection instructions. It then calls the Git-based method-level change comparison module and the change impact analysis module for analysis. It then outputs analysis reports to the release platform and the results feedback and visualization module.

[0079] (6) The result feedback and visualization module displays the analysis results in a visual form in the graphical interface: developers can view the scope of change impact or call dependency graph.

[0080] Receives result data from each analysis module. Provides a user-friendly graphical interface to display analysis results. Supports user interaction such as query, zoom, and export.

[0081] Compared with the prior art, the present invention has the following beneficial effects:

[0082] 1. Improved Change Management Efficiency: This invention can automatically detect and analyze code changes, quickly generating change reports and impact analysis, significantly reducing the time required for change assessment and processing, and improving the overall efficiency of change management. Through comprehensive impact analysis and dependency analysis, this invention can accurately identify potential risks associated with changes, helping development teams conduct thorough testing and verification before release, effectively reducing failures and errors caused by changes.

[0083] Second, enhanced code maintainability: Static code analysis and call dependency building provide a clear view of code structure and dependencies, helping developers better understand the code, refactor and optimize it, and thus improve code maintainability and readability. The visual interface and detailed reports provided by this invention make it easier for team members to share change information and impact, promoting communication and collaboration among teams and improving overall team effectiveness.

[0084] 3. Support continuous integration and continuous delivery: The close integration of this invention with the release platform realizes the automated process from code submission to change analysis, impact assessment and then to release, providing strong support for continuous integration (CI) and continuous delivery (CD), and accelerating the software development and delivery cycle. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0086] Figure 1 Schematic diagram of the method flow of the present invention;

[0087] Figure 2 This is a schematic diagram of analyzing the scope of variation of the present invention;

[0088] Figure 3 This is a schematic diagram of the automated change control and tracking implementation of the present invention;

[0089] Figure 4 Schematic diagram of the system composition of the present invention. DETAILED DESCRIPTION

[0090] To make the above-mentioned objects, features, and advantages of the present invention more clearly understood, the following detailed description of the specific embodiments of the present invention is given in conjunction with the accompanying drawings. The following description sets forth many specific details to facilitate a full understanding of the present invention. However, the present invention can be implemented in many other ways than those described herein, and those skilled in the art can make similar improvements without violating the scope of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0091] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Reference can be made to the common and similar parts between the various embodiments. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple, and the relevant parts can be referred to the method description.

[0092] Explanation of relevant terms:

[0093] (1) Syntax analysis and semantic analysis: Analyze the structure and meaning of source code.

[0094] (2) Intra-service: refers to the scope or environment within a single service.

[0095] (3) Dependency graph: A graphical representation showing the dependencies between code elements.

[0096] (4) Call relationship: The connection or relationship in which one code element calls another code element.

[0097] (5) Call dependency graph: A graph showing the call dependency relationships between services or code elements.

[0098] (6) Change branches: branches in the code base used to manage changes.

[0099] (7) Git-based method-level change comparison: Comparison of method-level code changes using Git.

[0100] (8) Git interface: A programming interface for interacting with the Git version control system.

[0101] (9) Code differences: differences in code between different versions or branches.

[0102] (10)Tracing function: a function used to track the calling paths and dependencies of code elements.

[0103] (11) Call chain: the order and relationship of a series of method calls.

[0104] (12) Affected classes, methods, entry points, and call topology: A comprehensive description of the code elements affected by the change and their call relationships.

[0105] Example 1: Figures 1 to 3 As shown, the online car-hailing platform is a complex system that contains multiple microservices, each of which consists of multiple classes and methods. In order to ensure that the update of the code base does not destroy the existing functions, a complete set of electrical data processing processes is required to perform change analysis and control. To this end, this embodiment discloses a cross-service full-link change analysis and automated control solution, specifically the application of the change impact automated control method based on static code analysis in the operation and maintenance of the online car-hailing platform. It includes the following execution steps:

[0106] In this embodiment, regarding step S1, static code analysis:

[0107] Specifically, step S100 reads source code: Specify the path to the ride-hailing platform's codebase. Read all relevant source code files, including those for passenger services, driver services, and order services. Preprocess the source code, such as removing comments and processing include relationships.

[0108] Specifically, step S101, syntax analysis: Syntax analysis is performed on the preprocessed source code to construct an abstract syntax tree (AST), check and report any syntax errors, and ensure the grammatical correctness of the code base.

[0109] Specifically, step S102, semantic analysis: Semantic analysis is performed on the AST to identify all classes, methods, and variables. The calling relationships between classes and methods are analyzed, including method calls and property accesses. Semantic analysis results are generated to clearly identify the classes, methods, and their calling relationships within each service.

[0110] Specifically, step S103, storing analysis results: storing semantic analysis results in a database to provide data support for subsequent analysis.

[0111] In this embodiment, regarding step S2, the service calls the dependency build:

[0112] Specifically, step S200 , loading static code analysis results: loading static code analysis result data from a database.

[0113] Specifically, step S201 constructs a service call dependency graph: Based on the static code analysis results, the call relationships between classes and methods within each service are identified. A graph theory algorithm is used to construct a service call dependency graph to clarify which methods call each method.

[0114] Specifically, step S202, secondary cleaning and identification of service call relationships: Static analysis data is secondary cleaned to remove irrelevant or redundant information. Call relationships between services are identified, such as passenger services calling order services, driver services calling order services, and so on. A call dependency graph is constructed between services to clarify the dependencies between services.

[0115] Specifically, step S204, storing the call dependency graph: storing the call dependency graph within the service and between services in the graph library for subsequent query and display.

[0116] In this embodiment, regarding step S3, Git-based method-level change comparison:

[0117] Specifically, step S300 receives a branch change instruction: listens for a branch change instruction input by a user, such as "compare the main branch and the feature-new-feature branch," and obtains relevant information about the changed branch, including the branch name and commit history.

[0118] Specifically, in step S301, the Git interface is called to obtain code differences: the code differences between the main branch and the feature-new-feature branch are obtained using the interface provided by Git. The code differences are parsed and processed to extract method-level change information.

[0119] Specifically, step S302, method-level change comparison: Based on the extracted method-level change information, a method-level change comparison is performed to identify newly added, modified, or deleted methods and generate a method-level change report.

[0120] Specifically, in step S303, call tracing and dependency query, the user queries the call chain and dependency relationships of a specific method. Based on the results of static code analysis, the system generates a call chain and dependency report. The method-level change report and call relationships are stored in a database to provide data support for subsequent analysis.

[0121] In this embodiment, regarding step S4, the change impact range analysis:

[0122] Specifically, step S400 combines call dependency and change information for analysis: Method-level change information is combined with the inter-service call dependency graph. The propagation path of the change within the call chain is traced, and the affected classes, methods, and entry points are identified. The impact of the change on the overall system architecture and business processes of the ride-hailing platform is analyzed.

[0123] Specifically, step S401 generates an impact scope report: Based on the analysis results, an impact scope report is generated, including the affected classes, methods, entry points, and call topology information. The impact scope report is stored in a database and transmitted to the publishing platform and other related systems.

[0124] In this embodiment, regarding step S5, automated change detection and release integration:

[0125] Specifically, step S500 detects new change branches: monitors change events in the code repository, detects the emergence of new change branches, and obtains detailed information about the change branches, including commit records and code differences.

[0126] Specifically, step S501 generates a report for use by the publishing platform: When a new change branch is detected, the change detection process is automatically triggered. Method-level change comparison and impact scope analysis are performed to generate a change detection report and impact scope report.

[0127] The publishing platform then decides whether to release the product based on the received report. If further testing and verification is required, the corresponding testing process is triggered. If the decision is to release the product, the release process is executed and the results are fed back to the relevant systems and personnel.

[0128] In this embodiment, regarding step S6, result feedback and visualization: the analysis results are displayed in a graphical interface in a visual form. Developers can view the scope of the change or call dependency graph to better understand the impact of the change and the structure of the system.

[0129] As you can see, the above process enables full-chain change analysis across services. By comparing changes at the method level, we can precisely identify code changes, including added, modified, and deleted methods. Combined with the call dependency graph within and between services, we can trace the propagation path of changes along the call chain, identifying affected classes, methods, and entry points. By analyzing the impact of changes on the overall system architecture and business processes, we can assess the risks and potential issues of the changes, providing a basis for release decisions.

[0130] Static code analysis captures the code's structure and call relationships, combined with dynamic tracing techniques (such as Git's change detection) to capture code change information. Graph theory algorithms are used to construct a call dependency graph, visually displaying the dependencies between code elements and facilitating analysis and tracing. Automated scripts and integrated tools link the various steps together to form a complete electrical data processing workflow. Furthermore, integration with the release platform enables automated control of the entire R&D process.

[0131] Through precise change analysis and impact assessment, we can promptly identify and fix potential issues, thereby improving code quality. Through comprehensive change analysis and test verification, we can reduce the risk of releases and minimize system failures or business interruptions caused by changes.

[0132] Automated change detection and release integration processes can save significant time and effort, allowing developers to focus more on code implementation and business logic design. Visual feedback also helps developers better understand the system structure and the impact of changes.

[0133] Example 2: Based on the application of Example 1, this example further provides its Python execution program:

[0134]

[0135]

[0136]

[0137]

[0138]

[0139] In the above program, the static_code_analysis function reads the source code and performs analysis. The build_call_dependency function uses the NetworkX library to build a directed graph representing the calling relationships between methods.

[0140] The git_based_change_comparison function uses the GitPython library to get the code differences between two branches. The analyze_impact_scope function uses NetworkX's DFS (depth-first search) or BFS (breadth-first search) algorithm to find all nodes affected by the change.

[0141] The automate_change_detection_and_release function connects the previous steps to execute the automated change detection and release integration process. The visualize_dependency_graph function uses the Matplotlib library to visualize the call dependency graph.

[0142] All of the above embodiments merely represent implementation methods of the present invention in practical applications. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art could make various modifications and improvements without departing from the scope of the present invention, all of which fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the appended claims.

[0143] For those skilled in the art, it can be further appreciated that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0144] At the same time, those skilled in the art will understand that all or part of the processes in all the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media provided in this application and used in the embodiments may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

Claims

1. An automated change impact management method based on static code analysis, characterized in that: After receiving the activation command, perform the following steps: S1, reads the source code of the specified service or code library and performs syntax analysis and semantic analysis; the analysis results include the classes, methods and their calling relationships within the service. S2, based on the results of static code analysis, builds a call dependency graph within the service; S3, when receiving the instruction to change the branch, calls the Git interface to obtain the code differences between different versions; Perform method-level change comparison and generate change reports; S4: Analyze the impact of the change based on the comparison results of inter-service call dependencies and method-level changes; Generate impact scope reports; S5, when a new change branch is detected, the change detection process is automatically triggered; Perform method-level change comparison and impact scope analysis, and generate reports for use on the publishing platform.

2. The method for automated control of change impact according to claim 1, characterized in that: The execution process of S1 includes: S100, reading source code: reading source code files according to the service or code library path specified by the user; preprocessing the source code files, including parsing comments and processing inclusion relationships; S101, perform syntax analysis on the preprocessed source code and construct an abstract syntax tree; check for syntax errors in the code and generate an error report; S102, performing semantic analysis based on the abstract syntax tree to identify classes, methods, and variables; analyzing the calling relationships between code elements, including method calls and property accesses; and generating semantic analysis results, including classes, methods, and their calling relationships within the service; S102: Store the semantic analysis result in a designated storage medium.

3. The method for automated control of change impact according to claim 1, characterized in that: S2 also includes secondary cleaning of static analysis data to identify the calling relationships between services; Similarly, a call dependency graph between services is constructed and stored in a graph library.

4. The method for automated control of change impact according to claim 3, characterized in that: The execution process of S2 includes: S200, loading static code analysis result data from a storage medium; S201, based on the static code analysis results, identifying the call relationships between classes and methods within the service; using a graph theory algorithm to construct a call dependency graph within the service; S202: Perform secondary cleaning on the static analysis data to filter out irrelevant or redundant information; identify the call relationships between services, including remote calls and message passing; and construct a call dependency graph between services based on the call relationships between services. S204: Store the call dependency graphs within and between services in a graph library.

5. The method for automated control of change impact according to claim 1, characterized in that: In the S3, according to the result of the static code analysis, the call chain and dependency relationship of a specific method are queried based on the preset method-level call tracing function.

6. The method for automated control of change impact according to claim 5, characterized in that: The execution process of S3 includes: S300, monitoring the branch change command input by the user or the triggering of the automated script; obtaining relevant information of the changed branch, including the branch name and commit history; S301, using the interface or command provided by Git, obtain the code differences between different versions; parse and process the code differences to extract method-level change information; S302, performing a method-level change comparison based on the extracted method-level change information; identifying the change types of addition, modification, and / or deletion; and generating a method-level change report including information on the change point and change type; S303, generating a call chain and dependency report based on the call chain and dependency relationship of the specific method queried by the user; and storing the method-level change report and the call relationship in a designated storage medium.

7. The method for automated control of change impact according to claim 1, characterized in that: The execution process of S4 includes: S400 combines method-level change information with the inter-service call dependency graph; tracks the propagation path of the change in the call chain, identifies the affected classes, methods, and entry points; and analyzes the impact of the change on the overall system architecture and business processes. S401, generating an impact scope report based on the analysis results, including the affected classes, methods, entry points and call topology information; and storing the impact scope report in a designated storage medium.

8. The method for automated control of change impact according to claim 1, characterized in that: It also includes S6, which displays the analysis results in a graphical interface in a visual form; Developers can view the scope of changes or call dependency graphs.

9. A system for implementing the method for automated control of change impacts according to any one of claims 1 to 8, characterized in that: The system comprises: A static code analysis module that reads the source code of a specified service or code base and performs syntax analysis and semantic analysis; Based on the results of static code analysis, build the service call dependency graph and the service call dependency building module; When receiving the instruction to change the branch, the Git-based method-level change comparison module calls the Git interface to obtain the code differences between different versions; The change impact scope analysis module analyzes the impact scope of the change based on the results of inter-service call dependencies and method-level change comparison.

10. The system according to claim 9, characterized in that: The system also includes an automated change detection and release integration module that automatically triggers a change detection process when a new change branch is detected; The analysis results are displayed in a visual form in the result feedback and visualization module in the graphical interface.

Images