A code version management method, device, system and storage medium

Abstract

The application provides a code version management method, device, system and storage medium, comprising: creating a new code version branch for each current data warehouse, merging a first requirement code branch into the new code version branch to obtain a merged code version branch, comparing the first requirement code branch and the merged code version branch when receiving a test pass notification of the merged code version branch, setting a new code version branch version number as a version number of each current data warehouse when the first requirement code branch is contained in the merged code version branch and when the code of the merged code version branch is different from that of an initial code version branch, and constructing the code of each current data warehouse according to the merged code version branch. Thus, the application can automatically manage the code version, greatly improves the efficiency of batch operation, avoids errors caused by manual operation, improves the accuracy of code version management, and reduces the code risk.

Description

Technical Field

[0001] This application relates to the field of computers, and in particular to a code version management method, apparatus, system, and storage medium. Background Technology

[0002] Currently, Git is the most mainstream code management tool, used by many large projects for version control in conjunction with company-required releases. However, because Git is primarily designed for general code management, it doesn't provide adequate automation for some specialized management scenarios.

[0003] For example, see Figure 1 As shown, this is a heavy-duty gateway system that integrates multiple message protocols in the backend. To facilitate code management, the project is divided into several sub-projects, such as core modules, plugin modules, and interface encapsulation modules, which are managed in different repositories. When delivering and deploying, all repository code is compiled and packaged uniformly.

[0004] Since different interface repositories correspond to different backend business systems, and the related requirements are strongly dependent on the backend business systems, the timing and frequency of modifications to different repositories vary greatly. At the same time, the entire project is required to be released as a whole based on the version. Therefore, many difficulties are encountered in the actual development process. The traditional solution is to rely on manual modification and adjustment, which is labor-intensive, inefficient and inaccurate, and consumes a lot of time and manpower. Summary of the Invention

[0005] In view of this, the purpose of this application is to provide a code version management method, apparatus, system and storage medium that can improve the accuracy and efficiency of code management while reducing labor costs.

[0006] This summary section is provided to briefly introduce the concepts, which will be described in detail in the detailed description section below. This summary section is not intended to identify key or essential features of the claimed technical solution, nor is it intended to limit the scope of the claimed technical solution.

[0007] To achieve the above objectives, this application provides the following technical solution:

[0008] In a first aspect, embodiments of this application provide a code version management method, including:

[0009] Create new code version branches for each current data warehouse;

[0010] Obtain each requirement code branch of each data warehouse. When the requirement code branch belongs to the new code version branch, it is used as the first requirement code branch. The first requirement code branch is merged into the new code version branch to obtain the merged code version branch.

[0011] When the test pass notification of the merged code version branch is received, the first requirement code branch and the merged code version branch are compared. If the first requirement code branch is included in the merged code version branch, the code differences between the merged code version branch and the initial code version branch are determined. If they are different, the version number of the new code version branch is used as the version number of each current data warehouse.

[0012] Based on the merged code version branch, the code of each current data warehouse is built and packaged into a deployment package.

[0013] Secondly, embodiments of this application also provide a code version management device, including:

[0014] Version creation unit, used to create new code version branches for each current data warehouse;

[0015] The requirement branch merging unit is used to obtain each requirement code branch of each data warehouse. When the requirement code branch belongs to the new code version branch, it is used as the first requirement code branch. The first requirement code branch is merged into the new code version branch to obtain the merged code version branch.

[0016] The version sealing unit is used to compare the first requirement code branch and the merged code version branch when it receives the test pass notification of the merged code version branch. When the first requirement code branch is included in the merged code version branch, it determines the code differences between the merged code version branch and the initial code version branch. If they are different, the version number of the new code version branch is used as the version number of each current data warehouse.

[0017] The version release unit is used to build the code of each current data warehouse according to the merged code version branch and package it into a deployment package.

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

[0019] This application provides a code version management method, apparatus, system, and storage medium. The method includes: creating new code version branches for each current data warehouse; obtaining each requirement code branch of each data warehouse; when a requirement code branch belongs to the new code version branch, using it as the first requirement code branch; merging the first requirement code branch into the new code version branch to obtain a merged code version branch; upon receiving a test pass notification for the merged code version branch; comparing the first requirement code branch and the merged code version branch; if both first requirement code branches are included in the merged code version branch; determining the code differences between the merged code version branch and the initial code version branch; if they differ, using the version number of the new code version branch as the version number of each current data warehouse; and building and packaging the code of each current data warehouse into a deployment package based on the merged code version branch. Therefore, this application can automate code version management, reducing manual workload while greatly improving the efficiency of batch operations, avoiding errors that may occur during manual operations, improving the accuracy of code version management, and reducing code risks. Attached Figure Description

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

[0021] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0022] Figure 1 A schematic diagram of a traditional data warehouse system is shown;

[0023] Figure 2 A flowchart of a code version management method provided in an embodiment of this application is shown;

[0024] Figure 3 A schematic diagram of a code version management device provided in an embodiment of this application is shown. Detailed Implementation

[0025] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0026] The term "comprising" and its variations as used herein are open-ended inclusions, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below.

[0027] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0028] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0029] As described in the background section, Git is currently the most mainstream code management tool, used by many large projects for version control in conjunction with company-required releases. However, because Git is primarily designed for general code management, it cannot effectively automate certain specialized management scenarios.

[0030] For example, see Figure 1 As shown, this is a heavy-duty gateway system that integrates multiple message protocols in the backend. To facilitate code management, the project is divided into several sub-projects, such as core modules, plugin modules, and interface encapsulation modules, which are managed in different repositories. When delivering and deploying, all repository code is compiled and packaged uniformly.

[0031] Since different interface repositories correspond to different backend business systems, and the related requirements are strongly dependent on the backend business systems, the timing and frequency of modifications to different repositories vary greatly. At the same time, the entire project is required to be released as a whole based on the version. Therefore, many difficulties are encountered in the actual development process. The traditional solution is to rely on manual modification and adjustment, which is labor-intensive, inefficient and inaccurate, and consumes a lot of time and manpower.

[0032] Specifically, the aforementioned difficulties mainly manifest as follows:

[0033] 1) If each version involves simultaneous modifications to multiple repositories, it requires creating the same version branch in multiple repositories, and then creating a separate requirement branch for each requirement, before finally merging them together. This process requires a great deal of manual intervention and checking, making it difficult to avoid omissions.

[0034] 2) Each version change requires modifying the version number of the corresponding repository. When there are multiple requirements in the same repository, modifying the version number becomes very troublesome. If the version number is modified for each requirement branch, it will inevitably lead to a lot of conflicts. If the modification is not made in the requirement branch but in the version branch, the requirement developers generally cannot directly operate the version branch due to permission issues. It is necessary to designate a special person to cooperate in modifying the version number of the version branch, which is inefficient.

[0035] 3) Due to the large number of repositories, code review before each version is released is extremely difficult. Reviewers need to know exactly how many repositories were modified in this version and how many requirements were addressed. This places too high a demand on reviewers and takes up too much of their time. Moreover, the review results are overly dependent on individual abilities.

[0036] 4) Before testing and deployment, a large number of branch merging operations are involved. Due to the large number of repositories, if each repository only has a new version branch for the ones with changes in requirements, and the others use the production branch, the workload for deployment personnel is huge. If corresponding version branches are created for all repositories, the operations between branches are also a huge workload and are very easy to make mistakes.

[0037] To address the aforementioned technical issues, this application provides a code version management method, apparatus, system, and storage medium. The method includes: creating new code version branches for each current data warehouse; obtaining each requirement code branch from each data warehouse; when a requirement code branch belongs to the new code version branch, using it as the first requirement code branch; merging the first requirement code branch into the new code version branch to obtain a merged code version branch; upon receiving a test pass notification for the merged code version branch; comparing the first requirement code branch and the merged code version branch; if both first requirement code branches are included in the merged code version branch; determining the code differences between the merged code version branch and the initial code version branch; if they differ, using the version number of the new code version branch as the version number of each current data warehouse; and building and packaging the code of each current data warehouse into a deployment package based on the merged code version branch. Therefore, this application can automate code version management, reducing manual workload while significantly improving the efficiency of batch operations, avoiding errors that may occur during manual operations, improving the accuracy of code version management, and reducing code risks.

[0038] Exemplary methods

[0039] See Figure 2 The flowchart shown is a code version management method provided in an embodiment of this application, including:

[0040] S101: Create new code version branches for each current data warehouse.

[0041] In this embodiment, each time a new code version branch is generated, a new code version branch can be automatically created for each data warehouse based on the existing code branches (i.e., the current production branch). This ensures that all warehouses have this version branch, facilitating subsequent testing, deployment, and production release. The creation of version branches can be automated without manual intervention.

[0042] In one possible implementation, all the repositories involved in the project, i.e., the current data repositories, can be added to the branch management tool in the form of configuration files. The corresponding repositories can be added or deleted by modifying the configuration files.

[0043] Specifically, version branches can be created for all repositories before each version release. The version branch name is defined as release_version number_planned release time (example: release_V2.3.25_20210819). Optionally, version branches can be created using the Git open-source distributed version control system, and relevant creation parameters can be recorded. This invention mainly optimizes the version branch management process. For technical implementation, open-source interfaces provided by Git and some relatively mature technologies can be used. There is no high barrier to entry in terms of technical difficulty, making it easier to implement.

[0044] S102: Obtain each requirement code branch of each data warehouse. When the requirement code branch belongs to the new code version branch, it is used as the first requirement code branch. The first requirement code branch is merged into the new code version branch to obtain the merged code version branch.

[0045] In this embodiment of the application, since each development package has a certain development time, the code branches of each requirement in each data warehouse can be obtained after the development deadline of the new code version branch is reached and the developers confirm that the development requirements they are responsible for have been completed.

[0046] Specifically, you can traverse and scan all requirement code branches in all repositories to obtain the name of each requirement code branch (the requirement branch name is the corresponding requirement number), and then determine whether each requirement code branch belongs to the new code version branch.

[0047] When the requirement code branch belongs to the new code version branch, it is used as the first requirement code branch. The first requirement code branch is merged into the new code version branch to obtain the merged code version branch. In one possible implementation, when code conflicts occur during the merging process, an email notification can be automatically sent to the requirement branch developers for manual handling. When the requirement code branch does not belong to the new code version branch, other requirement code branches can continue to be scanned.

[0048] S103: When the test pass notification of the merged code version branch is received, compare the first requirement code branch and the merged code version branch. If the first requirement code branch is included in the merged code version branch, determine the code differences between the merged code version branch and the initial code version branch. If they are different, use the version number of the new code version branch as the version number of each current data warehouse.

[0049] In this embodiment of the application, when a test pass notification is received for the merged code version branch, it indicates that the merged code version branch has met the release conditions and needs to be sealed. The code sealing means that the code is finalized and no further code changes are allowed.

[0050] Specifically, upon receiving a notification that the merged code version branch has passed the test, you can iterate through all repository branches and compare the differences between the first requirement code branch and the merged code version branch. If all the first requirement code branches are included in the merged code version branch, it means that the latest code from all requirement code branches has been merged into the merged code version branch.

[0051] At this point, we can continue to determine the differences between the merged code version branch and the initial code version branch. If they are different, it indicates that there is a requirement change for the current repository, and the version number of the new code version branch is used as the version number of each data warehouse. In one possible implementation, when the merged code version branch and the initial code version branch are identical, it indicates that there is no requirement change for the current repository, and the version number of the initial code version branch is used as the version number of each data warehouse. Specifically, in this embodiment, the initial code version branch version number refers to the version number of the most recently changed version.

[0052] In one possible implementation, when a test failure notification is received for the merged code version branch, an error signal for the first required code branch can be issued so that the first required code branch can be modified. The modified code can then be used as the first required code branch again for subsequent merging operations.

[0053] S104: Based on the merged code version branch, build the code of each current data warehouse and package it into a deployment package.

[0054] In this embodiment of the application, after the merged code version branch is sealed, there will still be a certain time gap between the actual release and the launch. It is necessary to ensure that the version code has not been changed during this period to further ensure the security of the release.

[0055] Specifically, you can scan all merged code version branches of all repositories to check if there have been code commits since the self-sealing. If there are code commits, you can get an alert so that you can contact the code committer to confirm the reason.

[0056] If no code commit has occurred, it is also necessary to check whether there are code changes in the merged code version branch of the current repository. In one possible implementation, when there are code changes, the data repository corresponding to the code changes is recorded in the change log table for easy tracking later.

[0057] Only when there are no code commits or changes before release can the code of each data repository be built and packaged into a production package based on the merged code version branch, so as to carry out the formal production release.

[0058] This invention automates batch operations in multi-warehouse project version management, as well as processes prone to errors in manual operations, thereby reducing the workload of configuration administrators and greatly improving the efficiency of batch operations.

[0059] This invention can avoid problems caused by manual operations, such as forgetting to merge branches, accidentally committing code to a closed branch, and causing conflicts when modifying the version number. Although these operations are not likely to occur, they are difficult to be detected manually without automatic program checks. Therefore, using this invention can minimize the code risks caused by human error.

[0060] In one possible implementation, this invention records all aspects of the code management process through program logs, providing a good tracing mechanism for subsequent problem discovery and further increasing the success guarantee of project release.

[0061] This application provides a code version management method, which includes: creating new code version branches for each current data warehouse; obtaining each requirement code branch of each data warehouse; when a requirement code branch belongs to the new code version branch, using it as the first requirement code branch; merging the first requirement code branch into the new code version branch to obtain a merged code version branch; when receiving a test pass notification for the merged code version branch; comparing the first requirement code branch and the merged code version branch; when both first requirement code branches are included in the merged code version branch; determining the code differences between the merged code version branch and the initial code version branch; if they are different, using the version number of the new code version branch as the version number of each current data warehouse; and building and packaging the code of each current data warehouse into a deployment package based on the merged code version branch. Therefore, this application can automate code version management, reducing manual workload while greatly improving the efficiency of batch operations, avoiding errors that may occur during manual operations, improving the accuracy of code version management, and reducing code risks.

[0062] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0063] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0064] Although the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous.

[0065] It should be understood that the steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.

[0066] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including but not limited to object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0067] Exemplary device

[0068] See Figure 3 As shown, an embodiment of this application provides a code version management device, comprising:

[0069] Version creation unit 501 is used to create new code version branches for each current data warehouse;

[0070] The requirement branch merging unit 502 is used to obtain each requirement code branch of each data warehouse. When the requirement code branch belongs to the new code version branch, it is used as the first requirement code branch. The first requirement code branch is merged into the new code version branch to obtain the merged code version branch.

[0071] Version sealing unit 503 is used to compare the first requirement code branch and the merged code version branch when it receives the test pass notification of the merged code version branch. When the first requirement code branch is included in the merged code version branch, it determines the code differences between the merged code version branch and the initial code version branch. When they are different, the version number of the new code version branch is used as the version number of each current data warehouse.

[0072] Version release unit 504 is used to build the code of each current data warehouse according to the merged code version branch and package it into a deployment package.

[0073] In one possible implementation, the device further includes:

[0074] An error signal unit is used to issue a first requirement code branch error signal when a test failure notification is received for the merged code version branch, so that the first requirement code branch can be modified.

[0075] In one possible implementation, the device further includes:

[0076] The version number update unit is used to use the version number of the initial code version branch as the version number of each data warehouse when the code of the merged code version branch is the same as that of the initial code version branch.

[0077] In one possible implementation, the device further includes:

[0078] The judgment unit is used to determine whether there are any code changes in each of the current data warehouses based on the merged code version branch;

[0079] The recording unit is used to record the data warehouse corresponding to the code change in the change record table when there is a code change.

[0080] This application provides a code version management method. The method using this device includes: creating new code version branches for each current data warehouse; obtaining each requirement code branch for each data warehouse; when a requirement code branch belongs to the new code version branch, using it as the first requirement code branch; merging the first requirement code branch into the new code version branch to obtain a merged code version branch; upon receiving a test pass notification for the merged code version branch; comparing the first requirement code branch and the merged code version branch; if both first requirement code branches are included in the merged code version branch; determining the code differences between the merged code version branch and the initial code version branch; if they differ, using the version number of the new code version branch as the version number of each current data warehouse; and building and packaging the code of each current data warehouse into a deployment package based on the merged code version branch. Therefore, this application can automate code version management, reducing manual workload while greatly improving the efficiency of batch operations, avoiding errors that may occur during manual operations, improving the accuracy of code version management, and reducing code risks.

[0081] The units described in the embodiments of this disclosure can be implemented in software or in hardware. The name of a unit does not necessarily limit the unit itself; for example, the first acquisition unit can also be described as "a unit that acquires at least two Internet Protocol addresses".

[0082] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0083] Based on the above embodiments, this application also provides a code version management system, including:

[0084] Memory, used to store computer programs;

[0085] A processor for implementing the code version management method described above when executing the computer program.

[0086] Based on the above embodiments, this application also provides a computer-readable medium storing a computer program, which, when processed and executed, implements the steps of the code version management method described above.

[0087] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0088] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0089] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts.

[0090] According to one or more embodiments of this disclosure, a code version management method is provided, comprising:

[0091] Create new code version branches for each current data warehouse;

[0092] Obtain each requirement code branch of each data warehouse. When the requirement code branch belongs to the new code version branch, it is used as the first requirement code branch. The first requirement code branch is merged into the new code version branch to obtain the merged code version branch.

[0093] When the test pass notification of the merged code version branch is received, the first requirement code branch and the merged code version branch are compared. If the first requirement code branch is included in the merged code version branch, the code differences between the merged code version branch and the initial code version branch are determined. If they are different, the version number of the new code version branch is used as the version number of each current data warehouse.

[0094] Based on the merged code version branch, the code of each current data warehouse is built and packaged into a deployment package.

[0095] According to one or more embodiments of this disclosure, a code version management method is provided, the method further comprising:

[0096] When a test failure notification is received for the merged code version branch, an error signal is issued for the first requirement code branch so that the first requirement code branch can be modified.

[0097] According to one or more embodiments of this disclosure, a code version management method is provided, the method further comprising:

[0098] When the code of the merged code version branch is the same as that of the initial code version branch, the version number of the initial code version branch is used as the version number of each current data warehouse.

[0099] According to one or more embodiments of this disclosure, a code version management method is provided, the method further comprising:

[0100] Determine whether there are any code changes in each of the current data warehouses based on the merged code version branch;

[0101] When code changes occur, the corresponding data warehouse is recorded in the change record table.

[0102] According to one or more embodiments of this disclosure, a code version management apparatus is provided, comprising:

[0103] Version creation unit, used to create new code version branches for each current data warehouse;

[0104] The requirement branch merging unit is used to obtain each requirement code branch of each data warehouse. When the requirement code branch belongs to the new code version branch, it is used as the first requirement code branch. The first requirement code branch is merged into the new code version branch to obtain the merged code version branch.

[0105] The version sealing unit is used to compare the first requirement code branch and the merged code version branch when it receives the test pass notification of the merged code version branch. When the first requirement code branch is included in the merged code version branch, it determines the code differences between the merged code version branch and the initial code version branch. If they are different, the version number of the new code version branch is used as the version number of each current data warehouse.

[0106] The version release unit is used to build the code of each current data warehouse according to the merged code version branch and package it into a deployment package.

[0107] According to one or more embodiments of this disclosure, the apparatus further includes:

[0108] An error signal unit is used to issue a first requirement code branch error signal when a test failure notification is received for the merged code version branch, so that the first requirement code branch can be modified.

[0109] According to one or more embodiments of this disclosure, the apparatus further includes:

[0110] The version number update unit is used to use the version number of the initial code version branch as the version number of each data warehouse when the code of the merged code version branch is the same as that of the initial code version branch.

[0111] According to one or more embodiments of this disclosure, the apparatus further includes:

[0112] The judgment unit is used to determine whether there are any code changes in each of the current data warehouses based on the merged code version branch;

[0113] The recording unit is used to record the data warehouse corresponding to the code change in the change record table when there is a code change.

[0114] According to one or more embodiments of this disclosure, a code version management system is provided, comprising:

[0115] Memory, used to store computer programs;

[0116] A processor for implementing the code version management method described above when executing the computer program.

[0117] According to one or more embodiments of the present disclosure, a computer-readable medium is provided, on which a computer program is stored, which, when processed and executed, implements the steps of the code version management method described above.

[0118] The above description is merely a preferred embodiment of this application. Although this application has disclosed preferred embodiments above, it is not intended to limit this application. Any person skilled in the art can make many possible variations and modifications to the technical solutions of this application using the methods and techniques disclosed above, or modify them into equivalent embodiments with equivalent changes, without departing from the scope of the technical solutions of this application. Therefore, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of this application without departing from the content of the technical solutions of this application shall still fall within the protection scope of the technical solutions of this application.

[0119] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

[0120] While several specific implementation details are included in the foregoing discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0121] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

Claims

1. A code version management method, characterized in that, include: Create new code version branches for each current data warehouse; The code branches of all requirements in all warehouses are traversed and scanned to obtain the code branches of each requirement in each data warehouse. When the code branch of the requirement belongs to the new code version branch, it is used as the first code branch. The first code branch of the requirement is merged into the new code version branch to obtain the merged code version branch. When the test pass notification of the merged code version branch is received, the first requirement code branch and the merged code version branch are compared. If the first requirement code branch is included in the merged code version branch, the code differences between the merged code version branch and the initial code version branch are determined. If they are different, the version number of the new code version branch is used as the version number of each current data warehouse. Based on the merged code version branch, the code of each current data warehouse is built and packaged into a deployment package; The method further includes: determining whether each current data warehouse has undergone code changes based on the merged code version branch; when code changes exist, recording the data warehouse corresponding to the code changes in the change record table to make the code changes traceable; Before code release, if there are no code changes and no code commits, the code of each current data repository is built and packaged into the online application package according to the merged code version branch.

2. The method according to claim 1, characterized in that, The method further includes: When a test failure notification is received for the merged code version branch, an error signal is issued for the first requirement code branch so that the first requirement code branch can be modified.

3. The method according to claim 1, characterized in that, The method further includes: When the code of the merged code version branch is the same as that of the initial code version branch, the version number of the initial code version branch is used as the version number of each current data warehouse.

4. A code version management device, characterized in that, include: Version creation unit, used to create new code version branches for each current data warehouse; The requirement branch merging unit is used to traverse and scan all requirement code branches of all warehouses to obtain each requirement code branch of each data warehouse. When the requirement code branch belongs to the new code version branch, it is used as the first requirement code branch. The first requirement code branch is merged into the new code version branch to obtain the merged code version branch. The version sealing unit is used to compare the first requirement code branch and the merged code version branch when it receives the test pass notification of the merged code version branch. When the first requirement code branch is included in the merged code version branch, it determines the code differences between the merged code version branch and the initial code version branch. If they are different, the version number of the new code version branch is used as the version number of each current data warehouse. The version release unit is used to build the code of each current data warehouse according to the merged code version branch and package it into a deployment package; The device further includes: The judgment unit is used to determine whether there are any code changes in each of the current data warehouses based on the merged code version branch; The recording unit is used to record the data warehouse corresponding to the code change in the change record table when there is a code change, so that the code change can be tracked; The device is also used to build and package the code of each current data warehouse into the online application package according to the merged code version branch before code release, when there are no code changes and no code commits.

5. The apparatus according to claim 4, characterized in that, The device further includes: An error signal unit is used to issue a first requirement code branch error signal when a test failure notification is received for the merged code version branch, so that the first requirement code branch can be modified.

6. The apparatus according to claim 4, characterized in that, The device further includes: The version number update unit is used to use the version number of the initial code version branch as the version number of each data warehouse when the code of the merged code version branch is the same as that of the initial code version branch.

7. A code version control system, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the code version management method as described in any one of claims 1-3 when executing the computer program.

8. A computer-readable medium, characterized in that, The computer-readable medium stores a computer program that, when processed and executed, implements the steps of the code version management method as described in any one of claims 1-3.

Images