Web platform for data linkage and unified management of underlying table items of multi-heterogeneous CI system based on DevOps architecture

Abstract

This application discloses a web platform for data linkage and unified management of underlying table entries across multiple heterogeneous CI systems based on a DevOps architecture. This platform relates to the fields of software development and operations technology, and includes a front-end interaction layer, an application service layer, a data processing layer, a storage layer, and an API gateway layer. The application service layer includes a data acquisition module, a data unification and backfilling module, and an underlying table entry unified management module. The data acquisition module automatically collects, parses, and converts data in various formats. The data unification and backfilling module performs unified standard data structure mapping and backfilling. During data flow and invocation across CI systems, the underlying table entry unified management module performs field conversion and matching based on established mapping relationships, achieving dynamic maintenance and maintaining global consistency. This application enables unified data management across multiple heterogeneous CI systems under a DevOps architecture, establishing a comprehensive solution for cross-system and global consistency at the underlying table entry level.

Description

Technical Field

[0001] This application relates to the fields of software development and operation and maintenance technology, and in particular to a web platform for data linkage and unified management of underlying table entries of multi-heterogeneous CI systems based on DevOps architecture. Background Technology

[0002] With the continuous evolution of software development models, DevOps (Development and Operations) has become an important methodology for promoting efficient collaboration between development and operations. In existing technologies, to achieve collaboration among multiple tools and systems during software development, some enterprises adopt a combination of various continuous integration (CI) and related management systems within their DevOps architectures to meet needs such as code hosting, build management, artifact storage, code quality inspection, project management, and collaborative communication. This approach is typically built upon multiple readily available independent systems (i.e., related management tools), such as code hosting platforms (GitLab), build management tools (Jenkins), artifact repositories (JFrog), code quality inspection tools (SonarQube), project management tools (Redmine), data reporting (Metebase), and enterprise collaboration platforms (DingTalk). Based on this, code hosting platforms (such as GitLab) are used to manage source code versions; build management tools (such as Jenkins) are used to execute continuous integration and automated build tasks; artifact repositories (such as JFrog Artifactory) are used to store and distribute build artifacts; code quality inspection tools (such as SonarQube) are used for static code analysis; project management tools (such as Redmine) are used to manage tasks, requirements, and defects; data analysis or visualization tools (such as Metabase) are used to generate business and technical reports; and enterprise collaboration platforms (such as DingTalk) are used for instant communication and information transfer. However, these CI systems operate independently under different technical backgrounds, and their respective data and interface designs have the following problems:

[0003] (1) Inconsistent data formats: The data standards, structures and storage methods produced by different systems are inconsistent, which makes data integration difficult;

[0004] (2) Inconsistent API interfaces: The API interface protocols, authentication methods, and calling rules provided by different systems differ significantly;

[0005] (3) Information is highly dispersed: Data for the same project is distributed across multiple platforms in different systems, making it difficult to view and analyze it globally;

[0006] (4) Inconsistent underlying table entries: For example, the same user maintains different user entities in multiple systems, with different fields and IDs that are not interoperable, resulting in complex cross-system operations and difficulty in synchronization;

[0007] (5) Dispersed configuration entry points: The underlying configuration parameters need to be maintained in multiple systems, which increases the configuration cost and the probability of errors.

[0008] Based on the above description, in the existing solution, each system operates independently, maintaining its own data storage structure and interface. The specific implementation steps include:

[0009] Each system independently collects, processes, and stores project data, such as build logs, code quality metrics, and task information.

[0010] Obtain the required data through the built-in APIs of each system or by manually exporting it;

[0011] Data from different systems can be integrated or compared manually or via scripts.

[0012] When dealing with underlying table entries such as users and projects, duplicate data across systems is manually maintained (e.g., the same user in different systems needs to be registered and assigned permissions separately).

[0013] Configuration items and parameters are set and maintained separately in different systems, lacking a globally unified configuration entry point;

[0014] If you need to call data or perform operations across multiple systems, you need to make multiple API requests to call the interfaces of each system separately.

[0015] Clearly, while existing technical solutions can meet the collaboration needs of multiple heterogeneous CI systems to a certain extent, they still lack centralized and automated solutions in areas such as data standardization, unified underlying table entries, data backfilling, and collaborative invocation of multiple systems. Summary of the Invention

[0016] To address the aforementioned issues, this application provides a web platform for data linkage and unified management of underlying table entries across multiple heterogeneous CI systems based on a DevOps architecture.

[0017] To achieve the above objectives, this application provides the following solution:

[0018] This application provides a web platform for data linkage and unified management of underlying table entries in multi-heterogeneous CI systems based on a DevOps architecture, including:

[0019] The front-end interaction layer is used to provide a visual interface and to perform data querying, configuration, analysis and processing.

[0020] The application service layer is used to implement the business logic of data linkage and unified management of underlying table entries; the application service layer includes:

[0021] The data acquisition module is used to interface with the API of the CI system using the adapter pattern, enabling automatic acquisition and parsing of data in various formats, and converting the acquired and parsed data into a unified intermediate data model.

[0022] The data unification and backfilling module is connected to the data acquisition module and is used to map the unified intermediate data model into a unified standard data structure, store it in a unified data warehouse, and backfill the data of the unified standard data structure into the CI system according to the set rules.

[0023] The underlying table entry unified management module, connected to the data unification and backfilling module, is used to establish the mapping relationship between the master data entity and the underlying table fields of each CI system. During the data flow and call process across CI systems, it is also used to automatically perform field conversion and matching based on the mapping relationship and the unified data warehouse, and supports the dynamic maintenance of the mapping relationship to maintain global consistency.

[0024] Optionally, the application service layer further includes:

[0025] The data analysis module is used to provide multi-dimensional data base items based on a unified data warehouse, and to provide various visualization reports based on third-party data reporting systems.

[0026] Optionally, the application service layer further includes:

[0027] The unified configuration management module provides an entry point for maintaining the underlying configuration table entries and automatically synchronizes configurations to the CI system, avoiding repetitive operations.

[0028] Optionally, the application service layer further includes:

[0029] The unified API gateway module provides RESTful standard API interfaces to implement authentication, rate limiting, logging, and access control.

[0030] Optionally, in terms of automatically acquiring and parsing data in multiple formats in the data acquisition module, the multiple formats include: JSON, XML and / or custom formats.

[0031] Optionally, in establishing the mapping relationship between master data entities and the underlying table fields of each CI system in the unified management module of underlying table entries, the following are included:

[0032] Define a globally unique master data topic, and combine it with the unified data warehouse to obtain the master data entity;

[0033] The mapping relationship is defined as the correspondence between the master data entity and the underlying table fields of each CI system.

[0034] Optionally, the design process for the adapter pattern includes:

[0035] Define a set of unified data acquisition interfaces;

[0036] Implement an adapter class for each CI system to adapt the CI system's API / data format to a unified interface.

[0037] Optionally, the adapter pattern is implemented using an adapter; the adapter includes:

[0038] The connector is responsible for interface calls and authentication, and supports multiple authentication methods.

[0039] A data parser is used to automatically parse data according to the data return formats of different CI systems;

[0040] A data mapper is used to transform collected and parsed data into a unified intermediate data model.

[0041] Optionally, the web platform for data linkage and unified management of underlying table entries across multiple heterogeneous CI systems based on DevOps architecture also includes:

[0042] The data processing layer is used for data processing; the data processing includes data standardization transformation, mapping transformation, cleaning, and aggregation.

[0043] The storage layer is used to maintain a unified data warehouse and mapping relationship tables;

[0044] The API gateway layer provides a unified entry point for external calls.

[0045] Optionally, the storage layer includes a relational database and a cache database.

[0046] According to the specific embodiments provided in this application, this application has the following technical effects:

[0047] This application provides a web platform for data linkage and unified management of underlying table entries across multiple heterogeneous CI systems based on a DevOps architecture. By adopting the adapter pattern, it can interface with CI systems using different technology architectures to solve the problem of inconsistent interfaces. Through the establishment of a data unification and backfilling module and an underlying table entry unified management module, the collected data is mapped to a unified standard data structure. During data flow and invocation across CI systems, it is also used to automatically perform field conversion and matching based on mapping relationships and a unified data warehouse, and supports dynamic maintenance of mapping relationships to maintain global consistency. This enables unified data management across multiple heterogeneous CI systems under a DevOps architecture, and establishes a comprehensive solution for cross-system and global consistency at the underlying table entry level, thereby solving problems such as inconsistent data standards, scattered information, inconsistent underlying table entries, and duplicate configuration entry points in DevOps heterogeneous CI systems. Attached Figure Description

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

[0049] Figure 1 A structural framework diagram of a web platform for data linkage and unified management of underlying table entries based on a DevOps architecture for multi-heterogeneous CI systems is provided in one embodiment of this application;

[0050] Figure 2 A schematic diagram of the processing flow of a data acquisition module provided in an embodiment of this application;

[0051] Figure 3 A schematic diagram of the data unification and backfilling module provided in an embodiment of this application;

[0052] Figure 4 A schematic diagram of a unified management module for underlying table entries provided in an embodiment of this application;

[0053] Figure 5 This is a schematic diagram of a unified interface call architecture provided in an embodiment of this application. Detailed Implementation

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

[0055] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0056] In one exemplary embodiment, this application provides a web platform for data linkage and unified management of underlying table entries across multiple heterogeneous CI systems based on a DevOps architecture, such as... Figure 1 As shown, this web platform includes: a front-end interaction layer, an application service layer, a data processing layer, a storage layer, and an API gateway layer. The functions of each layer are as follows:

[0057] Front-end interaction layer: Provides a visual interface, allowing users to query, configure, and analyze data from a single entry point.

[0058] Application service layer: Implements core business logic (data collection, backfilling, analysis, configuration, table item unification, etc.).

[0059] Data processing layer: responsible for data standardization, mapping, cleaning, aggregation, etc.

[0060] Storage layer: Includes relational databases and cache databases, and maintains a unified data warehouse and mapping relationship tables.

[0061] API Gateway Layer: Provides a unified entry point for external calls.

[0062] The application service layer provided in this application includes: a data acquisition module, a data unification and backfilling module, a unified management module for underlying table entries, a data analysis module, a unified configuration management module, and a unified API gateway module. The functions of each module are described below:

[0063] 1. Data acquisition module.

[0064] (1) Adopt the adapter pattern to connect to the API interfaces of CI systems with different technical systems, such as code hosting platform (GitLab), build management tool (Jenkins), artifact repository (JFrog), code quality inspection tool (SonarQube), project management tool (Redmine), data reporting (Metebase), and enterprise collaboration platform (DingTalk).

[0065] To interface with different CI / DevOps tools (i.e., CI systems), the core design principle of the Adapter Pattern is as follows:

[0066] (a) Define a set of unified data collection interfaces (unified abstraction layer), for example, by implementing the following code:

[0067] collectData() / / Retrieve data

[0068] parseData() / / Data parsing

[0069] transformData() / / Converts to an intermediate data model

[0070] (b) Implement an adapter class (adapter implementation layer) for each CI system to adapt the API / data format of that CI system to a unified interface.

[0071] Based on the adapter pattern setup described above, within the platform, only a unified CollectionService needs to be called, regardless of whether the underlying API being called is the Jenkins API or the GitLab API.

[0072] Furthermore, the adapter pattern is implemented using adapters. Each adapter includes:

[0073] 1) Connector: Responsible for API calls and authentication. Supports multiple authentication methods (HTTP Token / OAuth2 / Basic Auth / Webhook callback, etc.)

[0074] For example: the Jenkins adapter uses API Token + HTTP Basic authentication. The GitLab adapter uses Personal Access Token. The DingTalk adapter uses AppKey + Appsecret to obtain the Access Token.

[0075] 2) Data Parser: Automatically parses data according to the data return format of different systems.

[0076] For JSON, a JSON Schema validator can be used to parse and map the fields. For XML, the structure can be parsed using an XML DOM / SAX Parser. For custom formats (such as CSV / log text), regular expressions, fixed delimiters, or a custom parser can be written.

[0077] 3) Data Mapper / Transformer: Transforms the results into a unified intermediate data model. For example:

[0078] User → Unified User entity (including global user ID).

[0079] Build logs → Unified PipelineLog entity.

[0080] Project → Project entity.

[0081] (2) Implement automatic data collection and parsing in multiple formats (JSON / XML / custom formats). The complete data collection and parsing process is illustrated using GitLab (JSON interface) and Jenkins (XML / JSON hybrid interface) as examples:

[0082] 1) The GitLab adapter acquisition process includes:

[0083] (a) Client calls platform → Platform calls GitLabAdapter.collectData().

[0084] (b) The Connector sends an HTTP GET request to the GitLab API ( / projects / :id / events), carrying the Token.

[0085] (c) The API returns JSON, and the corresponding implementation code is as follows:

[0086] {

[0087] "id":123,

[0088] "title":"Fix bug",

[0089] "author":{"id":45,"name":"Alice"},

[0090] "created_at":"2024-06-01T12:00:00Z"

[0091] }

[0092] (d) The Parser automatically parses JSON fields.

[0093] (e) The Mapper maps the author to a global UserID and converts it into a unified CommitEvent entity. The corresponding implementation code can be described as follows:

[0094] {

[0095] "global_user_id":"U100045",

[0096] "event_type":"commit",

[0097] "timestamp":"2024-06-01T12:00:00Z",

[0098] "content":"Fix bug"

[0099] }

[0100] 2) The Jenkins adapter data collection process is as follows:

[0101] (a) Call JenkinsAdapter.collectData().

[0102] (b) The Connector requests the latest build information from the JenkinsJobAPI ( / job / xxx / api / xml) and returns XML;

[0103] (c) The parser uses Dom4j or SAX to parse XML. The implementation code is as follows:

[0104] <build>

[0105] <number> 120< / number>

[0106] <result> SUCCESS< / result>

[0107] <timestamp> 1717278400000< / timestamp>

[0108] < / build>

[0109] (d) The Mapper is converted into a unified PipelineRun entity, and its implementation code is as follows:

[0110] {

[0111] "pipeline_id":"P123456",

[0112] "run_number":120,

[0113] "status":"success",

[0114] "timestamp":"2024-06-01T10:30:00Z"

[0115] }

[0116] (3) Convert the collected and parsed data into a unified intermediate data model (IDM), that is, map data of different formats in various CI systems to a unified intermediate data model. Specifically, all collected data is ultimately converted into an intermediate data model, for example:

[0117] User: {global_user_id, name, email, role, ...}

[0118] Project: {global_project_id, repo_url, owner, ...}

[0119] PipelineRun: {pipeline_id, run_number, status, timestamp, ...}

[0120] These intermediate data models are stored in a unified data warehouse (MongoDB) to serve as the data foundation for subsequent backfilling, table mapping, and analysis.

[0121] Based on the above description, the implementation process of the data acquisition module is as follows: Figure 2 As shown. Among them, the CI systems such as code hosting platform (GitLab), build management tool (Jenkins), artifact repository (JFrog), code quality inspection tool (SonarQube), project management tool (Redmine), data reporting (Metebase), and enterprise collaboration platform (DingTalk) can correspond to... Figure 2 External systems A, B, and C.

[0122] 2. Data unification and backfilling module.

[0123] The data unification and backfilling module maps the collected data into a unified standard data structure and stores it in a unified data warehouse (such as MongoDB).

[0124] The data unification and backfilling module enables bidirectional data synchronization, backfilling unified data into the original CI system according to set rules to ensure data consistency across CI systems. It also provides the ability to directly view the backfilling results in the original CI system, allowing users to easily access the corresponding data directly.

[0125] Based on the above description, the implementation process of the data unification and backfilling module is as follows: Figure 3 As shown. Multiple CI systems can correspond to... Figure 3 The system A and system B are shown.

[0126] 3. Unified management module for underlying table entries.

[0127] The underlying table entry unified management module is based on a unified data warehouse and defines globally unique master data topics, such as user tables, project tables, and pipeline tables.

[0128] The underlying table entry unified management module assigns a unique identifier (Global ID) to each global entity and establishes a mapping relationship between it and the fields of the underlying tables in each system. In other words, the mapping relationship establishes a correspondence between the master data entity and the fields of the underlying tables in each system. For example:

[0129] Globally unique user ID ↔ GitLab user table ID.

[0130] Globally unique user ID ↔ Jenkins user table ID.

[0131] During the data flow and retrieval process across CI systems, the underlying unified table entry management module supports automatic field conversion and matching. That is, it automatically converts and matches fields through mapping relationships to achieve automatic ID mapping during cross-system data flow.

[0132] The underlying table entry unified management module supports dynamic maintenance of the underlying table entry mapping relationship. When any system experiences a change in the user / project / task field, the mapping is automatically updated to maintain global consistency.

[0133] As an optional implementation, the structure of the underlying unified table entry management module provided in this application is as follows: Figure 4 As shown, the underlying unified management process for table entries can be described as follows:

[0134] (1) The web platform uses a unified user master table (Customer Table) to store the mapping relationship, which includes all unique user IDs, unified usernames, role information, etc.

[0135] (2) Establish multiple sets of mapping relationship tables, for example:

[0136] user_mapping_gitlab: Stores the mapping between global user IDs and GitLab user IDs.

[0137] user_mapping_jenkins: Stores the mapping between global user IDs and Jenkins user IDs.

[0138] (3) When a cross-CI system task allocation or data update is initiated, the CI system automatically looks up the mapping relationship based on the current global user ID and calls the corresponding system API to perform the operation.

[0139] (4) When adding, deleting or modifying user information, the synchronization of multiple CI systems is achieved through mapping relationships.

[0140] 4. Data Analysis Module.

[0141] The data analysis module provides multi-dimensional data base tables based on a unified data warehouse.

[0142] The data analysis module is based on the third-party data reporting system Metabase, which can provide a variety of visual reports (project progress, quality, construction status, etc.) to facilitate decision-making and optimization.

[0143] 5. Unified configuration management module.

[0144] The unified configuration management module is based on a unified data warehouse, provides basic tables for multi-dimensional data analysis, and provides an entry point for unified maintenance of underlying configuration tables.

[0145] The unified configuration management module, combined with visual reporting tools (such as Metabase), generates various reports (project progress, quality indicators, construction status, etc.) to assist management decisions and automatically synchronize configurations to the system, avoiding repetitive operations.

[0146] 6. Unified API Gateway Module.

[0147] The unified API gateway module provides RESTful style standard APIs to the outside world.

[0148] The unified API gateway module integrates API management capabilities such as authentication, access control, rate limiting, and logging to achieve authentication, rate limiting, logging, and access control.

[0149] When connecting to external systems, the unified API gateway module provides a unified data access point through the API gateway, enabling CI systems to quickly access unified data.

[0150] like Figure 5 As shown, the process of unified interface calling can be described as follows: The CI system calls the unified API, for example, to obtain all task data associated with a project. The API gateway requests → queries the unified data warehouse → generates a unified format response according to the mapping rules → returns to the caller.

[0151] In another exemplary embodiment of this application, as an alternative to the data acquisition module, in addition to directly connecting to the APIs of each CI system using the adapter pattern, the change data pushed by each CI system can also be received through message middleware (such as Kafka, RabbitMQ, ActiveMQ).

[0152] As an optional implementation, a file monitoring mechanism (such as FTP / SFTP / NFS directory monitoring) can be connected to obtain data files exported by various CI systems.

[0153] As an optional implementation, for CI systems that support direct database connections, data can be obtained directly through the database query interface.

[0154] In another exemplary embodiment of this application, as an alternative to data storage and standardization, in addition to using MongoDB as the unified data warehouse, other types of databases, such as relational databases (e.g., MySQL, PostgreSQL), can also be used as the unified data warehouse.

[0155] As an optional implementation method, the data standardization process can be completed during the data acquisition phase or postponed to the data query phase through real-time mapping.

[0156] In another exemplary embodiment of this application, as an alternative to the underlying table entry mapping management, the mapping logic can be embedded in the API gateway layer to dynamically complete ID conversion and matching during interface calls.

[0157] As an alternative implementation, for CI systems with high access requirements, a cryptographic hash mapping method can be used to hide the real ID and use only the mapping value for cross-CI system association.

[0158] In another exemplary embodiment of this application, as an alternative to the data analysis module, in addition to using Metabase, other BI platforms (such as Grafana, Superset, Power BI, etc.) can be combined to generate visual analysis reports.

[0159] As an optional implementation, the data analysis logic can be embedded in the platform's web front end, returning aggregated data by calling a unified API.

[0160] In another exemplary embodiment of this application, as an alternative to the unified configuration and API gateway, in addition to providing a unified configuration entry point on the web, unified configuration management capabilities can also be provided through command line tools (CLI) or API clients.

[0161] As an optional implementation method, in addition to token verification, authentication methods can also use security protocols such as two-way TLS, OAuth 2.0, and JWT.

[0162] Based on the above description, this application provides an end-to-end processing chain that includes "data acquisition based on multiple heterogeneous CI systems → data standardization → unified management of underlying table entries → bidirectional data synchronization and backfilling → configuration management → data analysis → API gateway for external invocation." Compared with existing technologies, this application has the following advantages:

[0163] I. This application achieves data standardization and centralized management of multiple heterogeneous CI systems through mapping, conversion, and dynamic update algorithms between IDs / fields of different CO systems.

[0164] Second, by establishing a globally unified set of underlying table entries, such as user tables and project tables, this application can eliminate the inconvenience of inconsistencies in fields across CI systems and the hassle of identity switching.

[0165] Third, this application can support bidirectional data synchronization through data backfilling and synchronization rule calculation, thereby improving data consistency and timeliness among multiple systems.

[0166] Fourth, this application simplifies the integration process by providing unified authentication for API calls, a unified configuration management entry point, and API standards.

[0167] V. This application can improve the full-link visualization and data analysis capabilities of DevOps by setting the batch automated synchronization logic of attributes or configuration items, and support the optimization of management decisions.

[0168] VI. The mapping relationship in this application is dynamically updated, which can adapt to changes in system fields and has strong scalability.

[0169] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0170] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (RRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM).

[0171] The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0172] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0173] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A web platform for data linkage and unified management of underlying table entries in multi-heterogeneous CI systems based on DevOps architecture, characterized in that, include: The front-end interaction layer is used to provide a visual interface and to perform data querying, configuration, analysis and processing. The application service layer is used to implement the business logic of data linkage and unified management of underlying table entries; the application service layer includes: The data acquisition module is used to interface with the API of the CI system using the adapter pattern, enabling automatic acquisition and parsing of data in various formats, and converting the acquired and parsed data into a unified intermediate data model. The data unification and backfilling module, connected to the data acquisition module, is used to map the unified intermediate data model to a unified standard data structure, store it in a unified data warehouse, and backfill the data of the unified standard data structure to the CI system according to set rules; it provides the ability to directly view the backfilling results in the original CI system, making it convenient for users to view the corresponding data directly in the original CI system; The underlying table entry unified management module, connected to the data unification and backfilling module, is used to establish the mapping relationship between the master data entity and the underlying table fields of each CI system. During the data flow and call process across CI systems, it is also used to automatically perform field conversion and matching based on the mapping relationship and the unified data warehouse, and supports the dynamic maintenance of the mapping relationship. When any system experiences changes in user / project / task fields, the mapping is automatically updated to maintain global consistency.

2. The web platform for data linkage and unified management of underlying table entries based on DevOps architecture for multi-heterogeneous CI systems as described in claim 1, characterized in that, The application service layer also includes: The data analysis module is used to provide multi-dimensional data base items based on a unified data warehouse, and to provide various visualization reports based on third-party data reporting systems.

3. The web platform for data linkage and unified management of underlying table entries based on DevOps architecture for multi-heterogeneous CI systems as described in claim 1, characterized in that, The application service layer also includes: The unified configuration management module provides an entry point for maintaining the underlying configuration table entries and automatically synchronizes configurations to the CI system, avoiding repetitive operations.

4. The web platform for data linkage and unified management of underlying table entries based on DevOps architecture for multi-heterogeneous CI systems as described in claim 1, characterized in that, The application service layer also includes: The unified API gateway module provides RESTful standard API interfaces to implement authentication, rate limiting, logging, and access control.

5. The web platform for data linkage and unified management of underlying table entries based on DevOps architecture for multi-heterogeneous CI systems as described in claim 1, characterized in that, In terms of the data acquisition module, it can automatically acquire and parse data in various formats, including JSON, XML and / or custom formats.

6. The web platform for data linkage and unified management of underlying table entries based on DevOps architecture for multi-heterogeneous CI systems according to claim 1, characterized in that, In establishing the mapping relationship between master data entities and the underlying table fields of each CI system in the unified management module of underlying table entries, the following are included: Define a globally unique master data topic, and combine it with the unified data warehouse to obtain the master data entity; The mapping relationship is defined as the correspondence between the master data entity and the underlying table fields of each CI system.

7. The web platform for data linkage and unified management of underlying table entries based on DevOps architecture for multi-heterogeneous CI systems according to claim 1, characterized in that, The design process for the adapter pattern includes: Define a set of unified data acquisition interfaces; Implement an adapter class for each CI system to adapt the CI system's API / data format to a unified interface.

8. The web platform for data linkage and unified management of underlying table entries based on DevOps architecture for multi-heterogeneous CI systems according to claim 7, characterized in that, The adapter pattern is implemented using an adapter; the adapter includes: The connector is responsible for interface calls and authentication, and supports multiple authentication methods. A data parser is used to automatically parse data according to the data return formats of different CI systems; A data mapper is used to transform collected and parsed data into a unified intermediate data model.

9. The web platform for data linkage and unified management of underlying table entries based on DevOps architecture for multi-heterogeneous CI systems according to claim 1, characterized in that, The web platform for data linkage and unified management of underlying table entries in multi-heterogeneous CI systems based on DevOps architecture also includes: The data processing layer is used for data processing; the data processing includes data standardization transformation, mapping transformation, cleaning, and aggregation. The storage layer is used to maintain a unified data warehouse and mapping relationship tables; The API gateway layer provides a unified entry point for external calls.

10. The web platform for data linkage and unified management of underlying table entries based on DevOps architecture for multi-heterogeneous CI systems according to claim 9, characterized in that, The storage layer includes a relational database and a cache database.

Images