A version synchronization method, gitlab server and test server

Abstract

The present application is applicable to the field of computer technology, and provides a method for version synchronization, including: a gitlab server is deployed in an internal LAN, the gitlab server is provided with a gitlab warehouse, and when the gitlab warehouse receives a version update instruction, the version information and version content included in the version update instruction are obtained; the first preset hook script in the gitlab warehouse is called to push the version information to the test environment bare warehouse; when the second preset hook script is detected to be triggered, the version content is pushed to the test environment warehouse. In the above scheme, the gitlab server is deployed in an internal LAN, and the gitlab warehouse can summarize all version information and version content, and the version management is intranetized, making version management more secure. At the same time, the synchronization of versions is achieved through two preset hook scripts, and automatic push is achieved, so that all version information and version content can be summarized on the test server, further enhancing the security of version management.

Description

Technical Field

[0001] The present application belongs to the field of computer technology, and in particular, relates to a version synchronization method, a gitlab server, and a test server. Background Art

[0002] In project development, in order to synchronize the code and perform version management, a version control management system is used. Currently, the more popular open source version control management system is git. Git allows development teams to work together more efficiently, thereby improving productivity. The existing version synchronization method is to use the collaborative method of a third-party git hosting platform to synchronize the code. However, this method relies on a third-party git hosting platform and only deploys a project summary repository on the third-party git hosting platform. When a problem occurs with the third-party repository or it is deleted by mistake, the complete project summary version is lost. In other words, the existing version synchronization method project has low security and cannot fully internalize enterprise information. Summary of the invention

[0003] The embodiments of the present application provide a version synchronization method, a gitlab server, and a test server, which can solve the problem that the existing version synchronization method projects have low security and cannot fully internalize enterprise information.

[0004] In a first aspect, an embodiment of the present application provides a method for version synchronization applied to a gitlab server, wherein the gitlab server is deployed in an internal LAN, and the gitlab server is provided with a gitlab warehouse, and the method includes:

[0005] When the gitlab warehouse receives a version update instruction, the version information and version content included in the version update instruction are obtained; the version update instruction is pushed by a local warehouse, and the local warehouse is deployed on a development server in an internal LAN;

[0006] The first preset hook script in the gitlab warehouse is called to push the version information to the test environment bare warehouse; the version information is used to trigger the second preset hook script of the test environment bare warehouse, and the test environment bare warehouse and the test environment warehouse are deployed on the test server of the internal public network;

[0007] When it is detected that the second preset hook script is triggered, the version content is pushed to the test environment warehouse.

[0008] Furthermore, the version content includes the overall project content or the project branch content.

[0009] Furthermore, before calling the first preset hook script in the gitlab warehouse to push the version information to the test environment bare warehouse, it also includes:

[0010] When a first hook script creation instruction is detected, a first preset hook script is created according to the first hook script creation instruction, and the execution permission of the first preset hook script is set.

[0011] In a second aspect, an embodiment of the present application provides a method for version synchronization, which is applied to a test server, wherein the test server is deployed on an internal public network, and the test server is provided with a test environment bare warehouse and a test environment warehouse, and the method includes:

[0012] When the test environment bare warehouse receives the version information pushed by the gitlab warehouse through the first preset hook script, the second preset hook script in the test environment bare warehouse is run; the second preset hook script is used to instruct the gitlab warehouse to push the version content corresponding to the version information, and the gitlab warehouse is deployed on the gitlab server of the internal LAN;

[0013] The version content pushed by the gitlab repository is received through the test environment repository.

[0014] Further, after the test environment warehouse receives the version content pushed by the gitlab warehouse, it also includes:

[0015] When a pull instruction sent by the production environment warehouse is received, the version information and the version content are pushed to the production environment warehouse, and the production environment warehouse is deployed on a production environment server on the internal public network.

[0016] Further, when the test environment bare warehouse receives the version information pushed by the gitlab warehouse through the first preset hook script, before running the second preset hook script in the test environment bare warehouse, it also includes:

[0017] When the second hook script creation instruction is detected, a second preset hook script is created according to the second hook script creation instruction, and the execution permission of the second preset hook script is set.

[0018] In a third aspect, an embodiment of the present application provides a gitlab server, wherein the gitlab server is deployed in an internal LAN, the gitlab server is provided with a gitlab warehouse, and the gitlab server includes:

[0019] A first processing unit is configured to obtain the version information and version content included in the version update instruction when the gitlab warehouse receives the version update instruction; the version update instruction is pushed by the local warehouse, and the local warehouse is deployed on the development server of the internal LAN;

[0020] The second processing unit is used to call the first preset hook script in the gitlab warehouse to push the version information to the test environment bare warehouse; the version information is used to trigger the second preset hook script of the test environment bare warehouse, and the test environment bare warehouse and the test environment warehouse are deployed on the test server of the internal public network;

[0021] The third processing unit is configured to push the version content to the test environment repository when it is detected that the second preset hook script is triggered.

[0022] Furthermore, the version content includes the overall project content or the project branch content.

[0023] Furthermore, the gitlab server further includes:

[0024] The fourth processing unit is configured to, when detecting a first hook script creation instruction, create a first preset hook script according to the first hook script creation instruction, and set execution permissions for the first preset hook script.

[0025] In a fourth aspect, an embodiment of the present application provides a test server, which is deployed on an internal public network, and is provided with a test environment bare warehouse and a test environment warehouse, and the test server includes:

[0026] A fifth processing unit is used to run a second preset hook script in the test environment bare warehouse when the test environment bare warehouse receives the version information pushed by the gitlab warehouse through the first preset hook script; the second preset hook script is used to instruct the gitlab warehouse to push the version content corresponding to the version information, and the gitlab warehouse is deployed on a gitlab server in the internal LAN;

[0027] The sixth processing unit is used to receive the version content pushed by the gitlab warehouse through the test environment warehouse.

[0028] Furthermore, the test server further includes:

[0029] The seventh processing unit is used to push the version information and the version content to the production environment warehouse when receiving a pull instruction sent by the production environment warehouse, and the production environment warehouse is deployed on the production environment server of the internal public network.

[0030] Furthermore, the test server further includes:

[0031] The eighth processing unit is configured to, when detecting the second hook script creation instruction, create a second preset hook script according to the second hook script creation instruction, and set the execution permission of the second preset hook script.

[0032] In the fifth aspect, an embodiment of the present application provides a gitlab server, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the version synchronization method as described in the first aspect above is implemented.

[0033] In a sixth aspect, an embodiment of the present application provides a test server, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the version synchronization method as described in the second aspect above is implemented.

[0034] In a seventh aspect, an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method for version synchronization as described in the first aspect above is implemented.

[0035] In an eighth aspect, an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method for version synchronization as described in the second aspect above is implemented.

[0036] In an embodiment of the present application, the gitlab server is deployed in an internal LAN, and the gitlab server is provided with a gitlab warehouse. When the gitlab warehouse receives a version update instruction, the version information and version content included in the version update instruction are obtained; the version update instruction is pushed by a local warehouse, and the local warehouse is deployed on a development server in the internal LAN; the first preset hook script in the gitlab warehouse is called to push the version information to the test environment bare warehouse; the version information is used to trigger the second preset hook script of the test environment bare warehouse, and the test environment bare warehouse and the test environment warehouse are deployed on a test server in the internal public network; when it is detected that the second preset hook script is triggered, the version content is pushed to the test environment warehouse. The above scheme is applicable to a standardized version control process. In general, project development is completed by a local server, tested, and then updated to a test server. After the test server project is tested, it is finally updated to the formal server. However, this method adds a gitlab server as an intermediate forwarding server between the local server and the test server. The gitlab server is deployed in the internal LAN. The gitlab warehouse can summarize all version information and version content, and make version management internal, making version management more secure. At the same time, two preset hook scripts are used to synchronize versions and push them automatically, so that all version information and version content can be summarized on the test server, internalizing version management and automatically synchronizing versions, further enhancing the security of version management.

[0037] The test server is deployed on the internal public network. The test server is provided with a test environment bare warehouse and a test environment warehouse. When the test environment bare warehouse receives the version information pushed by the gitlab warehouse through the first preset hook script, the second preset hook script in the test environment bare warehouse is run; the second preset hook script is used to instruct the gitlab warehouse to push the version content corresponding to the version information. The gitlab warehouse is deployed on the gitlab server of the internal LAN; the version content pushed by the gitlab warehouse is received through the test environment warehouse. In the above scheme, the gitlab server is deployed on the internal LAN, and the gitlab warehouse can summarize all version information and version content, and make the version management intranet, making the version management more secure. At the same time, the synchronization of versions is realized through the preset hook script, and automatic push is realized, so that all version information and version content can also be summarized on the test server, and the internalization of version management and automatic synchronization of versions are realized, which further enhances the security of version management. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0039] Figure 1 This is an interaction diagram between various servers of a version synchronization method provided in the first embodiment of the present application;

[0040] Figure 2 is a schematic flow chart of a version synchronization method provided in the second embodiment of the present application;

[0041] Figure 3 is a schematic flow chart of a version synchronization method provided in the third embodiment of the present application;

[0042] Figure 4 is a schematic diagram of a gitlab server provided in the fourth embodiment of the present application;

[0043] Figure 5 is a schematic diagram of a test server provided in the fifth embodiment of the present application;

[0044] Figure 6 is a schematic diagram of a gitlab server provided in the sixth embodiment of the present application;

[0045] Figure 7 It is a schematic diagram of the test server provided in the seventh embodiment of the present application. DETAILED DESCRIPTION

[0046] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

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

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

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

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

[0051] References to "one embodiment" or "some embodiments" etc. described in the specification of this application mean that one or more embodiments of the present application include specific features, structures or characteristics described in conjunction with the embodiment. Therefore, the statements "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. that appear in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

[0052] See also Figure 1 , Figure 1 It is an interaction diagram between various servers of a version synchronization method provided by the first embodiment of the present application. In this embodiment, a gitlab server, a test server, a development server and a production environment server are provided. The gitlab server is deployed in an internal LAN, and the gitlab server is provided with a gitlab warehouse. The test server is deployed in an internal public network, and the test server is provided with a test environment bare warehouse and a test environment warehouse. The local warehouse is deployed on the development server in the internal LAN.

[0053] See also Figure 2 , Figure 2 This is a schematic flow chart of a version synchronization method provided in the second embodiment of the present application. In this embodiment, the execution subject of a version synchronization method is a gitlab server, which is deployed in an internal LAN and is provided with a gitlab warehouse. Figure 2 The version synchronization method shown may include:

[0054] S101: When the gitlab warehouse receives a version update instruction, the version information and version content included in the version update instruction are obtained; the version update instruction is pushed by a local warehouse, and the local warehouse is deployed on a development server in an internal LAN.

[0055] When developing a project, from project development to project testing to project launch, there will be multiple versions of the entire project. When managing multiple project versions, the distributed version control system git will be used. Git is an open source distributed version control system that can manage project versions effectively and quickly.

[0056] In this embodiment, the gitlab open source project is adopted. Gitlab is an open source application developed using Ruby on Rails. It implements a self-hosted Git project warehouse, and public or private projects can be accessed through a web interface. Gitlab has similar functions to github, and can browse source code, manage defects and comments. It can manage the team's access to the warehouse. It is very easy to browse the submitted versions and provide a file history library. It also provides a code snippet collection function that can easily realize code reuse, which is convenient for searching when needed in the future. The gitlab open source project is deployed on the gitlab server, and the gitlab server is deployed on the internal LAN. The gitlab server is provided with a gitlab warehouse. Among them, the gitlab warehouse can be created on the gitlab server according to the gitlab warehouse creation instruction.

[0057] When the gitlab repository of the gitlab server receives a version update instruction, it obtains the version information and version content included in the version update instruction. The version update instruction is pushed by the local repository, which is deployed on the development server of the internal LAN. When the local repository of the development server receives the newly developed version, it obtains the new version information and version content, generates a version update instruction based on the new version information and version content, and the development server pushes the version update instruction to the gitlab repository of the gitlab server. The version content includes the overall project content or the project branch content.

[0058] S102: Call the first preset hook script in the gitlab warehouse to push the version information to the test environment bare warehouse; the version information is used to trigger the second preset hook script of the test environment bare warehouse, and the test environment bare warehouse and the test environment warehouse are deployed on the test server of the internal public network.

[0059] The first preset hook script is stored in the gitlab repository in advance. When the gitlab repository receives the version update instruction pushed by the local repository, the gitlab repository will automatically trigger the first preset hook script. Among them, hook scripts are some scripts in the "$GIT-DIR / hooks" directory, which are called after being triggered by certain events (certain points). When the "git init" command is called, some very useful sample hook files are copied to the hooks directory of the new repository; however, these hooks are not effective by default. Remove the ".sample" file name suffix of these hook files to make them effective.

[0060] The gitlab server calls the first preset hook in the gitlab repository to push the version information to the test environment bare repository. In this embodiment, the test environment bare repository and the test environment repository are deployed on the test server of the internal public network. The test environment bare repository can be created on the test server through the test environment bare repository creation instruction, using git init --bare <repo>You can create a bare repository. A bare repository does not store files, but only historical version information. A bare repository does not contain a workspace, so there is no possibility of directly submitting changes to the bare repository.

[0061] The test environment bare warehouse receives the version information, and the version information is used to trigger the second preset hook script of the test environment bare warehouse. The second preset hook script is pre-stored in the test environment bare warehouse, and the second preset hook script is used to trigger the gitlab server to push the version content to the test environment warehouse, and the second preset hook script is used to instruct the gitlab warehouse to push the version content corresponding to the version information.

[0062] Further, after S102, it may also include: when a first hook script creation instruction is detected, a first preset hook script is created according to the first hook script creation instruction, and the execution permission of the first preset hook script is set. When the first hook script creation instruction is detected, a custom_hooks folder is created, a post-receive file is created, a first preset hook script is created, and execution permission is granted.

[0063] S103: When it is detected that the second preset hook script is triggered, the version content is pushed to the test environment warehouse.

[0064] When the second preset hook script in the test server is triggered, an instruction is sent to the gitlab server, which is used to trigger the gitlab server to push the version content to the test environment warehouse. When the gitlab server detects that the second preset hook script is triggered, it pushes the version content to the test environment warehouse.

[0065] In an embodiment of the present application, the gitlab server is deployed in an internal LAN, and the gitlab server is provided with a gitlab warehouse. When the gitlab warehouse receives a version update instruction, the version information and version content included in the version update instruction are obtained; the version update instruction is pushed by a local warehouse, and the local warehouse is deployed on a development server in the internal LAN; the first preset hook script in the gitlab warehouse is called to push the version information to the test environment bare warehouse; the version information is used to trigger the second preset hook script of the test environment bare warehouse, and the test environment bare warehouse and the test environment warehouse are deployed on a test server in the internal public network; when it is detected that the second preset hook script is triggered, the version content is pushed to the test environment warehouse. The above scheme is applicable to a standardized version control process. In general, project development is completed by a local server, tested, and then updated to a test server. After the test server project is tested, it is finally updated to the formal server. However, this method adds a gitlab server as an intermediate forwarding server between the local server and the test server. The gitlab server is deployed in the internal LAN. The gitlab warehouse can summarize all version information and version content, and make version management internal, making version management more secure. At the same time, two preset hook scripts are used to synchronize versions and push them automatically, so that all version information and version content can be summarized on the test server, internalizing version management and automatically synchronizing versions, further enhancing the security of version management.

[0066] See also Figure 3 , Figure 3 This is a schematic flow chart of a version synchronization method provided in the third embodiment of the present application. In this embodiment, the execution subject of a version synchronization method is a test server, which is deployed on the internal public network and is provided with a test environment bare warehouse and a test environment warehouse. Figure 3 The method of version synchronization shown may include:

[0067] S201: When the test environment bare warehouse receives the version information pushed by the gitlab warehouse through the first preset hook script, the second preset hook script in the test environment bare warehouse is run; the second preset hook script is used to instruct the gitlab warehouse to push the version content corresponding to the version information, and the gitlab warehouse is deployed on the gitlab server in the internal LAN.

[0068] In this embodiment, the test server is deployed on the internal public network, and the test server is provided with a test environment bare warehouse and a test environment warehouse. When the test environment bare warehouse of the test server receives the version information pushed by the gitlab warehouse through the first preset hook script, the second preset hook script in the test environment bare warehouse is run, and the second preset hook script is pre-stored in the test environment bare warehouse. The second preset hook script is used to trigger the gitlab server to push the version content to the test environment warehouse, and the second preset hook script is used to instruct the gitlab warehouse to push the version content corresponding to the version information. Among them, the gitlab warehouse is deployed on the gitlab server of the internal LAN.

[0069] Furthermore, before S201, the method may further include: when a second hook script creation instruction is detected, creating a second preset hook script according to the second hook script creation instruction, and setting the execution permission of the second preset hook script. When a second hook script creation instruction is detected, creating a custom_hooks folder, creating a post-receive file, creating a second preset hook script, and granting execution permission.

[0070] S202: Receive the version content pushed by the gitlab warehouse through the test environment warehouse.

[0071] Since the second preset hook script is used to trigger the gitlab server to push the version content to the test environment warehouse, and the second preset hook script is used to instruct the gitlab warehouse to push the version content corresponding to the version information, when the gitlab server detects that the second preset hook script is triggered, it pushes the version content to the test environment warehouse. The test server receives the version content pushed by the gitlab warehouse through the test environment warehouse.

[0072] Furthermore, after S202, it may also include: when receiving a pull instruction sent by the production environment warehouse, pushing the version information and the version content to the production environment warehouse, and the production environment warehouse is deployed on a production environment server on the internal public network.

[0073] In this embodiment, the test server is deployed on the internal public network. The test server is provided with a test environment bare warehouse and a test environment warehouse. When the test environment bare warehouse receives the version information pushed by the gitlab warehouse through the first preset hook script, the second preset hook script in the test environment bare warehouse is run; the second preset hook script is used to instruct the gitlab warehouse to push the version content corresponding to the version information. The gitlab warehouse is deployed on the gitlab server of the internal LAN; the version content pushed by the gitlab warehouse is received through the test environment warehouse. In the above scheme, the gitlab server is deployed on the internal LAN, and the gitlab warehouse can summarize all version information and version content, and make the version management intranet, making the version management more secure. At the same time, the synchronization of versions is realized through the preset hook script, and automatic push is realized, so that all version information and version content can also be summarized on the test server, and the internalization of version management and automatic synchronization of versions are realized, which further enhances the security of version management.

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

[0075] See also Figure 4 , Figure 4 Schematic diagram of the gitlab server provided in the fourth embodiment of the present application. The units included are used to execute Figure 2 For details of the steps in the corresponding embodiments, please refer to Figure 2 The gitlab server is deployed in an internal LAN, and the gitlab server is provided with a gitlab warehouse. For ease of explanation, only the parts related to this embodiment are shown. Figure 4 , gitlab-server 4 includes:

[0076] The first processing unit 410 is used to obtain the version information and version content included in the version update instruction when the gitlab warehouse receives the version update instruction; the version update instruction is pushed by the local warehouse, and the local warehouse is deployed on the development server of the internal LAN;

[0077] The second processing unit 420 is used to call the first preset hook script in the gitlab warehouse to push the version information to the test environment bare warehouse; the version information is used to trigger the second preset hook script of the test environment bare warehouse, and the test environment bare warehouse and the test environment warehouse are deployed on the test server of the internal public network;

[0078] The third processing unit 430 is configured to push the version content to the test environment repository when it is detected that the second preset hook script is triggered.

[0079] Furthermore, the version content includes the overall project content or the project branch content.

[0080] Furthermore, the gitlab server 4 also includes:

[0081] The fourth processing unit is configured to, when detecting a first hook script creation instruction, create a first preset hook script according to the first hook script creation instruction, and set execution permissions for the first preset hook script.

[0082] See also Figure 5 , Figure 5 Schematic diagram of the test server provided in the fifth embodiment of the present application. The units included are used to execute Figure 3 For details of the steps in the corresponding embodiments, please refer to Figure 3 The test server is deployed on the internal public network, and the test server is provided with a test environment bare warehouse and a test environment warehouse. For ease of explanation, only the parts related to this embodiment are shown. Figure 5 , the test server 5 includes:

[0083] The fifth processing unit 510 is used to run the second preset hook script in the test environment bare warehouse when the test environment bare warehouse receives the version information pushed by the gitlab warehouse through the first preset hook script; the second preset hook script is used to instruct the gitlab warehouse to push the version content corresponding to the version information, and the gitlab warehouse is deployed on the gitlab server of the internal LAN;

[0084] The sixth processing unit 520 is used to receive the version content pushed by the gitlab warehouse through the test environment warehouse.

[0085] Furthermore, the test server 5 further includes:

[0086] The seventh processing unit is used to push the version information and the version content to the production environment warehouse when receiving a pull instruction sent by the production environment warehouse, and the production environment warehouse is deployed on the production environment server of the internal public network.

[0087] Furthermore, the test server 5 further includes:

[0088] The eighth processing unit is configured to, when detecting the second hook script creation instruction, create a second preset hook script according to the second hook script creation instruction, and set the execution permission of the second preset hook script.

[0089] Figure 6 Schematic diagram of the gitlab server provided in the sixth embodiment of the present application. Figure 6 As shown, the gitlab server 6 of this embodiment includes: a processor 60, a memory 61, and a computer program 62 stored in the memory 61 and executable on the processor 60, such as a version synchronization program. When the processor 60 executes the computer program 62, the steps in the above-mentioned various version synchronization method embodiments are implemented, such as Figure 2 Alternatively, when the processor 60 executes the computer program 62, the functions of each module / unit in the above-mentioned device embodiments are realized, for example, Figure 4 Functions of modules 410 to 430 are shown.

[0090] Exemplarily, the computer program 62 may be divided into one or more modules / units, which are stored in the memory 61 and executed by the processor 60 to complete the present application. The one or more modules / units may be a series of computer program instruction segments capable of completing specific functions, which are used to describe the execution process of the computer program 62 in the gitlab server 6. For example, the computer program 62 may be divided into a first processing unit, a second processing unit, and a third processing unit, and the specific functions of each unit are as follows:

[0091] A first processing unit is configured to obtain the version information and version content included in the version update instruction when the gitlab warehouse receives the version update instruction; the version update instruction is pushed by the local warehouse, and the local warehouse is deployed on the development server of the internal LAN;

[0092] The second processing unit is used to call the first preset hook script in the gitlab warehouse to push the version information to the test environment bare warehouse; the version information is used to trigger the second preset hook script of the test environment bare warehouse, and the test environment bare warehouse and the test environment warehouse are deployed on the test server of the internal public network;

[0093] The third processing unit is configured to push the version content to the test environment repository when it is detected that the second preset hook script is triggered.

[0094] The gitlab server may include, but is not limited to, a processor 60 and a memory 61. A person skilled in the art may understand that Figure 6 It is only an example of the gitlab server 6 and does not constitute a limitation of the gitlab server 6. It may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, the gitlab server may also include input and output devices, network access devices, buses, etc.

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

[0096] The memory 61 may be an internal storage unit of the gitlab server 6, such as a hard disk or memory of the gitlab server 6. The memory 61 may also be an external storage device of the gitlab server 6, such as a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), etc. equipped on the gitlab server 6. Furthermore, the memory 61 may also include both an internal storage unit and an external storage device of the gitlab server 6. The memory 61 is used to store the computer program and other programs and data required by the focusing device. The memory 61 may also be used to temporarily store data that has been output or is to be output.

[0097] Figure 7 Schematic diagram of a test server provided in the seventh embodiment of the present application. Figure 7 As shown, the test server 7 of this embodiment includes: a processor 70, a memory 71, and a computer program 72 stored in the memory 71 and executable on the processor 70, such as a version synchronization program. When the processor 70 executes the computer program 72, the steps in the above-mentioned various version synchronization method embodiments are implemented, such as Figure 3 Alternatively, when the processor 70 executes the computer program 72, the functions of each module / unit in the above-mentioned device embodiments are realized, for example Figure 5 Functions of modules 510 to 520 are shown.

[0098] Exemplarily, the computer program 72 may be divided into one or more modules / units, which are stored in the memory 71 and executed by the processor 70 to complete the present application. The one or more modules / units may be a series of computer program instruction segments capable of completing specific functions, which are used to describe the execution process of the computer program 72 in the test server 7. For example, the computer program 72 may be divided into a fifth processing unit and a sixth processing unit, and the specific functions of each unit are as follows:

[0099] A fifth processing unit is used to run a second preset hook script in the test environment bare warehouse when the test environment bare warehouse receives the version information pushed by the gitlab warehouse through the first preset hook script; the second preset hook script is used to instruct the gitlab warehouse to push the version content corresponding to the version information, and the gitlab warehouse is deployed on a gitlab server in the internal LAN;

[0100] The sixth processing unit is used to receive the version content pushed by the gitlab warehouse through the test environment warehouse.

[0101] The test server may include, but is not limited to, a processor 70 and a memory 71. Those skilled in the art will appreciate that Figure 7 It is only an example of the test server 7 and does not constitute a limitation of the test server 7. It may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, the test server may also include input and output devices, network access devices, buses, etc.

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

[0103] The memory 71 may be an internal storage unit of the test server 7, such as a hard disk or memory of the test server 7. The memory 71 may also be an external storage device of the test server 7, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the test server 7. Further, the memory 71 may also include both an internal storage unit and an external storage device of the test server 7. The memory 71 is used to store the computer program and other programs and data required by the test server. The memory 71 may also be used to temporarily store data that has been output or is to be output.

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

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

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

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

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

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

[0110] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, U disk, mobile hard disk, disk, optical disk, computer memory, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), electric carrier signal, telecommunication signal and software distribution medium. It should be noted that the content contained in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.

[0111] The embodiments described above are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. Such modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.< / repo>

Claims

1. A version synchronization method, characterized in that: Applied to a gitlab server, the gitlab server is deployed in an internal LAN, and the gitlab server is provided with a gitlab warehouse, the method includes: When the gitlab warehouse receives a version update instruction, the version information and version content included in the version update instruction are obtained; the version update instruction is pushed by a local warehouse, and the local warehouse is deployed on a development server in an internal LAN; The first preset hook script in the gitlab warehouse is called to push the version information to the test environment bare warehouse; the version information is used to trigger the second preset hook script of the test environment bare warehouse, and the test environment bare warehouse and the test environment warehouse are deployed on the test server of the internal public network; When it is detected that the second preset hook script is triggered, the version content is pushed to the test environment warehouse.

2. The version synchronization method according to claim 1, characterized in that: The version content includes the overall project content or the project branch content.

3. The version synchronization method according to claim 1, characterized in that: Before calling the first preset hook script in the gitlab warehouse to push the version information to the test environment bare warehouse, it also includes: When a first hook script creation instruction is detected, a first preset hook script is created according to the first hook script creation instruction, and the execution permission of the first preset hook script is set.

4. A version synchronization method, characterized in that: Applied to a test server, the test server is deployed on an internal public network, the test server is provided with a test environment bare warehouse and a test environment warehouse, the method comprises: When the test environment bare warehouse receives the version information pushed by the gitlab warehouse through the first preset hook script, the second preset hook script in the test environment bare warehouse is run; the second preset hook script is used to instruct the gitlab warehouse to push the version content corresponding to the version information, and the gitlab warehouse is deployed on the gitlab server of the internal LAN; The version content pushed by the gitlab repository is received through the test environment repository.

5. The version synchronization method according to claim 4, characterized in that: After the test environment warehouse receives the version content pushed by the gitlab warehouse, it also includes: When a pull instruction sent by the production environment warehouse is received, the version information and the version content are pushed to the production environment warehouse, and the production environment warehouse is deployed on a production environment server on the internal public network.

6. The version synchronization method according to claim 4, characterized in that: When the test environment bare warehouse receives the version information pushed by the gitlab warehouse through the first preset hook script, before running the second preset hook script in the test environment bare warehouse, it also includes: When the second hook script creation instruction is detected, a second preset hook script is created according to the second hook script creation instruction, and the execution permission of the second preset hook script is set.

7. A gitlab server, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the method according to any one of claims 1 to 3 is implemented.

8. A test server, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the method according to any one of claims 4 to 6 is implemented.

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

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 4 to 6 is implemented.

Images