Code migration method, device, electronic device and medium based on container orchestration

Abstract

The present application is applicable to the field of software development technology, and provides a code migration method, device, electronic device and medium based on container orchestration, wherein the method comprises: responding to a user's project migration request, parsing the request to obtain the number of projects to be migrated and the corresponding project identifiers; when the number of projects to be migrated exceeds a preset threshold, dynamically adjusting the number of copies of the target container that performs the migration task based on the container orchestration platform to achieve parallel migration of multiple projects; allocating each project to the corresponding target container according to the project identifier and the number of copies of the current target container, and executing the migration task in the target container to migrate the project source code from the source warehouse to the target warehouse. The above scheme can flexibly expand and contract container resources according to the migration load, realize efficient and automated multi-project code migration, and improve the scalability and deployment efficiency of the system.

Description

Technical Field

[0001] The present application belongs to the field of software development technology, and in particular relates to a code migration method, device, electronic device, and medium based on container orchestration. Background Art

[0002] In large-scale enterprise development environments, GitLab, as a code repository management platform, often requires version upgrades or cross-instance repository merges due to security and compliance requirements (such as Operation Protect Network) or organizational restructuring. Traditional downtime migration solutions require interrupting R&D processes, significantly impacting developer productivity and increasing workload. Furthermore, when there are too many projects to migrate, existing solutions require a complete backup of the source data followed by a restore. Migration time increases linearly with data volume, severely hindering the pace of business iteration. Summary of the Invention

[0003] In view of this, the embodiments of the present application provide a code migration method, device, electronic device and medium based on container orchestration, which can flexibly scale container resources according to the migration load, realize efficient and automated multi-project code migration, and improve the scalability and deployment efficiency of the system.

[0004] A first aspect of an embodiment of the present application provides a code migration method based on container orchestration, which is applied to a server. The method includes:

[0005] Respond to the user's project migration request and obtain the number of projects to be migrated and the corresponding project IDs;

[0006] When the number of items to be migrated exceeds a preset threshold, dynamically adjusting the number of replicas of the target container used to perform the migration task based on the container orchestration platform to support parallel migration of multiple items to be migrated;

[0007] According to the project identifier of each project to be migrated and the number of copies of the current target container, the project to be migrated is allocated to the corresponding target container, and the migration task is performed in the target container to migrate the project source code from the source warehouse to the target warehouse.

[0008] In a possible implementation, responding to the user's project migration request and obtaining the number of projects to be migrated and corresponding project identifiers includes:

[0009] In response to a user's project migration request, the project migration request is parsed, the number of the projects to be migrated is determined, and a corresponding project identifier is assigned to each of the projects to be migrated.

[0010] In a possible implementation, allocating the to-be-migrated items to the corresponding target container according to the item identifier of each to-be-migrated item and the number of replicas of the current target container includes:

[0011] Performing a modulo operation based on the project identifier of the project to be migrated and the number of replicas of the current target container to determine a modulo result corresponding to the project to be migrated;

[0012] The project to be migrated is allocated to a corresponding target container according to the remainder result, wherein the remainder result corresponding to the project to be migrated is the same as the subscript identifier of the target container to which it is allocated. The subscript identifier of the target container is a sorting identifier of the target container in the container cluster, and the sorting identifier is automatically allocated based on the startup order of the containers.

[0013] In a possible implementation, executing the migration task in the target container to migrate the project source code from the source repository to the target repository includes:

[0014] By calling the API interface of the source warehouse, executing the code pull instruction, so as to clone the project source code of the project to be migrated from the source warehouse to the corresponding target container;

[0015] Execute code update instructions on each branch and tag of the project to be migrated in sequence to obtain updated code, and merge it with the project source code in the corresponding target container to form the target project source code;

[0016] Push the target project source code to the target warehouse.

[0017] In one possible implementation, the method further includes:

[0018] By calling the API interface of the source warehouse, the key configuration of the project to be migrated is migrated to the target warehouse. The key configuration includes at least the webhook push address configuration, the authorized member configuration, and the mirror warehouse configuration;

[0019] Trigger a simulated user request, execute the workflow corresponding to the simulated user request, and verify the working status of the target project source code.

[0020] In one possible implementation, the workflow includes at least code cloning, product building, code scanning, code pushing, and automated testing; triggering a simulated user request, executing the workflow corresponding to the simulated user request, and verifying the working status of the target project source code includes:

[0021] Trigger a simulated user request to pull the source code of the project to be migrated;

[0022] Building a product for the project source code of the project to be migrated to generate a software product package;

[0023] The software product package is pushed to the code scanning module, Nexus warehouse, product library and image deployment system in parallel. The code scanning module is used to perform static code quality detection and security vulnerability analysis. The Nexus warehouse is used to archive the product. The image deployment system is used to complete the image deployment according to the code configuration in the software product package.

[0024] Automatically trigger the automated test based on the push results of multiple branches and determine the automated test results. The automated test includes at least unit testing, interface testing, and software interface testing.

[0025] Verify the working status of the target project source code based on the automated test results.

[0026] In one possible implementation, the method further includes:

[0027] The working status of the migrated target project source code is pushed to project-related members.

[0028] A second aspect of an embodiment of the present application provides a code migration device based on container orchestration, which is applied to a server. The device includes:

[0029] The request response module is used to respond to the user's project migration request and obtain the number of projects to be migrated and the corresponding project identifiers;

[0030] A container orchestration module, configured to dynamically adjust the number of replicas of a target container for executing a migration task based on a container orchestration platform when the number of items to be migrated exceeds a preset threshold, so as to support the parallel migration of multiple items to be migrated;

[0031] The migration module is used to allocate the projects to be migrated to the corresponding target containers according to the project identifier of each project to be migrated and the number of copies of the current target container, and perform the migration task in the target container to migrate the project source code from the source warehouse to the target warehouse.

[0032] A third aspect of an embodiment of the present application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the container-based code migration method described in the first aspect is implemented.

[0033] A fourth aspect of an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the container-based orchestration code migration method described in the first aspect is implemented.

[0034] A fifth aspect of the embodiments of the present application provides a computer program product. When the computer program product is run on an electronic device, the electronic device executes the container-based orchestration code migration method described in the first aspect.

[0035] Compared with the prior art, the embodiments of the present application have the following beneficial effects:

[0036] The embodiment of the present application responds to the user's project migration request, obtains the number of projects to be migrated and the corresponding project identifiers, and when the number of projects to be migrated exceeds a preset threshold, dynamically adjusts the number of copies of the target container that executes the migration task based on the container orchestration platform to achieve parallel migration of multiple projects; finally, according to the project identifier and the number of copies of the current target container, each project is assigned to the corresponding target container, and the migration task is executed in the target container to migrate the project source code from the source warehouse to the target warehouse. The above scheme achieves parallel migration of multiple projects by dynamically adjusting the number of copies of the target container and assigning migration tasks based on the project identifier, which solves the problems of low efficiency and resource rigidity of traditional migration schemes, and has the advantages of improving the efficiency of large-scale project migration, avoiding interruptions in the R&D process, shortening the migration time, and dynamically adapting to the migration load. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments or descriptions of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0038] Figure 1 This is a flowchart of a code migration method based on container orchestration provided in Example 1 of the present application;

[0039] Figure 2 This is a flowchart of a code migration method based on container orchestration provided in Example 2 of the present application;

[0040] Figure 3 This is a schematic diagram of the structure of a code migration device based on container orchestration provided in Example 3 of the present application;

[0041] Figure 4 This is a structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0042] In the following description, specific details such as specific system structures and techniques are provided for purposes of illustration rather than limitation to facilitate a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application may be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid obscuring the description of the present application with unnecessary detail.

[0043] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, integers, steps, operations, elements and / or components, but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or collections thereof.

[0044] It will also be understood that the term "and / or" used in this specification and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.

[0045] As used in this specification and the appended claims, the term "if" can be interpreted as "when" or "upon" or "in response to determining" or "in response to detecting," depending on the context. Similarly, the phrase "if it is determined" or "if [described condition or event] is detected" can be interpreted as meaning "upon determination" or "in response to determining" or "upon detection of [described condition or event]" or "in response to detecting [described condition or event]," depending on the context.

[0046] In addition, in the description of the present application specification and the appended claims, the terms "first", "second", "third", etc. are only used to distinguish the descriptions and cannot be understood as indicating or implying relative importance.

[0047] It should be understood that the size of the serial numbers of each step in this embodiment does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of this application.

[0048] Existing technologies typically use a full backup and restore method for code repository migrations. This process increases linearly with the number of projects being migrated. Traditional solutions rely on a fixed number of processing nodes and are unable to dynamically adjust resources based on task load, leading to task backlogs in high-concurrency scenarios. When an enterprise needs to migrate hundreds of GitLab projects simultaneously, existing technologies either require lengthy downtime to complete the migration or face the conflict between wasted resources and inefficient migration, significantly impacting developer productivity and increasing developer workload.

[0049] In order to solve the above problems, the embodiments of the present application provide a code migration method, device, electronic device and medium based on container orchestration, which first responds to the user's project migration request and obtains the number of projects to be migrated and the corresponding project identifiers. Secondly, when the number of projects to be migrated exceeds a preset threshold, the number of copies of the target container that performs the migration task is dynamically adjusted based on the container orchestration platform to achieve parallel migration of multiple projects; finally, according to the project identifier and the number of copies of the current target container, each project is assigned to the corresponding target container, and the migration task is performed in the target container to migrate the project source code from the source warehouse to the target warehouse. The above scheme achieves parallel migration of multiple projects by dynamically adjusting the number of copies of the target container and assigning migration tasks based on the project identifier, which solves the problems of low efficiency and resource rigidity of traditional migration schemes, and has the advantages of improving the efficiency of large-scale project migration, avoiding R&D process interruptions, shortening migration time and dynamically adapting to migration loads.

[0050] See Figure 1 , Figure 1 This is a flow chart of a code migration method based on container orchestration provided in Example 1 of this application. This method is applied to a server, such as Figure 1 As shown, the method may include the following steps:

[0051] Step 101: respond to a user's project migration request and obtain the number of projects to be migrated and corresponding project identifiers.

[0052] It should be noted that the method described in this application runs on the first server, which is independent of the second and third servers. The second server is the source server that stores the source code of the project to be migrated, and the third server is the target server that receives the source code of the target project. The first server integrates an operations and maintenance dashboard and CI (Continuous Integration) / CD (Continuous Deployment) modules to support continuous integration, continuous deployment, and related automated operations during the migration process.

[0053] Among them, a project migration request refers to an operation instruction initiated by the user containing information about the projects to be migrated. It can be implemented using an HTTP request message. By parsing the parameters in the request message, the number of projects to be migrated and the project identifiers can be obtained to provide data support for subsequent resource scheduling.

[0054] In one possible implementation, in response to a user's project migration request, obtaining the number of projects to be migrated and corresponding project identifiers includes:

[0055] Respond to the user's project migration request, parse the project migration request, determine the number of projects to be migrated, and assign a corresponding project ID to each project to be migrated.

[0056] In an embodiment of the present application, the project migration request can be parsed using a structured data parsing algorithm, such as using a JSON parser to extract the project list information contained in the request body. The number of projects to be migrated can be determined by counting the length of the array. For example, if a project array is defined in the request body, its length is used directly as the number of projects to be migrated.

[0057] Among them, the project identification allocation process can use a hash algorithm to generate a unique string, such as performing a SHA-256 operation on the project name and timestamp combination and then extracting the first 12 bits as the identification; or generating an incremental number through a distributed sequence generator.

[0058] Specifically, when a user submits a project migration request containing multiple projects through the front-end interface, the request body is encapsulated into a structured data format and transmitted to the first server. The first server then calls a pre-configured parsing module to break down the request body layer by layer, identifying the project list field and counting its elements. For example, if the parsed project field contains metadata for three projects, the number of projects to be migrated is determined to be three.

[0059] Subsequently, the identifier generation service is called for each project's metadata, and the project name, creation time, and random number are input into a hash function to generate a unique string of fixed length as the project identifier. For example, the identifier of Project A is calculated as "a3f8b2c7d1e9," and the identifier of Project B is generated as "e5d4c3b2a1f0." The generated identifier is mapped to the project metadata and stored in a cache queue, providing an index basis for the subsequent container allocation stage. This process ensures that each project to be migrated has an independent and traceable operation identifier in the subsequent processing flow, avoiding resource preemption or task conflicts caused by duplicate identifiers.

[0060] For example, after receiving a project migration request initiated by a user, the first server first parses the request. During the parsing process, the system identifies the project information to be migrated contained in the request and calculates the total number of projects to be migrated. For example, if the user requests to migrate projects A, B, and C simultaneously, the system will determine that the number of projects to be migrated is 3.

[0061] After determining the number of projects to be migrated, the system assigns each project a unique project ID. These IDs can be system-generated strings or numeric sequences. For example, the system might assign Projects A, B, and C project IDs "101," "102," and "103," respectively. These IDs will be used to track and manage the migration status of each project during the subsequent migration process.

[0062] Through this solution, this application achieves precise parsing of project migration requests and orderly allocation of project identifiers. This approach ensures the system accurately grasps the number of projects to be migrated, avoiding parsing omissions or errors caused by complex request content or data redundancy. Furthermore, assigning a unique identifier to each project provides a foundation for subsequent parallel migration and resource allocation, effectively preventing confusion and resource conflicts between projects. This not only improves the reliability of the migration process but also lays the foundation for efficient execution of the entire migration process.

[0063] Step 102: When the number of items to be migrated exceeds a preset threshold, the number of replicas of the target container used to perform the migration task is dynamically adjusted based on the container orchestration platform to support parallel migration of multiple items to be migrated.

[0064] Among them, the container orchestration platform dynamically adjusts the number of target container copies, which can mean automatically expanding or shrinking the number of container instances according to the scale of the project to be migrated. Specifically, this can be achieved by using the Horizontal Pod Autoscaler component of Kubernetes, which triggers the container instance expansion and contraction operations by monitoring the length of the task queue to ensure that resource supply and task load are dynamically matched.

[0065] In an embodiment of the present application, the preset threshold can be determined based on factors such as the performance of the first server and network bandwidth. If the number of items to be migrated exceeds the preset threshold, the first server can dynamically increase the number of replicas of the target container used to perform the migration task by calling the API interface of the container orchestration platform.

[0066] This mechanism realizes the on-demand supply of computing resources, forms an elastic resource pool, and breaks through the limitations of traditional static resource allocation.

[0067] Step 103 : Allocate the project to be migrated to the corresponding target container according to the project identifier of each project to be migrated and the number of replicas of the current target container, and execute the migration task in the target container to migrate the project source code from the source warehouse to the target warehouse.

[0068] In the embodiment of the present application, the server uses a modulo algorithm to allocate the project to be migrated to the target container. Specifically, a modulo operation is performed on the project identifier and the number of replicas of the current target container, and the result is used as the target container index for the project allocation.

[0069] In each target container, perform the migration task. First, clone the source code of the project to be migrated to the target container by calling the source repository's API. Then, update the code for each branch and tag and merge it with the cloned source code. Finally, push the merged code to the target repository.

[0070] In a possible implementation, allocating the to-be-migrated project to the corresponding target container according to the project identifier of each to-be-migrated project and the number of replicas of the current target container includes:

[0071] Perform a modulo operation based on the project ID of the project to be migrated and the number of replicas of the current target container to determine the modulo result corresponding to the project to be migrated;

[0072] Based on the remainder result, the project to be migrated is assigned to the corresponding target container. The remainder result corresponding to the project to be migrated is the same as the subscript identifier of the target container to which it is assigned. The subscript identifier of the target container is the sorting identifier of the target container in the container cluster. The sorting identifier is automatically assigned based on the startup order of the containers.

[0073] The divisor for the remainder operation is set to the total number of running target containers in the current container cluster. This value changes in real time with the dynamic scaling of the container orchestration platform. Project identifiers are generated using unique encoding rules. The container sorting identifier is automatically generated by the container orchestration platform when the instance is started. This is achieved by generating consecutive serial numbers in the Kubernetes cluster based on the Pod (i.e., target container) creation timestamp, ensuring that the serial number of the newly expanded target container is always the current maximum serial number plus one.

[0074] Specifically, when the container orchestration platform triggers horizontal expansion based on the number of projects to be migrated, the serial number of the newly added target container is automatically appended to the end of the sequence of existing serial numbers. For the projects to be migrated, the project ID is modulo the updated total number of containers, and the calculation result range is expanded to the newly added serial number interval. For example, when the original number of containers is 1 and is increased to 3, the migration task with the original project ID of 101 is calculated as 101%3 to obtain a modulo result of 2, corresponding to the target container with the subscript ID of 2. In the scaling-down scenario, the tasks of the removed containers are automatically assigned to the surviving containers by recalculating the modulo result. For example, when the number of containers is reduced from 3 to 1, the task originally assigned to the target container with the subscript ID of 2 will be re-executed as 101%1 to obtain a result of 0, and migrated to the target container with the subscript ID of 0 to continue execution.

[0075] Exemplarily, a modulo operation is performed based on the project ID of the project to be migrated and the number of replicas in the current target container to determine a modulo result corresponding to the project to be migrated. For example, suppose the project ID of the project to be migrated is "101" and the number of replicas in the current target container is 3. A modulo operation is performed on 101 and the number of replicas in the current target container, 3, to obtain a modulo result of 2.

[0076] Based on the remainder, the project to be migrated is assigned to the corresponding target container. In this example, the remainder is 2, so the project to be migrated is assigned to the target container with index 2. The target container's index is its order within the container cluster. The order is automatically assigned based on the order in which the containers are started. For example, the five target containers in the container cluster are assigned indexes 0, 1, 2, 3, and 4, in the order in which they are started.

[0077] It should be understood that the above identifier can also be a combination of text, numbers, and symbols, such as the project identifier "project_123". When performing the remainder operation, the project identifier "project_123" is first converted to a unique numeric identifier. A hash function can be used to calculate an integer value, such as 12345, which is then modulo the number of replicas in the target container.

[0078] Through the above technical solution, the present application realizes efficient task distribution in the scenario of dynamically adjusting the number of target container copies. By introducing a remainder operation mechanism based on the project identifier and the real-time number of container copies, it is ensured that each project to be migrated can obtain a unique allocation result that matches the current container scale. This method avoids the mapping failure problem caused by changes in the number of containers, so that newly added containers can be automatically added to the allocation queue, and tasks released by shrinking containers can be reallocated to surviving nodes. As a result, this solution realizes dynamic load balancing of the elastic resource pool and improves the scheduling efficiency and resource utilization of migration tasks. Furthermore, since the container sorting identifier is automatically generated based on the startup order, the consistency of the physical topology of the container cluster and the logical allocation rules is guaranteed, reducing the risk of human configuration errors.

[0079] In one possible implementation, a migration task is executed in the target container to migrate the project source code from the source repository to the target repository, including:

[0080] By calling the API interface of the source warehouse, executing the code pull instruction, the project source code of the project to be migrated is cloned from the source warehouse to the corresponding target container;

[0081] Execute code update instructions on each branch and tag of the migration project in sequence to obtain the updated code, and merge it with the project source code in the corresponding target container to form the target project source code;

[0082] Push the target project source code to the target repository.

[0083] Among them, during the code pulling stage, API interface calls can be implemented through the GitLab Open Api interface provided by GitLab, specifically involving the projects API endpoint to obtain repository metadata, and can also be combined with the repository files API to batch pull source code files.

[0084] The execution order of code update instructions can be based on branch creation time, for example, prioritizing the main branch over secondary branches, or processing them in ascending order of tag version numbers. Merge operations can use a three-way merge tool to automatically resolve conflicts, triggering manual intervention when the conflict rate exceeds 5%.

[0085] Specifically, the cloning process can directly obtain the latest code snapshot of the source repository through an API interface, avoiding the possibility of missing version information in hidden files or .git directories during manual export. When synchronizing multiple branches, each branch's update instructions will be independently generated as a temporary branch. Before merging, the difference analysis module will check compatibility with the main branch. For example, if an unmerged pull request is detected for a branch, a merge request record will be automatically generated for subsequent tracing.

[0086] Specifically, when pushing to the target repository, all branches and tags must be fully written. If a network interruption occurs, the transaction rollback log can be used to restore to the pre-migration state. This process works in conjunction with the dynamic container expansion mechanism. Cloning ensures the integrity of the migration task within a single container, while multi-container parallel processing isolates branch merge operations from different projects, preventing version confusion caused by resource competition.

[0087] Exemplarily, the solution of the present application is specifically implemented as follows: when executing the migration task in the target container, first execute the code pull instruction by calling the API interface of the source warehouse. For example, the Git command can be used to clone the project source code of the project to be migrated from the source warehouse to the corresponding target container. Next, the code update instruction is executed in sequence for each branch and tag of the project to be migrated. Specifically, the "git fetch" command can be used to obtain updates of all remote branches and tags, and then the "git checkout" command can be used to switch to each branch, and the "git pull" command is executed to pull the latest code. After obtaining the updated code, it is merged with the project source code in the corresponding target container into the target project source code. The merging process can use the "gitmerge" command to ensure that the code changes of all branches are integrated. Finally, the "git push" command is used to push the target project source code to the target warehouse to complete the code migration process.

[0088] Through the above technical solution, the present application realizes the cloning of source warehouse code and effective synchronization of multi-branch versions. By calling the source warehouse API interface to execute the code pull instruction, it is ensured that the target container can accurately obtain the latest version of the project source code in the source warehouse. The code update instruction is executed on each branch and tag, covering all historical versions and parallel development branches generated by the project during the development process. The updated code is merged with the source code in the container to generate the target project source code, realizing the integration of multiple versions of the code. Finally, the target project source code is pushed to the target warehouse, forming a target repository that is completely consistent with the source warehouse in code content and version structure. This method effectively avoids the problem of version differences between the target warehouse code and the source warehouse, eliminates the risk of code coverage caused by branch switching, and ensures the integrity and operational stability of the migrated code.

[0089] The above-mentioned embodiment 1 obtains the number of projects to be migrated and the corresponding project identifiers by responding to the user's project migration request. Secondly, when the number of projects to be migrated exceeds a preset threshold, the number of copies of the target container that performs the migration task is dynamically adjusted based on the container orchestration platform to achieve parallel migration of multiple projects. Finally, according to the project identifier and the number of copies of the current target container, each project is assigned to the corresponding target container, and the migration task is performed in the target container to migrate the project source code from the source warehouse to the target warehouse. The above-mentioned solution achieves parallel migration of multiple projects by dynamically adjusting the number of copies of the target container and assigning migration tasks based on the project identifier, which solves the problems of low efficiency and resource rigidity of traditional migration solutions. It has the advantages of improving the efficiency of large-scale project migration, avoiding interruptions in the R&D process, shortening the migration time, and dynamically adapting to the migration load.

[0090] See also Figure 2 , shows a flow chart of a code migration method based on container orchestration provided in the second embodiment of the present application. Figure 2 As shown, the method may include the following steps:

[0091] Step 201: respond to a user's project migration request and obtain the number of projects to be migrated and corresponding project identifiers.

[0092] Step 202: When the number of items to be migrated exceeds a preset threshold, the number of replicas of the target container used to perform the migration task is dynamically adjusted based on the container orchestration platform to support parallel migration of multiple items to be migrated.

[0093] Step 203 : Allocate the project to be migrated to the corresponding target container according to the project identifier of each project to be migrated and the number of replicas of the current target container, and execute the migration task in the target container to migrate the project source code from the source warehouse to the target warehouse.

[0094] The execution process of steps 201 to 203 in this embodiment is similar to that of steps 101 to 103 in the first embodiment, and they can be referenced to each other, and will not be repeated in this embodiment.

[0095] Step 204: Migrate the key configuration of the project to be migrated to the target warehouse by calling the API interface of the source warehouse.

[0096] Among them, the key configurations include at least Webhook push address configuration, authorized member configuration, and image repository configuration.

[0097] Key configuration migrations can utilize a logical tag deletion mechanism (identifying historical configuration states through version numbers rather than physical deletion) combined with incremental data insertion to migrate standardized configuration data to the target project database cluster. A bidirectional validation mechanism can be implemented during the migration process to ensure semantic consistency with the source project after configuration synchronization. Complete operation logs and version snapshots are also preserved, enabling millisecond-level configuration recovery through a transaction rollback interface.

[0098] Specifically, in the key configuration migration steps, the API interface of the source warehouse is called to extract the Webhook configuration, where the listening event type and key information of the push address are completely copied to the target warehouse to ensure that the downstream CI / CD process can be automatically triggered after the code is submitted; when authorizing member configuration migration, the user role mapping table of the source warehouse is parsed to rebuild the corresponding access control policy in the target warehouse, such as granting maintainer permissions to the original project members in batches; during the image warehouse configuration migration process, the image reference path in the build script is replaced with the image library address of the target warehouse.

[0099] Through the above technical solution, automatic migration of key configurations is achieved, which avoids the tedious work of manual reconfiguration and improves migration efficiency.

[0100] Step 205 : triggering a simulated user request, executing a workflow corresponding to the simulated user request, and verifying the working status of the target project source code.

[0101] In the embodiment of the present application, after all key configurations are completed, the operation and maintenance platform CI / CD module simulates users triggering Merge Request and PushRequest requests from IntelliJ IDEA, Eclipse, Git plug-in and GitLab management terminal respectively, in order to verify that the operation and maintenance platform CI / CD can work normally after migration.

[0102] The workflow includes at least code cloning, product building, code scanning, code pushing, and automated testing. Different projects in this application are suitable for different workflows.

[0103] It should be noted that users need to make relevant configurations in the CI / CD module of the operation and maintenance platform. These configurations are for the operations of specified projects on GitLab to achieve automated project construction, deployment and other processes.

[0104] Workflow configuration: Workflow is the core of the CI / CD process, which defines the series of steps from code submission to deployment. Three configuration methods are supported:

[0105] First, the Docker method requires configuring the push code branch, service name, Docker image namespace, number of copies of the target container, and Kubernetes service.

[0106] Push code branch: Specify the branch to use when pulling code from the GitLab repository, such as master, develop, etc.

[0107] Service Name: Give the service to be deployed an identification name to facilitate subsequent management and identification.

[0108] Docker image namespace: In a Docker image repository, namespaces are used to organize and isolate different images. Choosing the right namespace ensures orderly image management.

[0109] Number of replicas: refers to the number of container instances to run, which is set based on actual business needs and load conditions.

[0110] Kubernetes Service: Kubernetes is an open source platform for automating the deployment, scaling, and management of containerized applications. Configuring the Kubernetes service allows you to deploy Docker containers into a Kubernetes cluster.

[0111] Second, the VM (virtual machine) method requires configuring the push code branch, service name, deployment server IP address, MeterSphere configuration, YApi configuration, and installing Supervisor.

[0112] Push code branch: Same as Docker method, specify the branch to pull the code from the GitLab repository.

[0113] Service Name: Name the service deployed on the VM.

[0114] Deployment server IP address: Specify the IP address of the virtual machine where the service will be deployed, for remote connection and deployment operations.

[0115] MeterSphere configuration: MeterSphere is an open source one-stop testing platform. Configuring related information can implement functions such as testing deployed services.

[0116] YApi configuration: YApi is an efficient, easy-to-use, and powerful API management platform. Configuring YApi information can facilitate the management and testing of service APIs.

[0117] Install Supervisor: Supervisor is a process management tool that needs to be installed on the deployment server to monitor and manage the deployed service processes and ensure the stable operation of the services.

[0118] Third, when pushing to the enterprise intranet warehouse, you need to configure the push code branch and service name.

[0119] Push code branch: Specify the branch to pull the code from the GitLab repository.

[0120] Service Name: Name the service to be pushed to the intranet warehouse.

[0121] After completing the above configuration, you can execute workflows corresponding to simulated user requests for different projects and verify the working status of the target project's source code. Specifically, you can trigger a code commit event through the API to start the CI / CD pipeline. The workflow can include steps such as code cloning, artifact building, code scanning, code push, and automated testing. This allows you to verify that the migrated code compiles properly, passes tests, and that the build product meets expectations.

[0122] At the same time, by simulating user request verification workflows, we ensure the integrity and availability of the migrated project and reduce potential post-migration issues. This approach not only simplifies the migration process but also improves its accuracy and reliability, allowing for a quick return to normal development workflows after code migration.

[0123] Specifically, in one possible implementation, triggering a simulated user request, executing a workflow corresponding to the simulated user request, and verifying the working status of the target project source code includes:

[0124] Trigger a simulated user request to pull the source code of the project to be migrated;

[0125] Build artifacts for the project source code of the project to be migrated to generate software artifact packages;

[0126] Push software artifact packages to the code scanning module, Nexus repository, artifact library, and image deployment system in parallel;

[0127] Automatically trigger automated testing based on the push results of multiple branches and determine the automated testing results. Automated testing includes at least unit testing, interface testing, and software interface testing.

[0128] Verify the working status of the target project source code based on the automated test results.

[0129] Among them, the code scanning module is used to perform static code quality detection and security vulnerability analysis, the Nexus warehouse is used to archive the product, and the image deployment system is used to complete the image deployment according to the code configuration in the software product package.

[0130] In the embodiments of the present application, different programming languages ​​(Java, Python, NodeJs) may correspond to different workflows.

[0131] For example, taking Java language as an example, Java language code migration and verification of the final migration results:

[0132] A. Pull the source GitLab code through the git command;

[0133] B. Execute the mvn clean install command to build the jar.

[0134] C. Push the code to the target GitLab address through the git command;

[0135] D. Execute Sonar code scanning, push artifact library, and image deployment respectively;

[0136] E. Execute the mvn deploy command to push to the Nexus repository;

[0137] F. After summarizing the multiple branch nodes, perform automated testing.

[0138] For example, taking NodeJs language as an example, the NodeJs language code migration and verification of the final migration results:

[0139] A. Pull the source GitLab code through Git commands;

[0140] B. Execute the docker build and docker --config build commands respectively (configuration files for each project are different and executed dynamically);

[0141] C. Push the code to the target Git address through the Git command;

[0142] D. Image deployment;

[0143] E. Perform automated testing;

[0144] F. Send SMS / WeChat notifications.

[0145] In one possible implementation, the working status of the target project source code can be verified by analyzing the test report to determine indicators such as functional completeness and performance stability after the code migration.

[0146] Through the above technical solutions, this application has built a multi-dimensional workflow verification mechanism to solve the problem of insufficient full-link verification after code migration. By triggering simulated user requests to pull project source code, the real user operation scenario is restored, ensuring the consistency between the test environment and the production environment. The migrated source code is constructed to generate a software product package, providing a standardized code carrier for subsequent multi-module processing. It is pushed in parallel to the code scanning module, Nexus warehouse and mirror deployment system, realizing the synchronous execution of static code detection, product archiving and deployment verification, avoiding the waste of resources caused by serial processing.

[0147] Step 206: Push the working status of the migrated target project source code to project-related members.

[0148] In an embodiment of the present application, the working status of the target project source code after migration can be pushed to the project-associated members through an asynchronous message queue. Specifically, the first server can first obtain a list of members related to the target project from the project management database, including the R&D person in charge, test engineers, and system operation and maintenance personnel. Then, the source code working status information after migration is encapsulated into a message body, which contains core indicators such as project identification, migration timestamp, unit test pass rate, interface test response results, and interface test compatibility. Then, the system sends these message bodies to the message queue. After receiving these messages, the message queue server distributes the messages to different associated members according to pre-configured routing rules. For example, the client of the R&D person in charge may receive the status data required for code merging, while the client of the test engineer may receive a detailed report of the automated test results.

[0149] Compared to Example 1, this embodiment of the present application achieves automatic migration of key configurations, avoiding the tedious work of manual reconfiguration and improving migration efficiency. At the same time, by simulating user request verification workflows, the integrity and availability of the migrated project are ensured, reducing potential post-migration issues. This approach not only simplifies the migration process but also improves its accuracy and reliability, allowing for a quick return to normal development workflows after code migration.

[0150] See also Figure 3 , shows a structural diagram of a code migration device based on container orchestration provided in Example 3 of the present application. For the sake of convenience, only the parts related to the embodiment of the present application are shown.

[0151] The container-based code migration device 300 may specifically include the following modules:

[0152] The request response module 301 is used to respond to the user's project migration request and obtain the number of projects to be migrated and the corresponding project identifiers;

[0153] The container orchestration module 302 is configured to dynamically adjust the number of replicas of the target container used to perform the migration task based on the container orchestration platform when the number of items to be migrated exceeds a preset threshold, so as to support the parallel migration of multiple items to be migrated.

[0154] The migration module 303 is used to allocate the project to be migrated to the corresponding target container according to the project identifier of each project to be migrated and the number of copies of the current target container, and perform the migration task in the target container to migrate the project source code from the source warehouse to the target warehouse.

[0155] In the embodiment of the present application, the request response module 301 may specifically include:

[0156] The identifier allocation unit is used to respond to the user's project migration request, parse the project migration request, determine the number of projects to be migrated, and allocate a corresponding project identifier to each project to be migrated.

[0157] In the embodiment of the present application, the migration module 303 may specifically include:

[0158] A remainder unit, configured to perform a remainder operation based on the project identifier of the project to be migrated and the number of replicas of the current target container, and determine a remainder result corresponding to the project to be migrated;

[0159] An allocation unit is configured to allocate the project to be migrated to the corresponding target container based on the remainder result, wherein the remainder result corresponding to the project to be migrated is the same as the subscript identifier of the target container to which it is allocated, and the subscript identifier of the target container is the sorting identifier of the target container in the container cluster, and the sorting identifier is automatically allocated based on the startup order of the containers.

[0160] In the embodiment of the present application, the migration module 303 may further include:

[0161] The code pulling unit is used to execute the code pulling instruction by calling the API interface of the source warehouse to clone the project source code of the project to be migrated from the source warehouse to the corresponding target container;

[0162] A code update unit is used to execute code update instructions on each branch and tag of the migration project in sequence to obtain the updated code and merge it with the project source code in the corresponding target container to form the target project source code;

[0163] Push unit, used to push the target project source code to the target warehouse.

[0164] In the embodiment of the present application, the container-based code migration device 300 may further include the following modules:

[0165] The interface call module is used to migrate the key configurations of the project to be migrated to the target repository by calling the API interface of the source repository. The key configurations include at least the webhook push address configuration, authorized member configuration, and mirror repository configuration;

[0166] The simulation request module is used to trigger simulated user requests, execute the workflow corresponding to the simulated user requests, and verify the working status of the target project source code.

[0167] In an embodiment of the present application, when the workflow includes at least code cloning, product building, code scanning, code pushing, and automated testing, the simulation request module may specifically include:

[0168] Source code pulling unit, used to trigger simulated user requests and pull the project source code of the project to be migrated;

[0169] The artifact building unit is used to build artifacts for the project source code of the project to be migrated to generate a software artifact package;

[0170] The parallel push unit is used to push the software product package to the code scanning module, Nexus warehouse, product library and image deployment system in parallel. The code scanning module is used to perform static code quality detection and security vulnerability analysis. The Nexus warehouse is used to archive the product. The image deployment system is used to complete the image deployment according to the code configuration in the software product package.

[0171] The test unit is used to automatically trigger automated testing based on the push results of multiple branches and determine the results of automated testing. Automated testing includes at least unit testing, interface testing, and software interface testing.

[0172] The status verification unit is used to verify the working status of the target project source code based on the automated test results.

[0173] In the embodiment of the present application, the container-based code migration device 300 may further include the following modules:

[0174] The status push unit is used to push the working status of the migrated target project source code to project-related members.

[0175] The container-based orchestration code migration device 300 provided in an embodiment of the present application can be applied to the container-based orchestration code migration method provided in the aforementioned embodiment. For details, please refer to the description of the container-based orchestration code migration method provided in the aforementioned embodiment, which will not be repeated here.

[0176] Figure 4 Schematic diagram of the structure of the electronic device provided in the embodiment of the present application. Figure 4 As shown, the electronic device 400 of this embodiment includes: at least one processor 410 ( Figure 4 (only one is shown in the figure), a processor, a memory 420, and a computer program 421 stored in the memory 420 and executable on the at least one processor 410. When the processor 410 executes the computer program 421, the steps in the above-mentioned embodiment of the code migration method based on container orchestration are implemented.

[0177] The electronic device 400 may be a server, a physical server, a virtual machine, or an edge computing device deployed with a container service. The electronic device may include, but is not limited to, a processor 410 and a memory 420. Those skilled in the art will understand that Figure 4 This is merely an example of the electronic device 400 and does not constitute a limitation on the electronic device 400 . The electronic device 400 may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, the electronic device 400 may also include input and output devices, network access devices, etc.

[0178] The processor 410 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. A general-purpose processor may be a microprocessor or any conventional processor.

[0179] In some embodiments, the memory 420 may be an internal storage unit of the electronic device 400, such as a hard disk or memory of the electronic device 400. In other embodiments, the memory 420 may also be an external storage device of the electronic device 400, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) card, a flash memory card, etc. equipped on the electronic device 400. Furthermore, the memory 420 may include both an internal storage unit of the electronic device 400 and an external storage device. The memory 420 is used to store an operating system, application programs, a boot loader, data, and other programs, such as the program code of the computer program. The memory 420 may also be used to temporarily store data that has been output or is about to be output.

[0180] In a specific implementation, the processor 410, memory 420, and computer program 421 described in the embodiments of the present application can execute the embodiments of the code migration method based on container orchestration of the present application, which will not be repeated here.

[0181] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0182] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0183] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0184] In the embodiments provided in the present application, it should be understood that the disclosed devices / electronic devices and methods can be implemented in other ways. For example, the device / electronic device embodiments described above are merely schematic. For example, the division of the modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0185] The units described as separate components may or may not be physically separate, and 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 these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0186] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0187] If the integrated module / unit is implemented as a software functional unit and sold or used as a standalone product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application can implement all or part of the process steps in the above-mentioned method embodiments by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When executed by a processor, the computer program can implement the steps of each of the above-mentioned method embodiments. The computer program includes computer program code, which can be in source code form, object code form, executable file, or some intermediate form. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal, and software distribution medium. It should be noted that the content of the computer-readable medium can be appropriately increased or decreased based on the requirements of legislation and patent practice in a jurisdiction. For example, in some jurisdictions, based on legislation and patent practice, computer-readable media does not include electric carrier signals and telecommunication signals.

[0188] The present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed through a computer program product. When the computer program product runs on an electronic device, the electronic device can implement the steps in the above-mentioned method embodiments when executing.

[0189] The above embodiments are intended only to illustrate the technical solutions of the present application and are not intended to limit them. Although the present application has been described in detail with reference to the above embodiments, those skilled in the art should understand that they may still modify the technical solutions described in the above embodiments or replace some of the technical features therein with equivalents; and such modifications or replacements do not deviate from the spirit and scope of the technical solutions of the embodiments of the present application and should be included within the scope of protection of the present application.

Claims

1. A code migration method based on container orchestration, characterized in that: Applied to a server, the method includes: Responding to a user's project migration request, obtaining the number of projects to be migrated and their corresponding project identifiers, wherein the project name, creation time, and a random number are input into a hash function to generate a unique string of fixed length as the project identifier; When the number of items to be migrated exceeds a preset threshold, dynamically adjusting the number of replicas of the target container used to perform the migration task based on the container orchestration platform to support parallel migration of multiple items to be migrated; Allocate the project to be migrated to the corresponding target container according to the project identifier of each project to be migrated and the number of replicas of the current target container, and execute the migration task in the target container to migrate the project source code from the source warehouse to the target warehouse; By calling the API interface of the source warehouse, the key configuration of the project to be migrated is migrated to the target warehouse. The key configuration includes at least the Webhook push address configuration, the authorized member configuration, and the mirror warehouse configuration. When the push address configuration is migrated, the listening event type and key information of the push address are completely copied to the target warehouse. When the authorized member configuration is migrated, the corresponding access control policy is rebuilt in the target warehouse by parsing the user role mapping table of the source warehouse. When the mirror warehouse configuration is migrated, the mirror reference path in the build script is replaced with the mirror library address of the target warehouse; Trigger a simulated user request, execute the workflow corresponding to the simulated user request, and verify the working status of the target project source code; The performing of the migration task in the target container to migrate the project source code from the source warehouse to the target warehouse includes: By calling the API interface of the source warehouse, executing the code pull instruction, so as to clone the project source code of the project to be migrated from the source warehouse to the corresponding target container; Execute code update instructions on each branch and tag of the project to be migrated in sequence to obtain updated code, and merge it with the project source code in the corresponding target container to form the target project source code; Push the target project source code to the target warehouse.

2. The method according to claim 1, wherein The step of responding to the user's project migration request and obtaining the number of projects to be migrated and corresponding project identifiers includes: In response to a user's project migration request, the project migration request is parsed, the number of the projects to be migrated is determined, and a corresponding project identifier is assigned to each of the projects to be migrated.

3. The method according to claim 2, wherein Allocating the to-be-migrated items to the corresponding target containers according to the item identifier of each to-be-migrated item and the number of replicas of the current target container includes: Performing a modulo operation based on the project identifier of the project to be migrated and the number of replicas of the current target container to determine a modulo result corresponding to the project to be migrated; The project to be migrated is allocated to a corresponding target container according to the remainder result, wherein the remainder result corresponding to the project to be migrated is the same as the subscript identifier of the target container to which it is allocated. The subscript identifier of the target container is a sorting identifier of the target container in the container cluster, and the sorting identifier is automatically allocated based on the startup order of the containers.

4. The method according to claim 1, wherein The workflow includes at least code cloning, product building, code scanning, code pushing, and automated testing; The triggering of the simulated user request, executing the workflow corresponding to the simulated user request, and verifying the working status of the target project source code includes: Trigger a simulated user request to pull the project source code of the project to be migrated; Building a product for the project source code of the project to be migrated to generate a software product package; The software product package is pushed to the code scanning module, Nexus warehouse, product library and image deployment system in parallel. The code scanning module is used to perform static code quality detection and security vulnerability analysis. The Nexus warehouse is used to archive the product. The image deployment system is used to complete the image deployment according to the code configuration in the software product package. Automatically trigger the automated test based on the push results of multiple branches and determine the automated test results. The automated test includes at least unit testing, interface testing, and software interface testing. Verify the working status of the target project source code based on the automated test results.

5. The method according to claim 4, wherein The method further comprises: The working status of the migrated target project source code is pushed to project-related members.

6. A code migration device based on container orchestration, characterized in that: Applied to a server, the device includes: The request response module is used to respond to the user's project migration request and obtain the number of projects to be migrated and the corresponding project identifiers. The project name, creation time, and random number are input into the hash function to generate a unique string of fixed length as the project identifier; A container orchestration module, configured to dynamically adjust the number of replicas of a target container for executing a migration task based on a container orchestration platform when the number of items to be migrated exceeds a preset threshold, so as to support the parallel migration of multiple items to be migrated; A migration module is configured to allocate each project to be migrated to a corresponding target container according to its project identifier and the number of replicas in the current target container, and to execute a migration task in the target container to migrate the project source code from the source repository to the target repository; The interface call module is used to migrate the key configurations of the project to be migrated to the target warehouse by calling the API interface of the source warehouse. The key configurations include at least the Webhook push address configuration, the authorized member configuration, and the mirror warehouse configuration. Among them, when migrating the push address configuration, the listening event type and key information of the push address are completely copied to the target warehouse. When migrating the authorized member configuration, the corresponding access control policy is rebuilt in the target warehouse by parsing the user role mapping table of the source warehouse. When migrating the mirror warehouse configuration, the image reference path in the build script is replaced with the mirror library address of the target warehouse; The simulation request module is used to trigger the simulated user request, execute the workflow corresponding to the simulated user request, and verify the working status of the target project source code; The migration module includes: The code pulling unit is used to execute the code pulling instruction by calling the API interface of the source warehouse to clone the project source code of the project to be migrated from the source warehouse to the corresponding target container; A code update unit is used to execute code update instructions on each branch and tag of the migration project in sequence to obtain the updated code and merge it with the project source code in the corresponding target container to form the target project source code; Push unit, used to push the target project source code to the target warehouse.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 5 are implemented.

8. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 5 are implemented.

Images