Code migration method and device based on container arrangement, electronic equipment and medium

Abstract

The invention is suitable for the technical field of software development, and provides a code migration method and device based on container arrangement, electronic equipment and a medium, and the method comprises the steps: responding to a project migration request of a user, and analyzing the request to obtain the number of to-be-migrated projects and corresponding project identifiers; when the number of the to-be-migrated items exceeds a preset threshold value, dynamically adjusting the number of copies of a target container executing a migration task based on a container arrangement platform to realize parallel migration of multiple items; and according to the project identifier and the number of copies of the current target container, allocating each project to the corresponding target container, executing a migration task in the target container, and migrating the project source code from the source warehouse to the target warehouse. According to the scheme, the container resources can be flexibly expanded and shrunk according to the migration load, efficient and automatic multi-project code migration is achieved, and the expansibility and deployment efficiency of the system are improved.

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 needs to upgrade versions or merge cross-instance repositories due to security compliance requirements (such as the Internet Security Action) or organizational structure adjustments. Traditional downtime migration solutions require interrupting the R&D process, which will significantly affect the work efficiency of developers and increase their workload. When there are too many projects to be migrated, the existing solution requires a complete backup of the source data before performing a recovery operation. The migration time increases linearly with the amount of data, which seriously restricts 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 expand or shrink 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, and the method includes: Respond to the user's project migration request and obtain the number of projects to be migrated and the corresponding project identifiers; When the number of the items to be migrated exceeds a preset threshold, dynamically adjusting the number of copies 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; According to the project identifier of each of the projects to be migrated and the number of copies of the current target container, the projects to be migrated are allocated to the corresponding target containers, and the migration task is performed in the target containers to migrate the project source code from the source warehouse to the target warehouse.

[0005] In a possible implementation, the 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 allocated to each of the projects to be migrated.

[0006] In a possible implementation manner, 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: 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; According to the remainder result, the project to be migrated is allocated to the corresponding target container, 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 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.

[0007] In a possible implementation, executing 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 update code, and merge it with the project source code in the corresponding target container into the target project source code; Push the target project source code to the target warehouse.

[0008] In a possible implementation, the method further includes: By calling the API interface of the source warehouse, the key configuration of the project to be migrated is migrated to the target warehouse, and the key configuration includes at least the Webhook push address configuration, the authorized member configuration and the mirror warehouse configuration; Trigger a simulated user request, execute a workflow corresponding to the simulated user request, and verify the working status of the target project source code.

[0009] In a possible implementation, 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, wherein the code scanning module is used to perform static code quality detection and security vulnerability analysis, the Nexus warehouse is used to perform product archiving processing, and the image deployment system is used to complete image deployment according to the code configuration in the software product package; According to the push results of multiple branches, the automated test is automatically triggered to determine the automated test results, wherein the automated test includes at least unit testing, interface testing, and software interface testing; According to the automated test results, the working status of the target project source code is verified.

[0010] In a possible implementation, the method further includes: The working status of the migrated target project source code is pushed to project associated members.

[0011] 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, and 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; A container orchestration module, configured to dynamically adjust the number of copies of a target container for executing a migration task based on a container orchestration platform when the number of the items to be migrated exceeds a preset threshold, so as to support parallel migration of multiple items to be migrated; 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 execute the migration task in the target container to migrate the project source code from the source warehouse to the target warehouse.

[0012] 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, wherein when the processor executes the computer program, the container-based orchestration code migration method described in the first aspect is implemented.

[0013] 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-orchestration-based code migration method described in the first aspect is implemented.

[0014] A fifth aspect of an embodiment 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.

[0015] Compared with the prior art, the embodiments of the present invention have the following beneficial effects: 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 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 project identifiers, 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 to the R&D process, shortening the migration time, and dynamically adapting the migration load. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. 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 paying any creative work.

[0017] Figure 1 It is a flowchart of a code migration method based on container orchestration provided in Example 1 of the present application; Figure 2 This is a flowchart of a code migration method based on container orchestration provided in Embodiment 2 of the present application; Figure 3 It is a structural diagram of a code migration device based on container orchestration provided in Embodiment 3 of the present application; Figure 4 It is a structural schematic diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0018] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also 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 prevent unnecessary details from obstructing the description of the present application.

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

[0020] It should also be understood that the term “and / or” used in the specification and appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0021] As used in the specification and appended claims of this application, the term "if" can be interpreted as "when" or "uponce" 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 "uponce it is determined" or "in response to determining" or "uponce [described condition or event] is detected" or "in response to detecting [described condition or event]", depending on the context.

[0022] 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.

[0023] It should be understood that the size of the serial numbers of the steps 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 the present application.

[0024] In existing technologies, code repository migration usually uses a full backup and recovery method. As the number of migration projects increases, the migration time increases linearly. Traditional solutions rely on a fixed number of processing nodes and cannot dynamically adjust resources according to task loads, resulting in task backlogs in high-concurrency scenarios. When an enterprise needs to migrate hundreds of GitLab projects at the same time, existing technologies either require long downtime to wait for the migration to complete, or face the contradiction between resource waste and low migration efficiency, which will significantly affect the work efficiency of developers and increase the workload of developers.

[0025] 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. First, the method responds to the user's project migration request, obtains the number of projects to be migrated and the corresponding project identifiers, and then, when the number of projects to be migrated exceeds the 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 performed in the target container to migrate the project source code from the source warehouse to the target warehouse. The above scheme realizes the parallel migration of multiple projects by dynamically adjusting the number of copies of the target container, and assigns 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 to the R&D process, shortening the migration time and dynamically adapting the migration load.

[0026] See also Figure 1 , Figure 1 1 is a flow chart of a code migration method based on container orchestration provided in the first embodiment of the present application. The method is applied to a server, such as Figure 1 As shown, the method may include the following steps: Step 101, responding to a user's project migration request, obtaining the number of projects to be migrated and corresponding project identifiers.

[0027] It should be noted that the method in this application is run on the first server, which is independent of the second server and the third server; the second server is the source server storing the source code of the project to be migrated, and the third server is the target server receiving the source code of the target project. The first server is integrated with the operation and maintenance dashboard and CI (Continuous Integration) / CD (Continuous Deployment) module, which can support the execution of continuous integration, continuous deployment and related automated operations in the migration process.

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

[0029] In a possible implementation, in response to a user's project migration request, obtaining the number of projects to be migrated and corresponding project identifiers includes: 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.

[0030] In an embodiment of the present application, the parsing process of the project migration request can be implemented by a structured data parsing algorithm, for example, a JSON format parser is used 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, when the project array is defined in the request body, its length value is directly used as the number of projects to be migrated.

[0031] 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.

[0032] Specifically, when a user submits a project migration request containing multiple projects through the front-end interface, the request body can be encapsulated in a structured data format and transmitted to the first server. The first server then calls a preset parsing module to disassemble the request body layer by layer, identify the project list field and count its element count. For example, when the parsed projects field contains three project metadata, it is determined that the number of projects to be migrated is 3.

[0033] Subsequently, the identification generation service is called for each project metadata, and 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. 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 the cache queue to provide an index basis for the subsequent container allocation stage. Through this process, it is ensured that each project to be migrated has an independent and traceable operation identifier in the subsequent processing flow to avoid resource preemption or task conflict caused by duplicate identifiers.

[0034] For example, after the first server receives the project migration request initiated by the user, the system first parses the request. During the parsing process, the system identifies the information of the projects 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 three projects A, B, and C at the same time, the system will determine that the number of projects to be migrated is 3.

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

[0036] Through this solution, the application realizes accurate parsing of project migration requests and orderly allocation of project identifiers. This method ensures that the system can accurately grasp the number of projects to be migrated, avoiding parsing omissions or errors caused by complex request content or data redundancy. At the same time, assigning a unique identifier to each project provides a basis for subsequent parallel migration and resource allocation, and effectively prevents confusion and resource conflicts between projects. This not only improves the reliability of the migration process, but also lays the foundation for the efficient execution of the entire migration process.

[0037] Step 102: When the number of items to be migrated exceeds a preset threshold, the number of copies 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.

[0038] The container orchestration platform dynamically adjusts the number of target container copies, which can refer to automatically expanding or shrinking the number of container instances according to the scale of the project to be migrated. This can be achieved by using the Horizontal Pod Autoscaler component of Kubernetes, which triggers container instance expansion and contraction operations by monitoring the length of the task queue to ensure dynamic matching of resource supply and task load.

[0039] 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 copies of the target container used to perform the migration task by calling the API interface of the container orchestration platform.

[0040] 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.

[0041] Step 103, 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 executed in the target container to migrate the project source code from the source warehouse to the target warehouse.

[0042] 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 copies of the current target container, and the result is used as the target container index for the project allocation.

[0043] 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 API interface of the source repository. Then, update the code of each branch and tag and merge it with the cloned source code. Finally, push the merged code to the target repository.

[0044] 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: Based on the project identifier of the project to be migrated and the number of replicas of the current target container, a modulo operation is performed to determine a modulo result corresponding to the project to be migrated; According to the remainder result, the project to be migrated is allocated to the corresponding target container, 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 container.

[0045] The divisor of the remainder operation is set to the total number of target containers in operation in the current container cluster. This value changes in real time with the dynamic expansion and contraction of the container orchestration platform. The project identifier is generated using a unique coding rule. The container sorting identifier is automatically generated by the container orchestration platform when the instance is started. The specific implementation method is to generate a continuous serial number in the Kubernetes cluster based on the Pod (i.e., target container) creation timestamp to ensure that the serial number of the newly expanded target container is always the current maximum serial number plus one.

[0046] 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 modulo operation is performed on their project ID and the total number of containers after the update, 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 by 101%3 to obtain the 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 re-execute 101%1 to obtain the result of 0, and migrate to the target container with the subscript ID of 0 to continue execution.

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

[0048] According to the remainder result, the project to be migrated is assigned to the corresponding target container. In this example, the remainder result is 2, so the project to be migrated is assigned to the target container with the subscript 2. The subscript of the target container is the sorting identifier of the target container in the container cluster, and the sorting identifier is automatically assigned based on the startup order of the container. For example, the five target containers in the container cluster are assigned subscripts 0, 1, 2, 3, and 4 in the startup order.

[0049] It should be understood that the above identifier can also be an identifier that combines text, numbers, and symbols, such as the project identifier "project_123". When performing a modulo operation, first, the project identifier "project_123" is converted into a unique digital identifier, and a hash function can be used to calculate an integer value, such as 12345, and then a modulo operation is performed on the number of copies of the target container.

[0050] Through the above technical solution, the present application realizes efficient task distribution in the scenario of dynamically adjusting the number of copies of the target container. By introducing a modulo 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 problem of mapping failure 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.

[0051] In a possible implementation, a migration task is executed in a target container to migrate the project source code from a source repository to a target repository, including: By calling the API interface of the source warehouse, execute the code pull instruction to clone the project source code of the project to be migrated from the source warehouse to the corresponding target container; Execute the code update command on each branch and tag of the migration project in turn 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 the target project source code to the target repository.

[0052] Among them, in 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.

[0053] The execution order of code update instructions can be sorted based on the branch creation time, such as processing the main branch first and then the secondary branch, or processing in ascending order of the tag version number. The merge operation can use a three-way merge tool to automatically handle conflicts, and trigger the manual intervention process when the conflict rate exceeds 5%.

[0054] Specifically, the cloning process can be to directly obtain the latest code snapshot of the source repository through the API interface to avoid manual export that may miss hidden files or version information in the .git directory. When synchronizing multiple branches, the update instructions of each branch will independently generate a temporary branch, and the compatibility with the main branch will be checked through the difference analysis module before merging. For example, when an unmerged pull request is detected in a branch, a merge request record is automatically generated for subsequent tracing.

[0055] That is, when pushing to the target warehouse, it is necessary to ensure that all branches and tags are fully written. If a network interruption occurs in the middle, the transaction rollback log can be used to restore to the state before the migration. This process works in conjunction with the dynamic container expansion mechanism. Cloning ensures the integrity of the migration task in a single container, while multi-container parallel processing isolates the branch merge operations of different projects to avoid version confusion caused by resource competition.

[0056] 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 turn 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 can be 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.

[0057] 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. Code update instructions are executed for 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 multi-version 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.

[0058] 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 the preset threshold, the number of copies of the target container that executes 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 executed in the target container to migrate the project source code from the source warehouse to the target warehouse. The above-mentioned scheme realizes the parallel migration of multiple projects by dynamically adjusting the number of copies of the target container, and assigning migration tasks based on project identifiers, 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 to the R&D process, shortening the migration time, and dynamically adapting to the migration load.

[0059] 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: Step 201, responding to a user's project migration request, obtaining the number of projects to be migrated and corresponding project identifiers.

[0060] Step 202: When the number of items to be migrated exceeds a preset threshold, the number of copies 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.

[0061] Step 203, 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 executed in the target container to migrate the project source code from the source warehouse to the target warehouse.

[0062] 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 described in detail in this embodiment.

[0063] 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.

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

[0065] Among them, key configuration migration can use a logical mark deletion mechanism (using version numbers to identify historical configuration status rather than physical deletion) combined with incremental data insertion technology to migrate standardized configuration data to the target project database cluster. A two-way verification mechanism can be implemented during the migration process to ensure that the configuration is semantically consistent with the source project after synchronization, while retaining complete operation logs and version snapshots, and millisecond-level configuration recovery can be achieved through the transaction rollback interface.

[0066] 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 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, 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.

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

[0068] 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.

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

[0070] Among them, the workflow includes at least code cloning, product building, code scanning, code pushing and automated testing. In this application, different projects are suitable for different workflows.

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

[0072] Workflow configuration: Workflow is the core of the CI / CD process, which defines a series of steps from code submission to deployment. Three configuration methods are supported here: First, the Docker method requires configuration of the push code branch, service name, Docker image namespace, number of copies of the target container, and Kubernetes service.

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

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

[0075] Docker image namespace: In the Docker image repository, namespaces are used to organize and isolate different images. Choosing the right namespace can ensure orderly management of images.

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

[0077] 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.

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

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

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

[0081] Deployment server IP address: Specify the IP address of the virtual machine to which the service is to be deployed, for remote connection and deployment operations.

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

[0083] 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.

[0084] 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.

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

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

[0087] Service Name: Name the service to be pushed to the intranet repository.

[0088] After the above configuration is completed, you can execute the workflow corresponding to the simulated user request for different projects and verify the working status of the target project source code. Specifically, you can trigger a code submission event through the API to start the CI / CD pipeline. The workflow can include steps such as code cloning, product building, code scanning, code push, and automated testing. This can verify whether the migrated code can be compiled normally, whether the test passes, and whether the build product meets expectations.

[0089] At the same time, by simulating user request verification workflow, the integrity and availability of the migrated project is ensured, reducing the problems that may arise after the migration. This approach not only simplifies the migration process, but also improves the accuracy and reliability of the migration, allowing the normal development process to be quickly restored after the code migration.

[0090] Specifically, in a 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: Trigger a simulated user request to pull the source code of the project to be migrated; Build artifacts for the project source code of the project to be migrated to generate software artifact packages; Push the software artifact package to the code scanning module, Nexus repository, artifact library and image deployment system in parallel; According to the push results of multiple branches, the automated test is automatically triggered to 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.

[0091] 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.

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

[0093] For example, taking Java language as an example, Java language code migration and verification of the final migration results: A. Pull the source GitLab code through the git command; B. Execute the mvn clean install command to execute the jar build; C. Push the code to the target GitLab address through the git command; D. Execute Sonar code scanning, push product library, and image deployment respectively; E. Execute the mvn deploy command to push the Nexus repository; F. After the multi-branch nodes are summarized, perform automated testing.

[0094] For example, taking NodeJs language as an example, the NodeJs language code migration and verification of the final migration results: A. Pull the source GitLab code through Git command; B. Execute the docker build and docker --config build commands respectively (different configuration files for each project, dynamically executed); C. Push the code to the target Git address through the Git command; D. Image deployment; E. Perform automated testing; F. Send SMS / WeChat notification.

[0095] In a 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 code migration.

[0096] 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 a simulated user request to pull the project source code, the real user operation scenario is restored to ensure 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 image deployment system, realizing the synchronous execution of static code detection, product archiving and deployment verification, avoiding the waste of resources caused by serial processing.

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

[0098] 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 person in charge of R&D, 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 the pre-configured routing rules. For example, the client of the person in charge of R&D 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.

[0099] Compared with the first embodiment, the embodiment of the present application realizes the automatic migration of key configurations, avoids the tedious work of manual reconfiguration, and improves the migration efficiency. At the same time, by simulating user request verification workflow, the integrity and availability of the migrated project are ensured, and the problems that may arise after the migration are reduced. This method not only simplifies the migration process, but also improves the accuracy and reliability of the migration, so that the normal development process can be quickly restored after the code migration.

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

[0101] The container-based code migration device 300 may specifically include the following modules: 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; The container orchestration module 302 is used to dynamically adjust the number of copies 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; 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 execute the migration task in the target container to migrate the project source code from the source warehouse to the target warehouse.

[0102] In the embodiment of the present application, the request response module 301 may specifically include: 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.

[0103] In the embodiment of the present application, the migration module 303 may specifically include: A remainder unit, used 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; An allocation unit is used to allocate the project to be migrated to the 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, 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 container.

[0104] In the embodiment of the present application, the migration module 303 may further include: A code pulling unit is used to execute a code pulling instruction by calling an API interface of a source warehouse, so as 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, used to execute code update instructions on each branch and tag of the migration project in sequence to obtain update code, and merge it with the project source code in the corresponding target container into the target project source code; The push unit is used to push the target project source code to the target repository.

[0105] In the embodiment of the present application, the container-based code migration device 300 may further include the following modules: The interface calling 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, the authorized member configuration, and the image repository configuration. 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.

[0106] 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: Source code pulling unit, used to trigger simulated user requests and pull the project source code of the project to be migrated; An 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; 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 perform product archiving processing. The image deployment system is used to complete the image deployment according to the code configuration in the software product package. The test unit is used to automatically trigger automated testing and determine automated testing results based on the push results of multiple branches. Automated testing includes at least unit testing, interface testing, and software interface testing. The status verification unit is used to verify the working status of the target project source code based on the automated test results.

[0107] In the embodiment of the present application, the container-based code migration device 300 may further include the following modules: The status push unit is used to push the working status of the migrated target project source code to project-related members.

[0108] The container-based orchestration code migration device 300 provided in the 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.

[0109] 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.

[0110] The electronic device 400 may be a server, a physical server, a virtual machine, or an edge computing device that deploys 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 appreciate 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, it may also include input and output devices, network access devices, etc.

[0111] 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, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc.

[0112] 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 memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), etc. equipped on the electronic device 400. Further, the memory 420 may also 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, an application program, a boot loader (Boot Loader), data and other programs, such as the program code of the computer program, etc. The memory 420 may also be used to temporarily store data that has been output or is to be output.

[0113] 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 described in detail here.

[0114] The technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In practical applications, the above-mentioned function allocation can be 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 in a processing unit, or each unit can exist physically separately, or two or more units can be integrated in 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, which will not be repeated here.

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

[0116] Those of ordinary skill 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 to be beyond the scope of this application.

[0117] 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 only a logical function division. There may be other division methods in actual implementation, 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.

[0118] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0119] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0120] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, U disk, mobile hard disk, 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 contained in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.

[0121] The present application implements all or part of the processes in the above-mentioned embodiment method, and may 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.

[0122] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application is described in detail with reference to the above-mentioned embodiments, a person skilled in the art should understand that the technical solutions described in the above-mentioned embodiments can still be modified, or some of the technical features can be replaced by equivalents; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.

Claims

1. A code migration method based on container orchestration, characterized in that: Applied to a server, the method comprises: Respond to the user's project migration request and obtain the number of projects to be migrated and the corresponding project identifiers; When the number of the items to be migrated exceeds a preset threshold, dynamically adjusting the number of copies 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; According to the project identifier of each of the projects to be migrated and the number of copies of the current target container, the projects to be migrated are allocated to the corresponding target containers, and the migration task is performed in the target containers to migrate the project source code from the source warehouse to the target warehouse.

2. The method according to claim 1, characterized in that 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 allocated to each of the projects to be migrated.

3. The method according to claim 2, characterized in that The 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 copies 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; According to the remainder result, the project to be migrated is allocated to the corresponding target container, 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 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, characterized in that 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 update code, and merge it with the project source code in the corresponding target container into the target project source code; Push the target project source code to the target warehouse.

5. The method according to claim 1, characterized in that The method further comprises: By calling the API interface of the source warehouse, the key configuration of the project to be migrated is migrated to the target warehouse, and the key configuration includes at least the Webhook push address configuration, the authorized member configuration and the mirror warehouse configuration; 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.

6. The method according to claim 5, characterized in that The workflow at least includes 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, wherein the code scanning module is used to perform static code quality detection and security vulnerability analysis, the Nexus warehouse is used to perform product archiving processing, and the image deployment system is used to complete image deployment according to the code configuration in the software product package; According to the push results of multiple branches, the automated test is automatically triggered to determine the automated test results, wherein the automated test includes at least unit testing, interface testing, and software interface testing; According to the automated test results, the working status of the target project source code is verified.

7. The method according to claim 6, characterized in that The method further comprises: The working status of the migrated target project source code is pushed to project associated members.

8. A code migration device based on container orchestration, characterized in that: Applied to a server, the device comprises: 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; A container orchestration module, configured to dynamically adjust the number of copies of a target container for executing a migration task based on a container orchestration platform when the number of the items to be migrated exceeds a preset threshold, so as to support parallel migration of multiple items to be migrated; 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 execute the migration task in the target container to migrate the project source code from the source warehouse to the target warehouse.

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

10. 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 7 are implemented.

Images