A devops release and build history bi-directional tracing method and system

Abstract

The present application relates to the technical field of DevOps continuous integration and continuous delivery, and particularly relates to a DevOps release and construction history bidirectional tracing method and system, the system comprises a construction metadata acquisition module, a release event capture module, a bidirectional association engine and a tracing graph storage and query module, a global unique TraceID is generated and embedded in product metadata, bidirectional association between construction and release is established by analyzing the TraceID in the release stage, an event-driven incremental graph construction strategy is adopted to construct a version evolution graph based on a graph structure, an environment topology hierarchical model is introduced to support multi-environment tracing and consistency checking, and multi-dimensional decision information is automatically aggregated to assist rollback decision when rolling back; the present application realizes bidirectional strong association of release and construction history, eliminates information silos, greatly improves fault troubleshooting efficiency and rollback safety, realizes accurate cross-environment version consistency checking, and meets the audit compliance and system stability guarantee requirements of the whole software delivery process.

Description

Technical Field

[0001] This invention relates to the field of DevOps continuous integration and continuous delivery technology, specifically a method and system for bidirectional traceability of DevOps release and build history. Background Technology

[0002] The DevOps philosophy emphasizes close collaboration between development and operations, achieving efficient software delivery processes through automated toolchains. The CI / CD pipeline, as the core of DevOps practices, typically covers key stages such as code commit triggering, automated builds, artifact generation, and environment deployment. Throughout the software delivery lifecycle, release and rollback operations are crucial for ensuring system stability. With the widespread adoption of microservice architectures and multi-cloud deployment models, the iteration frequency of software versions has significantly increased. The same build package may be released to multiple environments with different release rhythms, placing higher demands on the traceability of release records and build history.

[0003] Currently, mainstream DevOps platforms in the industry mainly adopt three approaches to manage release and build history: a simple reference mode based on artifact repositories, a linear recording mode based on pipelines, and a loose association mode based on tags. These solutions all have obvious limitations: the reference mode based on artifact repositories only indirectly associates build information through artifact coordinates, and the traceability chain is easily broken due to the loss of artifact repository metadata or artifact cleanup; the linear recording mode based on pipelines only supports strictly linear processes and cannot cope with the actual scenario of building once and releasing multiple times, and pipeline configuration changes or branch merging can easily lead to confusion in traceability relationships; the association mode based on tags relies on manual standardization, and inconsistent tag naming or repeated use will cause association errors, and the tags themselves do not contain a complete build environment context.

[0004] Furthermore, existing technologies generally suffer from a disconnect between release and build history information. Release records only store surface-level information such as deployment targets and timestamps, making it difficult to quickly associate them with the corresponding original build records. Most technologies only support forward tracing from build to release, lacking the ability to trace backward from release to build, which severely impacts the efficiency of troubleshooting in production environments. Rollback operations are treated as independent new release events, lacking an explicit association with the original release records, making it impossible to clearly show the complete path of version evolution. At the same time, they cannot effectively manage the many-to-many mapping relationship between build packages and release records in multiple environments, making cross-environment version tracing and consistency verification extremely difficult. Therefore, in response to the above situation, there is an urgent need to develop a DevOps release and build history bidirectional tracing method and system to overcome the shortcomings in current practical applications. Summary of the Invention

[0005] The purpose of this invention is to provide a method and system for bidirectional tracing of DevOps release and build history, in order to solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides the following technical solution: A DevOps release and build history bidirectional traceability method includes the following steps: (1) Generate a globally unique unified traceability identifier TraceID during the construction phase, embed the TraceID into the internal metadata of the artifact to be released, and collect construction metadata to generate a construction record containing the TraceID; (2) During the release phase, pull the artifact to be released, parse the internal metadata of the artifact to extract the TraceID, collect the release context to generate a release record containing the TraceID; (3) Based on the TraceID, establish a bidirectional association between the build record and the release record, and use graph structure modeling to build events, release events and their relationships to build a version evolution traceability graph; (4) Provide multi-dimensional traceability query services based on the version evolution traceability map.

[0007] As a further aspect of the present invention: in step (1), the TraceID is generated using a hierarchical encoding structure, including a timestamp, a construction node identifier, and a random sequence number of a preset length; Embed the TraceID into the internal metadata of the artifact to be published, specifically by using the corresponding embedding method based on the artifact type: For Java artifacts, write the TraceID to a custom property in the MANIFEST.MF file; For Docker images, set the TraceID as part of the image tag and the LABEL attribute in the image configuration; For static resource packages, a metadata file containing TraceID is generated in the package root directory.

[0008] As a further aspect of the present invention: in step (3), an event-driven incremental graph construction strategy is used to construct a version evolution traceability graph. When a new construction record or release record is received, the nodes and edges of the graph are updated in real time.

[0009] As a further aspect of the present invention: in step (3), the establishment of a bidirectional association between the build record and the release record based on TraceID specifically includes: Establish a positive association from the build record to the release record, which is used to query all corresponding release histories from the build record; Establish a reverse association from the release record to the build record, which is used to query the corresponding complete build information from the release record; Detect rollback operations, establish rollback associations between rollback release records and the original release records that were rolled back, and incorporate rollback operations into the version evolution traceability graph.

[0010] As a further aspect of the present invention, it also includes managing multi-environment publishing scenarios using an environment topology hierarchy model. This model organizes environments into a tree structure, with each environment node assigned a unique hierarchical path identifier. Based on this environment topology hierarchy model, the following is implemented: Horizontal query: Enter TraceID to query the release status of the build package corresponding to that TraceID in all environments; Vertical query: Enter the environment path to query the complete version evolution history of that environment; Cross-environment consistency check: Compare the TraceIDs of the current running versions in multiple environments to determine whether they are built from the same source.

[0011] As a further aspect of the present invention, it also includes a rollback decision support step: When a rollback request is initiated, a rollback decision report is generated by aggregating multi-dimensional decision information, starting from the TraceID of the target rollback version. The multi-dimensional decision information includes build quality information, environment verification information, configuration change difference information, and rollback path analysis information.

[0012] As a further aspect of the present invention: after the rollback decision support step, the method further includes: After confirming the rollback decision, execute the rollback deployment operation; Capture rollback release events and generate rollback release records; Establish a rollback association between the rollback release record and the original release record that was rolled back.

[0013] As a further aspect of the present invention: in step (4), the version evolution tracing map adopts a hybrid storage strategy: Graph structured data is stored in a graph database, while large volumes of unstructured data, including raw build logs and release logs, are stored in an object storage system. The two are linked by TraceID. The multi-dimensional traceability and query services provided include precise traceability interface, path traceability interface, range query interface, and consistency comparison interface.

[0014] A DevOps release and build history bidirectional traceability system includes: A metadata collection module is built to generate a globally unique unified traceability identifier (TraceID) during the build phase, embed the TraceID into the internal metadata of the artifact to be released, and collect build metadata to generate a build record containing the TraceID. The release event capture module is used to pull the artifact to be released during the release phase, parse the internal metadata of the artifact to extract the TraceID, collect the release context and generate a release record containing the TraceID; A bidirectional association engine is used to establish a bidirectional association between build records and release records based on the TraceID. It uses a graph structure to model build events, release events and their relationships, and builds a version evolution traceability graph. The traceability graph storage and query module is used to store the version evolution traceability graph and provide multi-dimensional traceability query services based on the graph.

[0015] As a further aspect of the present invention: the bidirectional association engine adopts an event-driven incremental graph construction strategy, and updates the nodes and edges of the version evolution tracing graph in real time when a new construction record or release record is received.

[0016] Compared with the prior art, the beneficial effects of the present invention are: 1. It achieves complete traceability. By unifying the generation, embedding, extraction and association of traceability identifiers throughout the entire process, it builds a complete chain of evidence from code submission to production operation. Any release can be directly located to its code source, build environment and build parameters. Any build can be traced to all its deployment destinations. While meeting audit compliance requirements, it significantly shortens the information collection time for troubleshooting. 2. It has bidirectional real-time traceability capability. The bidirectional association engine adopts an event-driven incremental graph construction strategy. When a new event arrives, the association update is completed in seconds. Operation and maintenance personnel can query complete construction traceability information immediately after the release, without waiting for batch processing or manual synchronization. 3. Improved security of rollback operations: The rollback decision information aggregation mechanism can automatically collect build quality data, environment verification records and configuration change differences of the target version, providing comprehensive data support for rollback decisions and reducing the probability of introducing new faults during rollback; 4. It achieves global visibility across multiple environments. Through the environment topology hierarchy model and horizontal query capability, the operation and maintenance team can have a global grasp of the distribution of versions in various environments, promptly detect risky states such as going live without verification, and accurately identify cases with the same version number but different build sources based on the precise comparison of unified traceability identifiers, ensuring cross-environment version consistency. 5. It achieves interpretability of version evolution. The version evolution graph based on graph structure fully records the historical causal relationship between release and rollback, supports path tracing query, and can clearly display the complete version decision chain during fault review, helping the team understand the historical context and avoid repeating mistakes. Attached Figure Description

[0017] Figure 1This is a diagram of the DevOps release and build history bidirectional traceability system architecture in an embodiment of the present invention.

[0018] Figure 2 This is a schematic diagram of the time sequence of the construction period in an embodiment of the present invention.

[0019] Figure 3 This is a time sequence diagram of the release period in an embodiment of the present invention.

[0020] Figure 4 This is a timing diagram of the rollback period in an embodiment of the present invention. Detailed Implementation

[0021] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0022] The specific implementation of the present invention will be described in detail below with reference to specific embodiments.

[0023] Please see Figures 1-4 This invention provides a DevOps release and build history bidirectional traceability method and system. It generates a globally unique TraceID embedded within the artifact, spanning the entire software build and release lifecycle. Based on graph structure modeling of build, release, and rollback events and their relationships, it establishes a strong bidirectional association between release records and build history. An environment topology hierarchy model is introduced to support traceability and consistency verification in complex multi-environment scenarios. During rollback operations, it automatically aggregates multi-dimensional contextual information to provide data support for rollback decisions, ultimately achieving a complete, traceable, auditable, and evaluable DevOps delivery process from code submission to production operation.

[0024] I. System Overall Architecture The DevOps release and build history bidirectional traceability system described in this invention includes four core modules: a build metadata collection module, a release event capture module, a bidirectional association engine, and a traceability graph storage and query module.

[0025] The overall system workflow is as follows: The build metadata collection module generates a globally unique TraceID when the build task starts, injects it into the build environment and embeds it into the metadata of the final generated artifact, and collects complete build metadata to generate build records; The release event capture module intercepts the deployment process during the release phase, pulls artifacts and deeply parses their internal metadata to extract TraceIDs, captures complete release contexts and generates release records; The bidirectional association engine establishes a bidirectional association between build records and release records in real time based on TraceIDs, detects rollback operations and establishes rollback association edges, and builds a complete version evolution traceability graph; The traceability graph storage and query module adopts a hybrid storage strategy to persist traceability data and provides multi-dimensional traceability query and consistency verification interfaces.

[0026] II. Specific Implementation of Core Modules 2.1 Constructing a metadata collection module The metadata collection module is deployed on the build node of the CI / CD pipeline and is responsible for collecting metadata and managing TraceID throughout the entire lifecycle of the build process.

[0027] This module first implements a unified traceability identifier (TraceID) generation mechanism: When the build task starts, a globally unique TraceID with a hierarchical coding structure is generated. This TraceID consists of three parts: a timestamp, a build node identifier, and a random sequence number. The timestamp uses a millisecond-level Unix timestamp to ensure the temporal orderability of the TraceID; the build node identifier uses the unique hardware identifier of the build server or a node ID assigned by the cluster to ensure uniqueness in a distributed environment; and the random sequence number uses a 16-bit random number to prevent duplicate TraceIDs from being generated by the same node within the same millisecond. The generated TraceID is injected into the environment variables of the build process and persists throughout all build stages, including code retrieval, compilation, packaging, automated testing, and artifact uploading.

[0028] For scenarios with highly deterministic builds (such as completely standardized build environments and fixed build parameters), a separate TraceID can be omitted. Instead, the CommitID from the Git commit graph can be used as the traceability identifier, with both build and release records associated with this CommitID. This solution simplifies the identifier management process but cannot distinguish between multiple builds corresponding to the same CommitID (such as different build parameters or different build environments). The traceability granularity is relatively coarse, making it only suitable for small teams or simple project scenarios.

[0029] This module further implements the artifact metadata embedding mechanism: after the artifact is packaged but before being uploaded to the artifact repository, the TraceID is embedded in the artifact's internal metadata. Different embedding methods are used for different types of artifacts. For Java artifacts such as JAR / WAR, write the TraceID into the custom attribute X-Build-Trace-ID in the MANIFEST.MF file; For Docker images, set the TraceID as part of both the image tag and the LABEL attribute build.trace.id in the image configuration; For static resource packages (such as front-end JS / CSS bundled files), a metadata file named build-trace.json is generated in the root directory of the package, which contains the TraceID field.

[0030] After artifact embedding is complete, this module collects complete build metadata to generate build records. Each build record includes at least the following fields: Build ID, Trace ID, code repository address, commit ID, build parameters, build environment information, unit test coverage, test case pass rate, static code scan score, dependency vulnerability scan results, artifact coordinates, artifact hash value, build start time, build end time, and the person performing the build. The build record is then sent to the bidirectional association engine for further processing.

[0031] The above solution achieves deep binding between TraceID and artifact, ensuring that the traceability identifier of an artifact can always be extracted and cannot be tampered with after it leaves the build system, crosses network boundaries, and enters different environments. This fundamentally eliminates the problem of broken traceability chains caused by loss of artifact database metadata or replacement of artifacts in traditional solutions.

[0032] 2.2 Publishing the event capture module The release event capture module is deployed in the deployment agent of each environment and is responsible for intercepting the release execution process and deeply capturing the complete context information of the release event.

[0033] When operations personnel initiate a release request (specifying artifact coordinates and target environment), the deployment agent first pulls the specified version of the artifact from the artifact repository. Subsequently, this module performs deep metadata parsing on the pulled artifact, extracting the embedded TraceID based on the artifact type. The parsing process does not depend on any parameters passed in the release request, but is based solely on the actual deployed artifact itself, ensuring that the TraceID in the release record is strictly consistent with the actual running artifact.

[0034] After parsing, this module generates a complete release record, which includes at least the following fields: release unique identifier (DeployID), release timestamp, target environment identifier (EnvironmentID), deployment configuration version (ConfigVersion), artifact coordinates, TraceID parsed from the artifact, artifact cryptographic hash value (SHA-256), release status, and release operator. The release record is sent to the bidirectional association engine in real time.

[0035] The above solution avoids the traceability and association errors caused by incorrect parameter transmission, malicious replacement of artifacts, or duplicate version numbers in traditional solutions, ensuring a one-to-one correspondence between release records and actual deployed artifacts, and providing a reliable data foundation for two-way traceability.

[0036] 2.3 Bidirectional Relationship Engine The bidirectional association engine is the core processing unit of the system, responsible for linking discrete build, release, and rollback records into an organic traceability graph. This engine adopts an event-driven incremental graph construction strategy, updating the graph in real time when a new event arrives, rather than rebuilding it in batches, ensuring the real-time nature of traceability information.

[0037] This engine uses a graph database (such as Neo4j) or a graph extension of a relational database (such as the ltree extension of PostgreSQL) as its storage backend, modeling various events as graph nodes and the relationships between events as directed edges. The specific association rules are as follows: Forward association (build → release): When a release record containing a TraceID is received, the engine searches the graph for the build node with the corresponding TraceID and creates a directed edge from the build node to the release node. The edge attributes include release time, target environment, and release status. Through this association, all release history of the build package can be directly queried from any build record.

[0038] Reverse association (release → build): Based on the same TraceID, the engine simultaneously creates directed edges from the release node to the build node. The edge attributes include the build time, build node, and code version. Through this association, complete build information can be directly obtained from any release record.

[0039] Rollback Association (Release → Rollback): The engine detects rollback operations in two ways: first, by recognizing explicit rollback command identifiers; and second, by analyzing the rollback characteristics of the deployed artifact version relative to the current running version. When a rollback operation is detected, the engine creates a special rollback edge connecting the rollback release node with the original rollback release node. The edge attributes include the rollback reason and rollback time. Through this association, the rollback operation is explicitly incorporated into the version evolution graph, forming a complete version timeline.

[0040] The above solution breaks through the limitations of linear records in traditional relational databases, enabling flexible expression of complex version evolution patterns such as multiple rollbacks, cross-environment jumps, and parallel releases, and achieving a strong two-way association between the construction and release history.

[0041] 2.4 Traceability Map Storage and Query Module The traceability graph storage and query module adopts a hybrid storage strategy to achieve efficient persistence and querying of traceability data: the graph structure (nodes and edges) is stored in a graph database for fast execution of association queries and path analysis; large-capacity unstructured data such as original build logs and release logs are stored in an object storage system (such as S3 or MinIO), and the two are associated through TraceID.

[0042] This module provides the following multi-dimensional standardized query interfaces: Precise traceability interface: Input release ID, return complete build information corresponding to the release, including code version, build parameters, test results and build log download address; input build ID, return all associated release records of the build package, including release environment, release time, release status and operator.

[0043] Path tracing interface: Input two release IDs and return the complete evolution path between the two versions, including all intermediate versions, whether there is a rollback operation, and the path length.

[0044] Range query interface: Input a time range and an environment range, and return all published events within that range and their corresponding build traceability information.

[0045] Consistency comparison interface: Input multiple environment identifiers and return the build source comparison results of the current running version of each environment, including TraceID, build time and code version.

[0046] The above solution provides maintenance personnel with a unified and efficient traceability query portal, eliminating the need to switch between multiple independent systems and significantly reducing the time required for troubleshooting and auditing.

[0047] III. Specific Procedures of the Two-Way Traceability Method 3.1 Construction Phase Process The construction phase described in this invention specifically includes the following steps: S101: Code is committed to the code repository, triggering the CI / CD pipeline's build task; S102: The metadata collection module generates a globally unique TraceID with a hierarchical encoding structure and injects it into the environment variables of the build process; S103: Perform code retrieval, compilation, and packaging operations to generate artifacts to be released; S104: Build a metadata collection module to embed TraceID into the internal metadata of the artifact based on the artifact type; S105: Upload the artifact with embedded TraceID to the artifact library; S106: Collect complete build metadata, generate a build record containing TraceID, and send it to the bidirectional association engine; S107: Build task complete.

[0048] 3.2 Release Phase Process The release phase of this invention specifically includes the following steps: S201: Operations personnel initiate a release request through the release system, specifying the coordinates of the artifact to be released and the target environment; S202: Deploy the agent to pull the specified artifact from the artifact library; S203: The release event capture module performs deep analysis of the artifact's internal metadata and extracts the embedded TraceID; S204: The deployment agent performs deployment operations to deploy artifacts to the target environment; S205: The release event capture module generates a complete release record containing the TraceID and artifact hash value, and sends it to the bidirectional association engine; S206: The bidirectional association engine establishes forward and reverse associations between build nodes and release nodes based on TraceID; S207: Task completed.

[0049] 3.3 Rollback Phase Process The rollback phase described in this invention specifically includes the following steps: S301: The operations and maintenance personnel select the target version to roll back in the release system and initiate a rollback request; S302: The system queries the TraceID corresponding to the target version; S303: Triggers the rollback decision information aggregation process, starting with the TraceID of the target version, collecting build quality information, environment verification information, configuration change difference information and rollback path analysis information; S304: Generate a rollback decision report and display it to the operations and maintenance personnel; S305: After the operations and maintenance personnel confirm the rollback decision, the deployment agent executes the rollback deployment operation; S306: The release event capture module captures rollback release events, generates rollback release records, and sends them to the bidirectional association engine; S307: The bidirectional association engine establishes a rollback association edge between the rollback release node and the original release node that was rolled back; S308: Rollback task completed.

[0050] IV. Implementation of Multi-Environment Traceability and Consistency Verification For multi-environment deployment scenarios in microservice architectures and multi-cloud deployment environments, this invention introduces an environment topology hierarchical model for management. Environments are organized into a tree structure, with the root node being "Global." First-level child nodes include environment types such as "Development," "Testing," "Pre-release," and "Production." Each first-level child node can be further subdivided into specific clusters or instance nodes (e.g., "Production - East China," "Production - North China - Cluster 1"). Each environment node is assigned a unique environment identifier, represented by a hierarchical path (e.g., / prod / east / cluster1).

[0051] The bidirectional association engine records the environment hierarchy path information corresponding to the publication event while establishing the association between the publication node and the build node. Based on this model, the system implements the following core functions: Horizontal query: Enter the specified TraceID to query the release status of the build package in all environments and quickly identify abnormal states such as "test passed but not deployed to production" or "deployed to production but not verified by testing".

[0052] Vertical query: Enter the specified environment path to query the complete version evolution history of that environment and identify version jumps or abnormal rollback patterns across environments.

[0053] Cross-environment consistency verification: Compare the TraceIDs of the currently running versions in multiple environments to determine if they are from the same source. Even if the version numbers of two environments are exactly the same, as long as the TraceIDs are different, they can be accurately identified as different build versions, avoiding the risk of deploying unverified versions.

[0054] V. Implementation of the Rollback Decision Support System When operations and maintenance personnel initiate a rollback request, the system automatically triggers an information aggregation process, starting with the TraceID of the target rollback version, and aggregating the following multi-dimensional information from the traceability graph and various related systems: Build quality information: Obtain unit test coverage, test case pass rate, static code scan score, and dependency vulnerability scan results from the build record to evaluate the code quality of the target version.

[0055] Environment verification information: Query all historical release records of the build package corresponding to the TraceID from the trace map to identify which environments the version has been verified in, the verification time and verification duration, and determine its stability.

[0056] Configuration Change Differences: Compare the deployment configuration versions of the target rollback version and the current running version, generate a configuration difference report, and identify configuration items that may cause compatibility issues.

[0057] Rollback path analysis: Analyze the version evolution graph to identify the shortest rollback path from the current version to the target version, and indicate whether other transition versions are needed in between to avoid dependency conflicts caused by direct rollback.

[0058] The above information is integrated into a structured rollback decision report, which is displayed to operations personnel before they perform the rollback operation. Based on this report, operations personnel assess the rollback risks and only perform the rollback operation after confirmation. This mechanism upgrades rollback from a simple deployment operation to a traceable and assessable decision-making process, significantly reducing the probability of rollback introducing new faults.

[0059] One approach is to introduce a machine learning model based on the aforementioned information aggregation mechanism. This model analyzes historical rollback data to learn the correlation between different version characteristics, environment characteristics, and rollback success rate and rollback time. It can then predict the success rate of the current rollback operation, estimate the rollback time, and recommend the optimal rollback time window. This solution enhances the intelligence of rollback decisions, but relies on a large amount of historical data for training, making it suitable for large enterprise environments with high release frequency and abundant rollback cases.

[0060] It should be noted that, in this invention, although the specification describes the embodiments, not every embodiment contains only one independent technical solution. This way of describing the specification is only for clarity. Those skilled in the art should regard the specification as a whole. The technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A method for bidirectional tracing of DevOps release and build history, characterized in that, Includes the following steps: (1) Generate a globally unique unified traceability identifier TraceID during the construction phase, embed the TraceID into the internal metadata of the artifact to be released, and collect construction metadata to generate a construction record containing the TraceID; (2) During the release phase, pull the artifact to be released, parse the internal metadata of the artifact to extract the TraceID, collect the release context to generate a release record containing the TraceID; (3) Based on the TraceID, establish a bidirectional association between the build record and the release record, and use graph structure modeling to build events, release events and their relationships to build a version evolution traceability graph; (4) Provide multi-dimensional traceability query services based on the version evolution traceability map.

2. The DevOps release and build history bidirectional tracing method according to claim 1, characterized in that, In step (1), the TraceID is generated using a hierarchical encoding structure, including a timestamp, a construction node identifier, and a random sequence number of a preset length; Embed the TraceID into the internal metadata of the artifact to be published, specifically by using the corresponding embedding method based on the artifact type: For Java artifacts, write the TraceID to a custom property in the MANIFEST.MF file; For Docker images, set the TraceID as part of the image tag and the LABEL attribute in the image configuration; For static resource packages, a metadata file containing TraceID is generated in the package root directory.

3. The DevOps release and build history bidirectional tracing method according to claim 1, characterized in that, In step (3), an event-driven incremental graph construction strategy is used to construct a version evolution traceability graph. When a new construction record or release record is received, the nodes and edges of the graph are updated in real time.

4. The DevOps release and build history bidirectional tracing method according to claim 1, characterized in that, In step (3), establishing a bidirectional association between build records and release records based on TraceID specifically includes: Establish a positive association from the build record to the release record, which is used to query all corresponding release histories from the build record; Establish a reverse association from the release record to the build record, which is used to query the corresponding complete build information from the release record; Detect rollback operations, establish rollback associations between rollback release records and the original release records that were rolled back, and incorporate rollback operations into the version evolution traceability graph.

5. The DevOps release and build history bidirectional tracing method according to claim 1, characterized in that, It also includes managing multi-environment deployment scenarios using an environment topology hierarchy model. This model organizes environments into a tree structure, assigning a unique hierarchy path identifier to each environment node. Based on this environment topology hierarchy model, the following is implemented: Horizontal query: Enter TraceID to query the release status of the build package corresponding to that TraceID in all environments; Vertical query: Enter the environment path to query the complete version evolution history of that environment; Cross-environment consistency check: Compare the TraceIDs of the current running versions in multiple environments to determine whether they are built from the same source.

6. The DevOps release and build history bidirectional tracing method according to claim 1, characterized in that, It also includes the rollback decision support step: When a rollback request is initiated, a rollback decision report is generated by aggregating multi-dimensional decision information, starting from the TraceID of the target rollback version. The multi-dimensional decision information includes build quality information, environment verification information, configuration change difference information, and rollback path analysis information.

7. The DevOps release and build history bidirectional tracing method according to claim 6, characterized in that, The rollback decision support step is followed by: After confirming the rollback decision, execute the rollback deployment operation; Capture rollback release events and generate rollback release records; Establish a rollback association between the rollback release record and the original release record that was rolled back.

8. The DevOps release and build history bidirectional traceability method according to claim 1, characterized in that, In step (4), the version evolution tracing map adopts a hybrid storage strategy: Graph structured data is stored in a graph database, while large volumes of unstructured data, including raw build logs and release logs, are stored in an object storage system. The two are linked by TraceID. The multi-dimensional traceability and query services provided include precise traceability interface, path traceability interface, range query interface, and consistency comparison interface.

9. A DevOps release and build history bidirectional traceability system, characterized in that, include: A metadata collection module is built to generate a globally unique unified traceability identifier (TraceID) during the build phase, embed the TraceID into the internal metadata of the artifact to be released, and collect build metadata to generate a build record containing the TraceID. The release event capture module is used to pull the artifact to be released during the release phase, parse the internal metadata of the artifact to extract the TraceID, collect the release context and generate a release record containing the TraceID; A bidirectional association engine is used to establish a bidirectional association between build records and release records based on the TraceID. It uses a graph structure to model build events, release events and their relationships, and builds a version evolution traceability graph. The traceability graph storage and query module is used to store the version evolution traceability graph and provide multi-dimensional traceability query services based on the graph.

10. The DevOps release and build history bidirectional traceability system according to claim 9, characterized in that, The bidirectional association engine adopts an event-driven incremental graph construction strategy, which updates the nodes and edges of the version evolution tracing graph in real time when a new construction record or release record is received.

Images