Data processing method and device for AI code generation scenario, and computing device

Abstract

The embodiment of the specification provides a data processing method and device for an AI code generation scene and computing equipment, the method comprises the following steps: receiving first code data and a first session identifier input by an artificial intelligence code generation party; determining a first code snapshot based on the first code data, and generating a first version number for the first code snapshot; and establishing an association relationship among the first code snapshot, the first session identifier and the first version number, so as to realize the standardized management and version tracing of the code data for the AI code generation scene.

Description

Technical Field

[0001] This specification relates to the field of artificial intelligence technology, and in particular to a data processing method, apparatus and computing device for AI code generation scenarios. Background Technology

[0002] With breakthroughs in artificial intelligence technologies such as Large Language Models (LLM), the ability to generate code with AI assistance or autonomously has continuously improved, and the quality and complexity of generated code have reached a level suitable for practical software development projects. In such AI-generated code scenarios (hereinafter referred to as AI code generation), the code generator typically generates code based on dialogue and interaction with the user. The code data generated in a single dialogue session often constitutes a relatively complete code version, and the user will initiate multiple rounds of dialogue around the same application to iteratively optimize the generated code.

[0003] In traditional software development processes, code version management typically relies on a Version Control System (VCS). This system identifies and manages code versions through code changes submitted by developers (e.g., commits in Git). It then integrates with Continuous Integration and Continuous Deployment (CI / CD) pipelines to build, test, and release the code. A version control system uses code changesets as the basic unit of a version, recording the changes made, the commit time, and the committer information, thus forming the code's change history.

[0004] However, applying the traditional version management methods described above to AI code generation scenarios has certain limitations. For example, traditional version control systems use code change sets as version units, paying little attention to the contextual information of the code generation process itself. In AI code generation scenarios, multiple rounds of dialogue within the same application often correspond to different code iteration directions and design intentions. Recording versions solely through code changes makes it difficult to effectively link code data with the dialogue sessions that generated the code, resulting in insufficient traceability of code versions. Furthermore, in AI code generation scenarios, the code data provided by the code generator often includes complete, full code. The code data generated in each dialogue session logically constitutes an independent code version. Traditional version control systems, which model version using incremental changes (i.e., code change sets as version units), differ from the version management requirements for this type of full code data.

[0005] Therefore, in the R&D process for AI-driven code generation scenarios, how to provide an improved data processing method to achieve standardized management and version traceability of code data has become an urgent problem to be solved. Summary of the Invention

[0006] This specification provides one or more embodiments of a data processing method, apparatus, and computing device for AI-generated code scenarios, so as to achieve standardized management and version traceability of code data for AI-generated code scenarios.

[0007] Based on the first aspect, a data processing method for AI-generated code scenarios is provided, including:

[0008] Receive the first code data and the first session identifier from the AI ​​code generator;

[0009] A first code snapshot is determined based on the first code data, and a first version number is generated for the first code snapshot;

[0010] Establish the association between the first code snapshot, the first session identifier, and the first version number.

[0011] According to the second aspect, a data processing device for AI-generated code scenarios is provided, comprising:

[0012] The first receiving module is configured to receive the first code data and the first session identifier transmitted by the artificial intelligence code generator;

[0013] The first determining module is configured to determine a first code snapshot based on the first code data;

[0014] The first generation module is configured to generate a first version number for the first code snapshot;

[0015] A module is established and configured to establish an association between the first code snapshot, the first session identifier, and the first version number.

[0016] According to a third aspect, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method described in the first aspect.

[0017] According to a fourth aspect, a computing device is provided, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements the method described in the first aspect.

[0018] According to the method, apparatus and computing device provided in the embodiments of this specification, a first code data and a first session identifier are received from an artificial intelligence code generator; a first code snapshot is determined based on the first code data, and a first version number is generated for the first code snapshot; an association relationship is established between the first code snapshot, the first session identifier and the first version number, and an association relationship of "dialogue session-application version" is established, so as to realize standardized management and version traceability of code data for AI code generation scenarios. Attached Figure Description

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

[0020] Figure 1 This is a schematic diagram of the structure of a data processing system for AI-driven code generation scenarios disclosed in this specification.

[0021] Figure 2 A schematic diagram of a data processing method for AI-generated code scenarios provided in this embodiment;

[0022] Figure 3 This is another flowchart illustrating a data processing method for AI-generated code scenarios provided in this embodiment.

[0023] Figure 4 A schematic diagram of state machine state transitions provided in this embodiment;

[0024] Figure 5 This is a schematic diagram of a handling process for an abnormal situation in the execution node Job provided in this embodiment;

[0025] Figure 6 A schematic diagram illustrating the rollback process provided for an embodiment;

[0026] Figure 7 This is a schematic block diagram of a data processing device for AI-generated code scenarios provided in an embodiment. Detailed Implementation

[0027] The technical solutions of the embodiments of this specification will now be described in detail with reference to the accompanying drawings.

[0028] It is understood that before or during the use of the technical solutions of the various embodiments in this disclosure, users will be informed of the type, scope of use, and usage scenarios of the personal information involved in an appropriate manner in accordance with relevant laws and regulations, and user authorization will be obtained.

[0029] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose, based on the prompt message, whether to provide personal information to the software or hardware such as electronic devices, applications, servers, or storage media performing the operations of this disclosed technical solution.

[0030] As an optional but not limited implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0031] It is understood that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.

[0032] In this specification, the Large Language Model (LLM) may also be referred to simply as the Large Model. A Large Language Model is a natural language processing model based on deep learning techniques, typically with billions to hundreds of billions or even more parameters, possessing powerful language understanding and generation capabilities. Large Language Models can employ the Transformer architecture or its variants (such as GPT, BERT, etc.), which utilizes an attention mechanism to globally model sequential data, efficiently handling long-distance dependencies and thus performing exceptionally well in natural language tasks. Large Language Models learn the statistical features and semantic relationships of language through pre-training on large-scale corpora, giving them good generalization capabilities. The core capabilities of Large Language Models include, but are not limited to: understanding contextual semantics, generating coherent and grammatically correct text, performing logical reasoning, and handling multi-task scenarios. Its usage typically includes two modes: direct inference and fine-tuning. In direct inference mode, the user guides the Large Language Model to generate specific outputs by designing prompts. Cue words can be task descriptions or instructions in text form, used to stimulate the semantic understanding and generation capabilities of large language models. In fine-tuning mode, large language models are further trained on small-scale datasets in specific domains to optimize their performance on specific tasks. The powerful generalization ability and flexibility of large language models make them an important tool in the field of artificial intelligence, providing efficient and accurate solutions for automated text generation and understanding.

[0033] In some embodiments, large language models can also understand and generate data from other modalities (such as visual and audio data). In this case, large language models can also be called multimodal large language models (MLLMs). MLLMs provide a richer and more natural interactive experience by integrating multiple types of input and output, such as text, images, and sound. The core advantage of MLLMs lies in their ability to process and understand information from different modalities and fuse this information to complete complex tasks. For example, MLLMs can analyze an image and generate descriptive text, or generate a corresponding image based on a text description. This cross-modal understanding and generation capability makes MLLMs widely applicable across multiple fields.

[0034] It should be noted that the key technologies of large language models can be found in the detailed description in the paper "A Survey of Large Language Models" (paper number: arXiv:2303.18223v16, published on March 11, 2025), and will not be repeated here.

[0035] The following section will first introduce the definitions of terms used in the embodiments of this specification.

[0036] Pipeline: An execution engine that links multiple stages (build, test, deployment, etc.) in the software (code) delivery process into an automated workflow. Pipeline instance: A specific, independent execution process generated based on the pipeline definition for a specific triggering event (such as code release).

[0037] Job: The smallest execution unit in the pipeline, corresponding to the specific execution stage in the orchestration and release process (such as build compilation, approval, quality inspection, resource deployment, release, etc.).

[0038] Trigger: The mechanism that drives the state transition of nodes in the pipeline. It notifies the orchestrator of the execution status of the execution node through methods such as message notification and interface callback, and triggers external conditions of the state machine (such as approval, rejection, cancellation, breakpoint retry, etc.).

[0039] A rollback ticket contains information about the rollback operation, which records the rollback of online resources to the previous successfully released and stable version of code (software) when a version of code (code snapshot) fails to be released or an online anomaly occurs.

[0040] Domain Model: An abstract model of business concepts (applications, versions (code snapshots), release orders, etc.) and their relationships.

[0041] With the breakthrough development of artificial intelligence technologies such as Large Language Models (LLM), the ability to generate code using AI-assisted or autonomous methods has been continuously improving, and the quality and complexity of generated code have reached a level suitable for practical software development projects. In such AI-generated code (hereinafter referred to as AI code generation) scenarios, the AI ​​code generator typically generates code data based on dialogue and interaction with the user. The user initiates multiple rounds of dialogue around the same application to iteratively optimize the generated code data, and the code data generated in each round of dialogue often constitutes a relatively complete code version. In view of this, embodiments of this specification disclose a data processing method, apparatus, and computing device for AI code generation scenarios to achieve standardized management and version traceability of code data.

[0042] The data processing method, apparatus, and computing device for AI code generation scenarios provided in this specification will be described in detail below with reference to specific embodiments.

[0043] Figure 1 This diagram illustrates an implementation scenario of an embodiment disclosed in this specification. In this implementation scenario, a schematic diagram of the structure of a data processing system for an AI code generation scenario is exemplarily shown. The data processing system includes a data processing device and multiple AI code generators (such as…). Figure 1 (As shown in the diagram: AI code generator 1, AI code generator 2, ..., AI code generator N).

[0044] Among them, each AI code generator can refer to a software platform or device that can interact with users and generate code data based on a large language model. The programming language type and / or software architecture of the code data generated by different AI code generators may be different or the same.

[0045] For example, such as Figure 1 As shown, the data processing device includes a standardized access interface (Open API) layer and a domain model layer. Each AI code generator communicates with the data processing device through the standardized access interface layer, for example, by calling the interfaces provided by the standardized access interface layer to send code data and corresponding session identifiers to the data processing device.

[0046] Accordingly, the data processing device receives code data X1 and the corresponding session identifier S from any AI code generator i through a standardized access interface layer. Here, code data X1 is the full set of code data generated during the dialogue session corresponding to session identifier S; session identifier S is used to identify the dialogue session corresponding to the code generation process. In some embodiments, session identifier S can be used to identify a complete dialogue session that generates code data X1. In other embodiments, session identifier S can be used to identify the dialogue within a complete dialogue session that generates the code data X1.

[0047] Understandably, this large language model can be a large model capable of code generation with any architecture. It can be, but is not limited to, a large language model based on a Transformer architecture or a large language model based on a decoder-only architecture.

[0048] In some possible examples, any AI code generator i may pass in code data X1 and the corresponding session identifier S, along with corresponding service basic configuration information and application identifier (APP identifier). The service basic configuration information indicates the deployment method and access scope adopted after the code data X1 is published; the application identifier uniquely identifies an application entity. In some cases, a corresponding user identifier may also be passed in, which is the identifier of the user who initiated the AI ​​code generation operation (hereinafter referred to as the generation operator).

[0049] In some possible examples, the standardized access interface layer serves as the interface hub between the AI ​​code generator and the data processing device. It has built-in functional components such as parameter verification, multi-tenant authentication, multi-tenant data isolation, unified open interface (equivalent to the subsequent standardized interface), and logging.

[0050] The parameter validation component can perform format and integrity checks on the various data input by the AI ​​code generator based on predefined data validation rules (e.g., data validation based on AJV Schema) to ensure that the input data meets the preset data structure requirements.

[0051] The multi-tenant authentication component is used to authenticate and verify the identity and permissions of the caller initiating the interface call request (such as the AI ​​code generator, the aforementioned generation operator, and the version release operator mentioned later, where the generation operator and version release operator may be the same or different), confirming that the caller has legitimate system access permissions. It is understood that each caller can trigger an interface call request to the unified open interface provided by the standardized access interface layer to use services provided by the data processing device (such as version creation service, release order creation service, and rollback service).

[0052] In one possible implementation, the AI ​​code generator automatically initiates an interface call request as the caller after the code data is generated (to pass the code data and session identifier to the data processing device); in another possible implementation, the generation operator or version release operator triggers the operation through the front-end interface, and the corresponding client device sends the interface call request as the caller (e.g., to pass the code data and session identifier to the data processing device, or to trigger a release order creation request, trigger a rollback request, etc.).

[0053] Multi-tenant data isolation components are used to ensure that data between different AI code generators (i.e., different tenants) is isolated from each other during storage and processing, avoiding data crosstalk.

[0054] The unified open interface provides a standardized API access channel for AI code generators, enabling different AI code generators to interact with data processing devices through a unified interface protocol. This unified interface protocol specifies the data transmission format (e.g., using a data transmission format based on HTTP / HTTPS protocols) and the data carrier format (e.g., specifying that the code data transmitted by each AI code generator is in a predefined format, such as, but not limited to, JSON, multipart / form-data, compressed package format, and code snapshot format).

[0055] Through this unified interface protocol, AI code generators with different architectures and technologies can encapsulate their internally generated code data and session identifiers (as well as other data that needs to be passed in) into standard data packets that conform to this unified interface protocol, and then interact with data processing devices through a standardized API access channel.

[0056] The standardized access interface layer described above can shield the heterogeneity of the underlying data structures of various AI code generators, enabling data processing devices to receive and process code data from multiple sources using a unified parsing logic, thus achieving system scalability and compatibility.

[0057] The logging component is used to audit and record information such as API call time, caller ID, and operation type.

[0058] After receiving code data X1 and the corresponding session identifier S from the AI ​​code generator i, the standardized access interface (Open API) layer passes the data to the domain model layer. The domain model layer receives the code data X1 and the corresponding session identifier S from the standardized access interface (Open API) layer and determines a code snapshot based on the code data X1. Specifically, the domain model layer parses and persists the code data X1, generating a structured code snapshot entity (i.e., the code snapshot). This code snapshot entity records the complete content and characteristics of the code data X1 at the time of generation.

[0059] The domain model layer also generates a version number V1 for code snapshots. In one implementation, the domain model layer generates this version number V1 by incrementing the number of times code data under the same application identifier is passed in. Specifically, the domain model layer determines the application identifier to which the code data X1 belongs, queries the maximum number of code snapshots or version numbers generated under that application identifier, and generates the version number V1 by incrementing based on that number or maximum value.

[0060] After generating the code snapshot and version number V1, the domain model layer establishes an association between the code snapshot, the session identifier S, and the version number V1. Specifically, the domain model layer creates an association record in its internal data storage structure, binding the identification information of the code snapshot (such as the corresponding content fingerprint or a unique identifier assigned by the domain model layer), the session identifier S, and the version number V1 together, forming a three-layer association: First, the association between the code snapshot and the version, where each code snapshot corresponds to a version number, used to identify the position of the code snapshot in the application iteration history; second, the association between the session identifier S and the application, used to bind the dialogue session that generated the code to its respective application entity; and third, the association between the version and the application, used to assign the version number to the corresponding application entity. Through the establishment of the above three-layer association, bidirectional traceability can be achieved from the dialogue session to the code version (i.e., the application version) and from the code version to the code snapshot.

[0061] In this data processing system, the standardized access interface (Open API) layer provides a unified, standardized interface protocol that is independent of the specific AI code generation party's technical implementation. Each AI code generation party does not need to concern itself with the internal implementation details of the domain model layer; they only need to input data in the agreed-upon format according to the interface specifications defined by the standardized access interface (Open API) layer to complete the integration process (including subsequent code data version association and release). Simultaneously, the parameter validation function built into the standardized access interface (Open API) layer can adapt to the format differences of data input from different AI code generation parties, ensuring the structural consistency of the input data. Multi-tenant authentication and multi-tenant data isolation functions ensure that when multiple AI code generation parties share the same data processing equipment, their data and permissions are independent and do not interfere with each other. Furthermore, the unified open interface design means that adding a new AI code generation party does not require customized modifications to the data processing equipment; the caller only needs to initiate an interface call according to the standard interface specifications to complete the integration, significantly reducing the development cost and operational complexity of the integration process after different AI code generation parties have joined.

[0062] In some possible examples, such as Figure 1 As shown, the data processing device also includes an orchestrator. In response to a release order creation operation triggered by a code snapshot, the domain model layer creates a release order corresponding to the code snapshot and passes the code snapshot and its release order to the orchestrator.

[0063] The orchestrator constructs the corresponding pipeline instance based on the node configuration information in the release order and the predefined pluggable node pool; and drives the execution of each execution node in the pipeline instance through a state machine, completes code processing based on code snapshots, and obtains the release result.

[0064] The above process establishes a "dialogue session-application version" relationship, enabling standardized management and version traceability of code data for AI-driven code generation scenarios. It also allows for the automated release of code snapshots for any version corresponding to a dialogue session. By constructing a decoupled orchestrator and domain model layer, it automates the entire process from code generation to deployment, resolving issues such as broken links, high coupling, and insufficient flexibility in pipeline instance configuration.

[0065] Figure 2 This diagram illustrates a data processing method for an AI-driven code generation scenario according to one embodiment of this specification. The method is executed by the aforementioned data processing device. This data processing device can be implemented using any apparatus, device, platform, or device cluster with computing and processing capabilities.

[0066] like Figure 2As shown, the data processing for AI-driven code generation scenarios may include the following steps S210-S240:

[0067] In step S210, the first code data and the first session identifier are received from the AI ​​code generator.

[0068] Among them, AI code generators refer to software platforms or devices that can interact with users based on large language models and generate code data, such as AI code generation tools and AI programming assistants.

[0069] The first session identifier is used to identify the dialogue session corresponding to the code generation process. In some specific examples, the first session identifier can be a globally unique string, generated and maintained by the AI ​​code generator when establishing the dialogue session. This first session identifier can serve as a traceability identifier for the code generation process.

[0070] In one possible implementation, a session identifier is used to identify a complete dialogue session. A complete dialogue session includes multiple rounds of interaction between the generation operator and the AI ​​code generator. Within this session, the generation operator may initiate multiple code generation requests, each generating a version of the code data. These different versions of the code data share the same session identifier. This session identifier allows tracing back to all code versions generated throughout the entire dialogue session. Accordingly, a first session identifier is used to identify the complete dialogue session that generated the first set of code data.

[0071] In another possible implementation, a session identifier is used to identify a specific interaction within a complete dialogue session. For each round of dialogue initiated by the operator within the dialogue session (one round corresponds to one code generation requirement), the AI ​​code generator generates a corresponding session identifier for that round. This session identifier allows for precise tracing back to a specific dialogue (i.e., a specific code generation requirement).

[0072] In the above embodiments, the session identifier may include two parts: a first sub-identifier representing the entire dialogue session process (the session identifiers of all code data in the dialogue session process contain this first sub-identifier, wherein different dialogue session processes have different first sub-identifiers, for example, dialogue session processes generated by different operators, or dialogue session processes generated for different applications, have different first sub-identifiers); and a second sub-identifier representing the specific dialogue corresponding to the code data. For any code data, the first sub-identifier in its corresponding session identifier can uniquely identify the dialogue session process that generated the code data, and the second sub-identifier in its corresponding session identifier can uniquely identify the specific dialogue corresponding to the code data within the dialogue session process that generated the code data.

[0073] Correspondingly, the first session identifier is used to identify the specific dialogue in a complete dialogue session that generates the first code data.

[0074] First-round code data refers to the code data generated in a single dialogue round. In AI code generation scenarios, the code data generated by the AI ​​code generator in a single dialogue typically constitutes a relatively complete code set. Accordingly, first-round code data can be the full code data, containing all code files and their contents generated in that round of dialogue. The format of first-round code data can be diverse; for example, it can be a compressed package containing multiple files, or it can be a structured data format (such as JSON format) containing code text and its file path structure information.

[0075] In some possible examples, the first code data may also carry other auxiliary information, such as the identification information of the AI ​​code generator, the identification of the large language model used to generate the first code data, the context summary of the dialogue session, or the metadata of the first code data (such as the programming language type, software architecture type, and checksums of each code file (used to verify integrity)).

[0076] In some possible examples, step S210 can be specifically set as follows: receiving first code data and first session identifier passed in by the AI ​​code generator through a standardized interface.

[0077] In some examples, standardized interfaces (equivalent to the aforementioned unified open interface) may include application creation interfaces, application version creation interfaces, and release order creation interfaces.

[0078] In one possible implementation, an application creation interface is used to create a new application entity and associate it with a session identifier. The AI ​​code generator or other caller calls the application creation interface, passing parameters such as the application name, application description, and session identifier to the data processing device. The data processing device creates the application (entity), which includes the corresponding application identifier, establishes the association between the application identifier and the session identifier, and returns the application identifier to the AI ​​code generator or other caller. Subsequently, when the AI ​​code generator passes code data and the session identifier to the application, it also passes the application identifier.

[0079] In another possible implementation, the AI ​​code generator or other caller calls the application creation interface and passes parameters such as application identifier, application description, and session identifier to the data processing device. The data processing device then creates the application entity and establishes the association between the application identifier and the session identifier.

[0080] AI code generators can call the application version creation interface, pass in the application identifier, full code data, and session identifier to the data processing device, and trigger subsequent processing. The data processing device generates the corresponding code snapshot and version number, and returns the version number.

[0081] The Create Release Form interface is used to create release forms and trigger pipeline execution. The caller (such as the subsequent version release personnel, AI code generators, or other staff) calls the Create Release Form interface, passing in the version number (of the code snapshot to be released) and node configuration information. The data processing equipment builds and starts the pipeline instance.

[0082] Through the standardized interfaces described above, AI code generators can complete the entire process from code generation to deployment using a unified API, eliminating the need to write adaptation code for different DevOps systems and significantly reducing integration costs. Understandably, the standardized interfaces may also include interfaces that support triggering rollback requests, interfaces that support triggering breakpoint retry requests, and so on, for callers to utilize the corresponding services.

[0083] Then, in step S220, a first code snapshot is determined based on the first code data.

[0084] A code snapshot is a persistent representation of code data at a specific moment, used to record the complete content and characteristics of the code data at that moment, that is, to record the complete state of the code data at that moment. In some possible implementations, step S220 may include the following steps 11-14;

[0085] In step 11, based on the encapsulation format of the first code data, the first code data is standardized or its integrity is verified to obtain the data to be stored.

[0086] Specifically, when the first code data is passed in with different encapsulation formats, the data processing device performs format recognition and decapsulation on the first code data, and extracts the code files and their directory structure information.

[0087] Understandably, for first code data with different encapsulation formats, the data processing device can perform differentiated decapsulation processing. For example, when the first code data uses a structured data format, such as JSON serialized data, the data processing device performs parsing operations on the JSON serialized data. Specifically, the data processing device deserializes the JSON serialized data according to a preset JSON Schema, extracting the code text content and corresponding file path fields of each code file to obtain the code file content. During this process, the data processing device verifies whether the field structure of the JSON object conforms to the preset JSON Schema definition, ensuring the completeness and correctness of the extracted code text content and corresponding file path fields. Specifically, the data processing device parses and reconstructs the file path fields of each code file, identifying hierarchical relationships based on delimiters, thereby deriving the directory structure information corresponding to each code file.

[0088] For example, when the first code data is in a compressed archive format, such as a ZIP archive, the data processing device performs a decompression operation on the ZIP archive. Specifically, the data processing device identifies the compression algorithm used in the ZIP archive (e.g., Deflate or Store algorithm), decompresses each file in the archive according to the corresponding decompression algorithm, and extracts each code file and its directory structure information to obtain the code file content. During the decompression process, the data processing device handles filename encoding compatibility issues, such as performing correct conversion between UTF-8 encoding and GBK encoding, to ensure that the file path information in the extracted directory structure information can be correctly identified and stored by the target storage medium.

[0089] After decapsulation, the data processing device can standardize the decapsulated first code data, such as unifying the delimiter format of file paths, standardizing the file encoding format, or removing invisible control characters, to generate data to be stored in a uniform format.

[0090] In some implementations, if the initial code data input by the AI ​​code generator has already undergone preprocessing and standardization, the data processing device skips the standardization process and directly performs integrity checks to achieve content-level integrity verification of the standardized code data. This integrity check includes, for example, verifying whether the hash checksums of each code file in the initial code data match the checksums recorded in the metadata, checking for corrupted or missing code files, and verifying whether the total size of the initial code data is within a preset upper limit. If the integrity check passes, the data processing device uses the initial code data as data to be stored; if the integrity check fails, the data processing device generates an error response and sends it back to the AI ​​code generator.

[0091] Then, in step 12, the data to be stored is stored to a preset target storage medium, and a physical resource path identifier pointing to the storage location of the data to be stored is generated.

[0092] For example, the target storage medium can be an object storage system, a distributed file system, or other high-capacity persistent storage medium. During the storage process, the data processing device stores the data to be stored in the preset target storage medium, obtains its storage location, and generates a physical resource path identifier for that storage location. This physical resource path identifier can be used to locate the storage location in subsequent read, deployment, or rollback operations to further obtain the data to be stored.

[0093] In step 13, a content fingerprint is generated based on the data to be stored. The content fingerprint is a unique identifier for the data to be stored and can be used to quickly identify and compare content differences between different code snapshots. In some possible examples, the content fingerprint can be obtained by performing a hash calculation on the data to be stored. For instance, the data processing device arranges all code files contained in the data to be stored according to a predetermined sorting rule, calculates the hash value of each code file sequentially, and then concatenates the hash values ​​of all code files in order and performs an overall hash calculation to obtain a content fingerprint representing the entire data to be stored. This hash algorithm can be SHA-256 or other secure cryptographic hash algorithms.

[0094] Next, in step 14, a first code snapshot is instantiated, whereby the first code snapshot includes a content fingerprint and a physical resource path identifier. Instantiation refers to creating a code snapshot based on the information obtained from the aforementioned processing. The first code snapshot includes the aforementioned content fingerprint and physical resource path identifier. In addition, the first code snapshot may also carry other metadata information, such as the creation timestamp of the first code snapshot, the total volume of the first code data, or the number of code files. Through the above process, the first code data input by the AI ​​code generator can be converted into a structured, persistent code snapshot, providing a data foundation for the first code data in subsequent version management, release, rollback, and other operations.

[0095] In another specific implementation, the process of determining the first code snapshot based on the first code data may also include the following processing steps. First, the data processing device performs syntax parsing on each code file contained in the first code data, generating a corresponding Abstract Syntax Tree (AST). An AST is a structured tree representation of a code file, organizing the syntax elements in the code file into nodes and edges, thus reflecting the logical structure of the code rather than simply the text content. In some possible examples, the data processing device can select the corresponding parser based on the programming language type of each code file to parse the code file into an AST. For multiple code files contained in the first code data, the data processing device generates its own AST for each, forming a set of ASTs.

[0096] Then, the data processing device extracts code structure features based on the abstract syntax tree set. These features characterize the organization and complexity of the initial code data from a structural perspective. Specifically, the data processing device statistically analyzes metrics such as the total number of nodes in the abstract syntax tree set, the maximum tree depth, the number of function definition nodes, the number of class declaration nodes, and the number of control flow branch nodes. These structural features can be used in subsequent version comparisons to determine the degree of difference in code structure between two code snapshots without requiring a line-by-line comparison of the code text.

[0097] Next, the data processing device generates a structure hash value based on the set of abstract syntax trees (ASTs). Specifically, the data processing device performs normalization encoding on the AST corresponding to each code file, that is, converts the AST of each code file into a linear string representation according to a predetermined traversal order, and performs a hash calculation on this string representation to obtain the structure hash value of the corresponding code file. Subsequently, the data processing device performs a global hash calculation on the structure hashes of all code files in the first code data, arranges them in lexicographical order according to the file paths, concatenates them, and performs an overall hash calculation to obtain a structure hash value representing the structural characteristics of the entire code data. This structure hash value can be used to quickly determine whether there are changes in the code logical structure between two code snapshots, without being affected by non-structural differences such as code formatting, comments, and whitespace characters.

[0098] Finally, the data processing device instantiates a first code snapshot. In this implementation, the instantiated first code snapshot includes an abstract syntax tree set, code structure features, and a structure hash value representing the overall code data structure. Furthermore, the first code snapshot can also simultaneously carry the content fingerprint and physical resource path identifier mentioned above, to retain both the storage location information and code structure information of the code data. The first code snapshot determined through this implementation can not only be used for persistent storage and subsequent deployment of code data, but also provide structural-dimensional data support for structural comparison between code versions, code quality analysis, and assessment of the impact of code changes.

[0099] After obtaining the first code snapshot, in step S230, a first version number is generated for the first code snapshot.

[0100] In some possible examples, while receiving the first code data and the first session identifier from the AI ​​code generator, the data processing device also receives the corresponding first application identifier from the AI ​​code generator. Accordingly, step S230 may include the following steps: incrementally generating a first version number based on the number of code data already transmitted under the first application identifier.

[0101] Specifically, the application identifier is used to uniquely identify an application entity. This first application identifier is the identifier of the application to which the first code data belongs. In AI code generation scenarios, an application typically corresponds to a software project or a functional module. Users may initiate multiple dialogue sessions around the same application, and each dialogue session generates a version of the code data. Accordingly, the generation of the version number needs to be associated with the application identifier to ensure that the version number under each application has an independent incrementing sequence.

[0102] When the data processing device receives the first code data, it determines the first application identifier to which the first code data belongs. In some examples, this first application identifier can be assigned when the AI ​​code generator creates the application and is transmitted along with each piece of code data sent to the data transmission device. After determining the first application identifier, the data processing device queries the maximum value of the number of code data already transmitted under that first application identifier (i.e., the number of code snapshots already generated under that first application identifier) ​​or the version number. Based on this maximum value, it increments the first version number. For example, if the number of code data transmissions transmitted under that first application identifier is 3, meaning there are already three code snapshots under that first application identifier, such as version one, version two, and version three, then the data processing device increments the first version number of the first code data transmitted this time to version four; if there are no code snapshots under that first application identifier (i.e., the number of code data transmitted under that first application identifier is 0), then the data processing device sets the first version number to the initial version, i.e., version one.

[0103] By generating version numbers based on the incremental number of imported code data under the same application identifier, it is possible to ensure that the version number is consistent with the actual iteration history of the application, allowing users to intuitively understand which iteration of the application the imported code data belongs to through the version number.

[0104] In some other possible examples, the data processing device may also use a semantic versioning mechanism to generate the first version number for the first code snapshot. A semantic version number typically consists of three parts: a major version number, a minor version number, and a revision number. The major version number indicates a major incompatible change, the minor version number indicates a backward-compatible functional addition, and the revision number indicates a backward-compatible bug fix.

[0105] In AI-generated code scenarios, the semantic version number can be determined by combining the difference analysis results between code snapshots. Specifically, after the data processing device receives the first code data and generates the first code snapshot, it compares the first code snapshot with the previous code snapshot under the application identifier to determine the level of code change. In some possible implementations, the determination of the code change level can be achieved in the following ways: First, the data processing device compares the code structure features between the two code snapshots to obtain the magnitude of changes in their structural features, such as changes in the number of function definitions, the number of class declarations, and the number of control flow branches; second, the data processing device compares the content fingerprints between the two code snapshots to determine the proportion of differences at the code text level; finally, based on the magnitude of changes in structural features and the proportion of differences at the code text level, the data processing device determines the code change level according to predefined change level judgment rules.

[0106] The change level determination rules are set as follows: when the change in structural features exceeds a first preset threshold and the difference ratio at the code text level exceeds a second preset threshold, the data processing device determines it as a major change, increments the major version number, and resets the minor version number and revision number to zero (first code change level); when the change in structural features does not exceed the first preset threshold but the difference ratio at the code text level exceeds the second preset threshold, the data processing device determines it as a functional addition, increments the minor version number, and resets the revision number to zero (second code change level); when neither the change in structural features nor the difference ratio at the code text level exceeds the above thresholds, the data processing device determines it as a bug fix, and increments the revision number (third code change level).

[0107] After determining the specific code change level, the data processing device generates a first version number based on the previous version number, according to the incrementing rules corresponding to the change level. If there is no previous version number for the application identifier, the data processing device sets the first version number as the initial semantic version number. This semantic version number generation mechanism allows version numbers to not only reflect the order of application iterations but also intuitively represent the scope of impact of each code change, providing richer version semantic information for subsequent version management, release strategy formulation, and rollback target selection.

[0108] Through the above processing, the data processing device converts the first code data input by the AI ​​code generator into a structured first code snapshot, and assigns a first version number corresponding to the application iteration history to the first code snapshot, providing a data foundation for establishing the association between the first code snapshot, the first session identifier and the first version number.

[0109] In some possible examples, the data processing device can also feed back the generated first version number to the AI ​​code generator, so that the AI ​​code generator can display the first version number in the session interface corresponding to the first session identifier. Specifically, in the session interface corresponding to the first session identifier, the first version number can be displayed corresponding to the dialogue (content) of the first code data.

[0110] Next, in step S240, the association between the first code snapshot, the first session identifier, and the first version number is established. In this step, the data processing device associates the first code snapshot, the first session identifier, and the first version number to form a complete version tracing chain.

[0111] In some possible examples, the data processing device can create a version record in a specified database. This version record contains the identification information of the first code snapshot, the first session identifier, and the first version number. Through this version record, the data processing device binds together the code content represented by the first code snapshot, the dialogue session that generated the code content, and the version number of the code content in the application iteration history. The identification information of the first code snapshot can be the aforementioned content fingerprint.

[0112] In one implementation, the aforementioned relationships can be represented using an entity relationship model (also known as a domain model). Here, the application entity serves as the top-level management unit, and one application entity can be associated with multiple version entities. Each version entity corresponds to a code version generated during an AI code generation interactive dialogue. Version entities and code snapshots have a one-to-one binding relationship; that is, each version entity is bound to one code snapshot. Simultaneously, version entities are also associated with session management information under the application entity through session identifiers, allowing users to trace the code version corresponding to a given dialogue session using the session identifier.

[0113] By establishing the aforementioned relationships, the data processing device can achieve bidirectional traceability from dialogue sessions to code versions and from code versions to code snapshots. On the one hand, when it is necessary to view the code content generated by a particular dialogue session, the data processing device can quickly locate the corresponding code snapshot through the session identifier; on the other hand, when it is necessary to trace which dialogue generated a certain code version, the data processing device can reverse-engineer the corresponding session identifier through the version number. This structured association mechanism effectively solves the semantic gap problem of traditional version management systems in AI code generation scenarios, making code version management closely integrated with the contextual information of dialogue sessions.

[0114] In the above process, the data processing device converts the code data input by the AI ​​code generator into a code snapshot, generates a version number corresponding to the application's iteration history for the code snapshot, and then establishes a relationship between the code snapshot, session identifier, and version number, realizing standardized management and version traceability of code data in AI code generation scenarios. This process effectively solves the technical problem of traditional version control systems, which use code change sets as version units and cannot effectively associate code data with the dialogue session that generated the code data. It tightly integrates code version management with the context information of the dialogue session, reducing the cost of manual intervention in code management and release processes.

[0115] In some possible examples, when it is necessary to review the session data (i.e., the corresponding dialogue, or the corresponding code generation requirement) corresponding to a certain code version (such as the code version bound to the first code snapshot), the data processing device responds to the review request for the session data corresponding to the first code snapshot (the review request may carry the first version number), determines the first session identifier corresponding to the first code snapshot based on the aforementioned established association, and feeds back the first session identifier to the reviewer so that the reviewer can find the session data corresponding to the first code snapshot based on the first session identifier. This review request can be initiated by the code management platform or the review system. When the reviewer finds a potential problem in a certain code version (i.e., code snapshot), they can quickly locate the context information of the dialogue session that generated the corresponding code snapshot through this association, thereby completing the code review work more efficiently.

[0116] In some possible examples, such as Figure 3 As shown, the method also includes a release process for code data of a specific version, which may include the following steps S310-S330:

[0117] In step S310, in response to the release order creation request triggered for the first code snapshot, a release order corresponding to the first code snapshot is created. Furthermore, in step S320, based on the node configuration information in the release order and a predefined pluggable node pool, a corresponding pipeline instance is constructed, wherein the pipeline instance contains several execution nodes selected from the pluggable node pool based on the node configuration information.

[0118] After generating the first code snapshot and establishing the version association, a release operation can be initiated for the first code snapshot to deploy the code content represented by the first code snapshot to the target environment (i.e., a production environment).

[0119] A release order is an entity used to record and manage a release operation. When a release order creation request for the first code snapshot is received, the data processing device (through the aforementioned domain model layer) creates a new release order and associates it with the first code snapshot (also known as the code version bound to the first code snapshot). The release order creation request can be triggered by the version release personnel through the front-end interface, or it can be automatically triggered by calling the interface provided by the aforementioned standardized access interface layer (such as the release order creation interface that supports the creation of release orders, or the createAppPublish interface).

[0120] When a release order is created, the data processing device (through the aforementioned domain model layer) determines the node configuration information corresponding to that release order. The node configuration information defines the pipeline steps that need to be executed in this release. A pre-defined pluggable node pool contains various types of execution nodes, each representing a processing step in the pipeline. Execution nodes can be divided into two categories: mandatory execution nodes and optional execution nodes. Mandatory execution nodes include code injection nodes, code building and compilation nodes, resource deployment nodes, and release and deployment nodes; these nodes are indispensable steps in each release. Optional execution nodes include quality check nodes, approval process nodes, and custom hook nodes, which users can selectively enable according to their actual needs.

[0121] In some possible examples, when the data processing device receives the first code data and the first session identifier from the AI ​​code generator, it can also simultaneously receive the corresponding service deployment configuration information, or the node configuration information of the release order may include the corresponding service deployment configuration information. This service deployment configuration information indicates the resource deployment method corresponding to the first code snapshot, enabling the data processing device to guide the resource deployment process in subsequent pipeline instances based on this information. The service deployment configuration information also indicates the access scope of the first code snapshot after successful release. Accordingly, the resource deployment node can select the corresponding deployment execution strategy based on the service deployment infrastructure type and configure corresponding access control rules based on the access scope identifier.

[0122] For example, service deployment configuration information may include a service deployment infrastructure type and an access scope identifier. The service deployment infrastructure type indicates the deployment format that the first code data should adopt upon publication. In some specific instances, the service deployment infrastructure type may include at least one of a container deployment type, a Content Delivery Network (CDN) deployment type, and a cloud resource deployment type.

[0123] When the service deployment infrastructure type is container deployment, this indicates that the service corresponding to the first code data should be deployed in a containerized manner. Accordingly, subsequent code build and compilation nodes need to compile the code content of the corresponding first code snapshot into a compiled artifact suitable for containerized deployment. Subsequent resource deployment nodes need to deploy the compiled artifacts output by the code build and compilation nodes in a containerized manner.

[0124] When the service deployment infrastructure type is CDN deployment, this type indicates that the service corresponding to the first code data should be distributed via a content delivery network. Accordingly, subsequent code build and compilation nodes need to compile the code content of the corresponding first code snapshot into compiled artifacts that can be distributed via the content delivery network (e.g., compiling the code content of the first code snapshot into static resource files). Subsequent resource deployment nodes need to distribute and deploy the compiled artifacts output by the code build and compilation nodes via the content delivery network.

[0125] When the service deployment infrastructure type is cloud resource deployment, this type indicates that the service corresponding to the first code data should be deployed to a cloud server instance. Accordingly, subsequent code build and compilation nodes need to compile the code content of the corresponding first code snapshot into a compilation artifact that can be deployed to the cloud server instance (e.g., compiling the code content of the first code snapshot into an executable file or deployment package). Subsequent resource deployment nodes need to deploy the compilation artifacts output by the code build and compilation nodes to the cloud server instance.

[0126] In some other possible implementations, the service deployment infrastructure type and access scope can be configured through a release order during subsequent code releases. If the service deployment infrastructure type is not explicitly specified by the AI ​​code generator or in the release order, the data processing device can automatically infer the appropriate service deployment infrastructure type based on the programming language type and software architecture type of the first code data.

[0127] The access scope identifier is used to indicate the accessibility scope of the service corresponding to the first code data after successful publication. In some examples, the access scope identifier may include at least one of the following: accessible within a specified department, accessible within a specified organization, and publicly accessible.

[0128] When the access scope is identified as accessible only within a specified department, this access scope identifier indicates that the published service will only be open to users within that specific department. Specifically, after resource deployment, the data processing device configures access control policies to restrict access to the service to user identity tokens under a specific department identifier, or to restrict access to the service to IP addresses within a specific department's network segment.

[0129] When the access scope is identified as accessible only within a specified organization, this access scope identifier indicates that the published service will be open to users across the entire organization. Specifically, the data processing device is configured with organization-level unified identity authentication, enabling all registered users within that organization to access the service while denying access requests from outside the organization.

[0130] When the access scope is marked as publicly accessible, this access scope indicates that the published service is open to the public, and any end user with a service access address can access it. Specifically, the data processing device configures the service's access endpoint to be publicly accessible.

[0131] Upon receiving the service deployment configuration information, the data processing device (through its domain model layer) also associates this information with the first code snapshot or the release order mentioned later. When the resource deployment node of the subsequent pipeline instance is executed, it reads this service deployment configuration information, selects the corresponding deployment execution strategy based on the service deployment infrastructure type, and configures the corresponding access control rules based on the access scope identifier. In this way, the data processing device can convey the deployment intent of the AI ​​code generator throughout the entire chain from code input to final deployment, avoiding the need for users to manually specify deployment methods and access permissions during the deployment phase, further reducing the manual intervention cost from code generation to service deployment in AI code generation scenarios.

[0132] In some examples, the functions of each execution node are described below:

[0133] The code injection node is used to inject code data from the first code snapshot into the runtime environment of the pipeline instance. Specifically, based on the physical resource path identifier contained in the first code snapshot, the code injection node reads the corresponding code data from the target storage medium and decompresses it to the pipeline instance's temporary working directory, providing code input for subsequent build and compilation stages. After execution, the code injection node outputs a completion notification and the path information of the temporary working directory.

[0134] The code build and compilation node is used to compile and package the code data injected into the temporary working directory, generating deployable compiled artifacts. The code build and compilation node supports direct transfer of local compiled artifacts and also supports calling remote build and compilation services.

[0135] Code build and compilation nodes can include multiple nodes set up for different programming languages ​​and software architectures. For example, code build and compilation nodes may include, but are not limited to, code build and compilation nodes for Java, which generally compile code data based on the Maven or Gradle toolchain; and code build and compilation nodes for Node.js-based front-end projects, which compile code data based on the npm or yarn toolchain.

[0136] The data processing device provides its orchestrator with the ability to select the appropriate code build / compile node based on the programming language type and software architecture of the code snapshot to be compiled. Alternatively, the code build / compile node can directly invoke the corresponding tools and dependency manager based on the programming language type and software architecture of the transmitted code snapshot to be compiled.

[0137] The code build and compilation node can determine the build strategy and artifact type based on the service deployment infrastructure type carried in the release order (or the service deployment configuration information provided by the AI ​​code generator along with the code data), and obtain the corresponding compilation artifacts. When the service deployment infrastructure type is container deployment, the code build and compilation node performs regular compilation and packaging, and obtains the corresponding compilation artifacts.

[0138] Through the above configuration method, multiple code build and compilation nodes in the pluggable node pool are adapted to the differences in underlying toolchains of different programming language types and software architectures, and the build strategy is dynamically adjusted according to the deployment goal to ensure that the output compilation artifacts are seamlessly connected with the subsequent deployment process.

[0139] After the code build and compilation node completes its execution, it outputs the storage path of the compilation artifact and the hash value of the build artifact, so that subsequent execution nodes can retrieve the compilation artifact.

[0140] Resource deployment nodes are used to deploy the compiled artifacts generated by the code build and compilation nodes to the target environment. Specifically, resource deployment nodes determine the service deployment infrastructure type and access scope identifier corresponding to the first code data based on the service deployment configuration information carried in the release order (or the service deployment configuration information passed in by the AI ​​code generator along with the code data).

[0141] When the service deployment infrastructure type is container deployment, the resource deployment node, based on the compilation artifacts of the code build and compilation node, calls the container build tool to execute the container image build, generating a container image containing application code and runtime environment. This container image is then pushed to the container image repository, followed by the creation of a container instance, deployment of the container image into the container instance, and configuration of the container instance's network access policy to complete the deployment. Container deployment is suitable for services that require an independent runtime environment and elastic scaling capabilities.

[0142] When the service deployment infrastructure type is Content Delivery Network (CDN) deployment, the resource deployment nodes upload the compilation artifacts (including static resource files) output by the code build and compilation nodes to the object storage bucket and configure the CDN acceleration domain name to point to that object storage bucket. The CDN nodes cache the static resource files on edge nodes, allowing end users (users accessing the first code snapshot after release) to obtain resources from the nearest edge node, thereby reducing access latency. CDN deployment is suitable for scenarios such as front-end web applications or purely static websites.

[0143] When the service deployment infrastructure type is cloud resource deployment, the resource deployment node creates or reuses a cloud server instance through the orchestrator according to the preset cloud server configuration parameters (these parameters may be included in the node configuration information). The compilation artifacts (including executable files or deployment packages) output by the code build and compilation node are then transferred to this cloud server instance, and the corresponding service processes are started. Cloud resource deployment is suitable for scenarios requiring specific runtime environment configurations or direct manipulation of underlying operating system resources.

[0144] After the resource deployment node completes its execution, it outputs deployment status information and service access address, which the release and launch node can then use to release and launch the corresponding service.

[0145] The deployment node is used to switch deployed services to an externally accessible state after the resource deployment node has completed deployment. Specifically, driven by triggers and a state machine, the deployment node obtains deployment status information from the resource deployment node, confirming that the resource deployment node has completed deployment and that the deployment status is successful. When the deployment status is confirmed as successful, the deployment node executes the corresponding deployment operation based on the service deployment infrastructure type.

[0146] When the service deployment infrastructure type is container deployment, the deployment node calls the service deployment interface of the container orchestration system to register the newly deployed container instance to the service registry center and switch traffic from the old version container instance to the new version container instance.

[0147] When the service deployment infrastructure type is Content Delivery Network deployment type, the deployment node refreshes the cached data on the Content Delivery Network node, enabling the edge node to obtain the latest version of the static resource file.

[0148] When the service deployment infrastructure type is cloud resource deployment type, the published and online nodes update the load balancing configuration or domain name resolution records to route external access traffic to the new version of the service process.

[0149] After the deployment operation is completed, the deployment node updates the status of the corresponding version to "successfully deployed" and synchronizes the deployment completion status to the domain model layer. When the deployment status is confirmed as failed, the state machine sets the status of the deployment node to "rejected" to prevent the failed service from providing services to the outside world.

[0150] The quality check node is used to perform automated quality and safety checks on code snapshots and / or compilation artifacts. Specifically, the quality check node can invoke code scanning tools to perform static code analysis on code snapshots, detecting issues such as code style violations, potential security vulnerabilities, and outdated dependency versions. The quality check node can also invoke dependency auditing tools to perform license compliance checks and security vulnerability scans on third-party dependencies referenced in the project. When the quality check node detects a blocking-level security vulnerability or compliance issue, its status changes from running to rejected, and a quality check report is generated for user review. When the quality check node does not detect a blocking-level issue, its status changes from running to completed.

[0151] Approval process nodes are used to introduce a manual approval step during pipeline instance execution. Specifically, driven by a trigger, the approval process node changes its state from "running" to "waiting" and sends an approval notification to a pre-defined approver. The approval notification may include supplementary information such as a code change summary, version number, and quality inspection report for the approver's reference. The approver makes an approval decision on the request through a front-end interface or API call. When the approver approves, an asynchronous callback trigger changes the approval process node's state from "waiting" to "completed," continuing to drive subsequent execution nodes. When the approver rejects the approval, the approval process node's state changes to "rejected," and the pipeline instance is interrupted accordingly.

[0152] Custom hook nodes are used to trigger user-defined operations during pipeline instance execution. Specifically, custom hook nodes allow users to insert custom processing logic at any point during pipeline instance execution by configuring custom scripts or webhook addresses. For example, users can configure a deployment notification sending operation in a custom hook node to send a deployment result notification to an instant messaging tool or email system after resource deployment is complete. Custom hook nodes can also be configured to execute test cases, automatically running smoke tests or API tests after resource deployment to verify whether the deployed service is functioning correctly. After executing a user-defined operation, the custom hook node sets its status to either "complete" or "rejected" based on the execution result.

[0153] Data processing equipment can flexibly combine various execution nodes according to the node configuration information of the release order to form a pipeline instance that adapts to user needs.

[0154] Understandably, the release order carries the first version number of the first code snapshot. The node configuration information also includes configuration information related to the execution of each execution node during the release process. For specific configuration details, please refer to the relevant technical documentation for the configuration of the execution stages corresponding to each execution node; these details will not be elaborated upon here.

[0155] In some examples, when a release administrator needs to create a release order, they can dynamically specify the optional execution nodes to be enabled by adding node parameters (such as the `additionalNodes` parameter, which is a parameter specifying the input node configuration information predefined by the standardized access interface layer). The data processing device (which can be accessed through the aforementioned domain model layer) selects the corresponding execution nodes from the pluggable node pool based on the node configuration information in the release order, and constructs the corresponding pipeline instance based on the preset dependencies between the execution nodes.

[0156] In some specific examples, the process of building the pipeline instance in step S320 may include the following steps 21-22: In step 21, the corresponding execution node is selected from the predefined pluggable node pool according to the node configuration information in the release form.

[0157] In some examples, after the data processing device (through the domain model layer) has created a release order for the first code snapshot, it can pass the release order and the identification information of the first code snapshot to the orchestrator of the data processing device. The data processing device then selects the corresponding execution node from a predefined pool of pluggable nodes based on the node configuration information in the release order.

[0158] For mandatory execution nodes, the data processing device (through its orchestrator) selects all by default; for optional execution nodes, the data processing device (through its orchestrator) selects the enabled execution node identifier based on the node configuration information.

[0159] Next, in step 22, a pipeline instance is constructed based on the pre-defined dependencies between the execution nodes. Specifically, the data processing device (through its orchestrator) sorts the selected execution nodes based on the pre-defined dependencies, determining the execution order of each node in the pipeline. For example, the code injection node executes before the code build / compile node, the code build / compile node executes before the resource deployment node, and the resource deployment node executes before the release / launch node. For optional execution nodes, their dependencies can be predefined according to the node type; for example, the quality check node and the approval process node both execute before the resource deployment node, and the quality check node executes before the approval process node, etc. Through the sorting of pre-defined dependencies, the data processing device (through its orchestrator) generates an ordered pipeline instance in which the execution order of each execution node is determined.

[0160] In some possible examples, the aforementioned predefined pluggable node pool may include multiple build / compile nodes set up for various programming language types and software architectures (each build / compile node is configured with the tools and dependency manager used to build and compile code snapshots for the corresponding programming language type and software architecture); for example, the pluggable node pool may contain build / compile nodes for programming language A1 and software architecture B1, build / compile nodes for programming language A1 and software architecture B2, build / compile nodes for programming language A2 and software architecture B3, build / compile nodes for programming language A3 and software architecture B4, etc. The programming language types may include, but are not limited to, Java, Python, etc., and the software architecture may include, but is not limited to, front-end frameworks.

[0161] Accordingly, when selecting the corresponding execution node from the pluggable node pool in step 21, the data processing device (through its orchestrator) selects the corresponding first build / compile node from the pluggable node pool based on the programming language type and software architecture of the first code data (i.e., the first code entity). This programming language type and software architecture information can be provided by the AI ​​code generator when the first code data is input, or it can be determined through automatic analysis of the first code data. By setting build / compile nodes separately for different programming language types and software architectures, it can be ensured that pipeline instances can adapt to diverse code projects, improving the system's versatility and scalability.

[0162] Once the pipeline instance is built, its node configuration is locked to ensure consistency during execution.

[0163] After obtaining the pipeline instance, in step S330, the execution of each execution node in the pipeline instance is driven by the state machine, the code processing is completed based on the first code snapshot, and the release result is obtained.

[0164] In some possible implementations, the state machine defines six states: initialization, running, waiting, completion, cancellation, and rejection. After the pipeline instance starts, the state transitions of each execution node are driven by both the state machine and triggers.

[0165] Specifically, the first execution node in the pipeline instance is first set to an initialization state (e.g., ...). Figure 4 The "initialization" state shown is transitioned to the running state and execution begins under the drive of the trigger (as shown). Figure 4 The "Running" status is shown. When an execution node executes successfully, its status changes from the running state to the completed state (e.g., ...). Figure 4The trigger, indicating a "completed" status, immediately notifies the data processing device (the orchestrator) to schedule the next execution node (such as...). Figure 4 The process of transitioning from the initial state to the running state (as shown in the "flow to the next Job") continues until all execution nodes have completed and a release result indicating that the first code snapshot has been successfully published is obtained.

[0166] For nodes in the approval process that require manual intervention, their status can be changed to a waiting state after execution (e.g., ...). Figure 4 The "waiting" state indicates that the process is awaiting the reviewer's action. Once approved, an asynchronous callback trigger notifies the state machine of the approval. Correspondingly, the state machine responds by changing the state of the approval process node from the waiting state to the completed state (e.g., ...). Figure 4 The "Completed" status shown indicates that the process continues to drive subsequent execution nodes (such as...). Figure 4 The message "Transfer to the next Job" is shown. The review failed (e.g., ...). Figure 4 When the approval process is rejected ("approval rejected"), an asynchronous callback trigger notifies the state machine of the failure to approve. Correspondingly, the state machine changes the state of the approval process node from the waiting state to the rejected state (e.g., ...). Figure 4 (As shown in the "Reject" state), the pipeline instance is interrupted or canceled accordingly, that is, the release process for the first code snapshot is interrupted or canceled.

[0167] In some examples, while awaiting reviewer action, if the release administrator triggers a cancellation of the release for the first code snapshot, the data processing device notifies the state machine via a trigger to cancel the approval. The corresponding state machine then changes the status of the approval process node from the waiting state to the cancelled state (e.g., ...). Figure 4 The "Cancelled" status shown indicates that the pipeline instance has been cancelled (i.e., the release result of the first code snapshot release failed).

[0168] In some examples, the status of this approval process node changes from a waiting state to a rejected state (e.g.) Figure 4 Following the "Reject" state shown, during the pipeline instance interruption, if the release administrator triggers a re-execution of the approval process node, the data processing device will notify the state machine via a trigger to change the approval process node from the Reject state to the Initialization state, and then, after initialization, to the Running state, and so on. Alternatively, during the aforementioned pipeline instance interruption, if the release administrator triggers a cancellation release, for the release of the first code snapshot, the data processing device will notify the state machine via a trigger to change the state of the approval process node from the Reject state to the Cancelled state (e.g., ...). Figure 4 The "Cancelled" status shown indicates that the pipeline instance has been cancelled.

[0169] In some possible examples, during the execution of a pipelined instance, the data processing device persistently records the configuration information of each execution node through a checkpoint mechanism. When any execution node encounters an error, the data processing device resets the state of that execution node to its initial state based on the checkpoint mechanism to perform a breakpoint retry.

[0170] Specifically, the checkpointing mechanism records and persistently stores the input parameters, environment variables, dependent resources, and other configuration information of each execution node at the start of execution. That is, the data processing device (through its domain model layer) records and persistently stores this configuration information through the checkpointing mechanism. When any execution node fails due to network anomalies, insufficient resources, or other temporary errors, a trigger notifies the orchestrator. The orchestrator, based on the configuration information of the execution node (the execution node with execution failure) recorded through the checkpointing mechanism and obtained from the domain model layer, notifies the state machine through the trigger to reset the execution node's state from the abnormal state to the initial state (e.g., ...). Figure 4 As shown, if an execution node encounters an error in the "Running" state, it will be reset to the "Initialized" state via an error retry, and execution will be retried. The above process implements breakpoint retry for each execution node in the pipeline instance. This breakpoint retry mechanism can prevent the entire pipeline instance from failing due to temporary errors, thus improving the robustness of pipeline instance execution.

[0171] In another scenario, when an exception in an execution node cannot be resolved through retries, the trigger notifies the orchestrator to perform an exception circuit breaker operation, interrupting the execution of the pipeline instance and cascading the cancellation of any execution nodes that have not yet been executed.

[0172] In some possible examples, when any execution node encounters an exception, the data processing device can also capture the exception information of this exception through the state machine (corresponding to, for example...). Figure 5 As shown in S01), it notifies the orchestrator (corresponding to, for example, the data processing device) via a trigger (S01). Figure 5 As shown in S04-S05, after the orchestrator of the (data processing device) receives the exception information, it passes it to the domain model layer of the (data processing device) (corresponding to, for example, ...). Figure 5 As shown in S06, the domain model layer reports this exception information to the version release personnel to notify them of the execution exception of the execution node (corresponding to, for example, S06). Figure 5 As shown in S06, the release personnel decide whether to retry the breakpoint or cancel the current pipeline instance (i.e., cancel the release process of the first code snapshot).

[0173] If the release personnel choose to retry the breakpoint (by triggering the retryAppPublish interface provided by the standardized access interface layer to send a breakpoint retry request), the corresponding domain model layer responds to the breakpoint retry request and, based on the checkpoint mechanism, determines the configuration information of the execution node that recorded the execution exception (corresponding to, for example...). Figure 5 As shown in S08); the domain model layer passes this configuration information to the trigger through the orchestrator. The trigger then notifies the state machine of the configuration information of the execution node with the execution exception, driving the execution node with the execution exception to transition from the running state to the initialization state (corresponding to, as shown in S08). Figure 5 As shown in S09-S11, the configuration information of the execution node that experienced the execution error is re-initialized, and then the execution continues from the execution node that experienced the execution error.

[0174] If the release personnel decide to cancel this pipeline instance (i.e., cancel the release process of the first code snapshot) (by triggering the cancelAppPublish interface provided by the standardized access interface layer to send a breakpoint cancellation request), the corresponding domain model layer responds to the cancellation request and passes it to the trigger through the orchestrator. The trigger then notifies the state machine to transition the state of the execution node that caused the exception from the running state to the canceled state (corresponding to...). Figure 5 (S12-S14 shown). Then, the state machine notifies the orchestrator via triggers to update the status of the corresponding release order from "released" to "release failed," recording the cancellation reason (e.g., cancellation due to execution node execution exception) (corresponding to... Figure 5 (S15-S17 shown); and notify the domain model layer of the corresponding release order failure. The domain model layer records the status of the corresponding release order failure (i.e., obtains the release result of the first code snapshot release failure).

[0175] In some instances, after the state machine captures the exception information, it also records the exception log (corresponding to, for example...). Figure 5 As shown in S02), the execution node is kept in a running state (corresponding to, as shown in S02). Figure 5 (As shown in S03). The exception log can then be passed to the domain model layer so that it can manage the exception log.

[0176] In the aforementioned process, the data processing device, having completed the generation of code snapshots and the establishment of version associations, further realizes a complete release process from code snapshots to release results. Through a pluggable node pool and node configuration information-driven dynamic orchestration of pipeline instances, pipeline stages can be flexibly configured according to release requirements, adapting to diverse scenarios ranging from rapid personal deployment to compliant enterprise releases. Through the collaborative driving of state machines and triggers, the data processing device achieves fine-grained management of the pipeline execution node lifecycle, supporting complex execution scenarios such as approval waiting, circuit breaking for exceptions, and breakpoint retries, thereby improving the reliability and flexibility of pipeline execution.

[0177] In some possible examples, after the release result indicates that the first code snapshot has been successfully released, its functional services can be provided externally. In the process of providing these services, the method may further include the following steps 31-33:

[0178] In step 31, during the process of successfully providing services after the first code snapshot is published, in response to the rollback request, a code snapshot with the same application identifier as the first code snapshot, the latest version number, and a status marked as successfully published and stable is found and used as the rollback code snapshot.

[0179] In step 32, based on the rollback code snapshot and its corresponding release, a corresponding rollback pipeline instance is constructed.

[0180] In step 33, the execution of each execution node in the rollback pipeline instance is driven by the state machine to complete the rollback deployment of online resources.

[0181] Specifically, a rollback request can be initiated by the release administrator or other staff when they discover a problem with the code version being provided in service (i.e., the first code snapshot) after the current release has been successfully completed (running successfully online). Figure 7 (S41 in the original text). After receiving a rollback request, the data processing device (through its domain model layer) first determines the application identifier (i.e., the first application identifier) ​​targeted by the rollback request. Next, among all code snapshots under this first application identifier, the data processing device (through its domain model layer) searches for a code snapshot with a relatively recent version number that meets the following two conditions: first, the release status corresponding to this code snapshot is marked as successfully released, meaning that this code version has been successfully deployed to the production environment; second, the status of this code snapshot is marked as stable, meaning that this code version has not been marked as unstable after running online for a period of time. Through the above search logic, the data processing device (through its domain model layer) automatically determines a reliable code snapshot as the rollback code snapshot (corresponding to S41 in the original text). Figure 7 (S42 in the text).

[0182] In some instances, after determining the rollback code snapshot, the data processing device (through its domain model layer) also creates a rollback order and associates it with the source release order (i.e., the release order corresponding to the first code snapshot). Figure 7 S43 in the rollback form is used to record the metadata of this rollback operation. This rollback form can at least record the version number of the rollback code snapshot, and may also record information such as the rollback timestamp.

[0183] Then, the data processing device (through its domain model layer) finds the release order associated with the rollback code snapshot. It then sends the rollback code snapshot and its corresponding release order to the data processing device (its orchestrator). Based on the rollback code snapshot and its corresponding release order, the data processing device (through its orchestrator) constructs the corresponding rollback pipeline instance (see the aforementioned process of constructing the pipeline instance of the first code snapshot for details), and executes it through a state machine, such as... Figure 7 As shown in S44 and S45.

[0184] In some possible instances, the execution nodes of the aforementioned constructed rollback pipeline instance can be simplified relative to the normal release pipeline instance (the rollback code snapshot). For example, the data processing device (through its domain model layer) omits the quality check and approval process nodes in the corresponding release order, retaining only the build and compilation nodes and resource deployment nodes to speed up the rollback. The execution process of the rollback pipeline instance is consistent with the pipeline instance execution process described above. The data processing device drives the state transitions of each execution node through a state machine and triggers to complete the rollback deployment of online resources.

[0185] Through the aforementioned rollback mechanism, the data processing equipment can achieve precise rollback based on version traceability, eliminating the need for manual investigation of the target version and manual execution of rollback operations, thus significantly shortening the recovery time after a release failure.

[0186] The foregoing description describes specific embodiments of this specification; other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than those shown in the embodiments, and the desired result may still be achieved. Furthermore, the processes depicted in the drawings do not necessarily need to follow the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0187] Corresponding to the above method embodiments, this specification provides a data processing device 700 for AI code generation scenarios, the schematic block diagram of which is shown below. Figure 7 As shown, it includes:

[0188] The first receiving module 710 is configured to receive first code data and a first session identifier transmitted by the AI ​​code generator; the first determining module 720 is configured to determine a first code snapshot based on the first code data; the first generating module 730 is configured to generate a first version number for the first code snapshot; and the establishing module 740 is configured to establish an association between the first code snapshot, the first session identifier, and the first version number.

[0189] The above-described apparatus embodiments correspond to the method embodiments, and detailed descriptions can be found in the description of the method embodiments section, which will not be repeated here. The apparatus embodiments are derived based on the corresponding method embodiments and have the same technical effects as the corresponding method embodiments; detailed descriptions can be found in the corresponding method embodiments.

[0190] This specification also provides a computer-readable storage medium storing a computer program that, when executed in a computer, causes the computer to perform the data processing method for AI code generation scenarios provided in this specification.

[0191] This specification also provides a computing device, including a memory and a processor. The memory stores executable code, and when the processor executes the executable code, it implements the data processing method for AI code generation scenarios provided in this specification.

[0192] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments for storage media and computing devices are basically similar to the method embodiments, so they are described more simply; relevant parts can be referred to the descriptions of the method embodiments.

[0193] Those skilled in the art will recognize that the functions described in the embodiments of the present invention in one or more of the above examples can be implemented using hardware, software, firmware, or any combination thereof. When implemented in software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium.

[0194] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, or improvements made based on the technical solutions of the present invention should be included within the scope of protection of the present invention.

Claims

1. A data processing method for AI-generated code scenarios, comprising: Receive the first code data and the first session identifier from the AI ​​code generator; A first code snapshot is determined based on the first code data, and a first version number is generated for the first code snapshot; Establish the association between the first code snapshot, the first session identifier, and the first version number.

2. The method of claim 1, further comprising: In response to the release order creation request triggered by the first code snapshot, a release order corresponding to the first code snapshot is created; Based on the node configuration information in the release order and the predefined pluggable node pool, a corresponding pipeline instance is constructed, wherein the pipeline instance includes several execution nodes selected from the pluggable node pool based on the node configuration information; The execution of each execution node in the pipeline instance is driven by a state machine, and the code processing is completed based on the first code snapshot to obtain the release result.

3. The method as described in claim 2, wherein, The construction of the corresponding pipeline instance includes: Based on the node configuration information in the release order, select the corresponding execution node from the predefined pluggable node pool; The pipeline instance is constructed based on the preset dependencies between each execution node.

4. The method of claim 1, further comprising: In response to an audit request for the session data corresponding to the first code snapshot, a first session identifier corresponding to the first code snapshot is determined based on the association relationship; The first session identifier is fed back so that the auditors can find the session data corresponding to the first code snapshot based on the first session identifier.

5. The method of claim 1, wherein, The receiving of the first code data and the first session identifier transmitted by the AI ​​code generator includes: Receive the first code data, the first session identifier, and the first application identifier transmitted by the AI ​​code generator; The step of generating a first version number for the first code snapshot includes: The first version number is generated incrementally based on the number of code data already passed under the first application identifier.

6. The method of claim 1, wherein, Determining the first code snapshot based on the first code data includes: Based on the encapsulation format of the first code data, the first code data is standardized or its integrity is verified to obtain the data to be stored. The data to be stored is stored in a preset target storage medium, and a physical resource path identifier pointing to the storage location of the data to be stored is generated; Based on the data to be stored, a content fingerprint is generated; Instantiate a first code snapshot, wherein the first code snapshot includes the content fingerprint and the physical resource path identifier.

7. The method of claim 2, wherein, The node configuration information identifies mandatory execution nodes and optional execution nodes that are dynamically specified through additional node parameters; the mandatory execution nodes include code injection nodes, code building and compilation nodes, resource deployment nodes, and release and deployment nodes; the optional execution nodes include quality check nodes, approval process nodes, and custom hook nodes.

8. The method of claim 3, wherein, The pluggable node pool includes multiple build and compilation nodes set up for different programming language types and different software architectures; The step of selecting the corresponding execution node from the predefined pluggable node pool includes: Based on the programming language type and software architecture of the first code data, the corresponding first build and compilation node is selected from the pluggable node pool.

9. The method of claim 2, further comprising: During the execution of the pipeline instance, the configuration information of each execution node is persistently recorded through a checkpoint mechanism; If any execution node encounters an exception, the state of that execution node is reset to the initial state based on the checkpoint mechanism to allow for breakpoint retry.

10. The method of claim 2, further comprising: During the process of successfully publishing the first code snapshot and providing services, in response to the rollback request, a code snapshot with the same application identifier as the first code snapshot, the latest version number, and the status marked as successfully published and stable is found and used as the rollback code snapshot; Based on the rollback code snapshot and its corresponding release, construct the corresponding rollback pipeline instance; The execution of each execution node in the rollback pipeline instance is driven by a state machine to complete the rollback deployment of online resources.

11. The method of claim 1, wherein, The receiving of the first code data and the first session identifier transmitted by the AI ​​code generator includes: The system receives the first code data and the first session identifier from the AI ​​code generator through a standardized interface.

12. The method of claim 1, wherein, The state machine is defined with the following six states: initialization state, running state, waiting state, completion state, cancellation state, and rejection state; The process of driving the execution of each execution node in the pipeline instance through a state machine includes: The state machine and triggers drive each execution node to transition between the six states.

13. A data processing device for AI code generation scenarios, comprising: The first receiving module is configured to receive the first code data and the first session identifier transmitted by the artificial intelligence code generator; The first determining module is configured to determine a first code snapshot based on the first code data; The first generation module is configured to generate a first version number for the first code snapshot; A module is established and configured to establish an association between the first code snapshot, the first session identifier, and the first version number.

14. A computing device comprising a memory and a processor, wherein, The memory stores executable code, and when the processor executes the executable code, it implements the method of any one of claims 1-12.

Images