Code integration verification method and device, electronic equipment and storage medium

Abstract

The invention relates to the technical field of computers, and provides a code integration verification method and device, electronic equipment and a storage medium, and the method comprises the steps: creating homonymous branches in a plurality of preset code warehouses under the condition of receiving a branch creation instruction; obtaining the current version identification of each homonymous branch in the plurality of code repositories, and generating version snapshot information according to the current version identification; based on the version snapshot information, synchronously obtaining code versions corresponding to respective homonymous branches from a plurality of code warehouses, and generating an integrated code set according to the code versions; and executing joint compiling and integration testing on the integration code set to generate an integration verification result. According to the method, a series of operations such as homonymy branch creation, version snapshot generation, code synchronization and joint compilation test execution are integrated into a coherent automatic process, so that the integration verification efficiency in a multi-warehouse scene is remarkably improved, manual intervention is reduced, and the reliability and consistency of verification results are guaranteed.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a code integration verification method, apparatus, electronic device, and storage medium. Background Technology

[0002] In modern software development, especially in microservice architectures, multi-repository code management has become a common development pattern. In this pattern, project code is distributed across multiple independent code repositories and developed in parallel by different teams.

[0003] Currently, continuous integration (CI) processes are widely used in software development to ensure code quality. However, existing CI tools and methods are mainly designed for single-repository scenarios, and have significant limitations when applied to multi-repository environments, making it difficult to meet the needs of efficient integration and verification.

[0004] First, dependency management is complex. Code from different repositories often depends on each other, and traditional dependency management tools struggle to effectively parse and manage these cross-repository dependencies, leading to errors during joint compilation. Second, branch synchronization is difficult. Integration testing requires ensuring version consistency across multiple repositories. However, version control tools lack batch synchronization capabilities for multiple repository branches, relying on manual operations by developers—a cumbersome and error-prone process. Finally, automation is low. Existing continuous integration tools struggle to automatically coordinate code synchronization, compilation, and testing processes across repositories. This forces developers to rely on complex custom scripts or manual operations, resulting in inefficient and unreliable verification.

[0005] Therefore, how to achieve automated code synchronization, joint compilation, and integration verification in a multi-repository model is a technical problem that urgently needs to be solved in the field of software engineering. Summary of the Invention

[0006] This invention provides a code integration verification method, apparatus, electronic device, and storage medium, aiming to solve the defects of low efficiency and error susceptibility in the integration verification process caused by complex dependency management, difficulty in branch synchronization, and low degree of automation under multi-repository management mode.

[0007] This invention provides a code integration verification method, comprising: Upon receiving a branch creation instruction, create a branch with the same name in multiple pre-defined code repositories; Obtain the current version identifier of each branch with the same name in the plurality of code repositories, and generate version snapshot information based on the current version identifier. The version snapshot information is used to record the latest code version information corresponding to each branch with the same name in the plurality of code repositories. Based on the version snapshot information, the code versions corresponding to the branches with the same name are synchronously obtained from the multiple code repositories, and an integrated code set is generated according to the code versions; Perform joint compilation and integration testing on the integrated code set to generate integration verification results.

[0008] According to a code integration verification method provided by the present invention, the step of creating a branch with the same name in multiple preset code repositories upon receiving a branch creation instruction includes: Receive branch creation instructions; In response to the branch creation instruction, the application programming interface of the code version management platform is called to create branches with the same name in batches in the multiple code repositories, and an associated merge request is generated for each created branch with the same name.

[0009] According to a code integration verification method provided by the present invention, the step of obtaining the current version identifier of each branch with the same name in the plurality of code repositories and generating version snapshot information based on the current version identifier includes: Receive version synchronization instructions; In response to the version synchronization instruction, the multiple code repositories are traversed to obtain the current version identifier of the branch with the same name in each code repository; Based on the current version identifier of each branch with the same name and the code repository address information corresponding to the current version identifier, version snapshot information is generated, and the version snapshot information is updated to the version mapping relationship file.

[0010] According to a code integration verification method provided by the present invention, the method further includes, before performing joint compilation and integration testing on the integrated code set: If a code commit is received in any branch of the same name in any code repository, the unit test pipeline of that code repository is triggered to perform unit-level verification on the code commit.

[0011] According to a code integration verification method provided by the present invention, the step of performing joint compilation and integration testing on the integrated code set includes: Based on preset build rules, the cross-repository dependencies in the integrated code set are parsed, and the preset build rules define the cross-repository dependencies between the multiple code repositories; Based on the cross-repository dependencies, the integrated code set is jointly compiled, and after the joint compilation is successful, preset integration test cases are executed.

[0012] According to a code integration verification method provided by the present invention, the step of jointly compiling the integrated code set based on the cross-repository dependency relationship includes: Identify the target code that has been modified in the integrated code set, and determine the dependencies associated with the target code based on the cross-repository dependencies; Incremental compilation is performed on the target code and its associated dependencies.

[0013] The code integration verification method provided by the present invention further includes: Receive merge instruction; In response to the merge instruction, the preset merge conditions for each of the branches with the same name in the plurality of code repositories are checked; If all the preset merge conditions are met, each of the branches with the same name will be merged into the target branch corresponding to its respective merge request.

[0014] According to a code integration verification method provided by the present invention, the preset merging conditions include the integration verification result being verified as passed, and the merging request associated with the branch with the same name not having code conflicts.

[0015] According to a code integration verification method provided by the present invention, the plurality of code repositories include a manifest repository and at least one business repository, the version snapshot information is stored in the manifest repository, and the joint compilation and integration test of the integrated code set is triggered and executed by the integration pipeline of the manifest repository.

[0016] The present invention also provides a code integration verification device, comprising: The branch creation unit is used to create branches with the same name in multiple pre-defined code repositories when a branch creation instruction is received. An information generation unit is used to obtain the current version identifier of each branch with the same name in the plurality of code repositories, and generate version snapshot information based on the current version identifier. The version snapshot information is used to record the latest code version information corresponding to each branch with the same name in the plurality of code repositories. The code synchronization unit is used to synchronize and obtain the code version corresponding to the branch with the same name from the multiple code repositories based on the version snapshot information, and generate an integrated code set according to the code version; The compilation and testing unit is used to perform joint compilation and integration testing on the integrated code set and generate integration verification results.

[0017] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the code integration verification method as described above.

[0018] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the code integration verification method as described above.

[0019] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the code integration verification method as described above.

[0020] This invention provides a code integration verification method, apparatus, electronic device, and storage medium. Addressing the problems of difficult branch synchronization, reliance on manual operation, and susceptibility to errors in existing multi-repository management models, this invention automatically creates branches with the same name in multiple pre-defined code repositories by receiving branch creation instructions. This achieves automated and batch creation of branches across multiple repositories, ensuring that all related repositories are in a unified and aligned branch environment from the start of development. This significantly reduces the risk of integration failure due to branch version mismatches, simplifies branch management for developers, ensures consistent code versions across different repositories, and facilitates joint compilation and verification. Secondly, this invention obtains the current version identifier of the branch with the same name in each related code repository and generates version snapshot information based on this identifier. This creates a precise and unique snapshot for a set of interdependent cross-repository code versions. This snapshot information clarifies which specific code version should be used for the branch with the same name in each repository at a specific integration point, thus providing a reliable basis for cross-repository code synchronization and joint compilation, fundamentally solving the problems of chaotic dependency management and version conflicts. Furthermore, this invention integrates a series of operations, such as creating branches with the same name, generating version snapshots, synchronizing code, and performing joint compilation tests, into a coherent automated process. Developers only need to trigger the entire verification process with simple commands, which significantly improves the efficiency of integrated verification in multi-repository scenarios, reduces manual intervention, and ensures the reliability and consistency of verification results. Attached Figure Description

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

[0022] Figure 1This is a flowchart illustrating the code integration verification method provided by the present invention; Figure 2 This is a schematic diagram of the structure of the code repository provided by the present invention; Figure 3 This is a schematic diagram of the structure of the code integration verification device provided by the present invention; Figure 4 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0024] In modern software engineering practice, with the expansion of project scale and the popularization of microservice architecture, multi-repository code management has become a mainstream development model. This model allows different development teams to manage and iterate on the code repositories corresponding to their respective functional modules or services in parallel and independently, thereby improving development flexibility and efficiency.

[0025] To ensure code quality, existing software development processes typically employ continuous integration (CI) systems. In traditional single-repository scenarios, developers can utilize continuous integration tools such as Jenkins and GitLab CI, combined with unit testing and integration testing, to automate the building and verification of each code commit, effectively ensuring code correctness and stability. However, when these verification methods are applied to multi-repository scenarios, their inherent limitations become apparent, primarily facing the following technical challenges: First, dependency management is complex. In a multi-repository environment, implementing a feature or fixing a bug often requires modifications across multiple code repositories. These repositories have complex dependencies. Traditional dependency management tools (such as Maven and Gradle) are primarily designed for dependency resolution within a single repository and struggle to effectively handle and resolve cross-repository code dependencies. When multiple repositories need to be compiled and verified jointly, ensuring the correctness and consistency of all dependency versions becomes a challenging problem.

[0026] Second, branch synchronization is difficult. For joint debugging or integration testing across repositories, it's necessary to ensure all relevant repositories have switched to a specific, version-compatible branch. However, existing version control systems (such as Git) lack native support for batch, synchronized operations across multiple repository branches. Developers typically need to manually perform branch creation, switching, and code synchronization in each repository. This process is not only tedious and inefficient, but also highly susceptible to human error leading to branch version mismatches, resulting in compilation failures or integration test errors.

[0027] Third, the level of automation in verification is low. Existing continuous integration tools have limited automation capabilities when handling cross-repository integration verification processes. Due to the lack of a unified coordination mechanism, developers often need to write complex, highly customized scripts to connect the build and test pipelines of different repositories, or manually trigger these processes one by one. This approach is not only costly to maintain, but also inefficient and unreliable, making it difficult to form an efficient and reliable automated integration verification loop.

[0028] In response, this invention provides a dependency-based code integration verification method that can achieve cross-repository code synchronization, joint compilation, and automated verification in a multi-repository code management mode, thereby overcoming the above-mentioned defects.

[0029] Figure 1 This is a flowchart illustrating the code integration verification method provided by the present invention, as shown below. Figure 1 As shown, the method includes: Step 110: Upon receiving a branch creation instruction, create a branch with the same name in one of the preset code repositories.

[0030] It should be noted that this invention relates to a technical solution for efficient and automated integration verification in a multi-repository code management model. In modern software development, especially in microservice architectures or large-scale distributed team collaborations, it has become common practice to split a large project into multiple independent code repositories for management. However, this model also brings technical challenges such as difficulties in cross-repository code version synchronization, complex dependencies, and cumbersome integration verification processes. This invention aims to solve this problem.

[0031] Specifically, a branch creation command refers to the command to create a branch with the same name in the code repository, which can be triggered in various ways. For example, developers can enter a specific command through a command-line service, such as `@gitlabcreate_branch` (followed by the business repository identifier, the branch name, etc.). Once this command is received by the background service, it constitutes the triggering condition for this step. Of course, this command can also be triggered through the interface operation of a continuous integration (CI) system or by calling a preset API interface; this embodiment of the invention does not specifically limit this.

[0032] Upon receiving a branch creation instruction, the backend service will create branches with the same name (e.g., joint branches) in multiple pre-defined code repositories. Here, multiple code repositories refer to repositories that logically belong to the same project or product but are split into multiple independently managed repositories within a version control system (such as GitLab, GitHub, etc.). For example, an autonomous driving system project might be split into a perception algorithm repository, a planning and control repository, a middleware repository, and a main system integration repository. These repositories are pre-defined as a set that requires joint integration and verification.

[0033] The use of identically named branches is one of the core mechanisms of this invention. Its purpose is to establish a consistent version baseline for integration across all relevant code repositories. Here, an identically named branch can be a joint branch, which refers to branches with the same name across multiple code repositories that conform to the joint naming convention. When developers need to develop a new feature involving modifications to code in multiple repositories, they first need to create an identically named branch. For example, a branch named `joint / feature / new-perception-algorithm / 20250101` will be created simultaneously in the perception algorithm repository, the planning control repository, and other relevant repositories. In this way, all code modifications related to the feature will be performed on this identically named joint branch in their respective repositories, thus ensuring that the source version for integration verification is consistent.

[0034] In this embodiment of the invention, by creating a joint branch with the same name in multiple repositories, the code versions in multiple repositories are ensured to remain synchronized, avoiding compilation errors or runtime problems caused by version inconsistencies. Furthermore, developers do not need to manually manage branches in multiple repositories, reducing the risk of human error. In addition, different teams can develop independently in their respective repositories and ultimately integrate through the joint branch, improving development efficiency.

[0035] Step 120: Obtain the current version identifier of each branch with the same name in the multiple code repositories, and generate version snapshot information based on the current version identifier. The version snapshot information is used to record the latest code version information corresponding to each branch with the same name in the multiple code repositories.

[0036] Specifically, after creating a joint branch with the same name and performing a series of development and code commits, a mechanism is needed to accurately record the current code state used for integration. This step aims to achieve this.

[0037] The current version identifier typically refers to the commit hash in a distributed version control system (such as Git), which is a string that uniquely identifies a code commit. By retrieving the hash of the latest code commit on each joint branch with the same name, the code version of that branch can be precisely located.

[0038] Based on the current version identifier of the joint branch with the same name in each code repository, version snapshot information can be generated. Here, version snapshot information is a structured data collection used to centrally store the version information of all related joint branches with the same name. It's like an "integration bill of materials," clearly listing which specific versions of which repositories are needed for this integration.

[0039] For example, the generated version snapshot information can be stored in a JSON file (such as source.json). This file records the repository address (e.g., via the remote field), the current version identifier (e.g., via the commit field), and the timestamp of the current commit for each code repository (e.g., via the shallow_since field) for that commit. When a new code commit is made to any joint branch of the same name in any repository and needs to be integrated, an update action is triggered to retrieve the latest version identifier of that branch and update the version snapshot information.

[0040] Step 130: Based on the version snapshot information, synchronously obtain the code version corresponding to the branch with the same name from the multiple code repositories, and generate an integrated code set according to the code version.

[0041] Specifically, this step is a preparatory step before joint compilation and testing, and its execution entity can be a continuous integration (CI) server or a build server. Specifically, it first reads the version snapshot information generated in step 120; then, based on the address and version identifier of each repository recorded in the snapshot information, it automatically and in batches pulls the specified version of code from each code repository to the local workspace.

[0042] Finally, in the local workspace of the CI server, the code from all relevant repositories, with versions precisely synchronized, is brought together to form an integrated code collection. This collection logically constitutes a complete project view that can be built and tested holistically, laying the foundation for the next step of joint compilation.

[0043] Step 140: Perform joint compilation and integration testing on the integrated code set to generate integration verification results.

[0044] Specifically, the core step in this verification process ensures that code integrated from different repositories can work together. Joint compilation refers to building the entire collection of integrated code generated in step 130. This requires a build system capable of handling cross-repository dependencies. For example, advanced build tools like Bazel can be used. Through predefined build rules (Bazel Rules), the system can automatically resolve the dependencies of code in repository B on code in repository C and link them correctly at compile time. Successful joint compilation signifies that all code is compatible at both the syntax and dependency levels.

[0045] After successful joint compilation, the system will automatically execute pre-set integration test cases. These test cases aim to verify whether the interface calls, data interactions, and business logic between different modules (which may come from different repositories) meet expectations. For example, testing whether data output by a new algorithm module from the perception repository can be correctly received and processed by the planning repository module.

[0046] Ultimately, the entire compilation and testing process generates an integration verification result (e.g., success or failure). This result is a key metric for measuring the quality of the code integration and can be used for subsequent decisions, such as whether to allow code merging.

[0047] Through the above steps, the code integration verification method provided in this embodiment of the invention can ensure version consistency of code across multiple repositories by establishing a joint branch mechanism with the same name, accurately record and synchronize code status using version snapshot information, and achieve automated joint compilation and integration testing. This effectively solves the problems of complex integration verification processes, low automation, and susceptibility to errors in multi-repository scenarios in the prior art, significantly improving the efficiency and reliability of development and integration.

[0048] The method provided in this invention addresses the problems of difficult branch synchronization, reliance on manual operation, and susceptibility to errors in existing multi-repository management models. This invention receives branch creation instructions and automatically creates branches with the same name in multiple pre-defined code repositories, achieving automated and batch creation of branches across multiple repositories. This ensures that all related repositories are in a unified and aligned branch environment from the start of development, greatly reducing the risk of integration failure due to branch version mismatches, simplifying branch management for developers, ensuring consistent code versions across different repositories, and facilitating joint compilation and verification. Secondly, this invention obtains the current version identifier of the branch with the same name in each related code repository and generates version snapshot information based on this identifier. This creates a precise and unique snapshot for a set of interdependent cross-repository code versions. This snapshot information clarifies which specific code version should be used for the branch with the same name in each repository at a specific integration point, thus providing a reliable basis for cross-repository code synchronization and joint compilation, fundamentally solving the problems of chaotic dependency management and version conflicts. Furthermore, this invention integrates a series of operations, such as creating branches with the same name, generating version snapshots, synchronizing code, and performing joint compilation tests, into a coherent automated process. Developers only need to trigger the entire verification process with simple commands, which significantly improves the efficiency of integrated verification in multi-repository scenarios, reduces manual intervention, and ensures the reliability and consistency of verification results.

[0049] Based on any of the above embodiments, this invention provides a command-line service based on GitLab Merge Request (MR), namely Gitlab-CI-Bot, to help users quickly create code versions of joint branches with the same name, supporting a series of operations such as branch creation, branch rebase, and pipeline execution. The following are examples of command-line operations supported by Gitlab-CI-Bot and their descriptions:

[0050] In this embodiment of the invention, by providing the aforementioned command-line service, automated management of branches and merge requests (MR) via the GitLab API is achieved, thereby reducing manual intervention. Specifically, when branch creation and synchronization are required, users only need to enter the corresponding command to automatically create and manage joint branches with the same name via the GitLab API, ensuring branch synchronization across multiple repositories and reducing the complexity and error rate of manual operations. After code integration verification is successful, users can automatically create a merge request and trigger the code merge process by entering the command "@gitlab merge", reducing manual operations by developers and improving the efficiency of code integration.

[0051] In addition, the GitLab API allows for real-time monitoring of branch and MR status, enabling timely detection and resolution of integration issues and ensuring code quality.

[0052] Based on any of the above embodiments, the plurality of code repositories includes a manifest repository and at least one business repository, the version snapshot information is stored in the manifest repository, and the joint compilation and integration testing of the integrated code set is triggered and executed by the integration pipeline of the manifest repository.

[0053] It should be noted that the embodiments of the present invention provide a preferred, structured system architecture to implement the code integration verification method of the present invention. This architecture, by clearly defining the roles and responsibilities of different code repositories, constructs a clear, efficient, and easily scalable multi-repository management and verification system.

[0054] Specifically, Figure 2 This is a schematic diagram of the structure of the code repository provided by the present invention, as shown below. Figure 2 As shown, it illustrates the structural diagram of code repository organization and continuous integration pipeline interaction. In this embodiment of the invention, the organizational structure of multiple code repositories may include a manifest repository and at least one business repository, wherein the manifest repository is... Figure 2 According to RepoA, this repository plays a key coordinating and commanding role in the entire integration verification system. It may contain little or no business logic code; its primary responsibility is to manage and drive the entire integration process.

[0055] At least one business warehouse in Figure 2 Taking RepoB, RepoC, and Other Repos (other business repositories) as examples, these repositories are where the actual functional modules, microservices, or business logic code of the project are located. Different development teams can carry out independent development work in their respective business repositories.

[0056] Understandably, by dividing the code repository into a manifest repository and multiple business repositories, functional decoupling of the repositories is achieved, supporting independent and parallel development of each feature, which is then merged into a joint branch with the same name for integration and verification. Specifically, by creating joint branches with the same name in multiple repositories, different development teams can independently develop functional modules in their respective code repositories, and all development activities are based on derived branches of the same joint branch. Each repository's derived branch is synchronized with the joint branch of the manifest repository (i.e., the manifest repository) through the Pipeline and GitLab API, ensuring code version consistency during parallel development.

[0057] In this embodiment of the invention, the version snapshot information used to record the version correspondence of joint branches with the same name in all business repositories can be stored in a JSON format file (such as source.json), which can then be stored in the manifest repository RepoA. When a developer executes a version synchronization command (such as @gitlab sync_commit) in any associated merge request, the automation tool will traverse all business repositories, obtain the latest version identifier, generate new source.json content (i.e., generate new version snapshot information), and push it as a new commit to the manifest repository RepoA. By centrally storing this crucial "bulk list" in RepoA, centralized management of integrated versions is achieved, ensuring that each integration verification has a clear, traceable, and unique source of fact. It should be understood that before each Bazel joint compilation, code synchronization is performed on all business repositories based on the source.json file.

[0058] Furthermore, the joint compilation and integration testing of the integrated code set in step 140 is triggered and executed by the integration pipeline of the manifest repository. This embodies the core idea of ​​layered verification. Figure 2 This was clearly demonstrated in the text.

[0059] like Figure 2 As shown, each business repository (such as RepoB and RepoC) is configured with its own independent, lightweight unit test pipeline. This pipeline runs only within the current repository and is responsible for performing rapid verification such as unit tests, code coverage checks, and static code checks. Its purpose is to provide developers with immediate feedback to ensure that code submitted to the same-named joint branch meets basic quality requirements.

[0060] In addition, such as Figure 2As shown, the time-consuming and computationally resource-intensive joint compilation and integration testing process is uniformly configured within the integration test pipeline of the manifest repository RepoA. When the unit test pipeline of a business repository (such as RepoB) runs successfully, or when developers are ready to perform a complete integration verification, a trigger mechanism can be used to start the integration test pipeline of the manifest repository RepoA. Once triggered, the RepoA pipeline first reads the source.json file from its own repository, and then, based on the version information in the file, pulls the specified code version from all business repositories (such as RepoB, RepoC, etc.), ultimately forming an integration code set and executing a complete joint compilation and integration test.

[0061] In this embodiment of the invention, the adoption of this manifest repository and business repository architecture, combined with a layered pipeline design, brings significant technical advantages. It achieves separation of concerns, allowing the business repository to focus on business logic development and unit verification, while the manifest repository focuses on global integration and verification. This centralized integration and verification model not only simplifies configuration management but also significantly saves CI / CD resources through on-demand triggered heavyweight integration tests, avoiding the waste of performing a full build for every minor code commit. This ensures integration quality while significantly improving the operational efficiency and scalability of the entire R&D system.

[0062] Based on the above embodiments, step 110 specifically includes: Step 111: Receive branch creation instructions; Step 112: In response to the branch creation instruction, the application programming interface of the code version management platform is called to create branches with the same name in batches in the multiple code repositories, and an associated merge request is generated for each created branch with the same name.

[0063] It should be noted that the embodiments of the present invention are a further refinement of the creation of branches with the same name (e.g., joint branches with the same name) in step 110. By introducing deep integration with the code version management platform, the embodiments of the present invention greatly simplify the preliminary preparation work for multi-repository development and reduce the complexity and error rate of manual operation.

[0064] Specifically, a branch creation command is a specific command issued by a user or automated system to initiate a multi-repository branch creation process. The receipt of this command can be monitored and processed by a dedicated command-line service (i.e., Gitlab-CI-Bot).

[0065] In a specific application scenario, this service could be a continuous integration service (i.e., Gitlab-CI-Bot) deployed on a code version management platform (such as GitLab). Developers can enter a predefined command in the comments section of a merge request (MR) or through a command-line interface (CLI). For example, a developer could enter "@gitlab create_branch feature-xyz" to indicate that they want to create a new branch named "feature-xyz" in all relevant business repositories. The background service monitors these inputs in real time, and once it matches the preset command format, it considers it to have received a valid branch creation instruction and triggers the subsequent process. This approach simplifies complex operations into a simple text command, making it very developer-friendly.

[0066] Upon receiving the instruction, the background service will execute a series of automated operations. First, the service will call the application programming interface (API) of the code version control platform. This platform can be a mainstream industry platform such as GitLab, GitHub, or Bitbucket, all of which provide rich APIs that allow third-party programs to manipulate them programmatically. Then, by calling the API, it will create joint branches with the same name in multiple code repositories (mainly business repositories) in batches. Here, batch creation means that the service will automatically perform the branch creation operation in each specified business repository by repeatedly calling the platform API according to a preset list of business repositories, without requiring manual intervention. For example, the system will create a branch named feature-xyz for all business repositories such as RepoB, RepoC, and RepoD.

[0067] More importantly, this embodiment of the invention, while creating a joint branch with the same name, also automatically generates an associated Merge Request (MR) for each newly created branch. The Merge Request is the core carrier of the code review and merging process. Generating the corresponding MR at the early stage of branch creation has significant advantages: it provides a clear context and goal for subsequent development work, meaning that all commits on that branch ultimately aim to merge into the target branch (such as the main or develop branch) corresponding to that MR. This allows the integration status of the code, the execution results of the continuous integration pipeline, and code review discussions to be centralized on the respective repository's MR page, greatly improving the transparency and traceability of collaboration.

[0068] For example, after creating the feature-xyz branch for RepoB, the system immediately creates a MapReduce (MR) in RepoB via the API. The same operation is performed in all related repositories such as RepoC and RepoD. Subsequently, developers can enter the command "@gitlab rebase" to rebase all joint branches with the same name from all related business repositories to their respective target branches for the MR, facilitating subsequent code merging. Here, rebase is a command used in the Git version control system to merge branches. Unlike merge, it merges branches by rearranging the commit history.

[0069] In this embodiment of the invention, the tedious task of requiring developers to manually click multiple times on multiple repository interfaces is transformed into a single, instruction-driven automated process by automating the branch and merge request creation process. This not only significantly improves the efficiency of development startup but also ensures the consistency of all repository branch naming and MR configurations through a standardized process, preventing branch desynchronization or configuration errors caused by human error from the outset, and laying a solid foundation for smooth multi-repository code integration and verification in the future.

[0070] Based on any of the above embodiments, step 120 specifically includes: Step 121: Receive version synchronization command; Step 122: In response to the version synchronization instruction, traverse the multiple code repositories to obtain the current version identifier of the branch with the same name in each code repository; Step 123: Based on the current version identifier of each branch with the same name and the code repository address information corresponding to the current version identifier, generate version snapshot information and update the version snapshot information to the version mapping relationship file.

[0071] It should be noted that the embodiments of the present invention are a further refinement of the version snapshot information generation process in step 120. This process establishes a version status synchronization mechanism that is triggered on demand and executed automatically, which is a key link to ensure that subsequent integration and verification work is based on an accurate and consistent code baseline.

[0072] Specifically, a version synchronization command is a specific command used to trigger the version snapshot information update process. This command is designed to allow developers to proactively control when the latest code changes from each repository are included in the integration snapshot.

[0073] In a specific application scenario, this command can be received through the command-line service Gitlab-CI-Bot mentioned in the above embodiments. For example, when a developer has completed partial code commits on the same-named joint branches of different business repositories and wants to integrate these latest commits for integration verification, they can enter a preset command, such as "@gitlab sync_commit", in the comment section of any associated merge request (MR). The background command-line service will listen for and recognize this command, thus considering it a valid version synchronization command received. This interactive triggering method gives the development team great flexibility, allowing them to independently decide the timing of integration based on the development rhythm.

[0074] Once a version synchronization command is received, the background service begins execution. This service first iterates through a pre-defined list of all business repositories that need to participate in the integration. This iteration can be automated by calling the API of a code version management platform (such as GitLab) or executing standard Git commands. For each business repository in the list (e.g., RepoB, RepoC, RepoD, etc.), the service automatically locates the joint branch with the same name currently being integrated (e.g., feature-xyz) and retrieves the latest version identifier on that branch. As mentioned earlier, this identifier is typically a Git commit hash, uniquely pointing to a single code commit. Through this operation, the system can accurately capture the latest code version used for this integration in all relevant repositories.

[0075] After obtaining the latest version identifiers for all repositories, the system will enter the information aggregation and persistence phase. Version snapshot information is a structured data record that associates the version identifier obtained in the previous step with the code repository address information (i.e., the repository URL or remote address) to which that version belongs.

[0076] The version mapping file is used to store this version snapshot information. Preferably, this file can be a JSON file, such as source.json. The system generates or updates the contents of this source.json file based on the results of the traversal. Each item in the file clearly records the remote address of a repository (remote field), the latest commit hash on its named joint branch (commit field), and the timestamp corresponding to the commit (shallow_since field). It should be understood that the version mapping file (i.e., source.json file) is usually stored in the lead repository (such as RepoA).

[0077] The method provided in this invention establishes a complete, closed-loop process for generating and updating version snapshots. This process is triggered on demand by developers through simple commands, executed accurately by automated tools, and ultimately produces a versioned snapshot file that serves as the sole source of truth for integration. This completely resolves the omissions and errors that easily occur when manually tracking and synchronizing code versions in a multi-repository environment, providing accurate data input for subsequent reliable and automated integration code synchronization and compilation.

[0078] Based on any of the above embodiments, before performing joint compilation and integration testing on the integrated code set, the method further includes: If a code commit is received in any branch of the same name in any code repository, the unit test pipeline of that code repository is triggered to perform unit-level verification on the code commit.

[0079] Specifically, this embodiment of the invention introduces a pre-emptive, lightweight verification phase, that is, adding a unit-level verification step before performing the global joint compilation and integration testing in step 140. In essence, the core of this embodiment lies in establishing a layered verification strategy within a multi-repository continuous integration system. For example... Figure 2 As shown, it clearly illustrates the layered pipeline structure involved in the embodiments of the present invention.

[0080] When a developer is in charge of a certain business repository (e.g., Figure 2 This step is triggered when a feature development or bug fix is ​​completed on a joint branch (e.g., feature-xyz) with the same name as RepoB or RepoC, and the code is committed to the remote server using Git commands (e.g., git push). Version control platforms (such as GitLab) can automatically detect this event.

[0081] In response to the aforementioned code commit event, the code version control platform will immediately and automatically trigger the unit test pipeline defined within that code repository. This pipeline is lightweight and independent; its operation does not depend on other repositories, and its goal is to quickly verify the correctness of the committed code within the current repository.

[0082] Understandably, unit-level verification focuses on the smallest testable unit of code, ensuring its logical correctness and quality without considering complex dependencies across repositories. In this embodiment of the invention, such verification typically includes, but is not limited to, one or more of the following checks: unit testing, code coverage checks, static code analysis, etc.

[0083] Here, unit testing refers to running test cases written for functions, classes, or modules to verify whether they produce the expected output under preset inputs. This is the foundation for ensuring the correctness of code logic. Code coverage checking involves analyzing the percentage of new or modified code covered by unit tests. The system can set a threshold (e.g., 80%); if the coverage is not met, the pipeline fails to ensure the sufficiency of testing. Static code checking involves using static analysis tools to scan the code for non-compliance with team coding standards, potential logical errors, or security vulnerabilities. Figure 2 As shown, both RepoB and RepoC have their own independent unit test pipelines, which include the aforementioned checks.

[0084] In this embodiment of the invention, the core advantage of introducing this pre-emptive, distributed unit-level verification phase lies in providing a rapid feedback loop. Developers can receive initial feedback on the quality of their changes within minutes of submitting code, without having to wait for a potentially time-consuming full integration build. This allows defects to be discovered and fixed in the early stages of development, significantly reducing repair costs. Simultaneously, it ensures that only code that passes basic quality checks can proceed to the more resource-intensive joint compilation and integration testing phases, thereby effectively conserving the computational resources of the CI / CD system and improving the success rate of final integration verification.

[0085] Based on any of the above embodiments, step 140 specifically includes: Step 141: Based on preset build rules, parse the cross-repository dependencies in the integrated code set. The preset build rules define the cross-repository dependencies between the multiple code repositories. Step 142: Based on the cross-repository dependency relationship, perform joint compilation on the integrated code set, and after the joint compilation is successful, execute the preset integration test cases.

[0086] It should be noted that the embodiments of the present invention are a further refinement of joint compilation and integration testing. Its core lies in solving the core pain points of long compilation time and difficult dependency management in multi-repository scenarios through explicitly defined dependency relationships and intelligent incremental compilation.

[0087] Specifically, after step 130 is completed, an integrated code set containing specific versions of code from all relevant repositories is ready. At this point, the system does not compile blindly, but first performs dependency resolution according to preset build rules. The preset build rules are the key input for this step. Preferably, this embodiment of the invention utilizes Bazel rules to define cross-repository dependencies and build logic, enabling joint compilation of multiple repositories.

[0088] Understandably, Bazel rules can automatically resolve cross-repository dependencies, ensuring that all dependencies are correctly loaded during joint compilation, avoiding the tediousness and errors of manual configuration. Furthermore, Bazel supports incremental compilation, recompiling only the modified code and its dependencies, significantly reducing compilation time and improving development efficiency. Moreover, Bazel rules support multiple programming languages ​​and platforms, making this invention applicable to complex multi-language, multi-platform projects.

[0089] Specifically, each code repository contains a build file (e.g., a BUILD file) that defines how the code within that repository is built, tested, and its internal dependencies. More importantly, in a top-level manifest repository (e.g., RepoA), there is a global configuration file that explicitly declares all business repositories participating in the integration (e.g., RepoB, RepoC, etc.) and their mappings in the local workspace.

[0090] When a joint build is triggered, the build system (Bazel) first reads these build rules. Starting from one or more specified build targets, it recursively scans all BUILD files, thus building a complete and accurate cross-repository dependency graph across the entire integrated codebase (even if the code is scattered across physically different directories). This dependency graph not only includes dependencies within a single repository but also clearly depicts cross-repository dependencies, such as "module alpha in RepoC depends on library beta in RepoB".

[0091] After obtaining the accurate dependency graph, the system begins joint compilation. Unlike traditional methods, the compilation process in this embodiment is highly optimized, particularly in its support for incremental compilation, as detailed below: Further, in step 142, the joint compilation of the integrated code set based on the cross-repository dependency relationship includes: Identify the target code that has been modified in the integrated code set, and determine the dependencies associated with the target code based on the cross-repository dependencies; Incremental compilation is performed on the target code and its associated dependencies.

[0092] Specifically, the build system (Bazel) has a powerful caching mechanism that can accurately identify which files in the integrated codebase have undergone substantial changes since the last successful compilation. This modified code is the target code for this compilation.

[0093] Based on the cross-repository dependency graph generated above, the system not only knows that the target code itself needs to be recompiled, but can also quickly identify all related dependencies that directly or indirectly depend on these target codes. For example, if the library beta in RepoB is modified (i.e., becomes target code), the system will recognize that the module alpha in RepoC that depends on it also needs to be recompiled.

[0094] The system only performs compilation operations on the target code and all associated dependencies identified in the previous step. For other parts of the codebase that have not been modified and whose dependencies have not changed, the system directly reuses the previous compilation results from the cache. This incremental compilation approach avoids a full compilation of the entire large codebase. When the scope of code changes is small, it can greatly shorten compilation time, thus providing developers with faster feedback.

[0095] The system will only proceed with integration testing once the joint compilation process described above completes successfully without any compilation errors. The pre-defined integration test cases are specifically designed to verify the interaction functionality between modules from different code repositories. These test cases are also managed by build rules. For example, an integration test case might simulate a complete business process that spans multiple modules from RepoB, RepoC, and RepoD. Executing these tests effectively uncovers integration defects caused by interface mismatches between modules, inconsistent logical assumptions, and other reasons. Ultimately, the combined results of the joint compilation and integration testing constitute the final integration verification result.

[0096] The method provided in this invention, by utilizing rule-based dependency resolution and intelligent incremental compilation technology, not only solves the problem of managing code dependencies across multiple repositories and ensures the correctness of joint compilation, but also significantly improves the efficiency of integration verification by substantially reducing unnecessary repetitive compilation work. This makes frequent and reliable integration verification possible in large, complex multi-repository projects.

[0097] Based on any of the above embodiments, the method further includes: Receive merge instruction; In response to the merge instruction, the preset merge conditions of each branch with the same name in the plurality of code repositories are checked, wherein the preset merge conditions include the integration verification result being verified as passed, and the merge request associated with the branch with the same name having no code conflict; If all the preset merge conditions are met, each of the branches with the same name will be merged into the target branch corresponding to its respective merge request.

[0098] It should be noted that, based on the foregoing embodiments, this invention describes the final closed-loop stage of the entire code integration and verification process, namely automated code merging. This stage ensures that only code that has undergone comprehensive verification and meets all preset conditions can be safely and efficiently merged into the project's main branch, which is a key step in ensuring the stability and high quality of the main codebase.

[0099] Specifically, once a feature involving multiple repositories has been developed and its corresponding full integration verification has been successfully passed, the development team leader or designated developer can decide to formally merge these changes into the product codebase. At this point, the person will issue a clear merge instruction.

[0100] In a specific application scenario, merge commands can also be received via the Gitlab-CI-Bot command-line service. For example, on any associated merge request (MR) page, the person in charge can enter a predefined command, such as "@gitlab merge". This command clearly expresses the intention to merge all related joint branches with the same name. Upon receiving this command, the command-line service initiates an automated pre-merge check and execution process. This design achieves a good balance between automation and manual monitoring, ensuring that the final merge operation is performed with human confirmation.

[0101] Before performing the actual merge operation, the system conducts a rigorous and comprehensive final check to ensure the safety of the merge. This is the process of verifying the preset merge conditions, which include at least the following two core elements: the integration verification result is successful, and there are no code conflicts with the merge request associated with the joint branch with the same name.

[0102] Understandably, the system will automatically query and confirm the final status of the latest integration pipeline associated with the current joint branch (such as the joint compilation and integration test pipeline executed in the above embodiment). This condition is only met when the status is explicitly "successful" or "passed". Any pipeline in the "failed", "running", or "cancelled" status will cause the merge process to be immediately aborted, and the reason for the failure will be reported to the operator.

[0103] Furthermore, in parallel development, while developers are working on a specific branch (i.e., a joint branch with the same name), the project's main branch (i.e., the target branch, such as main or develop) may have already been updated by other teams. Therefore, code conflicts must be checked before merging. The automated service checks the merge status of merge requests (MRs) pointing from the feature-xyz branch to the main branch in all relevant repositories (RepoB, RepoC, RepoD, etc.) by calling the API of a code version management platform (such as GitLab). This condition is only met when all associated MRs show as automatically mergeable (i.e., conflict-free). If any MR has a conflict, the merge process will fail, and developers will be prompted to manually resolve the conflict first.

[0104] In addition to the two basic conditions mentioned above, other merging conditions can be configured in practical applications, such as requiring all code reviews to be approved and security scans to be passed. The system will perform atomicity checks on all these conditions.

[0105] The system will only perform the final merge operation when all the preset merge conditions from the previous step are met in all relevant code repositories. The automation service will programmatically and sequentially accept each associated merge request by calling the code version management platform's API. For example, it will first merge the MR in RepoB, then merge the MR in RepoC, and so on, until all joint branches with the same name have been successfully merged into their respective target branches.

[0106] The method provided in this invention introduces an automated merge management mechanism, transforming the complex operation of manually checking the status and clicking merge on multiple repository pages into an automated process triggered by instructions and whose correctness is guaranteed by the system. This not only greatly improves the efficiency of code release, but more importantly, through strict and programmatic pre-merge condition checks, it effectively prevents unverified or conflicting code from being incorrectly merged into the main branch, thus providing a solid guarantee for the code quality and version evolution stability of multi-repository projects.

[0107] The code integration verification device provided by the present invention is described below. The code integration verification device described below and the code integration verification method described above can be referred to in correspondence.

[0108] Based on any of the above embodiments Figure 3 This is a schematic diagram of the structure of the code integration verification device provided by the present invention, as shown below. Figure 3 As shown, the device includes: Branch creation unit 310 is used to create branches with the same name in multiple pre-defined code repositories when a branch creation instruction is received; The information generation unit 320 is used to obtain the current version identifier of each branch with the same name in the plurality of code repositories, and generate version snapshot information based on the current version identifier. The version snapshot information is used to record the latest code version information corresponding to each branch with the same name in the plurality of code repositories. The code synchronization unit 330 is used to synchronize and obtain the code version corresponding to the branch with the same name from the multiple code repositories based on the version snapshot information, and generate an integrated code set according to the code version; The compilation and testing unit 340 is used to perform joint compilation and integration testing on the integrated code set and generate integration verification results.

[0109] The apparatus provided in this invention addresses the problems of difficult branch synchronization, reliance on manual operation, and susceptibility to errors in existing multi-repository management models. This invention receives branch creation instructions and automatically creates branches with the same name in multiple preset code repositories, achieving automated and batch creation of branches across multiple repositories. This ensures that all related repositories are in a unified and aligned branch environment from the start of development, greatly reducing the risk of integration failure due to branch version mismatches, simplifying branch management for developers, ensuring consistent code versions across different repositories, and facilitating joint compilation and verification. Secondly, this invention obtains the current version identifier of the branch with the same name in each related code repository and generates version snapshot information based on this identifier. This creates a precise and unique snapshot for a group of interdependent cross-repository code versions. This snapshot information clarifies which specific code version should be used for the branch with the same name in each repository at a specific integration point, thus providing a reliable basis for cross-repository code synchronization and joint compilation, fundamentally solving the problems of chaotic dependency management and version conflicts. Furthermore, this invention integrates a series of operations, such as creating branches with the same name, generating version snapshots, synchronizing code, and performing joint compilation tests, into a coherent automated process. Developers only need to trigger the entire verification process with simple commands, which significantly improves the efficiency of integrated verification in multi-repository scenarios, reduces manual intervention, and ensures the reliability and consistency of verification results.

[0110] Based on any of the above embodiments, the branch creation unit 310 is specifically used for: Receive branch creation instructions; In response to the branch creation instruction, the application programming interface of the code version management platform is called to create branches with the same name in batches in the multiple code repositories, and an associated merge request is generated for each created branch with the same name.

[0111] Based on any of the above embodiments, the information generation unit 320 is specifically used for: Receive version synchronization instructions; In response to the version synchronization instruction, the multiple code repositories are traversed to obtain the current version identifier of the branch with the same name in each code repository; Based on the current version identifier of each branch with the same name and the code repository address information corresponding to the current version identifier, version snapshot information is generated, and the version snapshot information is updated to the version mapping relationship file.

[0112] Based on any of the above embodiments, the device further includes a unit testing module, the unit testing module being used for: If a code commit is received in any branch of the same name in any code repository, the unit test pipeline of that code repository is triggered to perform unit-level verification on the code commit.

[0113] Based on any of the above embodiments, the compilation test unit 340 includes: The dependency resolution subunit is used to resolve cross-repository dependencies in the integrated code set based on preset build rules, wherein the preset build rules define the cross-repository dependencies between the multiple code repositories; The compilation and testing subunit is used to perform joint compilation of the integrated code set based on the cross-repository dependency relationship, and execute preset integration test cases after the joint compilation is successful.

[0114] Based on any of the above embodiments, the compilation and testing subunit is specifically used for: Identify the target code that has been modified in the integrated code set, and determine the dependencies associated with the target code based on the cross-repository dependencies; Incremental compilation is performed on the target code and its associated dependencies.

[0115] Based on any of the above embodiments, the device further includes a merging unit, the merging unit being used for: Receive merge instruction; In response to the merge instruction, the preset merge conditions for each of the branches with the same name in the plurality of code repositories are checked; If all the preset merge conditions are met, each of the branches with the same name will be merged into the target branch corresponding to its respective merge request.

[0116] Based on any of the above embodiments, the preset merging conditions include the integration verification result being verified as passed, and the merging request associated with the branch of the same name not having code conflicts.

[0117] Based on any of the above embodiments, the plurality of code repositories includes a manifest repository and at least one business repository, the version snapshot information is stored in the manifest repository, and the joint compilation and integration testing of the integrated code set is triggered and executed by the integration pipeline of the manifest repository.

[0118] Figure 4 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 4 As shown, the electronic device may include: a processor 410, a communication interface 420, a memory 430, and a communication bus 440, wherein the processor 410, the communication interface 420, and the memory 430 communicate with each other through the communication bus 440. The processor 410 can call logical instructions in the memory 430 to execute a code integration verification method. The method includes: upon receiving a branch creation instruction, creating branches with the same name in multiple preset code repositories; obtaining the current version identifier of each branch with the same name in the multiple code repositories, and generating version snapshot information based on the current version identifier, wherein the version snapshot information is used to record the latest code version information corresponding to each branch with the same name in the multiple code repositories; based on the version snapshot information, synchronously obtaining the code version corresponding to each branch with the same name from the multiple code repositories, and generating an integrated code set based on the code version; performing joint compilation and integration testing on the integrated code set, and generating an integration verification result.

[0119] Furthermore, the logical instructions in the aforementioned memory 430 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to related technologies, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0120] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the code integration verification method provided by the above methods. The method includes: upon receiving a branch creation instruction, creating a branch with the same name in multiple preset code repositories; obtaining the current version identifier of each branch with the same name in the multiple code repositories, and generating version snapshot information based on the current version identifier, wherein the version snapshot information is used to record the latest code version information corresponding to each branch with the same name in the multiple code repositories; based on the version snapshot information, synchronously obtaining the code version corresponding to each branch with the same name from the multiple code repositories, and generating an integrated code set based on the code version; performing joint compilation and integration testing on the integrated code set, and generating an integration verification result.

[0121] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements the code integration verification method provided by the above methods. The method includes: upon receiving a branch creation instruction, creating branches with the same name in multiple preset code repositories; obtaining the current version identifier of each branch with the same name in the multiple code repositories, and generating version snapshot information based on the current version identifier, wherein the version snapshot information is used to record the latest code version information corresponding to each branch with the same name in the multiple code repositories; based on the version snapshot information, synchronously obtaining the code version corresponding to each branch with the same name from the multiple code repositories, and generating an integrated code set based on the code version; performing joint compilation and integration testing on the integrated code set, and generating an integration verification result.

[0122] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0123] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of software products. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0124] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A code integration verification method, characterized in that, include: Upon receiving a branch creation instruction, create a branch with the same name in multiple pre-defined code repositories; Obtain the current version identifier of each branch with the same name in the plurality of code repositories, and generate version snapshot information based on the current version identifier. The version snapshot information is used to record the latest code version information corresponding to each branch with the same name in the plurality of code repositories. Based on the version snapshot information, the code versions corresponding to the branches with the same name are synchronously obtained from the multiple code repositories, and an integrated code set is generated according to the code versions; Perform joint compilation and integration testing on the integrated code set to generate integration verification results.

2. The code integration verification method according to claim 1, characterized in that, Upon receiving a branch creation instruction, creating a branch with the same name in multiple pre-defined code repositories includes: Receive branch creation instructions; In response to the branch creation instruction, the application programming interface of the code version management platform is called to create branches with the same name in batches in the multiple code repositories, and an associated merge request is generated for each created branch with the same name.

3. The code integration verification method according to claim 1, characterized in that, The step of obtaining the current version identifier of each branch with the same name in the plurality of code repositories, and generating version snapshot information based on the current version identifier, includes: Receive version synchronization instructions; In response to the version synchronization instruction, the multiple code repositories are traversed to obtain the current version identifier of the branch with the same name in each code repository; Based on the current version identifier of each branch with the same name and the code repository address information corresponding to the current version identifier, version snapshot information is generated, and the version snapshot information is updated to the version mapping relationship file.

4. The code integration verification method according to claim 1, characterized in that, Before performing joint compilation and integration testing on the integrated code set, the following steps are also included: If a code commit is received in any branch of the same name in any code repository, the unit test pipeline of that code repository is triggered to perform unit-level verification on the code commit.

5. The code integration verification method according to claim 1, characterized in that, The joint compilation and integration testing of the integrated code set includes: Based on preset build rules, the cross-repository dependencies in the integrated code set are parsed, and the preset build rules define the cross-repository dependencies between the multiple code repositories; Based on the cross-repository dependencies, the integrated code set is jointly compiled, and after the joint compilation is successful, preset integration test cases are executed.

6. The code integration verification method according to claim 5, characterized in that, The joint compilation of the integrated code set based on the cross-repository dependency relationship includes: Identify the target code that has been modified in the integrated code set, and determine the dependencies associated with the target code based on the cross-repository dependencies; Incremental compilation is performed on the target code and its associated dependencies.

7. The code integration verification method according to any one of claims 1 to 6, characterized in that, Also includes: Receive merge instruction; In response to the merge instruction, the preset merge conditions for each of the branches with the same name in the plurality of code repositories are checked; If all the preset merge conditions are met, each of the branches with the same name will be merged into the target branch corresponding to its respective merge request.

8. The code integration verification method according to claim 7, characterized in that, The preset merging conditions include the integration verification result being verified as passed, and the merging request associated with the branch with the same name not having code conflicts.

9. The code integration verification method according to any one of claims 1 to 6, characterized in that, The plurality of code repositories includes a manifest repository and at least one business repository. The version snapshot information is stored in the manifest repository. The joint compilation and integration testing of the integrated code set is triggered and executed by the integration pipeline of the manifest repository.

10. A code integration verification device, characterized in that, include: The branch creation unit is used to create branches with the same name in multiple pre-defined code repositories when a branch creation instruction is received. An information generation unit is used to obtain the current version identifier of each branch with the same name in the plurality of code repositories, and generate version snapshot information based on the current version identifier. The version snapshot information is used to record the latest code version information corresponding to each branch with the same name in the plurality of code repositories. The code synchronization unit is used to synchronize and obtain the code version corresponding to the branch with the same name from the multiple code repositories based on the version snapshot information, and generate an integrated code set according to the code version; The compilation and testing unit is used to perform joint compilation and integration testing on the integrated code set and generate integration verification results.

11. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the code integration verification method as described in any one of claims 1 to 9.

12. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the code integration verification method as described in any one of claims 1 to 9.

13. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the code integration verification method as described in any one of claims 1 to 9.

Images