Code processing method and device, computer equipment and readable storage medium

Abstract

The invention provides a code processing method and device, computer equipment and a readable storage medium, efficient management of versions can be achieved, the method comprises the steps that a configuration warehouse is constructed, the configuration warehouse comprises configuration files of a plurality of code warehouses, the configuration file of each code warehouse comprises version information of the code warehouse, and the version information of each code warehouse is stored in the configuration warehouse; the plurality of code warehouses comprise a main warehouse and at least one sub-warehouse; according to the version stage of the main warehouse, version information of the code warehouses is configured; and performing version management on the plurality of code repositories through the version information of the plurality of code repositories.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and more specifically, to a code processing method, apparatus, computer device, and readable storage medium. Background Art

[0002] In large-scale software projects, when a project involves multiple code repositories, these repositories are typically managed independently. For example, when finalizing a project version, the final commit for each repository must be locked one by one. This version management approach is time-consuming and labor-intensive. Therefore, achieving efficient version management is an urgent problem that needs to be solved. Summary of the Invention

[0003] The present application provides a code processing method, apparatus, computer device and readable storage medium, which can achieve efficient version management.

[0004] In a first aspect, a code processing method is provided, comprising:

[0005] Building a configuration repository, wherein the configuration repository includes configuration files of multiple code repositories, wherein the configuration file of each code repositories includes version information of the code repositories, and the multiple code repositories include a main repositories and at least one sub-repository;

[0006] Configuring version information of the multiple code repositories according to the version stage of the main repository;

[0007] Version management is performed on the multiple code repositories using the version information of the multiple code repositories.

[0008] In a second aspect, a code processing device is provided, comprising:

[0009] A construction unit is configured to construct a configuration repository, wherein the configuration repository includes configuration files of multiple code repositories, wherein the configuration file of each code repositories includes version information of the code repositories, and the multiple code repositories include a main repository and at least one sub-repository;

[0010] A configuration unit, configured to configure version information of the multiple code repositories according to the version stage of the main repository;

[0011] The version management unit is configured to perform version management on the multiple code repositories based on the version information of the multiple code repositories.

[0012] In a third aspect, a computer device is provided, comprising a processor and a memory, wherein the memory is configured to store a computer program, and the processor is configured to call and execute the computer program stored in the memory to perform the method of the first aspect or its implementations.

[0013] In a fourth aspect, a computer-readable storage medium is provided for storing a computer program, which enables a computer to execute the method in the above-mentioned first aspect or its various implementations.

[0014] In a fifth aspect, a computer program product is provided, comprising computer program instructions, wherein the computer program instructions enable a computer to execute the method in the above-mentioned first aspect or its various implementations.

[0015] In a sixth aspect, a computer program is provided, which, when executed on a computer, enables the computer to execute the method in the first aspect or its various implementations.

[0016] Based on the above technical solution, multiple code repositories can be managed through their configuration files in independent configuration repositories. Specifically, each code repository's configuration file includes its version information. This information is configured based on the version phase of the main repository, enabling efficient version management of the multiple code repositories. Furthermore, each code repository corresponds to a separate configuration file, making the configuration of each code repository relatively independent and more clearly structured, reducing the possibility of conflicts when multiple people operate simultaneously. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 It is a schematic diagram of an application scenario applicable to an embodiment of the present application.

[0018] Figure 2 This is a schematic flowchart of a code processing method provided in an embodiment of the present application.

[0019] Figure 3 This is a schematic diagram of a configuration warehouse provided in an embodiment of the present application.

[0020] Figure 4 This is a schematic diagram of a one-click warehouse deployment provided in an embodiment of the present application.

[0021] Figure 5 This is a schematic flowchart of switching from product dependency to source code dependency provided in an embodiment of the present application.

[0022] Figure 6 This is a schematic block diagram of a code processing device provided in an embodiment of the present application.

[0023] Figure 7 This is a schematic block diagram of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0024] The following will describe the technical solutions in the embodiments of this application in conjunction with the drawings in the embodiments of this application. Obviously, the embodiments described are part of the embodiments of this application, not all of the embodiments. With respect to the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0025] It should be understood that in the embodiments of the present application, "B corresponding to A" means that B is associated with A. In one implementation, B can be determined based on A. However, it should also be understood that determining B based on A does not mean determining B based solely on A; B can also be determined based on A and / or other information.

[0026] In this application, unless otherwise specified, "at least one" means one or more, and "plurality" means two or more. Furthermore, "and / or" describes the association between related objects, indicating that three possible relationships exist. For example, "A and / or B" can mean: A exists alone, A and B exist simultaneously, and B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the related objects are in an "or" relationship.

[0027] It should be understood that the first, second, etc. descriptions appearing in the embodiments of the present application are only for illustration and distinction of the description objects, and there is no order. They do not represent any special limitation on the number of devices in the embodiments of the present application, and cannot constitute any limitation on the embodiments of the present application.

[0028] It should also be understood that the specific features, structures, or characteristics associated with the embodiments in the specification are included in at least one embodiment of the present application. In addition, these specific features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0029] In addition, the terms "include" and "have" and any variations thereof are intended to cover a non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, product, or device.

[0030] To facilitate understanding of the embodiments of the present application, the technologies related to the present application are explained.

[0031] A Git repository is a version control system for storing and managing code. It uses Git commands and tools for version control, code review, and branch management, improving development efficiency and code quality. Git allows multiple developers to store code in a local repository and share and collaborate with other developers by pushing it to a remote repository.

[0032] Git repositories can be categorized as local and remote. A local repository is a repository on a developer's computer, used to store and manage code files. Developers can commit, modify, and view history in the local repository, and push files and version information from the local repository to a remote repository. A remote repository can be a repository stored on a remote server, allowing multiple developers to share and collaborate.

[0033] Commit is a key concept in Git repositories. A commit is the process of saving locally modified files to the local repository. Each commit saves the file and version information to the local repository and generates a unique commit record (e.g., a commit ID) that identifies the code version. By viewing the commit history, you can understand the code change process and modification history.

[0034] Branches are another important concept in Git repositories. They enable parallel development and experimentation without affecting the stability of the main branch. Branches can contain multiple commits, which can be integrated by merging them back into the main branch. Using branches makes it easy to add features, fix bugs, and manage multiple development lines flexibly.

[0035] In software development and project management, a dependency usually refers to the dependency of one project or component on another. These dependencies can be source dependencies or binary dependencies.

[0036] A source dependency is when one project or component directly depends on the source code of another project or component. This means that the dependent project is compiled and linked from source code during the build process. A product dependency is when one project or component depends on the compilation products of another project or component (for example, binary files such as AAR (Android Archive), JAR (Java Archive), DLL (Dynamic Link Library), or other compiled files).

[0037] In the Android build system, source code dependencies and product dependencies are two common types of dependencies. Source code dependencies are dependencies built directly from source code, while product dependencies are dependencies built from precompiled binaries or APKs.

[0038] Figure 1 A schematic diagram of an application scenario of an embodiment of the present application is shown. Figure 1As shown, it includes a terminal 110 and a server 120. The terminal 110 communicates with the server 120 through a network.

[0039] In some implementations, terminal 110 refers to a device that supports a variety of human-computer interaction methods, has Internet access, typically runs various operating systems, and has strong processing capabilities. For example, terminal 110 may be a laptop computer, desktop computer, tablet computer, smartphone, wearable device, in-vehicle device, or other terminal device, but is not limited thereto.

[0040] In some implementations, server 120 may be an independent physical server, or a server cluster or distributed system composed of multiple physical servers. It may also be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. The server may also become a node of the blockchain. The server may be one or more servers. When there are multiple servers, there are at least two servers for providing different services, and / or there are at least two servers for providing the same service, such as providing the same service in a load balancing manner. This is not limited in the embodiments of the present application.

[0041] In some implementations, the network may be a wireless or wired network such as an intranet, the Internet, a Global System of Mobile communication (GSM), a Wideband Code Division Multiple Access (WCDMA), a 4G network, a 5G network, Bluetooth, Wi-Fi, or a call network.

[0042] In large-scale software projects, when a project involves multiple code repositories, the version management solutions in related technologies are usually to manage each code repository independently. The main repository only relies on the compiled products of the sub-repository (such as AAR dependency libraries). When the version is released, the compiled products of the sub-repository are directly used in the final compilation.

[0043] However, this version management solution has some obvious disadvantages:

[0044] 1. There is a lack of unified management of versions in multiple warehouses.

[0045] For example, during the version development cycle, the existing management model keeps each code repository relatively independent, hindering unified version management. For example, when finalizing a version, it's necessary to lock the final commit for each code repository. Under the existing management model, this can only be done individually, which is time-consuming and labor-intensive. Furthermore, after a version is released, there's no unified version archive for each code repository, making it difficult to restore the corresponding code when troubleshooting a specific version.

[0046] 2. The environment deployment process for multiple code repositories is cumbersome.

[0047] For example, when a development requirement involves multiple code repositories, the version branches of each repository need to be manually switched. In addition, each repository may also require initialization of different configuration items, making the environment deployment of each repository cumbersome and time-consuming.

[0048] 3. There are risks caused by product dependence.

[0049] For example, the main project often relies on independent repositories via compilation artifacts (such as AAR dependency libraries). The compilation process doesn't verify the correctness of the code that calls between AAR libraries. This makes it impossible to detect code errors early during the compilation process, increasing the risk of online application crashes. Furthermore, using artifact dependencies makes code debugging and troubleshooting difficult.

[0050] In response to the above problems, it is necessary to seek an improved warehouse version management solution to achieve unified version management, simplify the environment deployment process, and reduce the risks brought by product dependencies.

[0051] In response to the shortcomings of traditional version management solutions, the embodiments of the present application propose a code processing method that can uniformly configure each code repository through an independent configuration repository, simplifying the version management process and avoiding the problem of separate version configuration for each code repository. Each code repository corresponds to a separate configuration file, which makes the configuration of each code repository relatively independent, the structure clearer, and reduces the possibility of conflicts when multiple people operate at the same time. Specifically, the configuration file of the code repository includes the version information of the code repository. According to the stage of the software development cycle, by configuring the version information of the code repository, effective management of the entire software development cycle can be achieved, such as version management in the version start stage, the version finalization stage, and the release stage.

[0052] Furthermore, a set of command tools is provided, through which users can quickly deploy and initialize various code repositories, reducing the complexity of multi-repository environment deployment, enabling flexible warehouse environment deployment, and realizing on-demand deployment of source code repositories, thereby improving development efficiency.

[0053] Furthermore, the dependency relationship between the main repository and sub-repositories can be freely switched between source code dependency and product dependency. The dependency relationship can be configured according to the stage of the software development cycle. For example, during the debugging phase, the dependency can be configured as a source code dependency. This allows code errors to be discovered early during the compilation process, reducing the risk of online application crashes and facilitating code debugging and troubleshooting. During the testing phase, the dependency can be configured as a product dependency, which can speed up the test package output.

[0054] In some implementations, a configuration repository and at least one code repository are deployed on a terminal, and a configuration repository and at least one code repository are deployed on a server. The configuration repository deployed on the terminal is referred to as a local configuration repository, and the configuration repository deployed on the server is referred to as a remote configuration repository. The configuration repository can be used to manage the at least one code repository, such as for version management. The configuration repository can be implemented as a Git repository.

[0055] In some implementations, the configuration repository may include configuration files for each code repository, ensuring that the configuration of each code repository is relatively independent. This can reduce conflicts when multiple developers on a team operate on a code repository at the same time.

[0056] To facilitate understanding of the technical solutions of the embodiments of the present application, the technical solutions of the present application are described in detail below through specific embodiments. The following related technologies can be combined with the technical solutions of the embodiments of the present application as optional solutions, and they all fall within the scope of protection of the embodiments of the present application. The embodiments of the present application include at least part of the following contents.

[0057] Each embodiment of the present application provides a code processing method, which can be executed by a terminal or a server, or by both the terminal and the server. The embodiments of the present application illustrate the code processing method by the server as an example.

[0058] See also Figures 2 to 4 ,in, Figure 2 is a schematic flow chart of a code processing method provided in an embodiment of the present application. Figure 3 This is a schematic diagram of a configuration warehouse provided in an embodiment of the present application. Figure 4 This is a schematic diagram of a one-click warehouse deployment method provided by an embodiment of the present application. The method 200 may include at least some steps:

[0059] S210: Build a configuration repository, where the configuration repository includes configuration files of multiple code repositories, wherein the configuration file of each code repositories includes version information of the code repositories, and the multiple code repositories include a main repositories and at least one sub-repository;

[0060] S220: Configure version information of the multiple code repositories according to the version stage of the main repository;

[0061] S230: Perform version management on the multiple code repositories according to the version information of the multiple code repositories.

[0062] In some embodiments, the configuration repository and the multiple code repositories can be Git repositories or Git repositories. The configuration repository can include a local configuration repository and a remote configuration repository, wherein the local configuration repository is deployed on a terminal, such as a developer's local host, and the remote configuration repository is deployed on a server. Project managers can configure or manage the multiple code repositories through the local configuration repository or the remote configuration repository. The code repository can include a local code repository and a remote code repository, wherein the local code repository is deployed on a terminal, such as a developer's local host, and the remote code repository is deployed on a server.

[0063] In some embodiments, the configuration repository can be developed based on Dart, or other extensible programming languages, which are not limited in this application. Dart is an efficient and extensible programming language with excellent cross-platform performance. Therefore, using Dart to develop the configuration repository can ensure that the configuration repository can run smoothly on different operating systems and platforms, thereby meeting the needs of various development environments.

[0064] In an embodiment of the present application, the configuration repository is an independent repository used to uniformly configure or manage the multiple code repositories. For example, the configuration repository includes configuration files of the multiple code repositories, and the configuration file of each code repository includes version information of the code repository, so that the code repository can be version managed through the version information of the code repository. In this way, for large projects involving multiple code repositories, version management of the multiple code repositories can be achieved only through the configuration repository, thereby achieving unified and efficient version management.

[0065] In some embodiments, the configuration repository may have one or more branches, and each branch of the configuration repository may correspond to different version information of the multiple code repositories. Therefore, in an embodiment of the present application, different versions of the multiple code repositories can be recorded through different branches of the configuration repository. In this way, when performing version restoration, different versions of the multiple code repositories can be restored through different branches of the configuration repository, which facilitates subsequent problem finding and repair.

[0066] In some embodiments, the configuration files of the code repository can be considered as metadata, and the configuration repository can be considered as a metadata repository.

[0067] In some embodiments, the configuration file of each code repository may include at least one of the following information:

[0068] The name of the code repository (denoted as name), which is used to uniquely identify a code repository;

[0069] The local path of the code repository (denoted as path), which is used to indicate the local storage path of the code repository;

[0070] The remote path of the code repository (remote), or in other words, the Git address of the code repository;

[0071] Version information of the code repository;

[0072] Group information of the code repository;

[0073] The deployment information (or necessity information) of the code repository is used to indicate whether the code repository must be deployed. For example, for some basic repositories, each business needs to be deployed, so you can set it to require deployment;

[0074] The initialization script information of the code repository is used to automatically initialize and configure the code repository.

[0075] In some implementations, when a code repository is deployed locally, the target code repository to be deployed can be indicated by the name of the code repository.

[0076] In some implementations, the local path of the code repository (or, the path to the local code repository) can be relative to the root directory of the local configuration repository, where the root directory of the local configuration repository can be the root directory of the folder where the local configuration repository is located, that is, the path to the local workspace. Using a relative path as the local path of the code repository helps ensure that the local code repository storage path of project team members is consistent.

[0077] In some implementations, code repositories can be grouped according to business or needs. In this way, a group can include one or more code repositories, and different code repositories may belong to different groups. When deploying a code repository locally, the target code repository to be deployed can be indicated by the group information of the code repository. For example, Group 1 includes Code Repository 1, Code Repository 2, and Code Repository 3, and Group 2 includes Code Repository 4, Code Repository 5, and Code Repository 6. When deploying a code repository, the group information of the code repository to be deployed can be indicated as Group 1. Then, according to this indication, Code Repository 1, Code Repository 2, and Code Repository 3 in Group 1 can be deployed.

[0078] In some implementations, the version information of a code repository can be configured as branch information of the code repository, indicating that the current version of the code repository is configured as a branch of the code repository. Exemplarily, the branch information may include a branch name (or branch identifier), and a branch build record, such as the build time, build person, and build reason.

[0079] In other implementations, the version information of the code repository can also be configured as a commit information of the code repository, which is used to indicate that the current version of the code repository is configured as a commit of the code repository. Exemplarily, the commit information includes the commit name (or commit identifier), the commit build record, such as the content of the change submitted, the change time, the change person, and other information. By configuring the version information of the code repository as a commit of the code repository, it is equivalent to recording the precise commit point of each code repository. On the one hand, it can prevent the submission of untested code in the finalization stage, and on the other hand, it is convenient to restore the version in the future so as to find and fix problems when needed.

[0080] In some implementations, the version information of a code repository can also be configured as a tag for the code repository. This tag can be used to mark a commit of the code repository. By using a tag to mark a commit, the version information does not need to include all the information of a commit, thereby reducing storage space usage. For example, the version information of a code repository can be configured as a tag at a specific node (such as a release, milestone, or revision).

[0081] Figure 3 A schematic diagram of the deployment of a configuration repository and a code repository is shown. Figure 3 As shown, the configuration repository can include a repository configuration directory containing configuration files for the multiple code repositories, as well as a repository directory pointing to the local code repositories of the multiple code repositories. Developers can perform operations such as committing and modifying files based on the local code repositories and push files in the local code repositories to the remote code repository, allowing multiple developers to share and collaborate.

[0082] In some implementations, the local path of the code repository uses a soft link, and the local code repository directory is a soft link directory, including soft links to local code repositories of multiple code repositories, and the soft links of local code repositories point to the local code repository. Managing repository directories through soft links can have the following advantages:

[0083] 1. Improve the efficiency of adding and deleting repositories: Soft links can be created and deleted very quickly because they only require modifying the metadata of the file system without actually moving or copying files. This makes adding and deleting repositories more efficient.

[0084] 2. Save storage space: The soft link itself does not occupy the actual storage space of the file or directory, so using soft links to manage warehouse directories can save storage space and avoid repeated storage of the same files.

[0085] 3. Flexible warehouse organization: Through soft links, you can flexibly organize and manage warehouse directories without modifying the actual structure of files or directories, which helps to achieve clearer and more efficient warehouse management.

[0086] For example, Figure 3 In the example, the warehouse configuration directory may include a configuration file for warehouse one, a configuration file for warehouse two, and the like. For example, the configuration file for warehouse one may include the following information:

[0087] Repository 1 name: flutter_tools

[0088] The local path of warehouse 1 is project / wrouter;

[0089] The remote path of warehouse 1 is: http: / / git.xx.com / xxx / flutter_tools.git;

[0090] Version information of warehouse 1: master;

[0091] Warehouse 1's group information: yyy, indicating the business or requirements implemented by Warehouse 1;

[0092] Deployment information (necessity information) of warehouse 1: True, which means deployment is required.

[0093] The repository directory can include a soft link to repository 1, a soft link to repository 2, etc. For example, the soft link to repository 1 can be project / wrouter.

[0094] In some embodiments, configuring the version information of the multiple code repositories according to the version stage of the main repository includes:

[0095] Before the main repository is finalized (e.g., in the development phase, debugging phase, or testing phase), the version information of the code repository is configured as the branch information of the code repository; or

[0096] When the main repository is in the finalization stage, configuring the version information of the code repository as the first submission information of the code repository, wherein the finalized version of the main repository is generated based on the version branch corresponding to the first submission information of the code repository; or

[0097] When the main repository is in the version release stage, the version information of the code repository is configured as the second submission information or tag information of the code repository, wherein the tag information is used to mark a submission information of the code repository, wherein the release version of the main repository is generated based on the second submission information of the code repository or the version branch corresponding to the tag information.

[0098] In some implementations, the branch information can be used to indicate a specific branch of the code repository. For example, the branch information includes the branch name (or branch identifier) ​​of the specific branch, and branch build records, such as build time, builder, build reason, and other information.

[0099] In some implementations, the first commit information may indicate a specific commit of the code repository. For example, the first commit information may include the commit name (or commit identifier) ​​of the specific commit, the commit build record, such as the content of the changes made in this commit, the time of the change, the person who made the change, and other information.

[0100] In some implementations, the second commit information may indicate a specific commit of the code repository. For example, the second commit information may include the commit name (or commit identifier) ​​of the specific commit, the commit build record, such as the content of the changes made in this commit, the time of the change, the person who made the change, and other information.

[0101] In some implementations, the first tag information can be used to mark a specific commit of the code repository. Therefore, the first tag information does not need to include all the information of the specific commit. This approach can reduce storage space usage.

[0102] In some embodiments, the first commit information, the second commit information, or the first tag information may correspond to the latest commit of the code repository, or may also correspond to the previous commit of the code repository, etc., depending on the specific version management method, which is not limited by this application. For example, when the latest commit of the code repository is not finalized with the main repository, the version information of the code repository may be set to the commit information or tag information of the previous version of the code repository.

[0103] In some implementations, project managers can configure the version information of the multiple code repositories based on the version stage of the main repository. For example, the version information of the multiple code repositories in the remote configuration repository can be configured based on the version stage of the main repository, or the versions of the multiple code repositories in the local configuration repository can be configured based on the version stage of the main repository and further pushed to the remote configuration repository.

[0104] Therefore, in the embodiment of the present application, the version information of each code repository can be flexibly configured at different version stages, thereby achieving unified and effective management of the version of each code repository in the entire software development cycle.

[0105] In some embodiments, after the version of the code repository is released, the method 200 further includes:

[0106] The first branch of the configuration repository is locked, and an archive record of the first branch is generated, wherein the first branch of the configuration repository is used to store version information of the multiple code repositories corresponding to the release version of the main repository.

[0107] That is, when the version of the main repository is released, the corresponding branch of the configuration repository can be locked, and an archive record of the branch can be generated, such as the archiving time, the version information of each code repository corresponding to the branch, etc. This will facilitate code restoration in the future based on the version information of each code repository, and help find and fix problems in the code.

[0108] In some implementations, when deploying a code repository, you can deploy the code repository as a specific version based on the version information of the code repository to be deployed. For example, if the version information of the code repository is branch information, you can obtain the latest code on the branch corresponding to the branch information; or if the version information of the code repository is commit information, you can obtain the submitted code corresponding to the commit information; or if the version information of the code repository is tag information, you can obtain the submitted code corresponding to the tag information.

[0109] In some embodiments of the present application, the method 200 further includes:

[0110] receiving a first instruction, wherein the first instruction includes target branch information of a configuration repository and a remote address of the configuration repository;

[0111] According to the target branch information of the configuration warehouse, obtaining the target branch of the configuration warehouse from the remote address of the configuration warehouse;

[0112] Obtaining configuration files of the multiple code repositories from a target branch of the configuration repository;

[0113] The target branch of the configuration repository is deployed locally, and the code repository is deployed locally based on the configuration files of the multiple code repositories.

[0114] Therefore, the embodiment of the present application can realize branch switching of multiple code repositories by configuring the branch information of the warehouse. Therefore, there is no need to switch the branches of the multiple code repositories one by one, which is conducive to the rapid deployment of the code warehouse.

[0115] For example, when multiple code repositories include warehouse one, warehouse two and warehouse three, the version information of each warehouse corresponding to branch 1 of the configuration warehouse is: the version information of warehouse one is commit 1-1, the version information of warehouse two is commit 2-1, and the version information of warehouse three is commit 3-1; the version information of each warehouse corresponding to branch 2 of the configuration warehouse is: the version information of warehouse one is commit 1-2, the version information of warehouse two is commit 2-1, and the version information of warehouse three is commit 3-2; the version information of each warehouse corresponding to branch 3 of the configuration warehouse is: the version information of warehouse one is commit 1-2, the version information of warehouse two is commit 2-2, and the version information of warehouse three is commit 3-2; if the version information of warehouse one needs to be deployed as commit 1-2, the version information of warehouse two is commit 2-1, and the version information of warehouse three is commit 3-2, then the branch 2 of the deployment configuration warehouse can be indicated. Based on branch 2 of the configuration warehouse, the corresponding branches of each warehouse can be obtained, thereby realizing branch switching of multiple warehouses.

[0116] In some implementations, receiving the first instruction may include:

[0117] A first instruction is received through a visual interface of the terminal.

[0118] For example, when a developer needs to develop software, he can enter a first instruction in the visual interface of the terminal. The first instruction may include information about the configuration repository that the developer needs to deploy. For example, the branch information and remote address information of the configuration repository that needs to be deployed. In response to the first instruction, the target branch of the configuration repository can be obtained from the remote address of the configuration repository, wherein the target branch of the configuration repository includes configuration files of multiple code repositories, and then the code repository is deployed locally based on the configuration files of the multiple code repositories. The configuration file of each code repository may include the version information of the code repository,

[0119] In some implementations, the locally deploying the code repository based on the configuration files of the multiple code repositories includes:

[0120] Constructing a local code repository directory according to the local paths of the multiple code repositories, wherein the local code repository directory points to the local code repository of the multiple code repositories;

[0121] Obtain target codes corresponding to the version information of the multiple code repositories from remote paths of the multiple code repositories, and save the target codes to a local code repository of the multiple code repositories.

[0122] by Figure 3Taking the warehouse configuration in as an example, if multiple code repositories include warehouse one, warehouse two and warehouse three, the configuration file of warehouse one, the configuration file of warehouse two and the configuration file of warehouse three can be obtained from the target branch of the configuration warehouse, wherein the configuration file of each warehouse includes the version information of the warehouse, the local path and the remote path of the warehouse. Furthermore, the corresponding code can be pulled from the remote path of the warehouse to the local code repository of the warehouse based on the version information of each warehouse. For example, if the version information of warehouse one is configured as specific branch information, the latest code on the branch corresponding to the specific branch information of warehouse one can be pulled to the local code repository of warehouse one. For another example, if the version information of warehouse one is configured as specific commit information, the submitted code corresponding to the specific commit information of warehouse one can be pulled to the local code repository of warehouse one. For another example, if the version information of warehouse one is configured as specific tag information, the submitted code corresponding to the specific tag information of warehouse one can be pulled to the local code repository of warehouse one.

[0123] In some implementations, the local paths of the multiple code repositories are soft links, and the local code repository directory is a soft link directory. Constructing the local code repository directory based on the local paths of the multiple code repositories includes:

[0124] A soft connection directory is constructed according to the local paths of the multiple code repositories, wherein the soft connection directory includes soft links of local code repositories of the multiple code repositories, and the soft links of the local code repositories point to the local code repositories.

[0125] by Figure 3 Taking the repository configuration in as an example, if multiple code repositories include warehouse one, warehouse two, and warehouse three, the constructed local code repository directory may include soft links to warehouse one, warehouse two, and warehouse three, where the soft link to warehouse one points to the local code repository of warehouse one, the soft link to warehouse two points to the local code repository of warehouse two, and the soft link to warehouse three points to the local code repository of warehouse three.

[0126] In some embodiments, deploying a code repository locally based on configuration files of multiple code repositories includes:

[0127] Deploy the code repository locally based on the deployment information of the multiple code repositories;

[0128] For example, when the deployment information of the code repository indicates that the code repository needs to be deployed, the code repository is deployed locally; or, when the deployment information of the code repository indicates that the code repository does not need to be deployed, the code repository is not deployed locally.

[0129] In an embodiment of the present application, pulling the code on the remote path of the code repository to the local can be achieved by calling a clone or checkout command.

[0130] In some embodiments, deploying a code repository locally based on configuration files of multiple code repositories includes:

[0131] Initialize and configure the multiple code repositories according to the initialization script files of the multiple code repositories, for example, initialize the development environments of the multiple code repositories.

[0132] Therefore, the embodiment of the present application can be based on the command tool to pull the code repository that the developer wants to deploy with one click, and can automatically execute the initialization script file of the code repository to initialize the development environment of the code repository, which can reduce the tedious operations such as manual pulling of repositories, switching branches, and initializing repositories, and can achieve rapid deployment of multiple repositories.

[0133] Figure 4 A schematic diagram of a one-click code repository deployment method provided by an embodiment of the present application is shown. Upon receiving the first command, the target branch of the configuration file to be deployed can be obtained, and the configuration file of the code repository to be deployed can be obtained based on the target branch. Then, the clone or checkout command is called to pull the code of the code repository to the local computer, and the code repository is further initialized using the code repository's initialization script file.

[0134] Exemplarily, the first command may be wecom clone-u xxxxxx-b br_mm-g, where xxxxxx represents the remote address of the configuration repository, and br_mm represents the target branch of the configuration repository to be pulled.

[0135] In some embodiments, the method 200 further includes:

[0136] A second command is received, where the second command includes information about the code repository to be deployed, such as its name, group information, version information, etc. Furthermore, the code corresponding to the version information of the code repository can be pulled locally based on the name or group information of the code repository.

[0137] In some embodiments of the present application, the method 200 further includes:

[0138] Based on the version stage of the main repository, dependency configuration information corresponding to at least one sub-repository is configured. This dependency configuration information is used to configure the main repository's dependency on the sub-repository as either a source code dependency or a product dependency. Using source code dependency facilitates code writing and debugging, and better ensures the correctness of code calls. Using product dependency helps speed up compilation and improve packaging efficiency.

[0139] In some implementations, if the code of the main warehouse is in the debugging stage, the dependency configuration information corresponding to the sub-warehouse participating in the debugging of the main warehouse is configured as source code dependency, or the dependency configuration information corresponding to the sub-warehouse that does not participate in the debugging of the main warehouse (for example, the main warehouse has an AAR product dependency on the sub-warehouse) is configured as product dependency. In this way, configuring the dependency configuration information corresponding to the sub-warehouse with product dependency compiled by the main warehouse as source code dependency is conducive to realizing the joint debugging of codes in multiple warehouses and ensuring the correctness of code calls. Configuring the dependency configuration information corresponding to the sub-warehouse with source code dependency compiled by the main warehouse as product dependency is conducive to improving compilation efficiency.

[0140] In other implementations, when the code for the main repository is in the testing phase, the dependency configuration information corresponding to the sub-repositories of the main repository is configured as product dependencies. When the main repository is in the testing phase, it means that the code has been debugged and code call issues have been resolved. In this case, the dependency configuration information corresponding to the sub-repositories that the main repository depends on can be configured as product dependencies to improve the efficiency of test package production.

[0141] In some implementations, when the code of the main repository is in the finalization or release phase, the dependency configuration information corresponding to the sub-repositories of the main repository is configured as source code dependencies. When the main repository is in the finalization or release phase, configuring the dependency configuration information corresponding to the sub-repositories that the main repository depends on as source code dependencies helps ensure code correctness and reduce the risk of online application crashes.

[0142] Therefore, in an embodiment of the present application, the dependency configuration information can be used to quickly switch the dependency of the main warehouse on the sub-warehouse between source code dependency and product dependency, thereby supporting various compilation scenarios such as development, debugging, testing, versioning, and release. The flexibility of free switching of dependencies enables this solution to take advantage in different development stages, improve the overall development efficiency of the project, and ensure the correctness of the code.

[0143] In some embodiments, the dependency configuration information corresponding to the at least one sub-repository can be included in a project's properties file (e.g., local.properties). For example, the dependency configuration information corresponding to at least one sub-repository is a product dependency by default. If the dependency configuration information corresponding to one or more sub-repositories needs to be modified to a source dependency, the name of the sub-repository whose dependency configuration information needs to be modified can be included in the project's properties file.

[0144] In some embodiments, the dependency configuration information corresponding to the at least one sub-repository can be configured via an operating system environment variable. For example, the dependency configuration information corresponding to at least one sub-repository may default to a product dependency. When the dependency configuration information corresponding to one or more sub-repositories needs to be switched to a source code dependency, the name of the sub-repository whose dependency configuration information needs to be modified can be included in the operating system environment variable configuration.

[0145] For example, use sourceBuildModel (that is, use the source code dependency build model) as the primary key and set the value to the name of the sub-repository whose dependency configuration information needs to be modified, as shown below:

[0146] sourceBuildModel=aaa,bbb,ccc

[0147] Among them, aaa, bbb, and ccc represent the names of sub-repositories. That is, the dependency relationship of the main repository on sub-repositories aaa, bbb, and ccc needs to be switched to source code dependency.

[0148] In some embodiments, the method 200 further includes:

[0149] Obtain dependency configuration information corresponding to the at least one sub-warehouse;

[0150] Obtaining source code or products of the at least one sub-warehouse according to dependency configuration information corresponding to the at least one sub-warehouse;

[0151] According to the source code or product of the at least one sub-warehouse, code management is performed on the main warehouse, for example, compilation management is performed on the main warehouse.

[0152] Combine Figure 5 The present invention provides a method for switching from product dependency to source code dependency. Figure 5 The following steps may be included:

[0153] S501, when starting to compile a main project, adding at least one sub-project to the main project, wherein the main project is a project in a main repository, and the at least one sub-project corresponds to the at least one sub-repository, and the sub-project is a project in a sub-repository;

[0154] For example, use IncludeBuild to completely include at least one sub-project into the main project.

[0155] S502, searching for modules included in each sub-project and excluding invalid modules, such as modules already existing in the main project, such as the App module, to obtain at least one dependency of the main project on each sub-project, wherein one dependency corresponds to one module of the sub-project.

[0156] For example, using the gradle plug-in, the modules of the sub-project can be dynamically found when compiling the main project, and invalid modules can be excluded.

[0157] Step 503: Obtain the source code of the module corresponding to each dependency, and replace the dependency with the source code of the corresponding module.

[0158] For example, the source code of the module corresponding to each dependency is obtained from the local path of the sub-repository corresponding to each sub-project. For example, if the first dependency corresponds to a module in the first sub-repository, the source code corresponding to the module can be obtained based on the local path of the first sub-repository, and the first dependency in the main project can be replaced with the source code corresponding to the module.

[0159] S504 : Compile the main project based on the source code of the module corresponding to each dependency, thereby realizing the source code dependency of the main project on the sub-project.

[0160] In some implementations, first use the Gradle plugin to obtain at least one dependency of the main project, recorded as a DependencyResolveDetails object; then use the useTarget method of DependencyResolveDetails to replace the dependency with an empty dependency library. This dependency library has no code and is only used to replace the dependency; further use the project.findProject() method in the Gradle plugin to find the local source code corresponding to the module; then call

[0161] project.dependencies.add(), add the local source code to the corresponding empty dependency library.

[0162] In summary, the embodiments of the present application propose a code processing method that can uniformly configure each code repository through an independent configuration repository, simplifying the version management process of multiple repositories, avoiding the problem of separately configuring versions for each code repository, and achieving efficient version management. Among them, each code repository corresponds to a separate configuration file, which makes the configuration of each code repository relatively independent, the structure is clearer, and reduces the possibility of conflicts when multiple people operate simultaneously. Specifically, the configuration file of the code repository includes the version information of the code repository. The version information of the code repository is configured according to the stage of the software development cycle, thereby achieving effective management of the entire software development cycle, such as the version management of the version start stage, the finalization stage, and the release stage. For different branches of the configuration repository, the administrator can be responsible for maintaining the version number of the code repository provided by the branch, the submission information of the source code of the associated code repository, etc. Therefore, by managing the version information of multiple code repositories, the version and submission of the code repository can be locked during the release stage of the version, and a snapshot of the release can be generated to record the overall information of this release. The administrator can use this snapshot to review the permissions, security, etc. of the configuration repository.

[0163] In addition, the embodiments of the present application also provide a set of command tools that users (such as project managers) can use to quickly deploy and initialize various code repositories through commands, reducing the complexity of multi-repository environment deployment, enabling flexible warehouse environment deployment, and realizing on-demand deployment of code repositories, thereby improving development efficiency. For different integration platforms, the command tools provided by this application can automatically deploy and update code repositories based on the configuration files in the configuration repository.

[0164] In addition, the embodiment of the present application can also support the free switching of the dependency relationship between the main warehouse and the sub-warehouse between source code dependency and product dependency. And according to the stage of the software development cycle, the dependency relationship is configured. For example, in the debugging stage, the dependency relationship is configured as source code dependency. In this way, code errors can be discovered in advance during the compilation process, reducing the risk of online application crashes, and facilitating code debugging and problem troubleshooting. In the testing stage, the dependency relationship is configured as product dependency. In this way, the speed of test package output can be improved.

[0165] The specific embodiments of the present application are described in detail above in conjunction with the accompanying drawings. However, the present application is not limited to the specific details in the above embodiments. Within the technical concept of the present application, a variety of simple modifications can be made to the technical solution of the present application, and these simple modifications all fall within the scope of protection of the present application. For example, the various specific technical features described in the above specific embodiments can be combined in any suitable manner unless there is any contradiction. In order to avoid unnecessary repetition, the present application will not further explain various possible combinations. For another example, the various different embodiments of the present application can also be arbitrarily combined, and as long as they do not violate the ideas of the present application, they should also be regarded as the contents disclosed in the present application.

[0166] It should also be understood that in the various method embodiments of the present application, the order of the sequence numbers of the above-mentioned processes does not imply 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 embodiments of the present application. It should be understood that these sequence numbers can be interchanged where appropriate, so that the embodiments of the present application described can be implemented in an order other than those shown or described.

[0167] Combined with the following Figures 6 and 7 , describe in detail the device embodiments of the present application.

[0168] Figure 6 Schematic block diagram of the code processing device 600 of the embodiment of the present application. Figure 6 As shown, the apparatus 600 includes:

[0169] A construction unit 610 is configured to construct a configuration repository, wherein the configuration repository includes configuration files of multiple code repositories, wherein the configuration file of each code repositories includes version information of the code repositories, and the multiple code repositories include a main repository and at least one sub-repository;

[0170] A configuration unit 620 is configured to configure version information of the multiple code repositories according to the version stage of the main repository;

[0171] The version management unit 630 is configured to perform version management on the multiple code repositories based on the version information of the multiple code repositories.

[0172] In some implementations, the configuration unit 620 is specifically configured to:

[0173] Before the main repository is finalized, the version information of the code repository is configured as the branch information of the code repository; or

[0174] When the main repository is in the finalization stage, configuring the version information of the code repository as the first submission information of the code repository, wherein the finalized version of the main repository is generated based on the version branch corresponding to the first submission information of the code repository; or

[0175] When the main repository is in the version release stage, the version information of the code repository is configured as the second submission information or tag information of the code repository, wherein the tag information is used to mark a submission information of the code repository, wherein the release version of the main repository is generated based on the second submission information of the code repository or the version branch corresponding to the tag information.

[0176] In some embodiments or alternatively, the apparatus 600 further includes:

[0177] A processing unit is used to lock the first branch of the configuration repository and generate an archive record of the first branch during the version release stage of the main repository, wherein the first branch of the configuration repository is used to store the version information of the multiple code repositories corresponding to the release version of the main repository.

[0178] In some embodiments, the apparatus 600 further includes:

[0179] A receiving unit, configured to receive a first instruction, wherein the first instruction includes target branch information of the configuration repository and a remote address of the configuration repository;

[0180] an acquiring unit, configured to acquire the target branch of the configuration repository from the remote address of the configuration repository according to the target branch information of the configuration repository; and acquire configuration files of the plurality of code repositories from the target branch of the configuration repository;

[0181] A deployment unit is used to locally deploy the target branch of the configuration repository and to locally deploy the code repository based on the configuration files of the multiple code repositories.

[0182] In some implementations, the configuration file of each code repository further includes a remote path of the code repository and a local path of the code repository, and the deployment unit is further configured to:

[0183] Constructing a local code repository directory according to the local paths of the multiple code repositories, wherein the local code repository directory points to the local code repository of the multiple code repositories;

[0184] Obtain target codes corresponding to the version information of the multiple code repositories from remote paths of the multiple code repositories, and save the target codes to a local code repository of the multiple code repositories.

[0185] In some implementations, the local path of the code repository is a soft link, and the soft link of the code repository points to the local code repository of the code repository.

[0186] In some implementations, the local paths of the multiple code repositories are relative paths relative to the root directory of the folder where the configuration repository is located.

[0187] In some implementations, the configuration file of each code repository further includes deployment information of the code repository, where the deployment information of the code repository is used to indicate whether the code repository needs to be deployed, and the deployment unit is further configured to:

[0188] When the deployment information of the code repository indicates that the code repository needs to be deployed, locally deploy the code repository; or

[0189] When the deployment information of the code repository indicates that the code repository does not need to be deployed, the code repository is not deployed locally.

[0190] In some implementations, the configuration file of the code repository includes an initialization script file of the code repository, and the deployment unit is further configured to:

[0191] Initialize and configure the multiple code repositories according to the initialization script files of the multiple code repositories.

[0192] In some implementations, the configuration unit 620 is further configured to:

[0193] According to the version stage of the main warehouse, the dependency configuration information corresponding to the at least one sub-warehouse is configured, wherein the dependency configuration information is used to configure the dependency of the main warehouse on the sub-warehouse as source code dependency or product dependency.

[0194] In some implementations, the configuration unit 620 is further configured to:

[0195] If the main warehouse is in the debugging stage, the dependency configuration information corresponding to the sub-warehouse participating in the debugging of the main warehouse is configured as source code dependency, and the dependency configuration information corresponding to the sub-warehouse not participating in the debugging of the main warehouse is configured as product dependency; or

[0196] When the main warehouse is in the testing phase, all dependency configuration information corresponding to the at least one sub-warehouse is configured as product dependency; or

[0197] When the main warehouse is in the finalization stage or the release stage, the dependency configuration information corresponding to the at least one sub-warehouse is configured as source code dependency.

[0198] In some embodiments, the apparatus 600 further includes:

[0199] an acquisition unit, configured to acquire dependency configuration information corresponding to the at least one sub-warehouse; and acquire source code or artifacts of the at least one sub-warehouse based on the dependency configuration information corresponding to the at least one sub-warehouse;

[0200] A management unit is used to manage the code of the main warehouse based on the source code or product of the at least one sub-warehouse.

[0201] In some implementations, the management unit is further configured to:

[0202] If the dependency configuration information of the at least one sub-repository indicates that all of them are configured as source code dependencies, when compiling the main project corresponding to the main repository, add the sub-project corresponding to each sub-repository in the at least one sub-repository to the main project corresponding to the main repository;

[0203] Searching for modules included in the sub-projects of each sub-warehouse and excluding modules already existing in the main project, to obtain at least one dependency of the main project on each sub-project, wherein one dependency corresponds to one module of a sub-process;

[0204] Obtain the source code of the module corresponding to the main project's dependency on each sub-project according to the local path of the sub-warehouse corresponding to each sub-project;

[0205] Replace the main project's dependencies on each sub-project with the source code of the corresponding module;

[0206] Compile the main project.

[0207] It should be understood that the device embodiment and the method embodiment may correspond to each other, and similar descriptions may refer to the method embodiment. To avoid repetition, they will not be described here. Specifically, Figure 6 The device 600 shown can execute the above method embodiment, and the above and other operations and / or functions of each module in the device 600 are respectively for implementing the corresponding processes in the above method 200. For the sake of brevity, they are not repeated here.

[0208] The apparatus of the embodiment of the present application is described above from the perspective of functional modules in conjunction with the accompanying drawings. It should be understood that the functional module can be implemented in hardware form, can be implemented by instructions in software form, or can be implemented by a combination of hardware and software modules. Specifically, the steps of the method embodiment in the embodiment of the present application can be completed by the hardware integrated logic circuit and / or software form instructions in the processor, and the steps of the method disclosed in the embodiment of the present application can be directly embodied as being executed by a hardware decoding processor, or can be executed by a combination of hardware and software modules in the decoding processor. Optionally, the software module can be located in a mature storage medium in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps in the above method embodiment in conjunction with its hardware.

[0209] like Figure 7 It is a schematic block diagram of a computer device 700 provided in an embodiment of the present application.

[0210] like Figure 7 As shown, the computer device 700 may include:

[0211] Memory 710 and processor 720, the memory 710 is used to store computer programs and transmit the program code to the processor 720. In other words, the processor 720 can call and run the computer program from the memory 710 to implement the method in the embodiment of the present application. For example, the processor 720 can be used to execute the corresponding steps in the above-mentioned method 300 according to the instructions in the computer program.

[0212] In some implementations, the processor 720 is specifically configured to:

[0213] Building a configuration repository, wherein the configuration repository includes configuration files of multiple code repositories, wherein the configuration file of each code repositories includes version information of the code repositories, and the multiple code repositories include a main repositories and at least one sub-repository;

[0214] Configuring version information of the multiple code repositories according to the version stage of the main repository;

[0215] Version management is performed on the multiple code repositories using the version information of the multiple code repositories.

[0216] For example, before the main repository is finalized, the version information of the code repository is configured as the branch information of the code repository; or when the main repository is in the finalization stage, the version information of the code repository is configured as the first submission information of the code repository, wherein the finalized version of the main repository is generated based on the version branch corresponding to the first submission information of the code repository; or when the main repository is in the version release stage, the version information of the code repository is configured as the second submission information or tag information of the code repository, wherein the tag information is used to mark a submission information of the code repository, wherein the release version of the main repository is generated based on the second submission information of the code repository or the version branch corresponding to the tag information.

[0217] In some embodiments of the present application, the processor 720 may include but is not limited to:

[0218] General-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, etc.

[0219] In some embodiments of the present application, the memory 710 includes but is not limited to:

[0220] Volatile memory and / or non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link DRAM (SLDRAM), and direct RAM bus random access memory (DR RAM).

[0221] In some embodiments of the present application, the computer program may be divided into one or more modules, which are stored in the memory 710 and executed by the processor 720 to implement the coding method provided by the present application. The one or more modules may be a series of computer program instruction segments capable of performing specific functions, and the instruction segments are used to describe the execution process of the computer program in the computer device 700.

[0222] Optionally, the computer device 700 may further include:

[0223] The transceiver 730 may be connected to the processor 720 or the memory 710 .

[0224] The processor 720 may control the transceiver 730 to communicate with other devices. Specifically, the processor 720 may send information or data to other devices or receive information or data sent by other devices. The transceiver 730 may include a transmitter and a receiver. The transceiver 730 may further include one or more antennas.

[0225] It should be understood that the various components in the computer device 700 are connected via a bus system, wherein the bus system includes not only a data bus but also a power bus, a control bus and a status signal bus.

[0226] The present application also provides a computer-readable storage medium for storing a computer program. The computer-readable storage medium can be applied to a computer device, and the computer program causes the computer device to execute the corresponding process in the method embodiment of the present application. For the sake of brevity, it is not further described here.

[0227] The present application also provides a computer program product comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the corresponding process of the method embodiment of the present application. For the sake of brevity, these instructions are not further described here.

[0228] The present application also provides a computer program comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the corresponding process of the method embodiment of the present application. For the sake of brevity, these instructions are not further described here.

[0229] When software is used for implementation, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a digital video disc (DVD)), or a semiconductor medium (e.g., a solid state drive (SSD)).

[0230] It is understandable that in the specific implementation of this application, when the above embodiments of this application are applied to specific products or technologies and involve relevant data such as user information, user permission or consent is required, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards.

[0231] Those skilled in the art will appreciate that the modules 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.

[0232] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the modules is merely a logical function division. In actual implementation, there may be other division methods, such as multiple modules 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 modules, which can be electrical, mechanical or other forms.

[0233] Modules described as separate components may or may not be physically separate, and components displayed as modules may or may not be physical modules, i.e., they may be located in one place or distributed across multiple network elements. Some or all of the modules may be selected based on actual needs to achieve the purpose of the present embodiment. For example, the functional modules in the various embodiments of the present application may be integrated into a processing module, or each module may exist physically separately, or two or more modules may be integrated into a single module.

[0234] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in the present application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A code processing method, characterized in that: include: Building a configuration repository, wherein the configuration repository includes configuration files of multiple code repositories, wherein the configuration file of each code repositories includes version information of the code repositories, and the multiple code repositories include a main repositories and at least one sub-repository; Configuring version information of the multiple code repositories according to the version stage of the main repository; Version management is performed on the multiple code repositories using the version information of the multiple code repositories.

2. The method according to claim 1, characterized in that The configuring the version information of the multiple code repositories according to the version stage of the main repository includes: Before the main repository is finalized, the version information of the code repository is configured as the branch information of the code repository; or When the main repository is in the finalization stage, configuring the version information of the code repository as the first submission information of the code repository, wherein the finalized version of the main repository is generated based on the version branch corresponding to the first submission information of the code repository; or When the main repository is in the version release stage, the version information of the code repository is configured as the second submission information or tag information of the code repository, wherein the tag information is used to mark a submission information of the code repository, wherein the release version of the main repository is generated based on the second submission information of the code repository or the version branch corresponding to the tag information.

3. The method according to claim 2, characterized in that The method further comprises: During the version release phase of the main repository, the first branch of the configuration repository is locked and an archive record of the first branch is generated, wherein the first branch of the configuration repository is used to store version information of the multiple code repositories corresponding to the release version of the main repository.

4. The method according to any one of claims 1 to 3, characterized in that The method further comprises: receiving a first instruction, wherein the first instruction includes target branch information of the configuration repository and a remote address of the configuration repository; According to the target branch information of the configuration warehouse, obtaining the target branch of the configuration warehouse from the remote address of the configuration warehouse; Obtaining configuration files of the multiple code repositories from a target branch of the configuration repository; The target branch of the configuration repository is deployed locally, and the code repository is deployed locally based on the configuration files of the multiple code repositories.

5. The method according to claim 4, characterized in that The configuration file of each code repository further includes a remote path of the code repository and a local path of the code repository. The locally deploying the code repository based on the configuration files of the multiple code repositories includes: Constructing a local code repository directory according to the local paths of the multiple code repositories, wherein the local code repository directory points to the local code repository of the multiple code repositories; Obtain target codes corresponding to the version information of the multiple code repositories from remote paths of the multiple code repositories, and save the target codes to a local code repository of the multiple code repositories.

6. The method according to claim 5, characterized in that The local path of the code repository is a soft link, and the soft link of the code repository points to the local code repository of the code repository.

7. The method according to claim 5, characterized in that The local paths of the multiple code repositories are relative paths to the root directory of the folder where the configuration repository is located.

8. The method according to claim 4, characterized in that The configuration file of each code repository further includes deployment information of the code repository, where the deployment information of the code repository is used to indicate whether the code repository needs to be deployed. The locally deploying the code repository based on the configuration files of the multiple code repositories includes: When the deployment information of the code repository indicates that the code repository needs to be deployed, locally deploy the code repository; or When the deployment information of the code repository indicates that the code repository does not need to be deployed, the code repository is not deployed locally.

9. The method according to any one of claims 1 to 3, characterized in that The method further comprises: According to the version stage of the main warehouse, the dependency configuration information corresponding to the at least one sub-warehouse is configured, wherein the dependency configuration information is used to configure the dependency of the main warehouse on the sub-warehouse as source code dependency or product dependency.

10. The method according to claim 9, characterized in that The configuring dependency configuration information corresponding to the at least one sub-warehouse according to the version stage of the main warehouse includes: If the main warehouse is in the debugging stage, the dependency configuration information corresponding to the sub-warehouse participating in the debugging of the main warehouse is configured as source code dependency, and the dependency configuration information corresponding to the sub-warehouse not participating in the debugging of the main warehouse is configured as product dependency; or When the main warehouse is in the testing phase, all dependency configuration information corresponding to the at least one sub-warehouse is configured as product dependency; or When the main warehouse is in the finalization stage or the release stage, the dependency configuration information corresponding to the at least one sub-warehouse is configured as source code dependency.

11. The method according to claim 9, characterized in that The method further comprises: Obtain dependency configuration information corresponding to the at least one sub-warehouse; Obtaining source code or products of the at least one sub-warehouse according to dependency configuration information corresponding to the at least one sub-warehouse; Code management is performed on the main warehouse based on the source code or product of the at least one sub-warehouse.

12. The method according to claim 11, characterized in that The performing code management on the main warehouse according to the source code or product of the at least one sub-warehouse includes: If the dependency configuration information of the at least one sub-repository indicates that all of them are configured as source code dependencies, when compiling the main project corresponding to the main repository, add the sub-project corresponding to each sub-repository in the at least one sub-repository to the main project corresponding to the main repository; Searching for modules included in the sub-projects of each sub-warehouse and excluding modules already existing in the main project, to obtain at least one dependency of the main project on each sub-project, wherein one dependency corresponds to one module of a sub-process; Obtain the source code of the module corresponding to the main project's dependency on each sub-project according to the local path of the sub-warehouse corresponding to each sub-project; Replace the main project's dependencies on each sub-project with the source code of the corresponding module; Compile the main project.

13. A code processing device, characterized in that: include: A construction unit is configured to construct a configuration repository, wherein the configuration repository includes configuration files of multiple code repositories, wherein the configuration file of each code repositories includes version information of the code repositories, and the multiple code repositories include a main repository and at least one sub-repository; A configuration unit, configured to configure version information of the multiple code repositories according to the version stage of the main repository; The version management unit is configured to perform version management on the multiple code repositories based on the version information of the multiple code repositories.

14. A computer device, characterized in that: The computer device includes a processor and a memory, wherein a computer program is stored in the memory, and the processor is configured to execute the code processing method according to any one of claims 1 to 12 by calling the computer program stored in the memory.

15. A computer-readable storage medium, characterized in that Used to store a computer program, wherein the computer program causes a computer to execute the method according to any one of claims 1 to 12.

Images