Code management method, system, device and equipment, storage medium and program product
By storing code repository metadata through a distributed consensus component, the master-slave synchronization problem in traditional Git services is solved, enabling lightweight code repository management and open-source-friendly shared storage, thus improving code repository management efficiency.
Patent Information
- Application Number
- CN202511328706.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-09-17
- Publication Date
- 2026-01-13
AI Technical Summary
Traditional Git services consume a lot of system resources when implementing synchronous read and write operations, which affects the efficiency of code repository management. Furthermore, when processing asynchronously, a lot of work needs to be done at the application layer to maintain data consistency.
It adopts an index database and content routing table of distributed consensus components, and stores the metadata of the code repository through consensus nodes. Each Git service node in the server can directly obtain the latest metadata from the distributed consensus components, realizing lightweight code repository management without master-slave synchronization.
It solves the problem of master-slave synchronization in traditional code repository management, saves system resources, improves the efficiency of code repository management, and implements an open-source-friendly shared storage mechanism.
Smart Images

Figure CN121326293A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of software integration and deployment technology, and in particular to a code management method, system, device, equipment, storage medium, and program product. Background Technology
[0002] Code repository management, as a widely used code repository management service, is being adopted by an increasing number of enterprises and developers. Currently, most code repository management services use Git as their technical backend.
[0003] Traditional Git services, for performance reasons, require asynchronous processing to achieve synchronous read and write operations. When using asynchronous processing, traditional Git services need to perform a significant amount of work at the application layer to provide consistent service, such as setting master-slave synchronization flags for <repositories and slave nodes> and pulling inconsistent repositories from the Git master service.
[0004] The measures taken by traditional Git services to solve the master-slave synchronization problem consume a lot of system resources and affect the efficiency of code repository management. Summary of the Invention
[0005] Therefore, it is necessary to provide a code management method, system, device, equipment, storage medium, and program product that can improve the efficiency of code repository management in response to the above-mentioned technical problems.
[0006] Firstly, this application provides a code management method applied to distributed consensus components; the method includes:
[0007] If a metadata query instruction for the first code repository is received from the server, the storage location information of the first code repository in the object storage service is sent to the server using the index database and content routing table of the consensus node in the distributed consensus component.
[0008] The storage location information is used to instruct the server to send a repository data retrieval instruction to the object storage service; the repository data retrieval instruction is used to instruct the object storage service to send the code repository content of the first code repository to the server based on the storage location information.
[0009] In one embodiment, the content routing table includes one or more code repository content entries; each code repository content entry includes a repository content identifier, a data bucket identifier, and a reference counter.
[0010] The repository content identifier is a data identifier for the content of the code repository; the data bucket identifier is used to point to the data bucket storage location in the object storage service; the reference counter is used to mark the number of code repositories that currently reference the content of the current code repository;
[0011] The index database includes a list of indexes corresponding to each code repository.
[0012] In one embodiment, the storage location information includes the data bucket storage location corresponding to the code repository content of the first code repository;
[0013] Before using the consensus node's index database and content routing table to send information to the server about the storage location of the first code repository in the object storage service, the method also includes:
[0014] Based on the metadata query instructions, determine the list of indexes in the index database corresponding to the first code repository;
[0015] Based on the content identifier in the content routing table and the repository content identifier in the index list corresponding to the first code repository, the data bucket storage location corresponding to the code repository content of the first code repository is obtained.
[0016] In one embodiment, the method further includes:
[0017] If a content update instruction for the first code repository is received from the server, the content routing table and the index list corresponding to the first code repository in the index database are adjusted according to the changes in the repository content of the first code repository.
[0018] The content update instruction is sent to the distributed consensus component when the server determines that the content of the code repository corresponding to the first code repository in the object storage service has been changed.
[0019] In one embodiment, the method further includes:
[0020] If a copy creation instruction for the first code repository is received from the server, an index list corresponding to the second code repository is generated in the index database, and the reference counter in the content routing table is adjusted according to the second code repository;
[0021] The second code repository is a copy of the first code repository that retains its historical records and repository file data.
[0022] In one embodiment, the method further includes:
[0023] If a modification commit instruction for the first and second code repositories is received from the server, the content routing table and the index list corresponding to the first code repository are adjusted according to the changes in the repository content of the second code repository relative to the first code repository.
[0024] In one embodiment, the method further includes:
[0025] If it is determined that there is a code repository content entry without a reference in the content routing table, a storage space reclamation instruction is sent to the object storage service via the server;
[0026] The storage space reclamation command is used to instruct the object storage service to reclaim the storage space corresponding to unreferenced code repository content entries; unreferenced code repository content entries are code repository content entries whose reference counter in the content routing table is 0.
[0027] Secondly, this application also provides a code management method applied to a server; the method includes:
[0028] Send a metadata query command for the first code repository to the distributed consensus component;
[0029] Receive the storage location information of the first code repository in the object storage service sent by the distributed consensus component;
[0030] Based on the storage location information, send a warehouse data retrieval command to the object storage service;
[0031] The code repository content of the first code repository sent by the object storage service.
[0032] In one embodiment, the server is a Git server that provides one or more stateless Git services; a stateless Git service is a Git service that does not store or cache code repository data.
[0033] In one embodiment, the method further includes:
[0034] When a surge in traffic to the current server is detected, add one or more stateless git services.
[0035] In one embodiment, the server is a Git server deployed on a Kubernetes cluster.
[0036] Thirdly, this application also provides a code management method applied to object storage services, the method including:
[0037] Receive warehouse data retrieval instructions from the server;
[0038] Based on the repository data retrieval command and the storage location information of the first code repository in the object storage service, retrieve the code repository content of the first code repository;
[0039] Send the contents of the first code repository to the server.
[0040] In one embodiment, the method further includes:
[0041] When the current data bucket of the object storage service is found to be insufficient, a new data bucket is generated using the device's free storage space.
[0042] Fourthly, this application also provides a code management method, which includes:
[0043] The server sends a metadata query command for the first code repository to the distributed consensus component;
[0044] If the distributed consensus component receives a metadata query instruction, it uses the consensus node's index database and content routing table to send the storage location information of the first code repository in the object storage service to the server.
[0045] The server receives storage location information and sends a warehouse data retrieval instruction to the object storage service;
[0046] The object storage server receives the repository data retrieval instruction, retrieves the code repository content of the first code repository according to the storage location information, and sends the code repository content of the first code repository to the server.
[0047] Fifthly, this application also provides a code management device for use in a distributed consensus component; the device includes:
[0048] The storage location information sending module is used to send the storage location information of the first code repository in the object storage service to the server using the index database and content routing table of the consensus node in the distributed consensus component if it receives a metadata query instruction for the first code repository from the server.
[0049] The storage location information is used to instruct the server to send a repository data retrieval instruction to the object storage service; the repository data retrieval instruction is used to instruct the object storage service to send the code repository content of the first code repository to the server based on the storage location information.
[0050] Sixthly, this application also provides a code management device for use on a server; the device includes:
[0051] The metadata query instruction sending module is used to send metadata query instructions for the first code repository to the distributed consensus component;
[0052] The storage location information receiving module is used to receive the storage location information of the first code repository in the object storage service sent by the distributed consensus component;
[0053] The warehouse data retrieval instruction sending module is used to send warehouse data retrieval instructions to the object storage service based on the storage location information;
[0054] The code repository content receiving module is used to receive the code repository content of the first code repository sent by the object storage service.
[0055] Seventhly, this application also provides a code management apparatus for object storage services, the apparatus comprising:
[0056] The warehouse data retrieval instruction receiving module is used to receive warehouse data retrieval instructions from the server;
[0057] The code repository content retrieval module is used to retrieve the code repository content of the first code repository based on the repository data retrieval instruction and the storage location information of the first code repository in the object storage service.
[0058] The code repository content sending module is used to send the code repository content of the first code repository to the server.
[0059] Eighthly, this application also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described method.
[0060] Ninthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.
[0061] In a tenth aspect, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described method.
[0062] The aforementioned code management method, system, device, equipment, storage medium, and program product involve the server sending a metadata query instruction for a first code repository to a distributed consensus component. When the distributed consensus component receives the metadata query instruction, it uses the index database and content routing table of the consensus nodes to send the storage location information of the first code repository in the object storage service to the server. The server receives the storage location information and sends a repository data retrieval instruction to the object storage service. The object storage server receives the repository data retrieval instruction, retrieves the code repository content of the first code repository based on the storage location information, and sends the code repository content of the first code repository to the server. This application, through the above method, uses consensus nodes for metadata storage, enabling each Git service node in the server to directly obtain the latest metadata of each code repository from the distributed consensus component. This solves the master-slave synchronization problem in traditional code repository management schemes, thereby saving system resources and improving the efficiency of code repository management. Attached Figure Description
[0063] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0064] Figure 1 This is a schematic diagram illustrating the implementation of a traditional code repository management scheme in one embodiment;
[0065] Figure 2 This is a diagram illustrating the application environment of the code management method of this application in one embodiment;
[0066] Figure 3 This is a flowchart illustrating a code management method in one embodiment;
[0067] Figure 4 This is a schematic diagram of a traditional self-developed code repository management process based on Git services in one embodiment;
[0068] Figure 5 This is a schematic diagram of the distributed consensus component of this application in one embodiment;
[0069] Figure 6 This is a schematic diagram of the process for obtaining the data bucket storage location in one embodiment;
[0070] Figure 7 This is a schematic diagram illustrating the process of performing a warehouse data upload operation in one embodiment;
[0071] Figure 8 This is a schematic diagram illustrating the process of performing a warehouse data download operation in one embodiment;
[0072] Figure 9 This is a schematic diagram illustrating the implementation of an open-source mechanism in a traditional code repository management scheme in one embodiment;
[0073] Figure 10 This is a schematic diagram illustrating the implementation of the open-source mechanism of the present application in one embodiment;
[0074] Figure 11 This is a flowchart illustrating the code management method in another embodiment;
[0075] Figure 12 This is a schematic diagram illustrating the process of adding a node in a traditional code repository management scheme in one embodiment.
[0076] Figure 13 This is a schematic diagram illustrating the process of adding new nodes and elastically expanding capacity in one embodiment of this application;
[0077] Figure 14 This is a flowchart illustrating a code management method in yet another embodiment;
[0078] Figure 15 This is a schematic diagram of a code management system architecture in one embodiment;
[0079] Figure 16 A schematic diagram illustrating the process of adding a self-developed code repository shard to a traditional code repository management scheme in one embodiment;
[0080] Figure 17 This is a flowchart illustrating the code management method in another embodiment;
[0081] Figure 18 This is a structural block diagram of a code management device in one embodiment;
[0082] Figure 19 This is a structural block diagram of the code management device in another embodiment;
[0083] Figure 20 This is a structural block diagram of the code management device in yet another embodiment;
[0084] Figure 21 This is a diagram of the internal structure of an electronic device in one embodiment. Detailed Implementation
[0085] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.
[0086] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.
[0087] Code repository management, as a widely used code repository management service, is being adopted by more and more enterprises and developers. Most code repository management services use Git as their technical backend. The traditional deployment method of code repository management solutions is to mount a high-performance disk through the Git service and use the file system on the disk to store and manage the file data of the code repository.
[0088] For example, such as Figure 1As shown, in a traditional Git repository management system, users can interact with the Git server through a local Git client. When a user performs a code push operation (i.e., `git push`), they need to interact with a Git service node (i.e., `git server1`) that has write permissions (i.e., `wr`). This Git service processes the write operation according to the user's instructions and stores the user's uploaded data in its mounted file system. When a user performs a code clone or pull operation (i.e., `git clone` / `git pull`), they can interact with Git service nodes (i.e., `git server2`, `git server3`, `git server4`) that have read-only permissions (i.e., `ro1`, `ro2`, `ro3`). Each Git service node, acting as a read node, can read the required repository data from its corresponding mounted file system and return the repository data to the user.
[0089] Furthermore, in traditional Git repository management systems, file systems mounted by different Git services need to be synchronized asynchronously to maintain data consistency. However, in asynchronous processing, traditional Git services need to perform a significant amount of work at the application layer to provide consistent services, such as setting master-slave synchronization flags for <repositories, slave nodes> and pulling inconsistent repositories from the master Git service. These consistency measures consume considerable system resources, thus impacting the efficiency of code repository management.
[0090] Furthermore, as more and more code repositories are stored in code repository management services, and the amount of file data stored in each repository is also increasing, the traditional file system-based deployment method in code repository management services has gradually become a system performance bottleneck. Moreover, due to the open-source strategy of R&D cloud, most code repositories contain a significant amount of redundant data, further wasting system resources.
[0091] Before introducing the specific embodiments of this application, the technical terms involved in this application will be explained:
[0092] opensource: refers to the open source of a repository, meaning that the code repository can be made public for other users to view, download, and perform other operations.
[0093] fork repo: refers to copying the code repository and its modification history to create a new code repository.
[0094] Pull request: This is a mature feature of a code repository that allows users to contribute changes from a copy of the code repository to the original code repository by submitting a pull request.
[0095] etcd refers to a middleware service that implements a distributed consensus algorithm.
[0096] Gateway: Refers to a gateway, which is used to receive outbound traffic and send the traffic to the backend business server.
[0097] The code management method provided in this application embodiment can be applied to, for example, Figure 2 In the application environment shown, server 200 is communicatively connected to distributed consensus component 100 and object storage service 300, and receives traffic from Git clients through a gateway.
[0098] For example, server 200 may include one or more stateless Git services. These Git services can be used to provide users with Git functionalities such as code cloning (git clone), code pulling (git pull), and code pushing (git push) to provide multi-replica services (i.e., pods in Kubernetes). Furthermore, the Git services in server 200 can be lightweight, stateless services; that is, when these stateless Git services run, they neither store nor cache file data from various code repositories.
[0099] It is understandable that the stateless nature of the Git service can be utilized to achieve rapid restart of the Git service. Optionally, server 200 can be a standalone physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server providing cloud computing services. In one possible implementation, server 200 can be a Git server 200 deployed on a Kubernetes (k8s) cluster.
[0100] Furthermore, the object storage service 300 can be used to store Git repository content data and repository history data, thereby providing data management services for Git. In some examples, the object storage service 300 can use content addressing to store code repository data.
[0101] In one exemplary embodiment, such as Figure 3 As shown, a code management method is provided, which can be applied to... Figure 2 Taking the distributed consensus component 100 as an example, the code management method includes the following steps S302. Wherein:
[0102] Step S302: If a metadata query instruction for the first code repository is received from the server, the storage location information of the first code repository in the object storage service is sent to the server using the index database and content routing table of the consensus node in the distributed consensus component.
[0103] The storage location information can be used to instruct the server to send a repository data retrieval instruction to the object storage service; the repository data retrieval instruction can be used to instruct the object storage service to send the code repository content of the first code repository to the server based on the storage location information.
[0104] For example, a distributed consensus component can be used to communicate through multiple consensus nodes ( Figure 2 (Only 3 are shown in the text) The metadata corresponding to each code repository created by the user is stored in a consistent manner, and each consensus node can be accessed by all git service nodes in the server.
[0105] In some examples, the consensus nodes of a distributed consensus component include a content routing table and an index database. The index database can be used to store repository branch information for each code repository, while the content routing table can be used to provide information on the storage location of each code repository's content in the object storage service, as well as repository references.
[0106] It should be noted that the metadata of each code repository obtained by each Git service node on the server meets the strong consistency requirement, meaning that the metadata of the code repositories maintained by each consensus node is completely consistent. In some examples, the number of consensus nodes can be odd, and the distributed consensus component can use the Raft distributed consensus algorithm to achieve strong consistency among the consensus nodes. Optionally, the distributed consensus component can use middleware services such as ZooKeeper or etcd.
[0107] Specifically, when the distributed consensus component receives a metadata query instruction from the server for the first code repository, it uses the consensus node's index database and content routing table to send the storage location information of the first code repository in the object storage service to the server. Based on the received storage location information of the first code repository, the server sends a repository data retrieval instruction to the object storage service, instructing the object storage server to return the code repository content of the first code repository to the server based on the storage location information.
[0108] Furthermore, Figure 4 This is a traditional process for managing self-developed code repositories based on Git services. For example... Figure 4As shown, in the traditional management of self-developed code repositories, for the `git push` operation, users (i.e., actors) can initiate a code push request to the master node of the self-developed code repository service (i.e., the stateful Git service), and then the master node performs the code push operation on its mounted file systems. After the code push operation is completed, the master node and the ro node of the self-developed code repository service need to maintain data consistency between the various file systems through an asynchronous data synchronization mechanism. Similarly, for the `git pull` operation, users can choose to initiate a code pull request to either the master node or the ro node of the self-developed code repository service; the master node reads data from its own mounted file systems, and the ro node reads data from its own mounted file systems. Likewise, for the code pull operation, the master node and the ro node also need to continuously maintain data consistency and timeliness through an asynchronous data synchronization mechanism.
[0109] In the aforementioned traditional self-developed code repository management solutions, the Git service requires asynchronous processing for read and write synchronization due to performance considerations. Therefore, in order to provide consistent services to the outside world, traditional self-developed code repository management solutions need to perform tasks at the application layer, such as setting a master-slave synchronization flag for <repository, slave node> and pulling inconsistent repositories from the Git master service. Furthermore, in traditional self-developed code repository management solutions, the Git service cannot simultaneously act as both a write node and a read node.
[0110] Because this application uses a distributed consensus component to store the metadata of each code repository, each Git service node in the server can directly obtain the latest metadata information from the consensus node of the distributed consensus component, thus eliminating the master-slave synchronization problem of traditional solutions. It can be understood that, without the master-slave synchronization problem of traditional code repository management solutions, each Git service in the server of this application can simultaneously play the roles of a write node and a read node in the code repository management architecture; that is, each Git service can provide complete code management services (such as cloning / pulling / pushing code files). Through this approach, this application achieves strict external consistency while effectively saving system resources and improving the efficiency of code repository management.
[0111] In the above code management method, the server sends a metadata query instruction for the first code repository to the distributed consensus component. When the distributed consensus component receives the metadata query instruction, it uses the index database and content routing table of the consensus nodes to send the storage location information of the first code repository in the object storage service to the server. The server receives the storage location information and sends a repository data retrieval instruction to the object storage service. The object storage server receives the repository data retrieval instruction, retrieves the code repository content of the first code repository according to the storage location information, and sends the code repository content of the first code repository to the server. Through the above method, each Git service node of this application can directly obtain the latest metadata of each code repository from the distributed consensus component, solving the master-slave synchronization problem in traditional code repository management schemes. Thus, while achieving strict external consistency, it effectively saves system resources and improves the efficiency of code repository management.
[0112] In one embodiment, the content routing table includes one or more code repository content entries; each code repository content entry includes a repository content identifier, a data bucket identifier, and a reference counter.
[0113] The repository content identifier is a data identifier for the code repository content; the data bucket identifier is used to point to the data bucket storage location in the object storage service; the reference counter is used to mark the number of code repositories that currently reference the content of the current code repository; the index database includes a list of indexes corresponding to each code repository.
[0114] The index list includes one or more repository branch entries, each containing a branch name tag corresponding to the code repository and a repository content identifier.
[0115] In some examples, the repository content identifier can be calculated using a digest algorithm based on the code repository content. Digest algorithms can include MD5, SHA-1, etc.
[0116] For example, embodiments of this application provide, as follows: Figure 5 The diagram shows a distributed consensus component. Among them, such as... Figure 5 As shown, a distributed consensus component can include multiple consensus nodes (three consensus nodes are shown in the figure).
[0117] The index database includes index lists corresponding to code repositories repoA, repoB, repoC, and repoD, respectively. Taking the index list corresponding to code repository repoA as an example, the first column of the index list is the branch name label corresponding to each branch of code repository repoA. This branch name label can be user-defined for better readability. The second column of the index list is the repository content identifier (similar to a data content ID), which is associated with the specific code repository content of the code repository branch. For example, based on the code repository content, a preset digest algorithm can be used to calculate the repository content identifier for each branch. For instance, in the index list corresponding to code repository repoA, "main" in the first column is used to tag the repository content identifier "commitA" to improve readability. The data identifier "commitA" is used to find the storage location of the code repository content corresponding to "commitA" in the object storage service through the content routing table of the consensus node.
[0118] It's important to note that a "commit" corresponds to a single action by an operator in the code repository. A commit represents a change to a code file, and changes include adding, modifying, and deleting files within the code repository. It's crucial to understand that a commit is the smallest unit of change in Git and cannot be altered. Users or the Git server can retrieve the corresponding commit operation using the repository's content identifier (which can be understood as a commit ID), thereby querying the changes made to the code repository. In practice, a commit in the code repository typically includes the following information: ① The user information and commit time associated with this commit; ② The corresponding repository directory / folder (i.e., the "tree" in Git) and the content of the changed files (i.e., the "blob" in Git).
[0119] Furthermore, Figure 5 The content routing table shown has three columns: the first column is the repository content identifier, the second is the data bucket identifier, and the third is the reference counter. For example, using... Figure 5 Taking the first row of the content routing table as an example, the first row of the content routing table "commitA, bucket1, count:1" indicates that the code repository content corresponding to the repository content identifier "commitA" is stored in the data bucket 1 in the object storage service, and there is currently 1 code repository using the code repository content corresponding to "commitA".
[0120] In one embodiment, the storage location information includes the data bucket storage location corresponding to the code repository content of the first code repository; before using the consensus node's index database and content routing table to feed back the storage location information of the first code repository in the object storage service to the server, such as Figure 6 As shown, the method further includes steps S402 to S404. Wherein:
[0121] Step S402: Determine the index list corresponding to the first code repository in the index database according to the metadata query instruction.
[0122] The metadata query command can be used to instruct the distributed consensus component to return the data bucket storage location corresponding to the code repository content of the first code repository.
[0123] Specifically, when the distributed consensus component receives a metadata query instruction from the server for the first code repository, it can retrieve the index list corresponding to the first code repository from the index database.
[0124] Step S404: Based on the content identifier in the content routing table and the repository content identifier in the index list corresponding to the first code repository, obtain the data bucket storage location corresponding to the code repository content of the first code repository.
[0125] Specifically, the distributed consensus component can obtain the repository content identifiers corresponding to each branch of the current first code repository based on the index list corresponding to the first code repository. Then, based on these repository content identifiers, it can query the content routing table to obtain the repository content entries corresponding to each repository content identifier. Finally, using the data bucket identifiers corresponding to these repository content entries, it can query the data bucket storage location of the code repository content of the first code repository in the object storage service.
[0126] In one embodiment, the method further includes the following steps:
[0127] If a content update instruction for the first code repository is received from the server, the content routing table and the index list corresponding to the first code repository in the index database are adjusted according to the changes in the repository content of the first code repository.
[0128] The content update instruction is sent to the distributed consensus component when the server determines that the content of the code repository corresponding to the first code repository in the object storage service has been changed.
[0129] Specifically, when the distributed consensus component receives a content update instruction for the first code repository, it adjusts the content routing table and the index list corresponding to the first code repository in the index database according to the changes in the repository content of the first code repository (such as adding / deleting / modifying code files).
[0130] For example, taking a Git server deployed on a Kubernetes (k8s) cluster as the server and repoA as the first code repository, this application provides Figure 7 The following is an exemplary process for performing a data upload operation on a first code repository.
[0131] like Figure 7 As shown, "1.repoA / info / refs?service=git-recieve-service" is a standard Git protocol step, indicating that the user's Git client requests a data upload operation, and the Git server needs to obtain the metadata of the code repository repoA; "2.return repoA latest refs" is also a standard Git protocol step, indicating that the Git server requests the distributed consensus component to return the latest metadata of the code repository repoA; "3.repoA / git-recieve-service" is also a standard Git protocol step, indicating that the Git client requests to upload the latest file content modified by the user; "4.send packdata" indicates that the Git server will write the latest file content modified by the user into the object storage service based on the metadata information of repoA returned by the consensus node; "5.update repoA ref" indicates that after receiving the result that the data write to the object storage service is complete, the Git server sends an instruction to the distributed consensus component to update the metadata information of repoA in the consensus node (such as updating the metadata information in the content routing table and index database).
[0132] For example, taking a Git server deployed on a Kubernetes (k8s) cluster as the server and repoA as the first code repository, this application provides Figure 8 The diagram illustrates an exemplary process for performing a data download operation on a first code repository.
[0133] like Figure 8As shown, "1.repoA / info / refs?serivice=git-upload-service" is a standard Git protocol step, indicating that the user's Git client requests to perform a data download operation, and the Git server needs to obtain the metadata of the code repository repoA; "2.return repoA latest refs" indicates that the Git server requests the distributed consensus component to return the latest metadata of the code repository repoA; "3.repoA / git-upload-service" is a standard Git protocol step, indicating that the Git client requests to download the code repository content corresponding to the first code repository; "4.return repoA pack data" indicates that the Git server requests the object storage server to return the code repository content corresponding to the first code repository based on the location storage information.
[0134] In one embodiment, the method further includes the following steps:
[0135] If a copy creation instruction for the first code repository is received from the server, an index list corresponding to the second code repository is generated in the index database, and the reference counter in the content routing table is adjusted according to the second code repository.
[0136] The second code repository is a copy of the first code repository that retains its historical records and repository file data.
[0137] For example, when a user needs to create a replica code repository for the first code repository, the Git server can send a replica creation instruction for the first code repository to the distributed consensus component.
[0138] Specifically, when the distributed consensus component receives a replica creation instruction for the first code repository from the server, it generates an index list corresponding to the second code repository in the index database. Since the code repository content corresponding to the first code repository has added a reference to a code repository, the reference counter of the repository content entry corresponding to the first code repository in the content routing table also needs to be adjusted (incremented by 1).
[0139] In practical applications, the three essential components of open-source code are "opensource", "fork repo", and "pull request". "Fork repo" refers to copying the original open-source code repository, while "pull request" involves modifying files in the "forked" copy and contributing them back to the original open-source code repository.
[0140] For example, Figure 9This is an exemplary process for implementing an open-source mechanism based on a master node in a traditional code repository management solution. For example... Figure 9 As shown, in traditional code repository management schemes, each open-source code repository is an independent directory to isolate the directories of each code repository from other repository directories. When a fork operation is performed, it's equivalent to copying the original open-source code repository's directory. If the open-source code repository is large and there are many forks of that repository, it will put enormous pressure on the system storage. Similarly, when performing a pull request operation, traditional code repository management schemes also need to create a copy of the new file data (i.e., ...) in the original open-source code repository. Figure 10 (Document 3 content).
[0141] Compared to traditional code repository management solutions, the code management method proposed in this application enables a more open-source-friendly shared storage mechanism. For example, Figure 10 This document describes an exemplary process for implementing an open-source mechanism for the stateless Git service described in this application. For example... Figure 10 As shown, the distributed consensus component stores the hash value (i.e., repository content identifier) and content pointer (i.e., data bucket identifier) of the code repository content for each code repository. This content pointer points to the address of shared storage in the object storage service. When a fork operation is performed on an open-source code repository, since the code repository content remains largely unchanged, only the metadata information of the replica code repository (including metadata in the index list and content routing table) needs to be added to the distributed shared component. It can be understood that when a replica code repository is created, each content pointer points to the same shared storage address as the original open-source code repository content, without adding extra storage content. This makes the entire fork operation very lightweight, thereby saving system resources, improving the efficiency of code repository management, and implementing an open-source-friendly shared storage mechanism.
[0142] In one embodiment, the method further includes the following steps:
[0143] If a modification commit instruction for the first and second code repositories is received from the server, the content routing table and the index list corresponding to the first code repository are adjusted according to the changes in the repository content of the second code repository relative to the first code repository.
[0144] It is understandable that the second code repository is a copy of the first code repository, and users can make changes and modifications to the content of the code repository based on the second code repository.
[0145] For example, when a user needs to contribute modifications from the second code repository to the first code repository, the Git server can send a commit instruction for the modifications to both the first and second code repositories to the distributed consensus component.
[0146] Specifically, when the distributed consensus component receives a modification commit instruction from the server for the first code repository and the second code repository, it adjusts the content routing table and the index list corresponding to the first code repository according to the changes in the repository content of the first code repository relative to the second code repository.
[0147] For example, let's say the second code repository, repoB, adds a file named 3 compared to the first code repository, repoA. Figure 10 As shown, when performing a pull request operation on the forked replica repository `repoB`, since the newly added code repository content already exists in the shared storage of the object storage service, the distributed consensus component only needs to add a content pointer to the index list of the first code repository `repoA` pointing to the storage address corresponding to the newly added file 3 in the second code repository `repoB` in the object storage service, and adjust the reference counter corresponding to "file 3 content" in the content routing table. It can be understood that the pull request operation in this application does not add any additional storage content, making the entire modification and commit (pull request) operation process very lightweight, thereby saving system resources, improving the efficiency of code repository management, and realizing an open-source-friendly shared storage mechanism.
[0148] In one embodiment, the method further includes the following steps:
[0149] If it is determined that there is an unreferenced code repository content entry in the content routing table, a storage space reclamation instruction is sent to the object storage service via the server.
[0150] Among them, the storage space reclamation instruction can be used to instruct the object storage service to reclaim the storage space corresponding to unreferenced code repository content entries; unreferenced code repository content entries are code repository content entries whose reference counter in the content routing table is 0.
[0151] It is understandable that a reference counter can be used to indicate how many code repositories are currently sharing the corresponding code repository content (e.g., commit / tree / blob).
[0152] For example, both code repositories repoA and repoB contain a single code repository file with the content "hello world". The reference counter for this "hello world" blob is 2. Using reference counters, this application can reduce storage space usage for identical content and track how many times a piece of content is referenced. Furthermore, if the reference counter for a code repository content equals 0 (i.e., count = 0 in the content routing table), it means that no code repository is currently using this content. At this point, the code repository content corresponding to this entry can be deleted, reclaiming the storage space for that content in the object storage service, thereby further saving system resources.
[0153] In one exemplary embodiment, such as Figure 11 As shown, this application also provides a code management method, which is applied to... Figure 2 Taking server 200 as an example, the code management method includes the following steps S502 to S508. Wherein:
[0154] Step S502: Send a metadata query instruction for the first code repository to the distributed consensus component.
[0155] Specifically, when a user needs to query the contents of the first code repository, they can instruct the server to send a metadata query command for the first code repository to the distributed consensus component through the Git client.
[0156] Step S504: Receive the storage location information of the first code repository in the object storage service sent by the distributed consensus component.
[0157] Specifically, after receiving a metadata query instruction for the first code repository, the distributed consensus component can obtain the storage location information of the first code repository in the object storage service through the index list and content routing table corresponding to the first code repository, and return the storage location information to the server.
[0158] Step S506: Send a warehouse data retrieval instruction to the object storage service based on the storage location information.
[0159] Specifically, the server sends a repository data retrieval instruction to the object storage service based on the storage location information of the first code repository, instructing the object storage service to retrieve the code repository content of the first code repository based on the storage location information.
[0160] Step S508: Receive the code repository content of the first code repository sent by the object storage service.
[0161] Specifically, the server can receive the code repository content of the first code repository obtained by the object storage service based on the storage location information. Furthermore, the server can also send the code repository content of this first code repository to the Git client on the user's side.
[0162] In one embodiment, the server is a Git server used to provide one or more stateless git services.
[0163] Among them, stateless git service can be characterized as a git service that does not store or cache code repository data.
[0164] It is understandable that, compared with the traditional stateful Git service that directly mounts the file system, the stateless Git service in this application embodiment does not store or cache the code repository content, thereby enabling the Git service to restart quickly, making code repository management more lightweight and improving code repository management efficiency.
[0165] In some examples, each stateless Git service in the Git server can provide full Git functionality (e.g., clone / pull / push). The Git server gateway can select the appropriate Git service to implement code repository management functions based on a preset traffic policy. The preset traffic policy can be random traffic allocation or Round Robin, etc.
[0166] In one embodiment, the method further includes the following steps:
[0167] When a surge in traffic to the current server is detected, add one or more stateless git services.
[0168] It's understandable that as more and more users utilize the self-developed code repository engine service, the traffic it handles will also increase. Traditional code repository management solutions use a master-slave block-based storage strategy. However, since the self-developed code repository service mounted on disk is a stateful service, adding each read node in the traditional Git service mechanism is a heavy operation, affecting the scalability of the code repository management service.
[0169] For example, Figure 12 This is an exemplary process for adding a node operation in a traditional code repository management solution. For example... Figure 12As shown, when traffic surges and read nodes need to be added to distribute the read load, traditional code repository management solutions require starting one or more read-only Git services, mounting a corresponding high-performance disk on each new Git service, and copying the code repository from the master Git service's (i.e., the master node's) file system to the disk of the new read node. Understandably, the node addition operation in this traditional code repository management solution is quite cumbersome, consuming significant system resources and impacting code repository management efficiency.
[0170] Compared to the traditional node addition operations in the aforementioned code repository management solutions, the node addition operation in this application is very lightweight. Specifically, as follows: Figure 13 As shown, when the server determines that the current traffic has reached a set traffic threshold, it can be identified as a traffic surge. At this point, the server can add one or more stateless Git services (i.e., self-developed code repository services) and associate these stateless Git services with the distributed consensus component and object storage service. It can be understood that stateless Git services, because they do not store or cache the code repository content, can achieve rapid Git service startup. This allows for quick relief of the current server traffic pressure without consuming significant system resources, thus improving the efficiency of code repository management.
[0171] In one embodiment, the server can be a Git server deployed on a Kubernetes cluster.
[0172] It is understood that the solution provided by the code management method implemented from the server perspective is similar to the solution described in the code management method implemented from the perspective of the distributed consensus component. Therefore, the specific limitations of one or more code management method embodiments implemented from the server perspective provided below can be found in the limitations of the code management method implemented from the perspective of the distributed consensus component above, and will not be repeated here.
[0173] In one exemplary embodiment, this application also provides a code management method, such as... Figure 14 As shown, this method is applied to Figure 2 Taking the object storage service 300 as an example, the method includes the following steps S602 to S606. Wherein:
[0174] Step S602: Receive warehouse data retrieval instructions from the server.
[0175] Specifically, the repository data retrieval instruction is sent by the server to the object storage service based on the storage location information of the first code repository in the object storage service; the storage location information is sent by the distributed consensus component to the server using the index database and content routing table of the consensus node in the distributed consensus component if the distributed consensus component receives the metadata query instruction for the first code repository sent by the server.
[0176] Specifically, the object storage service can receive a repository data retrieval instruction from the server for the first code repository.
[0177] Step S604: Obtain the code repository content of the first code repository according to the repository data acquisition instruction and the storage location information of the first code repository in the object storage service.
[0178] Specifically, the object storage service can obtain the code repository content of the first code repository based on the storage location information obtained by querying the distributed consensus component.
[0179] Step S606: Send the code repository content of the first code repository to the server.
[0180] Specifically, object storage services can send the contents of the first code repository stored in each data bucket to the server.
[0181] To further illustrate, this application provides, as follows: Figure 15 This illustrates an exemplary code management system architecture. For example... Figure 15 As shown, the big file in each bucket of the object storage service is the smallest indivisible unit, typically around 64MB in size. In practice, since most files in a Git repository are small files with limited space requirements, it would be wasteful for each repository file to occupy a single storage unit (i.e., a big file) in the object storage service. To address this issue, the object storage service can aggregate small files from multiple different repositories into a single storage unit and store the data using content-addressed storage, thus avoiding wasted storage capacity and excessive data redundancy.
[0182] For example, Figure 15The `bigfile1` in the code stores the contents of four smaller files (including directories): `big file1 = {{blobAsha1→AAA}, {treeAsha1→readme blobsha1, folder / init1.txt blobsha1}, {commitAsha1→message:xxx, author:AAA, email:AAA@chinatelecom.com}, {blobBsha1→BBB}}`. It's important to note that `blobAsha1`, `treeAsha1`, and `commitAsha1` on the left of the arrows are strings calculated using the SHA-1 hash algorithm. These correspond to repository content identifiers in the content routing table and index list, allowing you to locate the file's specific content in the object storage service. The content on the right of the arrows corresponds to the specific code repository content (i.e., the code repository data). For example, `folder / init1.txt` represents the `init1.txt` file in the `folder1` directory. Furthermore, the code repository content corresponding to `commit` can include the user's change message, author name, and email address.
[0183] In one embodiment, the method further includes the following steps:
[0184] When the current data bucket of the object storage service is found to be insufficient, a new data bucket is generated using the device's free storage space.
[0185] Understandable, such as Figure 16 As shown, in traditional code repository management solutions, when the disk space mounted on the Git service is insufficient and a new self-developed code repository shard needs to be added, it is necessary to add a Git service write node and a corresponding high-performance disk to the system, and at the same time, add a Git service read node and a corresponding high-performance disk to complete the expansion operation. The above-mentioned code repository shard expansion method in traditional code repository management solutions is very cumbersome and requires a lot of operational and maintenance resources to implement.
[0186] Compared to the scaling operations of traditional code repository management solutions, the solution proposed in this application allows for elastic scaling. Specifically, as... Figure 13 As shown, when the data bucket storage space is insufficient, the Git service can dynamically detect the current capacity status in the object storage service and allocate new buckets on relatively empty devices (as shown in bucket5 in the figure) to achieve dynamic and efficient expansion, thereby effectively improving the management efficiency of the code repository.
[0187] It is understood that the solution provided by the code management method implemented from the perspective of object storage service is similar to the solution described in the code management method implemented from the perspective of distributed consensus components and servers. Therefore, the specific limitations of one or more embodiments of the code management method implemented from the perspective of object storage service provided below can be found in the limitations of the code management method implemented from the perspective of distributed consensus components and servers above, and will not be repeated here.
[0188] In one exemplary embodiment, such as Figure 17 As shown, this application also provides a code management method. Taking the application scenario shown in Figure 2 as an example, the method includes the following steps S702 to S708. Wherein:
[0189] In step S702, the server sends a metadata query instruction for the first code repository to the distributed consensus component.
[0190] In step S704, if the distributed consensus component receives a metadata query instruction, it uses the consensus node's index database and content routing table to send the storage location information of the first code repository in the object storage service to the server.
[0191] In step S706, the server receives the storage location information and sends a warehouse data retrieval instruction to the object storage service.
[0192] In step S708, the object storage server receives the repository data retrieval instruction, retrieves the code repository content of the first code repository according to the storage location information, and sends the code repository content of the first code repository to the server.
[0193] It is understood that the solution provided by the code management method implemented from the perspective of the overall code management application is similar to the solution described in the code management method implemented from the perspective of distributed consensus components, servers and object storage services. Therefore, the specific limitations of one or more embodiments of the code management method implemented from the perspective of the overall code management application provided below can be found in the limitations of the code management method implemented from the perspective of distributed consensus components, servers and object storage services above, and will not be repeated here.
[0194] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.
[0195] Based on the same inventive concept, this application also provides a code management device 800 for implementing the code management method described above. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations of one or more embodiments of the code management device 800 provided below can be found in the limitations of the code management method described above, and will not be repeated here.
[0196] In one exemplary embodiment, such as Figure 18 As shown, a code management device 800 is provided, applied to a distributed consensus component; the device 800 includes:
[0197] The storage location information sending module 802 is used to send the storage location information of the first code repository in the object storage service to the server using the index database and content routing table of the consensus node in the distributed consensus component if it receives a metadata query instruction for the first code repository sent by the server.
[0198] The storage location information is used to instruct the server to send a repository data retrieval instruction to the object storage service; the repository data retrieval instruction is used to instruct the object storage service to send the code repository content of the first code repository to the server based on the storage location information.
[0199] In one embodiment, the content routing table includes one or more code repository content entries; each code repository content entry includes a repository content identifier, a data bucket identifier, and a reference counter.
[0200] The repository content identifier is a data identifier for the content of the code repository; the data bucket identifier is used to point to the data bucket storage location in the object storage service; the reference counter is used to mark the number of code repositories that currently reference the content of the current code repository;
[0201] The index database includes a list of indexes corresponding to each code repository.
[0202] In one embodiment, the storage location information includes the data bucket storage location corresponding to the code repository content of the first code repository; the device 800 further includes:
[0203] The index list determination module is used to determine the index list in the index database corresponding to the first code repository based on the metadata query instruction;
[0204] The data bucket storage location acquisition module is used to obtain the data bucket storage location corresponding to the code repository content of the first code repository based on the content identifier of the content routing table and the repository content identifier in the index list corresponding to the first code repository.
[0205] In one embodiment, the device 800 further includes:
[0206] The first adjustment module is used to adjust the content routing table and the index list corresponding to the first code repository in the index database according to the changes in the repository content of the first code repository if it receives a content update instruction for the first code repository from the server.
[0207] The content update instruction is sent to the distributed consensus component when the server determines that the content of the code repository corresponding to the first code repository in the object storage service has been changed.
[0208] In one embodiment, the device 800 further includes:
[0209] The second adjustment module is used to generate an index list corresponding to the second code repository in the index database and adjust the reference counter in the content routing table according to the second code repository if it receives a copy creation instruction for the first code repository from the server.
[0210] The second code repository is a copy of the first code repository that retains its historical records and repository file data.
[0211] In one embodiment, the device 800 further includes:
[0212] The third adjustment module is used to adjust the content routing table and the index list corresponding to the first code repository based on the changes in the repository content of the second code repository relative to the first code repository if it receives a modification commit instruction from the server for the first code repository and the second code repository.
[0213] In one embodiment, the device 800 further includes:
[0214] The space reclamation instruction sending module is used to send a storage space reclamation instruction to the object storage service through the server if it is determined that there is an unreferenced code repository content entry in the content routing table.
[0215] The storage space reclamation command is used to instruct the object storage service to reclaim the storage space corresponding to unreferenced code repository content entries; unreferenced code repository content entries are code repository content entries whose reference counter in the content routing table is 0.
[0216] Each module in the aforementioned code management device 800 can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.
[0217] Based on the same inventive concept, this application also provides a code management device 900 for implementing the code management method described above. The solution provided by this device 900 is similar to the solution described in the above method; therefore, the specific limitations of one or more embodiments of the code management device 900 provided below can be found in the limitations of the code management method described above, and will not be repeated here.
[0218] In one exemplary embodiment, such as Figure 19 As shown, a code management device 900 is provided, applied to a server; the device 900 includes:
[0219] Metadata query instruction sending module 902 is used to send metadata query instructions for the first code repository to the distributed consensus component;
[0220] The storage location information receiving module 904 is used to receive the storage location information of the first code repository in the object storage service sent by the distributed consensus component.
[0221] The warehouse data retrieval instruction sending module 906 is used to send warehouse data retrieval instructions to the object storage service based on the storage location information;
[0222] The code repository content receiving module 908 is used to receive the code repository content of the first code repository sent by the object storage service.
[0223] In one embodiment, the server is a Git server that provides one or more stateless Git services; a stateless Git service is a Git service that does not store or cache code repository data.
[0224] In one embodiment, the device 900 further includes:
[0225] The Stateless Git Service Addition Module is used to add one or more stateless Git services when a surge in traffic to the current server is detected.
[0226] In one embodiment, the server is a Git server deployed on a Kubernetes cluster.
[0227] Each module in the aforementioned code management device 900 can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.
[0228] Based on the same inventive concept, this application also provides a code management device for implementing the code management method described above. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more code management device embodiments provided below can be found in the limitations of the code management method described above, and will not be repeated here.
[0229] In one exemplary embodiment, such as Figure 20 As shown, a code management device 1000 is provided for object storage services; the device 1000 includes:
[0230] The warehouse data retrieval instruction receiving module 1002 is used to receive warehouse data retrieval instructions from the server;
[0231] The code repository content acquisition module 1004 is used to acquire the code repository content of the first code repository based on the repository data acquisition instruction and the storage location information of the first code repository in the object storage service.
[0232] The code repository content sending module 1006 is used to send the code repository content of the first code repository to the server.
[0233] In one embodiment, the device 1000 further includes:
[0234] The elastic expansion module is used to generate new data buckets by utilizing the device's free storage space when the current data bucket storage space of the determined object storage service is insufficient.
[0235] Each module in the aforementioned code management device 1000 can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.
[0236] In one exemplary embodiment, an electronic device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 21 As shown, this electronic device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores code repository content, data buckets, content routing tables, index lists, and other data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements the aforementioned code repository management method.
[0237] Those skilled in the art will understand that Figure 21 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the electronic device to which the present application is applied. The specific electronic device may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.
[0238] In one embodiment, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.
[0239] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.
[0240] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.
[0241] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.
[0242] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.
[0243] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.
Claims
1. A code management method, characterized in that, Applied to distributed consensus components; the method includes: If a metadata query instruction for the first code repository is received from the server, the storage location information of the first code repository in the object storage service is sent to the server using the index database and content routing table of the consensus node in the distributed consensus component. The storage location information is used to instruct the server to send a repository data retrieval instruction to the object storage service; the repository data retrieval instruction is used to instruct the object storage service to send the code repository content of the first code repository to the server according to the storage location information.
2. The method according to claim 1, characterized in that, The content routing table includes one or more code repository content entries; each code repository content entry includes a repository content identifier, a data bucket identifier, and a reference counter. The repository content identifier is a data identifier for the code repository content; the data bucket identifier is used to point to the data bucket storage location in the object storage service; the reference counter is used to mark the number of code repositories that currently reference the current code repository content; The index database includes a list of indexes corresponding to each code repository.
3. The method according to claim 2, characterized in that, The storage location information includes the data bucket storage location corresponding to the code repository content of the first code repository; Before using the consensus node's index database and content routing table to send the storage location information of the first code repository in the object storage service to the server, the method further includes: Based on the metadata query instruction, determine the index list in the index database corresponding to the first code repository; Based on the content identifier in the content routing table and the repository content identifier in the index list corresponding to the first code repository, the data bucket storage location corresponding to the code repository content of the first code repository is obtained.
4. The method according to claim 2, characterized in that, The method further includes: If a content update instruction for the first code repository is received from the server, the content routing table and the index list corresponding to the first code repository in the index database are adjusted according to the changes in the repository content of the first code repository. The content update instruction is sent to the distributed consensus component when the server determines that the content of the code repository corresponding to the first code repository in the object storage service has been changed.
5. The method according to claim 2, characterized in that, The method further includes: If a copy creation instruction for the first code repository is received from the server, an index list corresponding to the second code repository is generated in the index database, and the reference counter in the content routing table is adjusted according to the second code repository; The second code repository is a copy of the first code repository that retains its historical records and repository file data.
6. The method according to claim 5, characterized in that, The method further includes: If a modification commit instruction for the first code repository and the second code repository is received from the server, the content routing table and the index list corresponding to the first code repository are adjusted according to the changes in the repository content of the second code repository relative to the first code repository.
7. The method according to claim 2, characterized in that, The method further includes: If it is determined that there is an unreferenced code repository content entry in the content routing table, then a storage space reclamation instruction is sent to the object storage service through the server; The storage space reclamation instruction is used to instruct the object storage service to reclaim the storage space corresponding to the unreferenced code repository content entry; the unreferenced code repository content entry is the code repository content entry in the content routing table whose reference counter count is 0.
8. A code management method, characterized in that, Applied to a server; the method includes: Send a metadata query command for the first code repository to the distributed consensus component; Receive the storage location information of the first code repository in the object storage service sent by the distributed consensus component; Based on the storage location information, a warehouse data retrieval instruction is sent to the object storage service. Receive the code repository content of the first code repository sent by the object storage service.
9. The method according to claim 8, characterized in that, The server is a Git server used to provide one or more stateless Git services; the stateless Git service is characterized by not storing or caching code repository data.
10. The method according to claim 9, characterized in that, The method further includes: When a surge in traffic is detected on the current server, one or more stateless git services are added.
11. The method according to any one of claims 8 to 10, characterized in that, The server is a Git server deployed on a Kubernetes cluster.
12. A code management method, characterized in that, Applied to object storage services, the method includes: Receive warehouse data retrieval instructions from the server; Based on the warehouse data retrieval instruction and the storage location information of the first code repository in the object storage service, the code repository content of the first code repository is retrieved; Send the code repository content of the first code repository to the server.
13. The method according to claim 12, characterized in that, The method further includes: When it is determined that the current data bucket storage space of the object storage service is insufficient, a new data bucket is generated using the device's free storage space.
14. A code management method, characterized in that, The method includes: The server sends a metadata query command for the first code repository to the distributed consensus component; If the distributed consensus component receives the metadata query instruction, it uses the index database and content routing table of the consensus node to send the storage location information of the first code repository in the object storage service to the server. The server receives the storage location information and sends a warehouse data retrieval instruction to the object storage service; The object storage server receives the repository data retrieval instruction, retrieves the code repository content of the first code repository according to the storage location information, and sends the code repository content of the first code repository to the server.
15. A code management device, characterized in that, Applied to distributed consensus components; the device includes: The storage location information sending module is used to send the storage location information of the first code repository in the object storage service to the server using the index database and content routing table of the consensus node in the distributed consensus component if it receives a metadata query instruction for the first code repository sent by the server. The storage location information is used to instruct the server to send a repository data retrieval instruction to the object storage service; the repository data retrieval instruction is used to instruct the object storage service to send the code repository content of the first code repository to the server according to the storage location information.
16. A code management device, characterized in that, Applied to a server; the device includes: The metadata query instruction sending module is used to send metadata query instructions for the first code repository to the distributed consensus component; The storage location information receiving module is used to receive the storage location information of the first code repository in the object storage service sent by the distributed consensus component; The warehouse data retrieval instruction sending module is used to send a warehouse data retrieval instruction to the object storage service based on the storage location information; The code repository content receiving module is used to receive the code repository content of the first code repository sent by the object storage service.
17. A code management device, characterized in that, The apparatus is used for object storage services and includes: The warehouse data retrieval instruction receiving module is used to receive warehouse data retrieval instructions from the server; The code repository content acquisition module is used to acquire the code repository content of the first code repository according to the repository data acquisition instruction and the storage location information of the first code repository in the object storage service. The code repository content sending module is used to send the code repository content of the first code repository to the server.
18. An electronic device comprising a memory and a processor, the memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 14.
19. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 14.
20. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 14.