Specification and code consistency monitoring method, system, device and program product based on incremental difference

Abstract

The application provides a specification and code consistency monitoring method, system, device and program product based on incremental difference, the method comprises the following steps: receiving a monitoring task and analyzing, determining a target code repository branch; obtaining a comparison benchmark of the target code repository branch and determining an incremental difference comparison interval accordingly; obtaining change data from the corresponding code repository according to the incremental difference comparison interval; dividing the change data to obtain specification difference data and implementation code difference data, and inputting the two into an intelligent agent to obtain a corresponding consistency monitoring result. Through the above scheme, the number of repeated calculations of the incremental difference is reduced, and a systematic monitoring result can be obtained. In addition, the application separates data collection and reasoning, solves the problem of untraceability caused by mixed processing, and improves the credibility.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, system, device, and program product for monitoring specification and code consistency based on incremental differences. Background Technology

[0002] In Specification-Driven Development (SDD) or Documentation-First practices, monitoring the consistency between specifications and implementation code is crucial. The dual-track evolution of specifications and implementation code makes it difficult to consistently guarantee their consistency. Relying solely on manual code reviews cannot systematically answer questions such as: Is the submitted code within the specification's scope? Have specification changes been fully implemented in the code? Is the implementation code semantically consistent with the specification?

[0003] Existing technologies can also monitor large warehouses by performing a full comparison, but this method is costly and incremental monitoring status is easily lost. If only the "current snapshot" is viewed each time without "the baseline relative to the last verified submission", there will be a lot of repetitive work and it will be impossible to form a sustainable incremental monitoring loop.

[0004] If the determination of the difference range and the output conclusion are mixed in a single script or a large model generated at one time, it is difficult to ensure that the conclusion strictly comes from the difference range determined in this instance, and it is also difficult to audit.

[0005] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0006] To address the problems in the prior art, the purpose of this application is to provide a method, system, device, and program product for monitoring specification and code consistency based on incremental differences. This aims to solve the problems in the prior art where manual review is difficult to answer systematically, full comparison is costly, and one-time generation makes it difficult to constrain the conclusions to originate from the current differences.

[0007] The first aspect of this application provides a specification and code consistency monitoring method based on incremental differences, comprising the following steps: receiving and parsing a monitoring task to determine a target code repository branch; obtaining a comparison benchmark for the target code repository branch and determining an incremental difference comparison interval accordingly; obtaining change data from the corresponding code repository based on the incremental difference comparison interval; dividing the change data to obtain specification difference data and implementation code difference data, and inputting both into an intelligent agent to obtain corresponding consistency monitoring results, wherein the intelligent agent is configured to perform inference based on built-in analysis dimensions and inputs, and output corresponding consistency monitoring results.

[0008] In some embodiments of this application, the monitoring task includes location information for determining the target code repository branch and convention information for changing data partitioning; the location information includes project ID and repository branch information, or the location information includes repository coordinates.

[0009] In some embodiments of this application, obtaining the comparison benchmark of the target code repository branch specifically includes: reading the last processed code commit object of the target code repository branch from the persistent storage data of the target code repository branch; if the last processed code commit object is empty, then the parent commit of the latest code commit object of the target code repository branch is the comparison benchmark of the target code repository branch; if the last processed code commit object is not empty, then the last processed code commit object of the target code repository branch is the comparison benchmark of the target code repository branch.

[0010] In some embodiments of this application, the incremental difference comparison interval is the comparison benchmark of the target code repository branch and the latest code commit object.

[0011] In some embodiments of this application, the intelligent agent is also pre-configured with an output template, and the intelligent agent outputs consistency monitoring results according to the output template.

[0012] In some embodiments of this application, the monitoring task is initiated by the user or issued via a scheduled task.

[0013] In some embodiments of this application, the method further includes: after the data partitioning is completed, updating the latest code commit object of the target code repository branch to the previously processed code commit object.

[0014] A second aspect of this application also provides a specification and code consistency monitoring system based on incremental differences, used to implement the above-mentioned specification and code consistency monitoring method based on incremental differences. The system includes: a target determination module, used to receive and parse monitoring tasks to determine a target code repository branch; a change acquisition module, used to acquire a comparison benchmark of the target code repository branch and determine an incremental difference comparison interval accordingly; obtain change data from the corresponding code repository according to the incremental difference comparison interval; divide the change data to obtain specification difference data and implementation code difference data; and a monitoring module, used to input the specification difference data and implementation code difference data into an intelligent agent to obtain corresponding consistency monitoring results. The intelligent agent is configured to perform inference based on built-in analysis dimensions and inputs, and output corresponding consistency monitoring results.

[0015] A third aspect of this application also provides a specification and code consistency monitoring device based on incremental differences, comprising: processor; A memory in which executable instructions of the processor are stored; The processor is configured to perform the aforementioned steps of incremental difference-based specification and code consistency monitoring by executing the executable instructions.

[0016] A fourth aspect of this application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described steps for monitoring specification and code consistency based on incremental differences.

[0017] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application.

[0018] The specification and code consistency monitoring method, system, device, and program products based on incremental differences in this application have the following beneficial effects: This application reduces the number of recalculations for incremental differences through the aforementioned scheme, while providing systematic monitoring results. Furthermore, this application separates data acquisition from inference, resolving the untraceability issue caused by mixed processing and improving reliability. Attached Figure Description

[0019] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings.

[0020] Figure 1 This is a flowchart of a specification and code consistency monitoring method based on incremental differences according to an embodiment of this application; Figure 2 This is a flowchart illustrating the process of obtaining specification and implementation code difference data according to an embodiment of this application; Figure 3 This is a schematic diagram of a pluggable channel according to an embodiment of this application; Figure 4 This is an architecture diagram of a specification and code consistency monitoring system based on incremental differences, according to a specific embodiment of this application. Figure 5 This is a sequence diagram of the interaction between the intelligent agent and the difference acquisition tool according to a specific embodiment of this application; Figure 6 This is a schematic diagram of the structure of a specification and code consistency monitoring system based on incremental differences according to an embodiment of this application; Figure 7 This is a schematic diagram of the structure of a specification and code consistency monitoring device based on incremental differences according to an embodiment of this application. Detailed Implementation

[0021] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0022] Furthermore, the accompanying drawings are merely illustrative of this application and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices. Although the terms "first" or "second," etc., are used in this specification to denote certain features, these are only for indicating function and not as a limitation on the number or importance of specific features.

[0023] The flowchart shown in the attached diagram is merely an illustrative example and does not necessarily include all steps. For example, some steps may be broken down, while others may be combined or partially combined. Therefore, the actual execution order may change depending on the specific circumstances.

[0024] Specification-driven development (SWD) or documentation-first practice refers to using a verifiable, unambiguous, and machine-readable specification document (Spec) as the sole source of fact throughout the entire process. This involves first fully defining system behavior, contracts, and constraints, and then driving code generation and implementation. Conventional processes require revising and updating the specification document before developing code based on the updated document. However, in actual project implementation, specification document adjustments and code development may occur simultaneously. The method in this application is primarily applied to the above-mentioned scenarios to continuously ensure consistency between specifications and code. It should be noted, however, that the method in this application is not limited to the above-mentioned application scenarios; the method provided in this application is also applicable to other types of specification-driven development or documentation-first practice.

[0025] like Figure 1 As shown in the figure, this application provides a specification and code consistency monitoring method based on incremental differences, including the following steps: Step S101: Receive and parse the monitoring task to determine the target code repository branch.

[0026] The monitoring task includes location information to determine the branch of the code repository to be monitored. This location information can be obtained by parsing the monitoring task. Based on this information, the branch of the code repository to be monitored in this task can be located within the corresponding code repository; this branch is the target code repository branch. There can be one or more target code repository branches.

[0027] Step S102: Obtain the comparison benchmark of the target code repository branch and determine the incremental difference comparison interval accordingly; obtain change data from the corresponding code repository based on the incremental difference comparison interval.

[0028] In one embodiment, the comparison benchmark is the parent commit of the last processed code commit object or the latest code commit object of the target code repository branch.

[0029] In one embodiment, the comparison baseline of the target code repository branch and the latest code commit object of the target code repository branch are determined as the incremental difference comparison interval; the change data includes the difference data between the latest code commit object and the comparison baseline.

[0030] Step S103: Divide the changed data to obtain specification difference data and implementation code difference data, and input both into the intelligent agent to obtain the corresponding consistency monitoring results. The intelligent agent is configured to perform inference based on the built-in analysis dimensions and inputs, and output the corresponding consistency monitoring results.

[0031] In one embodiment, the agent, for example, is implemented using a large language model, capable of reasoning based on built-in analysis dimensions and input. Analysis dimensions include, but are not limited to, whether the implementation code is within the specification range, whether specification changes have been fully implemented in the code, and whether the implementation code is semantically consistent with the specification. Input includes: specification difference data, implementation code difference data, and prompts to the agent to perform consistency analysis on both.

[0032] In one embodiment, the consistency monitoring results include, for example, whether the implementation code is consistent with the specification or inconsistent with the specification.

[0033] This application's specification and code consistency monitoring method based on incremental differences reduces the number of repeated calculations of incremental differences by obtaining a comparison benchmark and determining the incremental difference comparison interval accordingly. Simultaneously, this application generates systematic consistency monitoring results through an intelligent agent with built-in analysis dimensions. Furthermore, this application separates data acquisition and inference by first acquiring change data and dividing it into specification and implementation code difference data, and then inputting both into the intelligent agent for inference. This solves the untraceability problem caused by mixed processing, facilitates verification, and improves reliability.

[0034] The following section provides a further explanation of the specific implementation methods for each step.

[0035] Step S101: Receive and parse the monitoring task to determine the target code repository branch.

[0036] In one embodiment, the monitoring task includes location information for determining the target code repository branch and convention information for changing data partitioning.

[0037] In one embodiment, the monitoring task can be parsed by an intelligent agent, which can be implemented using a large oracle model or a lightweight small model, and can parse the monitoring task through built-in parsing logic, identify the location information and agreed information therein and output them.

[0038] In one embodiment, the location information includes a project ID and repository branch information. Specifically, different project IDs correspond to different projects, and the code for each project can be stored in one or more code repositories. A code repository branch is an independent snapshot copy of the code within a code repository. Multiple branches of the same repository code can run in parallel without interfering with each other, used to isolate different stages of development work. The repository branch information is generally the branch name. The corresponding code repository can be located using the project ID, and then the corresponding code repository branch can be located using the branch name; the located code repository branch is the target code repository branch.

[0039] In another embodiment, the location information includes code repository coordinates. Code repository coordinates are a standardized identifier that uniquely locates a code repository, typically represented as a string. The code repository coordinates contain information about the code repository branch to be monitored, which allows the corresponding code repository branch to be located. For example, one form of code repository coordinates is: [protocol]: / / [domain / IP] / [organization] / [repository name].git#[branch]. The protocol is http / https / ssh / git, the domain is github.com, the organization is a company, personal account, group, etc., the repository name is the project repository name, the suffix .git is used to standardize the identification of the code repository, and #[branch] represents the information of the code repository branch.

[0040] In one embodiment, the monitoring task can be initiated in any of the following ways: The first method: user-initiated. Specifically, users can submit monitoring tasks via API (Application Programming Interface), CLI (Command Line Interface), or other types of front-ends. For example, a user can initiate a monitoring task by submitting a request via API to "perform a consistency check on projectId / branch".

[0041] The second method involves initiating monitoring tasks via scheduled tasks. Scheduled tasks can be one-time or periodic. Specifically, depending on actual needs, one or more time points are selected, and monitoring tasks are set up for each time point. The monitoring tasks for each time point can be the same or different. When the specified time point is reached, the monitoring task is automatically initiated. This method achieves automated and continuous one-time monitoring of specifications and code. For example, a scheduled task scheduler (such as cron) can be built, and one or more monitoring tasks for each time point can be pre-configured in the scheduler. When the specified time point is reached, the scheduler automatically issues the monitoring task. As another example, monitoring tasks for different specified times can be pre-configured in a table and then imported into a scheduling platform (such as a scheduled task scheduler). The platform automatically issues the monitoring tasks based on the table content.

[0042] In one embodiment, if multiple code repository branches are to be monitored, a scheduled task can be registered or refreshed for each code repository branch.

[0043] In one embodiment, for a unified code repository branch, when a new monitoring task is initiated, an idempotent replacement or other cleanup strategy is used to replace the old monitoring task. It should be understood that idempotent replacement refers to using a fixed set of values ​​for full coverage replacement. Whether executed once or repeatedly N times, the final data state is completely consistent, and there are no side effects such as superposition, accumulation, or duplicate addition.

[0044] Step S102: Obtain the comparison benchmark of the target code repository branch and determine the incremental difference comparison interval accordingly; obtain change data from the corresponding code repository based on the incremental difference comparison interval.

[0045] It is worth noting that when there are multiple target code repository branches, it is necessary to obtain the incremental difference comparison range for each target code repository branch separately, and then obtain the corresponding change data from the corresponding code repository based on the incremental difference comparison range for each target code repository branch, so as to perform consistency monitoring for each target code repository branch separately. The following describes how to obtain the incremental difference comparison range for one target code repository branch. The other branches can be obtained by referring to the same method, and will not be elaborated further.

[0046] like Figure 2As shown, the first step is to retrieve the branch commit list of the target code repository branch. The branch commit list of the target code repository branch records all code commit records of the target code repository branch up to the current time point, sorted chronologically. Each code commit record points to a code commit object within the code repository branch. The code commit object stores all associated structured data encapsulating this code commit. Associated structured data includes, but is not limited to, the hash of the parent commit, the hash value of the tree object, etc. The hash value of the parent commit points to the previous code commit object of the current code commit object; this code commit object is the parent commit of the current code commit object. The hash value of the tree object points to a complete directory snapshot of the current commit object (i.e., the state of all files at that time).

[0047] This process reads the last processed commit object from the persistent storage data of the target code repository branch. It's important to understand that a code repository is independent of memory and process lifecycle; it writes all data, including versions, commits, branches, file differences, indexes, and remote configurations, to disk files. This data is not lost after process exit or machine restart, and the repository can be fully restored the next time it's opened. The data written to the disk files is the persistent storage data of the code repository. By reading this storage data, a snapshot of the code repository's complete runtime state is reconstructed, representing the persistent state of the code repository. The persistent storage data of the code repository includes the persistent storage data of each code repository branch. Retrieving the branch commit list and reading the last processed commit object can be performed simultaneously or sequentially. Figure 2 This example illustrates one possible execution order and does not constitute a limitation on the order.

[0048] If the last processed code commit object is empty, it means that there is no valid comparison base. In this case, the parent commit of the latest commit object of the target code repository branch determined by the branch commit list will be used as the comparison base of the target code repository branch.

[0049] If the last processed commit is not empty, it means that there is a valid comparison base. The last processed code commit object is the comparison base of the target code repository branch.

[0050] Next, the comparison baseline of the target code repository branch and the latest commit object of the target code repository branch are determined as the incremental difference comparison interval.

[0051] For example, the target code repository branches have the following commits ordered chronologically: A1, B1, C1, D1, E1, where E1 is the latest commit and D1 is the parent commit of E1. If the last processed commit was C1, the incremental difference comparison range is C1 and E1. If the last processed commit was empty, the comparison base is D1, and the incremental difference comparison range is D1 and E1.

[0052] In one embodiment, the branch commit list is obtained through the Git Hosted HTTP API. It should be understood that the Git Hosted HTTP API is a REST-compliant interface provided by the code hosting platform, relying on HTTP / HTTPS protocols for underlying communication. It allows for code repository-related operations such as repository creation and management, branch maintenance, and commit information retrieval via HTTP requests.

[0053] In specification-driven development or documentation-first practices, both specification documents and implementation code are typically stored in a code repository. After determining the incremental difference comparison range using the methods described above, change data is retrieved from the corresponding code repository based on this range. Change data is generally presented in file format.

[0054] In one embodiment, change data is obtained by calling the `compare / repository compare` class interface. It should be understood that the `compare / repository compare` class interface is an interface provided in the code repository. When an incremental difference comparison range is input to this class interface, the interface can return all the difference data between the comparison base and the latest code commit object; this difference data is the change data.

[0055] Step S103: Divide the changed data to obtain specification difference data and implementation code difference data, and input both into the intelligent agent to obtain the corresponding consistency monitoring results.

[0056] In step S103, as Figure 2As shown, based on the aforementioned agreed-upon information, the change data is divided into specification difference data, implementation code difference data, and exclusion data. Specification difference data refers to the comparison data of specification changes between the benchmark and the latest code submission. Implementation code difference data refers to the comparison data of code changes between the benchmark and the latest code submission. Exclusion data refers to the change data other than specification difference data and implementation code difference data, and is not involved in subsequent reasoning. The agreed-upon information mainly includes the rules for distinguishing between specification difference data and implementation code difference data. These rules include, but are not limited to, the suffix of specification files (e.g., spec.md), the path of specification files (e.g., openspec / ), the suffix of code files, and the path of code files. Through these rules, specification difference data and implementation code difference data can be distinguished from the change data. Specifically, the change data originates from specification files, code files, etc. Specification files are generally in Markdown format and stored in a folder with the path "openspec / ". If a file is stored in the path "openspec / " and / or has the suffix ".md", then that file can be identified as a specification file. The data within this specification file is the specification change data. Code file path structures can be of various types, such as the classic structure categorized by language / framework, or business paths divided by functional modules. Classic structures categorized by language / framework include src / , target / , etc. Business paths divided by functional modules include / controllers / , / services / , etc. Multiple code file paths are pre-stored in the convention information; a file is identified as a code file if its path matches any one of these paths. Code file extensions include, but are not limited to, .java, .c, .py, .cs, etc., depending on the language used during development. The data within the code file is the code change data.

[0057] After acquiring specification and implementation code difference data, the latest code commit object of the target code repository branch is updated to the previously processed code commit object in the persistent storage data of the target code repository branch, so as to obtain the incremental comparison range for subsequent use. By maintaining the previously processed commit at the code repository branch level, a repeatable incremental difference range is formed, reducing the number of times incremental differences are repeatedly calculated. Persistent storage allows monitoring to continue even after the service restarts.

[0058] Step S103 involves dividing the change data and inputting the resulting specification difference data and implementation code difference data into the intelligent agent for reasoning. This allows the application to focus on the comparison and semantic consistency judgment of specification changes and implementation code changes, rather than general code changes. Simultaneously, separating difference acquisition from reasoning avoids nested secondary model reasoning during data collection. The former ensures traceability of the source, while the latter completes reasoning under clearly defined analysis dimensions and output structure. This allows for comparison with specification documents in Specification-Driven Development (SDD) or Document-First Practice, facilitating subsequent review and improving credibility.

[0059] It is worth noting that, in the case of multiple target code repository branches, after obtaining the change data of each target code repository, the change data of each target code repository is divided and consistency is monitored in step S103.

[0060] In one embodiment, to facilitate processing by the intelligent agent, the specification difference data and the implementation code difference data need to be structured separately to obtain corresponding structured data. It should be understood that structured data is standardized data with a fixed format, unified fields, clearly defined rows and columns, and the ability to be stored in a two-dimensional table. The meaning, data type, and length of the fields are all predefined, the rules are uniform, and it is extremely easy for machines to read, retrieve, and calculate. Optionally, the specification difference data and the implementation code difference data can also be output in the form of a document with a pre-defined format.

[0061] In one embodiment, specification difference data, implementation code difference data, and prompts are input into the agent. The agent performs reasoning based on the built-in analysis dimensions and the input, and outputs the corresponding consistency monitoring results according to the template.

[0062] It should be noted that the intelligent agent can use existing large language models without fine-tuning or adaptive fine-tuning according to specific application scenarios. The intelligent agent is internally configured with analysis dimensions, and the required results can be output simply by inputting the corresponding information.

[0063] Analysis dimensions can be configured according to actual needs. Analysis dimensions generally include, but are not limited to, whether the implementation code is within the scope of the specification (Code→Spec reverse tracing), whether specification changes are fully implemented in the code (Spec→Code coverage), and whether the implementation code is semantically consistent with the specification, etc.

[0064] The agent can directly output monitoring results or output corresponding monitoring results according to an output template. The output template can be input via prompts or built into the agent. For example, output templates include: an overview table, consistency monitoring conclusions, a problem list, severity levels, etc. An overview table is a table summarizing key information from the agent's reasoning process, providing a clear overview of the overall conclusions. Key information includes whether the implementation code is consistent with the specifications, and the proportion of inconsistencies. Consistency monitoring conclusions are the conclusions drawn from the results generated by the agent. For example, if a specification change is not fully implemented in the code, the implementation code is inconsistent with the specifications. Another example is if the implementation code is within the specification range, the specification change is fully implemented in the code, and the implementation code is semantically consistent with the specifications, therefore the implementation code is consistent with the specifications. A problem list is a list of each inconsistency between the specifications and the implementation code. Severity levels measure the magnitude or urgency of the impact of the inconsistency. Severity levels can be categorized according to requirements. For example, severity levels can be high, medium, and low. When the proportion of inconsistencies between the specifications and the implementation code exceeds a first threshold, the severity level is high. The severity level is low when the proportion of discrepancies between the specification and the implementation code is below the second threshold. Otherwise, the severity level is medium.

[0065] The prompt words are, for example, to perform consistency analysis on the input data and output the analysis results according to the template.

[0066] It should be noted that the output template and prompts can be set according to requirements, and this application does not impose any restrictions on them.

[0067] In one embodiment, specification difference data and implementation code difference data are assembled into a payload and sent to the agent.

[0068] In one embodiment, agent inference supports streaming output, a maximum number of tool loops, and timeout protection to prevent abnormal hangs. Streaming output refers to outputting content in segments in real time, like a continuous stream of water, rather than waiting for the complete result to be generated before returning it all at once. The maximum number of tool loops refers to the hard limit on the number of rounds in a single inference task where the agent completes the entire loop of inference, tool invocation, and obtaining tool results; it is a safety circuit breaker parameter for the agent. Timeout protection refers to the maximum allowed execution time set for a single complete inference request, tool invocation, and agent inference loop. Once the execution time exceeds a preset threshold, the task is immediately forcibly terminated, and the execution process is interrupted.

[0069] In one embodiment, consistency monitoring results can be reported as output. For example... Figure 3As shown, consistency monitoring results and change data can be output through pluggable channels. It should be understood that pluggable channels are a modular, standardized, and loosely coupled channel access architecture: the system defines a unified standard interface, and each type of external channel (payment, messaging, e-commerce, login, hardware peripherals, etc.) is encapsulated as an independent plugin; adding, deactivating, or switching channels does not require modification of core business code, supports dynamic loading / unloading (hot-swapping), and upper-layer businesses are completely unaware of the differences in underlying channels. Types of pluggable channels include, but are not limited to, enterprise IM, email, webhook, and site messaging.

[0070] In one embodiment, when using a session-based channel, a request domain context can be bound to a session identifier, used only for delivery to the target and within the permission boundary. Specifically, a session-based channel refers to a stateful, continuously interactive communication channel, such as an IM session. A request domain context is an independent data container shared throughout an entire HTTP request, belonging only to the current user request. A session identifier is a unique string number assigned by the server to each user, used to distinguish different user sessions. When consistency monitoring results need to be sent to a specific user, a corresponding request is generated. By parsing this request, a request domain context is constructed. The request domain context is bound to the session identifier to locate the specified user and verify whether the specified user is within the permission boundary, thereby sending the consistency monitoring results to the specified user without any intermediate processing. The permission boundary refers to whether the target is qualified to receive messages.

[0071] In one embodiment, the obtained specification difference data and implementation code difference data are encapsulated into a callable tool. The tool returns structured data or a pre-defined document format, and its responsibility ends with fact collection and status updates.

[0072] To better illustrate the method of this application, the following specific embodiments are provided: like Figure 4 as well as Figure 5 As shown, the user issues a monitoring task or a scheduled task issues a monitoring task to the agent. The agent parses the monitoring task and calls the difference collection tool via a function call. The difference collection tool obtains the branch commit list through the Git-hosted HTTP API and determines the incremental difference comparison range based on this. Then, it obtains the change data based on the incremental difference comparison range. The change data is divided into specification difference data and implementation code difference data, and assembled into a payload. The difference collection tool returns the payload to the agent for inference and generates consistency monitoring results. The consistency monitoring results are output in a structured report format.

[0073] Optionally, consistency monitoring results can be output through a notification adaptation layer. The notification adaptation layer uses pluggable channels, including but not limited to enterprise IM, email, webhook, and in-site messages.

[0074] Figure 6 This is the overall architecture diagram of the specification and code consistency monitoring system based on incremental differences proposed in this application. Figure 6 As shown, the specification and code consistency monitoring system based on incremental differences in this application includes: The target determination module M100 is used to receive and parse monitoring tasks to determine the target code repository branch. The change acquisition module M200 is used to acquire the incremental difference range of the target code repository branch relative to its last processed commit and accordingly acquire the corresponding change data from the code repository; the change data is divided to obtain specification difference data and implementation code difference data; The monitoring module M300 is used to input the specification difference data and implementation code difference data into the intelligent agent to obtain the corresponding consistency monitoring results. The intelligent agent is configured to perform inference based on the built-in analysis dimensions and inputs, and output the corresponding consistency monitoring results.

[0075] In the specification and code consistency monitoring system based on incremental differences in this application, the functions of each module can be implemented using the specific implementation method of the specification and code consistency monitoring method based on incremental differences as described above, and the technical effects of the specification and code consistency monitoring method based on incremental differences can be obtained. These details will not be elaborated here.

[0076] This application also provides a specification and code consistency monitoring device based on incremental differences, including a processor; a memory storing executable instructions of the processor; wherein the processor is configured to perform the steps of the specification and code consistency monitoring method based on incremental differences by executing the executable instructions.

[0077] Those skilled in the art will understand that various aspects of this application can be implemented as systems, methods, or computer program products. Therefore, various aspects of this application can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software implementations, collectively referred to herein as a "circuit," "module," or "platform."

[0078] The following reference Figure 7 To describe an electronic device 600 according to this embodiment of the present application. Figure 7 The electronic device 600 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0079] like Figure 7 As shown, the electronic device 600 is presented in the form of a general-purpose computing device. The components of the electronic device 600 may include, but are not limited to: at least one processing unit 610, at least one storage unit 620, a bus 630 connecting different system components (including storage unit 620 and processing unit 610), a display unit 640, etc.

[0080] The storage unit stores program code that can be executed by the processing unit 610, causing the processing unit 610 to perform the steps described in the above section of this specification on the specification and code consistency monitoring method based on incremental differences, according to various exemplary embodiments of this application. For example, the processing unit 610 can perform, as follows: Figure 1 The steps are shown in the figure.

[0081] The storage unit 620 may include a readable medium in the form of a volatile storage unit, such as a random access memory unit (RAM) 6201 and / or a cache storage unit 6202, and may further include a read-only memory unit (ROM) 6203.

[0082] The storage unit 620 may also include a program / utility 6204 having a set (at least one) program module 6205, such program module 6205 including but not limited to: an operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0083] Bus 630 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0084] Electronic device 600 can also communicate with one or more external devices 700 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 600, and / or with any device that enables electronic device 600 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 650. Furthermore, electronic device 600 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 660. Network adapter 660 can communicate with other modules of electronic device 600 via bus 630. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 600, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0085] In the incremental difference-based specification and code consistency monitoring device, when the program in the memory is executed by the processor, it implements the steps of the incremental difference-based specification and code consistency monitoring method. Therefore, the device can also obtain the technical effects of the incremental difference-based specification and code consistency monitoring method.

[0086] An exemplary embodiment of this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the steps of the above-described specification and code consistency monitoring method based on incremental differences.

[0087] In one embodiment, the computer program product can be a tangible product containing a computer program, such as a computer-readable storage medium storing the computer program. The readable storage medium can be a storage medium based on electrical, magnetic, optical, electromagnetic, infrared, or other signals, including but not limited to: random access memory (RAM), read-only memory (ROM), magnetic tape, floppy disk, flash memory, hard disk drive (HDD), solid-state drive (SSD), etc. Exemplarily, the computer program product can be implemented as a non-volatile storage medium storing a computer program, such as read-only memory, NAND flash memory, etc.

[0088] In one implementation, the computer program product can be an intangible product containing a computer program. For example, the computer program product can be implemented as a virtual digital product, such as an executable file, installation package, or other digital file storing the computer program.

[0089] Computer program code can be written in one or more programming languages. Examples of programming languages ​​include C, Java, C++, and Python. Program code can execute entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, such as a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via an internet connection provided by a mobile network operator).

[0090] Computer programs can be carried or transmitted via signals such as electricity, magnetism, light, electromagnetic fields, and infrared radiation. Electronic devices can convert the signals carrying computer programs into digital signals, thereby running the computer programs. When a computer program runs on an electronic device, its code is used to cause the electronic device to execute (more specifically, the processor of the electronic device to execute) the method steps of various exemplary embodiments of this application, such as the steps of the specification and code consistency monitoring method based on incremental differences described above.

[0091] When the computer program is executed by the processor, it implements the steps of the above-described incremental difference-based specification and code consistency monitoring method. Therefore, the computer program product can also obtain the technical effects of the above-described incremental difference-based specification and code consistency monitoring method.

[0092] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of this application and should not be construed as limiting the specific implementation of this application to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of this application, and all such modifications or substitutions should be considered within the scope of protection of this application.

Claims

1. A specification and code consistency monitoring method based on incremental differences, characterized in that, Includes the following steps: Receive and analyze monitoring tasks to determine the target code repository branch; Obtain the comparison benchmark of the target code repository branch and determine the incremental difference comparison interval accordingly; The change data is obtained from the corresponding code repository based on the incremental difference comparison range. The changed data is divided into specification difference data and implementation code difference data, and both are input into the intelligent agent to obtain the corresponding consistency monitoring results. The intelligent agent is configured to perform inference based on the built-in analysis dimensions and inputs, and output the corresponding consistency monitoring results.

2. The specification and code consistency monitoring method based on incremental differences according to claim 1, characterized in that, The monitoring task includes location information for determining the target code repository branch and convention information for changing data partitioning; the location information includes the project ID and repository branch information, or the location information includes repository coordinates.

3. The specification and code consistency monitoring method based on incremental differences according to claim 1, characterized in that, Obtaining the comparison benchmark for the target code repository branch specifically includes: Read the last processed code commit object of the target code repository branch from the persistent storage data of the target code repository branch; If the last processed code commit object is empty, then the parent commit of the latest code commit object of the target code repository branch is the comparison benchmark of the target code repository branch; If the last processed code commit object is not empty, then the last processed code commit object of the target code repository branch is the comparison benchmark of the target code repository branch.

4. The specification and code consistency monitoring method based on incremental differences according to claim 3, characterized in that, The incremental difference comparison range is the comparison benchmark of the target code repository branch and the latest code commit object.

5. The specification and code consistency monitoring method based on incremental differences according to claim 1, characterized in that, The agent is also pre-configured with an output template, and the agent outputs consistent monitoring results according to the output template.

6. The specification and code consistency monitoring method based on incremental differences according to claim 1, characterized in that, The monitoring task is initiated by the user or distributed via a scheduled task.

7. The specification and code consistency monitoring method based on incremental differences according to claim 1, characterized in that, The method further includes: after the data change is completed, updating the latest code commit object of the target code repository branch to the previously processed code commit object.

8. A specification and code consistency monitoring system based on incremental differences, characterized in that, The system is used to implement the specification and code consistency monitoring method based on incremental differences as described in any one of claims 1 to 7, the system comprising: The target determination module is used to receive and parse monitoring tasks to determine the target code repository branch. The change acquisition module is used to acquire the comparison benchmark of the target code repository branch and determine the incremental difference comparison range accordingly; obtain change data from the corresponding code repository according to the incremental difference comparison range; divide the change data to obtain specification difference data and implementation code difference data; The monitoring module is used to input the specification difference data and implementation code difference data into the agent to obtain the corresponding consistency monitoring results. The agent is configured to perform inference based on the built-in analysis dimensions and the input, and output the corresponding consistency monitoring results.

9. A specification and code consistency monitoring device based on incremental differences, characterized in that, include: processor; A memory in which executable instructions of the processor are stored; The processor is configured to perform the steps of the specification and code consistency monitoring method based on incremental differences according to any one of claims 1 to 7 by executing the executable instructions.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the specification and code consistency monitoring method based on incremental differences as described in any one of claims 1 to 7.

Images