WO2021217868A1

WO2021217868A1 - Git-based project version release method and apparatus, device, and medium

Info

Publication number: WO2021217868A1
Application number: PCT/CN2020/099527
Authority: WO
Inventors: 耿铭
Original assignee: 平安科技（深圳）有限公司
Priority date: 2020-04-30
Filing date: 2020-06-30
Publication date: 2021-11-04
Also published as: CN111666081A; CN111666081B

Abstract

A Git-based project version release method and apparatus, a device, and a medium. The method comprises: upon receiving a project version creation release instruction, obtaining a creation release file package, wherein the creation release file package comprises an initial version number, an initial version file, and an initial deployment operation file associated with each other; storing the initial version file to a Git local repository and pushing same to a Git central repository; sending to first target servers a version initial instruction comprising the initial version number; upon receiving a first pulling instruction of the first target servers, transmitting the initial version file to the first target servers by means of the Git central repository according to a first transmission mode; installing the initial version file to the first target servers according to an initial deployment command file; and upon receiving all installation success instructions, determining that the creation release file package is successfully released. The method implements the automatic configuration of an environment of a target server on the basis of a Git distributed control system, improves efficiency, and reduces costs.

Description

Git-based project version release method, device, equipment and medium

This application claims the priority of a Chinese patent application filed with the Chinese Patent Office on April 30, 2020, the application number is 202010366362.8, and the invention title is "Git-based project version release method, device, equipment, and medium". The entire content is approved The reference is incorporated in this application.

Technical field

This application relates to the field of distributed deployment, and in particular to a method, device, computer equipment, and storage medium for project version release based on Git.

Background technique

At present, in the field of project development, from project testing to project launch, project developers or project commissioners will put forward different requirements for the project. Therefore, there are often multiple project versions. The inventor realized that in the existing technology, Usually based on svn (subversion, an open source version control system) single backbone centralized release system, the management of multiple project versions is realized in the following way: all developers develop on the same backbone of a svn warehouse, Testers conduct test verification in the same test environment, and finally manually deploy the modified files on the line incrementally. The inventor found that the shortcomings of the existing technical solutions are: first, the code cannot be remotely shared to multiple target servers in the development and testing phases, and testers can only perform testing and verification in the environment of the same configuration file; When the project version is deployed online, it is extremely prone to file missed release and entrained release problems, and only the code is deployed when the deployment is online, and the configuration file needs to be manually deployed to each target server; at the same time, when an exception occurs after the deployment is online The operation of rolling back to the historical version is complicated.

Summary of the invention

This application provides a Git-based project version release method, device, computer equipment, and storage medium, which realizes the environment of automatically configuring target servers based on the Git distributed control system, improves efficiency, greatly reduces manual configuration costs, and reduces Operating costs have greatly shortened the release time of the project version.

A Git-based project version release method, including:

The project version creation release instruction is received, and the creation release file package is obtained; the creation release file package includes an initial version number, an initial version file, and an initial deployment job file associated with each other; the initial version file includes an initial code file and an initial configuration File; the initial deployment job file includes a first IP address set and an initial deployment command file;

Store the initial version file in the Git local warehouse, and push the initial version file to the Git central warehouse at the same time;

Sending a version initial instruction containing the initial version number to all first target servers that match the first IP address in the first IP address set;

After receiving the first pull instruction for the version initial instruction including the initial version number that is fed back by the first target server, it is transmitted to the first target server through the Git central warehouse according to the first transmission method The initial version file associated with the initial version number included in the first pull instruction; the first transmission method is to associate with the initial version number included in the first pull instruction The initial version file is directly transmitted to the first target server;

According to the initial deployment command file, install the initial version file to the first target server through a non-interactive dialogue with the first target server;

After receiving all installation success instructions sent by the first target server that has fed back the first pull instruction, it is determined that the creation and release file package is successfully released.

A Git-based project version release device, including:

The receiving module is used to receive the project version creation release instruction and obtain the creation release file package; the creation release file package includes the initial version number, the initial version file, and the initial deployment job file related to each other; the initial version file includes the initial A code file and an initial configuration file; the initial deployment job file includes a first IP address set and an initial deployment command file;

The storage module is used to store the initial version file to the Git local warehouse, and at the same time push the initial version file to the Git central warehouse;

A sending module, configured to send a version initial instruction containing the initial version number to all first target servers that match the first IP address in the first IP address set;

The transmission module is configured to, after receiving the first pull instruction for the version initial instruction including the initial version number, fed back by the first target server, to the Git central warehouse according to the first transmission method The first target server transmits the initial version file associated with the initial version number included in the first pull instruction; the first transmission method is to combine with the initial version number included in the first pull instruction The initial version file associated with the initial version number is directly transmitted to the first target server;

An installation module, configured to install the initial version file to the first target server through a non-interactive dialogue with the first target server according to the initial deployment command file;

The determining module is configured to determine that the creation and release file package is successfully released after receiving all installation success instructions sent by the first target server that has fed back the first pull instruction.

A computer device including a memory, a processor, and a computer program stored in the memory and capable of running on the processor. The processor implements the above-mentioned Git-based project version publishing method when the processor executes the computer program Steps, for example, implement the following steps:

A computer-readable storage medium that stores a computer program that, when executed by a processor, implements the steps of the above-mentioned Git-based project version publishing method, for example, the following steps are implemented:

This application realizes the environment of automatically configuring the target server based on the Git distributed control system, improves efficiency, greatly reduces manual configuration costs, reduces operating costs, and greatly shortens the project version release time.

Description of the drawings

FIG. 1 is a schematic diagram of the application environment of the Git-based project version release method in an embodiment of the present application;

Figure 2 is a flowchart of a Git-based project version release method in an embodiment of the present application;

FIG. 3 is a flowchart of step S60 of the Git-based project version publishing method in an embodiment of the present application;

FIG. 4 is a flowchart of step S120 of the Git-based project version publishing method in an embodiment of the present application;

FIG. 5 is a flowchart of step S40 of the Git-based project version publishing method in an embodiment of the present application;

FIG. 6 is a flowchart of step S100 of the Git-based project version publishing method in an embodiment of the present application;

FIG. 7 is a flowchart of step S110 of the Git-based project version publishing method in an embodiment of the present application;

Figure 8 is a functional block diagram of a Git-based project version publishing device in an embodiment of the present application;

FIG. 9 is a functional block diagram of the determining module 16 in the Git-based project version publishing device in an embodiment of the present application;

Fig. 10 is a schematic diagram of a computer device in an embodiment of the present application.

Detailed ways

The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

The technical solution of this application can be applied to the field of artificial intelligence or big data. For example, when it involves distributed artificial intelligence technology, the involved data can be stored in a database, or can be distributed storage through a blockchain, which is not limited by this application.

The Git-based project version release method provided by this application can be applied in the application environment as shown in Figure 1, where the client (computer equipment) communicates with the server through the network. Among them, the client (computer equipment) includes, but is not limited to, various personal computers, notebook computers, smart phones, tablet computers, cameras, and portable wearable devices. The server can be implemented as an independent server or a server cluster composed of multiple servers.

In one embodiment, as shown in FIG. 2, a Git-based project version release method is provided, and the technical solution mainly includes the following steps S10-S60:

S10. A project version creation release instruction is received, and a creation release file package is obtained; the creation release file package includes an initial version number, an initial version file, and an initial deployment job file that are related to each other; the initial version file includes an initial code file and Initial configuration file; the initial deployment job file includes the first IP address set and the initial deployment command file.

Understandably, the application scenario of this application can be an operation on a webpage or an application. In one embodiment, through the application webpage interface, the user uploads relevant files according to the requirements of the webpage template, that is, according to the set The order of the web page template requires that the relevant files be uploaded in sequence. The application web interface refers to the interface that implements application operations through the web; after receiving all the documents related to the project version that have been determined, the project version creation and release instruction is triggered, so The project version is the version corresponding to the project that needs to be released, so that all files related to the project version are merged according to the preset initial template, that is, all files related to the project version are processed in accordance with the requirements of the initial template Splitting and merging, the initial template refers to the template corresponding to the first release project, and is compressed according to preset initial compression parameters to generate the creation and release package. The initial compression parameters can be set according to requirements, such as The initial compression parameter is a parameter converted into rar format, or the initial compression parameter is a parameter converted into zip format, etc., and the compressed creation and release file package is uploaded to a cloud server; After receiving the creation and release package, decompress the creation and release package to obtain the initial version number contained in the creation and release package and the initial version file associated with the initial version number And the initial deployment job file associated with the initial version number, in this way, by compressing the creation and release file package and uploading it to the cloud server, and then decompressing it to obtain the creation and release file package, a plurality of compressed all files can be received through the cloud server. Said creating and publishing file packages, transferring and backing up a plurality of compressed creating and publishing file packages, can avoid the risk of loss in the process of obtaining a plurality of creating and publishing file packages.

Wherein, the initial version file includes the initial code file and the initial configuration file, the initial code file is the source code file of the initial version of the project, and the initial configuration file is the configuration required to run the initial code file. Files related to the operating environment, the initial deployment job file includes the first IP address set and the initial deployment command file, and the first IP address set is all target servers to which the initial version file needs to be released A collection of corresponding IP addresses.

S20: Store the initial version file in the Git local warehouse, and at the same time push the initial version file to the Git central warehouse.

Understandably, the Git local warehouse is a storage warehouse set based on the Git distributed control system, and the Git distributed control system is a system based on Git that includes a Git local warehouse and a Git central warehouse. The Git local The warehouse can accept and store project version files and version records uploaded or updated by users. The Git central warehouse is a temporary warehouse set based on the Git distributed control system, and the Git central warehouse receives the Git local warehouse. The initial version file pushed over and temporarily stored.

S30: Send a version initial instruction containing the initial version number to all first target servers that match the first IP address in the first IP address set.

Understandably, the first target server is a target server consistent with the first IP address, and the first IP address is an element in the first IP address set, and sends to all the first target servers The version initial instruction, the version initial instruction is an instruction for issuing an initial version file, the version initial instruction can be set according to requirements, for example, the version initial instruction is generated according to the initial instruction template provided by the Docker container management tool, etc., The version initial instruction includes the initial version number.

S40. After receiving the first pull instruction that includes the initial version number fed back by the first target server for the initial instruction of the version, the Git central warehouse sends the first pull instruction to the first target according to the first transmission method. The server transmits the initial version file associated with the initial version number included in the first pull instruction; the first transmission method is to be related to the initial version number included in the first pull instruction The associated initial version file is directly transmitted to the first target server.

Understandably, after the first target server receives the version initial instruction, the first target server performs a check inside the first target server for the version initial instruction. When referring to the file related to the initial version number, the first target server feeds back the first pull instruction, indicating that the first target server needs to pull the initial version file, and the first transmission method is to push the file directly To the first target server, the initial version file is transmitted to the first target server according to the first transmission mode through the Git central warehouse.

In one embodiment, as shown in FIG. 5, in the step S40, the Git central warehouse is used to transmit to the first target server according to the first transmission mode. The included initial version file associated with the initial version number includes:

S401: Transmit the initial version file to the first target server through the Git central warehouse.

Understandably, the transmission method can be set according to requirements. For example, the Git central warehouse is connected to the first target server through SSH (Secure Shell), and the first target server is sent to the first target server after the connection. The target server transmits the initial version file, and the SSH mode is to generate a public key and a private key based on an asymmetric encryption method through the SSH protocol, and establish a communication connection through password authentication or public key authentication to ensure the security and integrity of information interaction.

S402: Receive a creation success instruction fed back after the first target server creates the local Git file associated with the initial version number.

Understandably, the initial version file is transmitted to the first target server through the Git central warehouse, and after receiving the initial version file, the first target server creates a local file associated with the initial version number locally. A Git file, marking that the first target server contains a file related to the initial version number, and feeding back the creation success instruction at the same time.

S50, according to the initial deployment command file, install the initial version file to the first target server in a non-interactive dialogue manner with the first target server.

Understandably, the initial deployment command file is a collection of guidance command instructions corresponding to the process instructions fed back by the first target server during the deployment process in all the execution deployment processes, and the non-interactive dialogue mode requires no manual operation. Perform an interactive dialogue with the target server to execute command instructions, directly and automatically execute the corresponding command instructions according to the corresponding relationship of one question and one answer, and install the initial version file to the first target server through a non-interactive dialogue mode, so, There is no need to manually configure the first target server manually, and the initial configuration file and the initial code file are automatically installed.

S60: After receiving all installation success instructions sent by the first target server that has fed back the first pull instruction, it is determined that the creation and release file package is successfully released.

Understandably, the first target server that has fed back the first pull instruction triggers the installation success instruction after the installation of the initial configuration file and the initial code file is completed, and all the first pull instructions that have been fed back are received After the installation success instruction fed back by the first target server of the instruction, it is confirmed that the creation and release file package is successfully released.

This application obtains the creation and release package by receiving the project version creation release instruction; the creation release package includes the initial version number, the initial version file, and the initial deployment job file that are related to each other; the initial version file includes the initial code file And the initial configuration file; the initial deployment job file contains the first IP address set and the initial deployment command file; the initial version file is stored in the Git local warehouse, and the initial version file is pushed to the Git central warehouse at the same time; All the first target servers that match the first IP address in the first IP address set send the initial version instruction containing the initial version number; the first target server receives the inclusion of the initial version instruction feedback After the first pull instruction of the initial version number, the Git central warehouse transmits the association with the initial version number contained in the first pull instruction to the first target server according to the first transmission method The initial version file; the first transmission method is to directly transmit the initial version file associated with the initial version number contained in the first pull instruction to the first target server; The initial deployment command file, install the initial version file to the first target server through a non-interactive dialogue with the first target server; receive all the first pull instructions that have fed back the first pull instruction After a successful installation instruction sent by a target server, it is determined that the creation and release file package is successfully released.

In this way, this application realizes that by obtaining the creation and release package, the initial version file in the creation and release package is stored in the Git local warehouse, and at the same time, it is pushed to the Git central warehouse, and the initial version is sent to all the first target servers. After receiving the first pull instruction feedback from the first target server for the initial instruction of the version, the Git central warehouse transmits the data to the first target server according to the first transmission method. According to the initial deployment command file, during the deployment process, the initial file is installed to the first target server through a non-interactive dialogue mode, and all the first pull instructions that have been fed back to the first target server are received. After a successful installation instruction sent by a target server, it is determined that the creation and release file package is successfully released, and the initial code file and initial configuration file are released through the first transmission method based on the Git distributed control system, and the initial deployment file is based on non-interactive The automatic installation of the initial code file and initial configuration file accurately transmitted to the target server is completed in a dialogue mode, thereby realizing the environment of automatically configuring the target server based on the Git distributed control system, which improves efficiency, greatly reduces manual configuration costs, and reduces This reduces operating costs and greatly shortens the release time of the project version.

In an embodiment, as shown in FIG. 3, after the step S60, that is, after the determining that the creation and release file package is successfully released, the method includes:

S70. The project version update release instruction is received, and the update release file package is obtained; the update release file package includes an associated update version number, a branch version file, and an update deployment file; the branch version file includes an update code file and an update Configuration file; the update deployment file contains the second IP address set and the update deployment command file.

Understandably, when there is an updated version that needs to be released during the project development process, firstly, through the application web interface, the user uploads related files that need to be updated according to the requirements of the web template, that is, according to the order of the set web template Upload related files to be updated in sequence; after receiving all files related to the project update version that have been determined, trigger the project version update release instruction, and the project update version is the version corresponding to the update and upgrade of the released project , So that all files related to the updated version of the project are merged according to the preset update template, that is, all files related to the updated version of the project are split and merged according to the requirements of the updated template. Refers to a template corresponding to the updated project that has been released, and compressed according to preset update compression parameters to generate the creation and release file package. The update compression parameters can be set according to requirements, such as the update compression parameters It is a parameter converted into rar format, or the updated compression parameter is a parameter converted into zip format, etc., wherein the updated compression parameter and the initial compression parameter may be consistent or inconsistent, and all compressed parameters The update release file package is uploaded to the cloud server; after the update release file package is received through the cloud server, the update release file package is decompressed, so as to obtain the update release file package. The update version number, the branch version file associated with the update version number, and the update deployment file associated with the update version number are compressed and uploaded to the cloud server by compressing the update release file package, and then decompressing the file to obtain The update release file package can receive multiple compressed update release file packages through a cloud server, and transfer and back up multiple compressed update release file packages, which can avoid obtaining multiple update release file packages. Risk of loss in the process.

Wherein, the branch version file includes the update code file and the update configuration file, the update code file is a source code file corresponding to the project update version, and the update configuration file is used to run the update code file. Files related to the operating environment that need to be configured, the update deployment job file includes the second IP address set and the update deployment command file, and the second IP address set is for all files that need to be released to the branch version The set of IP addresses corresponding to the target server.

S80: Store the branch version file in the Git local warehouse, and at the same time push the branch version file to the Git central warehouse.

Understandably, the Git local warehouse is a storage warehouse set based on the Git distributed control system, and the Git distributed control system is a system based on Git that includes a Git local warehouse and a Git central warehouse. The Git local The warehouse can accept and store project version files and version records uploaded or updated by users. The Git central warehouse is a temporary warehouse set based on the Git distributed control system, and the Git central warehouse receives the Git local warehouse. The branch version file pushed over and temporarily stored.

S90: Send a version update instruction containing the branch version number to all second target servers that match the second IP address in the second IP address set.

Understandably, the second target server is a target server consistent with the second IP address, and the second IP address is an element in the second IP address set, and sends to all the second target servers The version update instruction, the version update instruction is an instruction for publishing a branch version file, the version update instruction can be set according to requirements, such as generating a version update instruction according to an update instruction template provided by a Docker container management tool, etc., The version update instruction includes the update version number, and there may be a first IP address that is the same as the second IP address in the second IP address set, or there may be a first IP address that is the same as the first IP address in the first IP address set. A second IP address that is not the same as the first IP address.

S100. After receiving the second pull instruction that includes the branch version number fed back by the second target server for the version update instruction, the Git central warehouse uses the second transmission method to send the second pull instruction to the second target. The server transmits the difference file corresponding to the second target server; the second transmission method is to determine the difference file with the second target server according to the local Git file associated with the branch version number in the second pull instruction Corresponding difference files, and transmitting the difference files corresponding to the second target server to the second target server.

Understandably, after the second target server receives the version update instruction, the second target server detects the version update instruction inside the second target server, and the second target server feeds back In the second pull instruction, the second transmission method is based on the local Git file associated with the branch version number in the second pull instruction, and the local Git file associated with the branch version number is stored The file recorded in the Git folder directory format that reflects the association relationship between the folders in the second target server is determined, and the difference file corresponding to the second target server is determined and compared with the second target server. The corresponding difference file is transmitted to the second target server, that is, when the second target server detects that it does not contain any local Git file associated with the branch version number, it will feedback that there is no local Git file associated with the branch version number. According to the second pull instruction of the Git file, it is determined that the second target server needs to pull the entire branch version file according to the second pull instruction, so that the branch version file is sent to the second target server; The second target server detects that it locally contains the local Git file associated with the branch version number and the local Git file associated with the branch version number, that is, the branch version is determined by the degree of matching with the branch version number The local Git file associated with the branch version number, the second pull instruction containing the local Git file associated with the branch version number is fed back, and the received local Git file associated with the branch version number is combined with the branch version The files are compared, and the difference file after comparing the local Git file associated with the branch version number with the branch version file is obtained, so as to determine the difference file corresponding to the second target server. The second target The difference file corresponding to the server includes a code difference file and a configuration difference file. The code difference file is between the code file in the local Git file associated with the branch version number and the updated code file in the branch version file The configuration difference file is the file of the difference content between the configuration file in the local Git file associated with the branch version number and the updated configuration file in the branch version file. The difference file corresponding to the second target server is transmitted to the second target server.

In one embodiment, as shown in FIG. 6, in the step S100, that is, after the second pull instruction that includes the branch version number fed back by the second target server for the version update instruction is received , Transmitting the difference file corresponding to the second target server to the second target server according to the second transmission mode through the Git central warehouse, including:

S1001. Receive the second pull instruction sent after the second target server determines the local Git file associated with the branch version number according to the branch version number;

Understandably, the second target server locally searches for the relevant local Git file matching the branch version number according to the branch version number, and determines the second pull instruction according to the query result, that is, in the The second target server detects that it does not contain any local Git file associated with the branch version number, and then feeds back that there is no second pull instruction for the local Git file associated with the branch version number; check on the second target server When the local Git file associated with the branch version number is contained locally, the second pull instruction containing the local Git file associated with the branch version number is fed back.

S1002, comparing the local Git file with the branch version file by using the Git tool in the Git central warehouse to obtain a difference file corresponding to the second target server;

Understandably, the Git tool is a comparison tool for Git files in the Git central warehouse. The branch version file is converted into a Git file corresponding to the branch version file, and the local The Git file and the Git file corresponding to the branch version file are input into the Git tool for comparison, and the difference file corresponding to the second target server is obtained. The difference file is the local Git file and the Files with different content between the Git files corresponding to the branch version files.

S1003. After the difference file corresponding to the second target server is transmitted to the second target server through the Git central warehouse, a feedback is received after the second target server updates the local Git file associated with the initial version number The successful update instruction.

Understandably, the difference file is transmitted to the second target server through the Git central warehouse, and after that, the second target server updates the received difference file to the original version number. The associated local Git file, that is, the difference file with the same name as the local Git file associated with the initial version number in the difference file overwrites the local Git file, and the difference file is compared with the initial version The difference file with different names of the local Git file associated with the number is directly stored in the storage path of the local Git file associated with the initial version number, and the update success instruction is fed back after the update of the second target server is completed. The update success instruction refers to an instruction triggered after the second target server completes the update of the difference file.

In this way, the present application can reduce the transmission content, improve the transmission efficiency, and reduce the risk of information loss by transmitting the different file content based on the Git distributed control system.

S110: According to the update deployment command file, update the received branch version file to the second target server through a non-interactive dialogue with the second target server.

Understandably, the update deployment command file is a collection of update guidance command instructions corresponding to the update process instructions fed back by the second target server during the update deployment process in the update deployment process. The non-interactive dialogue The method is that there is no need for manual interactive dialogue with the target server to execute the command instructions, and the corresponding command instructions are directly executed automatically according to the corresponding relationship of one question and one answer, and the branch version file is installed to the second target through a non-interactive dialogue mode. The server, in this way, does not need to manually configure the second target server manually, and realizes the automatic installation and update of the configuration file and the update of the code file.

In one embodiment, as shown in FIG. 7, in the step S110, that is, according to the update deployment command file, the received branch version is exchanged with the second target server in a non-interactive dialogue manner. The file update to the second target server includes:

S1101: Receive a transmission completion instruction issued by the second target server after the branch version file is completed, and send a stop instruction and a deployment instruction in the update deployment command file to the second target server.

Understandably, the second target server triggers the transfer completion instruction after confirming that the branch version file is received, and after receiving the transfer completion instruction, sends the stop instruction and the stop instruction to the second target server in sequence. The deployment instruction, the stop instruction is an instruction in the update deployment command file to stop running the local Git file associated with the initial version number in the second target server, and the deployment instruction is the update The deployment command file executes instructions related to the deployment operation of the branch version file in the second target server.

S1102: When receiving the abnormal instruction fed back by the second target server during the execution of the stop instruction and the deployment instruction, search for a repair instruction matching the abnormal instruction from the update deployment command file, and The repair instruction is sent to the second target server to complete the update process until the completion instruction fed back by the second target server is received.

Understandably, when the second target server has an abnormal situation during the execution of the stop instruction and the deployment instruction, for example, the abnormal situation is downtime, the abnormal instruction corresponding to the abnormal situation is fed back, such as The abnormal instruction is an instruction corresponding to the downtime. After receiving the abnormal instruction, search for a repair instruction matching the abnormal instruction from the update deployment command file, and send the repair instruction to the second For the target server, for example, the repair instruction is an instruction to restart the server corresponding to the solution of the downtime, etc., and the update process refers to the process of executing the stop instruction and the deployment instruction until the second target server feedback is received The completion instruction is an instruction triggered after the second target server completes the update process.

S1103: Upon receiving the completion instruction fed back after the second target server completes all the deployment instructions, send the start instruction in the update deployment command file to the second target server, and confirm that the branch version file is updated To the second target server.

Understandably, when the completion instruction fed back by the second target server is received, the start instruction is sent to the second target server, and the start instruction is in the update deployment command file and the start The instruction related to the branch version file determines that the branch version file has been updated to the second target server.

In this way, the present application completes the non-interactive dialogue with the second target server. The second target server does not need to be manually configured in the deployment process, so that the update code in the branch version file is automatically updated. Documents and update configuration files greatly reduce manual operations, improve the efficiency of project version release, and reduce operating costs.

S120: After receiving all the update success instructions sent by the second target server that has fed back the second pull instruction, it is determined that the update release file package is successfully released.

Understandably, the second target server that has fed back the second pull instruction triggers the update success instruction after completing the installation of the branch version file, and receives all the second pull instructions that have fed back the second pull instruction. After the update success instruction fed back by the second target server, it is confirmed that the update release file package is successfully released.

In this way, this application realizes that by obtaining the update release file package, the branch version file in the update release file package is stored in the Git local warehouse, and at the same time, it is pushed to the Git central warehouse, and the updated version is sent to all second target servers. After receiving the second pull instruction fed back by the second target server, the updated version file is transmitted to the second target server according to the second transmission method through the Git central warehouse. During the deployment process, according to the update deployment command file, the update file is installed to the second target server in a non-interactive dialogue mode, and all updates sent by the second target server that have fed back the second pull instruction are received After the successful instruction, it is determined that the update release file package is successfully released, and the Git distributed control system is based on the second transmission method to release the update code file and the update configuration file. According to the update deployment file, the transmission is completed through non-interactive dialogue. The update code file and update configuration file of each target server are automatically updated, so as to automatically configure the environment corresponding to the updated version number of the target server, improve efficiency, reduce operating costs, and greatly shorten the project version release time.

In an embodiment, as shown in FIG. 4, after the step S120, that is, after determining that the update release file package is successfully released, the method includes:

S130. A project version rollback release instruction is received, and a rollback release file package is obtained; the rollback release file package includes a rollback version number and a rollback deployment job file; the rollback deployment job file includes a third IP address Collect and roll back deployment command files.

Understandably, after the update release file package is successfully released, it is found that there is an abnormality in the operation process, and it needs to be rolled back to a certain version number in the history, or according to the demand, it needs to be rolled back to a certain version number in the history. In the application web interface, select the rollback version number from all the historical version numbers, and the rollback version number is the initial version number and all historical update version numbers (that is, except for the current update version number). The rollback deployment job file contains the third IP address set and the rollback deployment command file, and the third IP address set can be as needed Setting is performed, for example, the third IP address set is the same as the second IP address set.

S140: Query and obtain a version file associated with a version number consistent with the rollback version number from the local Git warehouse.

Understandably, the Git local warehouse stores version numbers of all project versions and version files associated with the version numbers, where the version numbers include the initial version number and at least one of the updated version numbers, and the version files include The initial version file and at least one of the updated version files, the version number is associated with the version file one by one, that is, the initial version number is associated with the initial version file, and the updated version number is associated with the update Version file association.

S150: Push the version file associated with the version number consistent with the rollback version number to the Git central warehouse.

Understandably, the obtained version file associated with the version number consistent with the rollback version number is pushed to the Git central warehouse.

S160: Send a version rollback instruction containing the rollback version number to all third target servers that match the third IP address in the third IP address set.

Understandably, the third target server is a target server that is consistent with the third IP address, and the third IP address is an element in the third IP address set, which is sent to all third target servers The version rollback instruction, the version rollback instruction is an instruction for the second target server that has been released to roll back to the historical project version, and the initial version instruction can be set according to requirements, for example, according to The rollback instruction template provided by the Docker container management tool generates a version rollback instruction, etc., the version initial instruction includes the rollback version number, and the third IP address set may be the same as the second IP address set.

S170. After receiving the third pull instruction that includes the rollback version number that is fed back by the third target server for the version rollback instruction, the Git central warehouse sends the third transmission method to the The third target server transmits the difference file corresponding to the third target server; the third transmission method is also based on the local Git file associated with the rollback version number in the third pull instruction to determine the The difference file corresponding to the third target server is transmitted, and the difference file corresponding to the third target server is transmitted to the third target server.

Understandably, after the third target server receives the version rollback instruction, the third target server detects the version rollback instruction inside the third target server, and the third target server The third pull instruction is fed back, and the third transmission method is based on the local Git file associated with the rollback version number in the third pull instruction, and the local Git file associated with the rollback version number Git files are files stored in the third target server and recorded in the Git folder directory format that reflects the association relationship between folders. The difference file corresponding to the third target server is determined, and the difference file is compared with the third target server. The difference file corresponding to the third target server is transmitted to the third target server, that is, when the third target server detects that it does not contain any local Git file associated with the rollback version number, the feedback is not related to the rollback version number. Roll the third pull instruction of the local Git file associated with the version number, and determine according to the third pull instruction that the third target server needs to pull the entire version file associated with the version number that is consistent with the rollback version number, thereby The version file associated with the version number consistent with the rollback version number is sent to the third target server; the third target server detects that the local Git file associated with the rollback version number locally contains the local Git file associated with the rollback version number, that is, through The degree of matching with the branch version number determines the local Git file associated with the rollback version number, and then the third pull instruction containing the local Git file is fed back, and the received version is the same as the rollback version number. The associated local Git file is compared with the obtained version file, and the difference file between the local Git file associated with the rollback version number and the obtained version file is obtained, and the difference file is determined to be the third The difference file corresponding to the target server, and the difference file corresponding to the third target server.

S180, according to the rollback deployment command file, roll back the version file to the third target server in a non-interactive dialogue manner with the third target server.

Understandably, the rollback deployment command file is a collection of all rollback guidance command instructions corresponding to the rollback process instructions fed back by the third target server during the rollback deployment process in the rollback deployment process, so The non-interactive dialogue mode is to execute the command instruction without manual interactive dialogue with the target server, and directly and automatically execute the corresponding command instruction according to the corresponding relationship of one question and one answer, and the version number will be rolled back through the non-interactive dialogue mode. The version file associated with the consistent version number is installed to the third target server, so that there is no need to manually configure the third target server manually, and the version associated with the version number consistent with the rollback version number is automatically installed. document.

S190: After receiving all the rollback success instructions sent by the third target server that has fed back the third pull instruction, it is determined that the rollback release file package is successfully released.

Understandably, after the third target server that has fed back the third pull instruction completes the installation of the version file associated with the version number that is consistent with the rollback version number, the rollback success instruction is triggered, and all the completed rollback instructions are received. After the rollback success instruction fed back by the third target server that feeds back the third pull instruction, it is confirmed that the rollback release file package is successfully released.

In this way, this application realizes that the version file is queried and obtained from the Git local warehouse by obtaining the rollback version number. Based on the Git distributed control system, the version file associated with the rollback version number is released through the third transmission method, and the rollback deployment file is passed Complete the automatic rollback of version files transferred to multiple target servers in a non-interactive dialog mode, so as to automatically configure the target server and the environment corresponding to the rollback version number, and quickly roll back in the case of abnormalities after the project version is released To the historical version, reducing operating costs.

In one embodiment, a Git-based project version publishing device is provided, and the Git-based project version publishing device corresponds to the Git-based project version publishing method in the foregoing embodiment in a one-to-one correspondence. As shown in FIG. 8, the Git-based project version release device includes a receiving module 11, a storage module 12, a sending module 13, a transmission module 14, an installation module 15 and a determination module 16. The detailed description of each functional module is as follows:

The receiving module 11 is configured to receive a project version creation and release instruction, and obtain a creation and release file package; the creation and release file package includes an initial version number, an initial version file, and an initial deployment job file associated with each other; the initial version file includes An initial code file and an initial configuration file; the initial deployment job file includes a first IP address set and an initial deployment command file;

The storage module 12 is used to store the initial version file in the Git local warehouse, and at the same time push the initial version file to the Git central warehouse;

The sending module 13 is configured to send a version initial instruction containing the initial version number to all first target servers that match the first IP address in the first IP address set;

The transmission module 14 is configured to, after receiving the first pull instruction that includes the initial version number fed back by the first target server for the initial instruction of the version, send it to the office in accordance with the first transmission method through the Git central warehouse. The first target server transmits the initial version file associated with the initial version number included in the first pull instruction; the first transmission method is to communicate with all the files included in the first pull instruction Directly transmitting the initial version file associated with the initial version number to the first target server;

The installation module 15 is configured to install the initial version file to the first target server through a non-interactive dialogue with the first target server according to the initial deployment command file;

The determining module 16 is configured to determine that the creation and release file package is successfully released after receiving all installation success instructions sent by the first target server that has fed back the first pull instruction.

In an embodiment, as shown in FIG. 9, the determining module 16 includes:

The receiving unit 61 is configured to receive the project version update release instruction and obtain the update release file package; the update release file package includes the associated update version number, the branch version file, and the update deployment file; the branch version file includes the update A code file and an update configuration file; the update deployment file includes a second IP address set and an update deployment command file;

The storage unit 62 is configured to store the branch version file to the Git local warehouse, and at the same time push the branch version file to the Git central warehouse;

The sending unit 63 is configured to send a version update instruction containing the branch version number to all second target servers that match the second IP address in the second IP address set;

The transmission unit 64 is configured to, after receiving the second pull instruction containing the branch version number that is fed back by the second target server for the version update instruction, to the Git central warehouse according to the second transmission method. The second target server transmits the difference file corresponding to the second target server; the second transmission method is to determine the difference file corresponding to the branch version number according to the local Git file associated with the branch version number in the second pull instruction A difference file corresponding to the second target server, and transmitting the difference file corresponding to the second target server to the second target server;

The update unit 65 is configured to update the received branch version file to the second target server through a non-interactive dialogue with the second target server according to the update deployment command file;

The determining unit 66 is configured to determine that the update release file package is successfully released after receiving all the update success instructions sent by the second target server that has fed back the second pull instruction.

In an embodiment, the determining unit 66 includes:

The first receiving subunit is configured to receive the project version rollback release instruction and obtain the rollback release file package; the rollback release file package includes the rollback version number and the rollback deployment job file; the rollback deployment job The file contains the third IP address set and the rollback deployment command file;

The query subunit is used to query and obtain the version file associated with the version number consistent with the rollback version number from the Git local warehouse;

A push sub-unit for pushing version files associated with a version number consistent with the rollback version number to the Git central warehouse;

A sending subunit, configured to send a version rollback instruction containing the rollback version number to all third target servers that match the third IP address in the third IP address set;

The first transmission subunit is configured to receive the third pull instruction containing the rollback version number that is fed back by the third target server for the version rollback instruction, and then use the Git central warehouse to follow the first The third transmission mode transmits the difference file corresponding to the third target server to the third target server; the third transmission mode is also based on the local version associated with the rollback version number in the third pull instruction. Git file, determining a difference file corresponding to the third target server, and transmitting the difference file corresponding to the third target server to the third target server;

A rollback subunit, configured to roll back the version file to the third target server through a non-interactive dialogue with the third target server according to the rollback deployment command file;

The determining subunit is configured to determine that the rollback release file package is successfully released after receiving all the rollback success instructions sent by the third target server that has fed back the third pull instruction. In an embodiment, the transmission module 14 includes:

A transmitting unit, configured to transmit the initial version file to the first target server through the Git central warehouse;

The feedback unit is configured to receive a creation success instruction fed back after the first target server creates the local Git file associated with the initial version number.

In an embodiment, the transmission unit 64 includes:

A second receiving subunit, configured to receive the second pull instruction sent after the second target server determines the local Git file related to the branch version according to the branch version number;

The comparison subunit is used to compare the local Git file with the branch version file through the Git tool in the Git central warehouse to obtain a difference file corresponding to the second target server;

The second transmission subunit is used to update the initial version number association after receiving the second target server after transmitting the difference file corresponding to the second target server to the second target server through the Git central warehouse After the local Git file, the update success instruction is fed back.

In an embodiment, the update unit 65 includes:

The third receiving subunit is configured to receive the transmission completion instruction issued by the second target server after the branch version file is completed, and send the stop instruction and the deployment instruction in the update deployment command file to the second target server;

The execution update subunit is configured to, upon receiving the abnormal instruction fed back by the second target server during the execution of the stop instruction and the deployment instruction, search for a match with the abnormal instruction from the update deployment command file And send the repair instruction to the second target server to complete the update process until the completion instruction fed back by the second target server is received;

The update completion subunit is configured to send the start instruction in the update deployment command file to the second target server when receiving the completion instruction fed back after the second target server completes all the deployment instructions, and confirm all The branch version file is updated to the second target server.

For the specific limitation of the Git-based project version release device, please refer to the above limitation on the Git-based project version release method, which will not be repeated here. Each module in the Git-based project version release device can be implemented in whole or in part by software, hardware, and a combination thereof. The above-mentioned modules may be embedded in the form of hardware or independent of the processor in the computer equipment, or may be stored in the memory of the computer equipment in the form of software, so that the processor can call and execute the operations corresponding to the above-mentioned modules.

In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as shown in FIG. 10. The computer equipment includes a processor, a memory, a network interface, and a database connected through a system bus. Among them, the processor of the computer device is used to provide calculation and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external terminal through a network connection. The computer program is executed by the processor to implement a Git-based project version release method.

In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and capable of running on the processor. When the processor executes the computer program, the Git-based project version in the above-mentioned embodiment is implemented. Publishing method.

In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the Git-based project version publishing method in the foregoing embodiment is implemented. Optionally, the storage medium involved in this application, such as a computer-readable storage medium, may be non-volatile or volatile.

A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be implemented by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer readable storage. In the medium, when the computer program is executed, it may include the processes of the above-mentioned method embodiments. Wherein, any reference to memory, storage, database, or other media used in the embodiments provided in this application may include non-volatile and/or volatile memory. Non-volatile memory may include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. As an illustration and not a limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous chain Channel (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

Those skilled in the art can clearly understand that, for the convenience and conciseness of description, only the division of the above functional units and modules is used as an example. In practical applications, the above functions can be allocated to different functional units and modules as needed. Module completion, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the functions described above.

The above-mentioned embodiments are only used to illustrate the technical solutions of the present application, not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, a person of ordinary skill in the art should understand that it can still implement the foregoing The technical solutions recorded in the examples are modified, or some of the technical features are equivalently replaced; these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the application, and should be included in Within the scope of protection of this application.

Claims

A Git-based project version release method, which includes:

The project version creation release instruction is received, and the creation release file package is obtained; the creation release file package includes an initial version number, an initial version file, and an initial deployment job file associated with each other; the initial version file includes an initial code file and an initial configuration File; the initial deployment job file includes a first IP address set and an initial deployment command file;

Store the initial version file in the Git local warehouse, and push the initial version file to the Git central warehouse at the same time;

Sending a version initial instruction containing the initial version number to all first target servers that match the first IP address in the first IP address set;

After receiving the first pull instruction that includes the initial version number that is fed back by the first target server for the version initial instruction, the Git central warehouse transmits it to the first target server according to the first transmission method The initial version file associated with the initial version number included in the first pull instruction; the first transmission method is to associate with the initial version number included in the first pull instruction The initial version file is directly transmitted to the first target server;

According to the initial deployment command file, install the initial version file to the first target server through a non-interactive dialogue with the first target server;

After receiving all installation success instructions sent by the first target server that has fed back the first pull instruction, it is determined that the creation and release file package is successfully released.
The Git-based project version release method of claim 1, wherein after the determining that the creation and release file package is successfully released, it comprises:

The project version update release instruction is received, and the update release file package is obtained; the update release file package includes an associated update version number, a branch version file, and an update deployment file; the branch version file includes an update code file and an update configuration file ; The update deployment file includes a second IP address set and an update deployment command file;

Storing the branch version file in the Git local warehouse, and at the same time pushing the branch version file to the Git central warehouse;

Sending a version update instruction containing the branch version number to all second target servers that match the second IP address in the second IP address set;

After receiving the second pull instruction containing the branch version number that the second target server returns for the version update instruction, the Git central warehouse transmits it to the second target server in the second transmission mode The difference file corresponding to the second target server; the second transmission method is to determine the file corresponding to the second target server according to the local Git file associated with the branch version number in the second pull instruction A difference file, and transmitting the difference file corresponding to the second target server to the second target server;

According to the update deployment command file, update the received branch version file to the second target server through a non-interactive dialogue with the second target server;

After receiving all the update success instructions sent by the second target server that has fed back the second pull instruction, it is determined that the update release file package is successfully released.
3. The Git-based project version release method of claim 2, wherein, after determining that the update release file package is successfully released, the method comprises:

The project version rollback release instruction is received, and the rollback release file package is obtained; the rollback release file package includes the rollback version number and the rollback deployment job file; the rollback deployment job file contains the third IP address set and Roll back the deployment command file;

Query and obtain the version file associated with the version number consistent with the rollback version number from the local Git warehouse;

Push the version file associated with the version number consistent with the rollback version number to the Git central warehouse;

Sending a version rollback instruction containing the rollback version number to all third target servers that match the third IP address in the third IP address set;

After receiving the third pull instruction that contains the rollback version number that is fed back by the third target server for the version rollback instruction, the Git central warehouse uses the third transmission method to send the third pull instruction. The target server transmits the difference file corresponding to the third target server; the third transmission method is also to determine the difference file with the Three difference files corresponding to the target server, and transmitting the difference file corresponding to the third target server to the third target server;

According to the rollback deployment command file, roll back the version file to the third target server through a non-interactive dialogue with the third target server;

After receiving all the rollback success instructions sent by the third target server that has fed back the third pull instruction, it is determined that the rollback release file package is successfully released.
The Git-based project version release method of claim 1, wherein the Git central warehouse transmits the data contained in the first pull instruction to the first target server in a first transmission mode. The initial version file associated with the initial version number includes:

Transmitting the initial version file to the first target server through the Git central warehouse;

The creation success instruction fed back after the first target server creates the local Git file associated with the initial version number is received.
The Git-based project version release method according to claim 2, wherein after receiving the second pull instruction that contains the branch version number fed back by the second target server, the Git central warehouse is used, The transmission of the difference file corresponding to the second target server to the second target server according to the second transmission mode includes:

Receiving the second pull instruction sent after the second target server determines the local Git file related to the branch version according to the branch version number;

Comparing the local Git file with the branch version file by using the Git tool in the Git central warehouse to obtain a difference file corresponding to the second target server;

After the difference file corresponding to the second target server is transmitted to the second target server through the Git central warehouse, the update fed back after the second target server updates the local Git file associated with the initial version number is received Successful instruction.
The Git-based project version release method according to claim 2, wherein, according to the update deployment command file, the received branch version file is updated through a non-interactive dialogue with the second target server To the second target server, including:

Receiving the transmission completion instruction issued by the second target server after the branch version file is completed, and sending the stop instruction and the deployment instruction in the update deployment command file to the second target server;

When receiving the abnormal instruction fed back by the second target server during the execution of the stop instruction and the deployment instruction, it searches for a repair instruction matching the abnormal instruction from the update deployment command file, and restores all the instructions. The repair instruction is sent to the second target server to complete the update process until the completion instruction fed back by the second target server is received;

Upon receiving the completion instruction fed back after the second target server completes all the deployment instructions, send the start instruction in the update deployment command file to the second target server to confirm that the branch version file is updated to all The second target server.
A Git-based project version release device, which includes:

The receiving module is used to receive the project version creation release instruction and obtain the creation release file package; the creation release file package includes the initial version number, the initial version file, and the initial deployment job file related to each other; the initial version file includes the initial A code file and an initial configuration file; the initial deployment job file includes a first IP address set and an initial deployment command file;

The storage module is used to store the initial version file to the Git local warehouse, and at the same time push the initial version file to the Git central warehouse;

A sending module, configured to send a version initial instruction containing the initial version number to all first target servers that match the first IP address in the first IP address set;

The transmission module is configured to, after receiving the first pull instruction that includes the initial version number fed back by the first target server for the initial instruction of the version, use the Git central warehouse to send the first transmission method to the The first target server transmits the initial version file associated with the initial version number included in the first pull instruction; the first transmission method is to combine with the initial version number included in the first pull instruction The initial version file associated with the initial version number is directly transmitted to the first target server;

An installation module, configured to install the initial version file to the first target server through a non-interactive dialogue with the first target server according to the initial deployment command file;

The determining module is configured to determine that the creation and release file package is successfully released after receiving all installation success instructions sent by the first target server that has fed back the first pull instruction.
The Git-based project version publishing device according to claim 7, characterized in that it comprises:

The receiving unit is configured to receive the project version update release instruction and obtain the update release file package; the update release file package includes the associated update version number, the branch version file, and the update deployment file; the branch version file includes the update code File and an update configuration file; the update deployment file includes a second IP address set and an update deployment command file;

The storage unit is configured to store the branch version file in the Git local warehouse, and at the same time push the branch version file to the Git central warehouse;

A sending unit, configured to send a version update instruction containing the branch version number to all second target servers that match the second IP address in the second IP address set;

The transmission unit is configured to, after receiving the second pull instruction including the branch version number fed back by the second target server for the version update instruction, to the Git central warehouse according to the second transmission method The second target server transmits the difference file corresponding to the second target server; the second transmission method is based on the local Git file associated with the branch version number in the second pull instruction to determine the difference file with the first 2. a difference file corresponding to the target server, and transmitting the difference file corresponding to the second target server to the second target server;

The update unit is configured to update the received branch version file to the second target server through non-interactive dialogue with the second target server according to the update deployment command file;

The determining unit is configured to determine that the update release file package is successfully released after receiving all the update success instructions sent by the second target server that has fed back the second pull instruction.
A computer device includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor implements the following steps when the processor executes the computer program:

The project version creation release instruction is received, and the creation release file package is obtained; the creation release file package includes an initial version number, an initial version file, and an initial deployment job file associated with each other; the initial version file includes an initial code file and an initial configuration File; the initial deployment job file includes a first IP address set and an initial deployment command file;

Store the initial version file in the Git local warehouse, and push the initial version file to the Git central warehouse at the same time;

Sending a version initial instruction containing the initial version number to all first target servers that match the first IP address in the first IP address set;

After receiving the first pull instruction that includes the initial version number that is fed back by the first target server for the version initial instruction, the Git central warehouse transmits it to the first target server according to the first transmission method The initial version file associated with the initial version number included in the first pull instruction; the first transmission method is to associate with the initial version number included in the first pull instruction The initial version file is directly transmitted to the first target server;

According to the initial deployment command file, install the initial version file to the first target server through a non-interactive dialogue with the first target server;

After receiving all installation success instructions sent by the first target server that has fed back the first pull instruction, it is determined that the creation and release file package is successfully released.
9. The computer device according to claim 9, wherein, after said determining that the creation and release file package is successfully released, the processor further implements the following steps when executing the computer program:

The project version update release instruction is received, and the update release file package is obtained; the update release file package includes an associated update version number, a branch version file, and an update deployment file; the branch version file includes an update code file and an update configuration file ; The update deployment file includes a second IP address set and an update deployment command file;

Storing the branch version file in the Git local warehouse, and at the same time pushing the branch version file to the Git central warehouse;

Sending a version update instruction containing the branch version number to all second target servers that match the second IP address in the second IP address set;

After receiving the second pull instruction that contains the branch version number that is fed back by the second target server for the version update instruction, the Git central warehouse transmits it to the second target server in the second transmission mode The difference file corresponding to the second target server; the second transmission method is to determine the file corresponding to the second target server according to the local Git file associated with the branch version number in the second pull instruction A difference file, and transmitting the difference file corresponding to the second target server to the second target server;

According to the update deployment command file, update the received branch version file to the second target server through a non-interactive dialogue with the second target server;

After receiving all the update success instructions sent by the second target server that has fed back the second pull instruction, it is determined that the update release file package is successfully released.
10. The computer device according to claim 10, wherein after said determining that the update release file package is successfully released, the processor further implements the following steps when executing the computer program:

The project version rollback release instruction is received, and the rollback release file package is obtained; the rollback release file package includes the rollback version number and the rollback deployment job file; the rollback deployment job file contains the third IP address set and Roll back the deployment command file;

Query and obtain the version file associated with the version number consistent with the rollback version number from the local Git warehouse;

Push the version file associated with the version number consistent with the rollback version number to the Git central warehouse;

Sending a version rollback instruction containing the rollback version number to all third target servers that match the third IP address in the third IP address set;

After receiving the third pull instruction that contains the rollback version number that is fed back by the third target server for the version rollback instruction, the Git central warehouse uses the third transmission method to send the third pull instruction. The target server transmits the difference file corresponding to the third target server; the third transmission method is also to determine the difference file corresponding to the first Three difference files corresponding to the target server, and transmitting the difference file corresponding to the third target server to the third target server;

According to the rollback deployment command file, roll back the version file to the third target server through a non-interactive dialogue with the third target server;

After receiving all the rollback success instructions sent by the third target server that has fed back the third pull instruction, it is determined that the rollback release file package is successfully released.
9. The computer device according to claim 9, wherein the initial version number contained in the first pull instruction is transmitted to the first target server through the Git central warehouse in a first transmission manner When associating the initial version file, the following steps are specifically implemented:

Transmitting the initial version file to the first target server through the Git central warehouse;

The creation success instruction fed back after the first target server creates the local Git file associated with the initial version number is received.
The computer device according to claim 10, wherein after receiving the second pull instruction containing the branch version number fed back by the second target server, the Git central warehouse is used to perform the second transmission method When transmitting the difference file corresponding to the second target server to the second target server, the following steps are specifically implemented:

Receiving the second pull instruction sent after the second target server determines the local Git file related to the branch version according to the branch version number;

Comparing the local Git file with the branch version file by using the Git tool in the Git central warehouse to obtain a difference file corresponding to the second target server;

After the difference file corresponding to the second target server is transmitted to the second target server through the Git central warehouse, the update fed back after the second target server updates the local Git file associated with the initial version number is received Successful instruction.
The computer device according to claim 10, wherein, according to the update deployment command file, the received branch version file is updated to the second target server through non-interactive dialogue with the second target server. For the target server, implement the following steps:

Receiving the transmission completion instruction issued by the second target server after the branch version file is completed, and sending the stop instruction and the deployment instruction in the update deployment command file to the second target server;

When receiving the abnormal instruction fed back by the second target server during the execution of the stop instruction and the deployment instruction, it searches for the repair instruction matching the abnormal instruction from the update deployment command file, and compares all the instructions. The repair instruction is sent to the second target server to complete the update process until the completion instruction fed back by the second target server is received;

Upon receiving the completion instruction fed back after the second target server completes all the deployment instructions, send the start instruction in the update deployment command file to the second target server to confirm that the branch version file is updated to all The second target server.
A computer-readable storage medium storing a computer program, wherein the computer program is executed by a processor to implement the following steps:

The project version creation release instruction is received, and the creation release file package is obtained; the creation release file package includes an initial version number, an initial version file, and an initial deployment job file associated with each other; the initial version file includes an initial code file and an initial configuration File; the initial deployment job file includes a first IP address set and an initial deployment command file;

Store the initial version file in the Git local warehouse, and push the initial version file to the Git central warehouse at the same time;

Sending a version initial instruction containing the initial version number to all first target servers that match the first IP address in the first IP address set;

After receiving the first pull instruction that includes the initial version number that is fed back by the first target server for the version initial instruction, the Git central warehouse transmits it to the first target server in the first transmission mode The initial version file associated with the initial version number included in the first pull instruction; the first transmission mode is to associate with the initial version number included in the first pull instruction The initial version file is directly transmitted to the first target server;

According to the initial deployment command file, install the initial version file to the first target server through a non-interactive dialogue with the first target server;

After receiving all installation success instructions sent by the first target server that has fed back the first pull instruction, it is determined that the creation and release file package is successfully released.
15. The computer-readable storage medium according to claim 15, wherein, after it is determined that the creation and release file package is successfully released, the following steps are further implemented when the computer program is executed by the processor:

The project version update release instruction is received, and the update release file package is obtained; the update release file package includes an associated update version number, a branch version file, and an update deployment file; the branch version file includes an update code file and an update configuration file ; The update deployment file includes a second IP address set and an update deployment command file;

Storing the branch version file in the Git local warehouse, and at the same time pushing the branch version file to the Git central warehouse;

Sending a version update instruction containing the branch version number to all second target servers that match the second IP address in the second IP address set;

After receiving the second pull instruction that contains the branch version number that is fed back by the second target server for the version update instruction, the Git central warehouse transmits it to the second target server in the second transmission mode The difference file corresponding to the second target server; the second transmission method is to determine the file corresponding to the second target server according to the local Git file associated with the branch version number in the second pull instruction A difference file, and transmitting the difference file corresponding to the second target server to the second target server;

According to the update deployment command file, update the received branch version file to the second target server through a non-interactive dialogue with the second target server;

After receiving all the update success instructions sent by the second target server that has fed back the second pull instruction, it is determined that the update release file package is successfully released.
16. The computer-readable storage medium according to claim 16, wherein, after said determining that the update release file package is successfully released, the following steps are further implemented when the computer program is executed by the processor:

The project version rollback release instruction is received, and the rollback release file package is obtained; the rollback release file package includes the rollback version number and the rollback deployment job file; the rollback deployment job file contains the third IP address set and Roll back the deployment command file;

Query and obtain the version file associated with the version number consistent with the rollback version number from the local Git warehouse;

Push the version file associated with the version number consistent with the rollback version number to the Git central warehouse;

Sending a version rollback instruction containing the rollback version number to all third target servers that match the third IP address in the third IP address set;

After receiving the third pull instruction that contains the rollback version number that is fed back by the third target server for the version rollback instruction, the Git central warehouse uses the third transmission method to send the third pull instruction. The target server transmits the difference file corresponding to the third target server; the third transmission method is also to determine the difference file corresponding to the first Three difference files corresponding to the target server, and transmitting the difference file corresponding to the third target server to the third target server;

According to the rollback deployment command file, roll back the version file to the third target server through a non-interactive dialogue with the third target server;

After receiving all the rollback success instructions sent by the third target server that has fed back the third pull instruction, it is determined that the rollback release file package is successfully released.
15. The computer-readable storage medium according to claim 15, wherein the Git central warehouse transmits the data contained in the first pull instruction to the first target server in a first transmission mode. When the initial version file is associated with the initial version number, the following steps are specifically implemented:

Transmitting the initial version file to the first target server through the Git central warehouse;

The creation success instruction fed back after the first target server creates the local Git file associated with the initial version number is received.
16. The computer-readable storage medium according to claim 16, wherein after receiving the second pull instruction containing the branch version number fed back by the second target server, the Git central warehouse is used to follow the When the difference file corresponding to the second target server is transmitted to the second target server in the second transmission mode, the following steps are specifically implemented:

Receiving the second pull instruction sent after the second target server determines the local Git file related to the branch version according to the branch version number;

Comparing the local Git file with the branch version file by using the Git tool in the Git central warehouse to obtain a difference file corresponding to the second target server;

After the difference file corresponding to the second target server is transmitted to the second target server through the Git central warehouse, the update fed back after the second target server updates the local Git file associated with the initial version number is received Successful instruction.
16. The computer-readable storage medium according to claim 16, wherein, according to the update deployment command file, the received branch version file is updated to all the branch version files through a non-interactive dialogue with the second target server. When describing the second target server, the following steps are specifically implemented:

Receiving the transmission completion instruction issued by the second target server after the branch version file is completed, and sending the stop instruction and the deployment instruction in the update deployment command file to the second target server;

When receiving the abnormal instruction fed back by the second target server during the execution of the stop instruction and the deployment instruction, it searches for the repair instruction matching the abnormal instruction from the update deployment command file, and compares all the instructions. The repair instruction is sent to the second target server to complete the update process until the completion instruction fed back by the second target server is received;

Upon receiving the completion instruction fed back after the second target server completes all the deployment instructions, send the start instruction in the update deployment command file to the second target server to confirm that the branch version file is updated to all The second target server.