CN111666081B

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

Info

Publication number: CN111666081B
Application number: CN202010366362.8A
Authority: CN
Inventors: 耿铭
Original assignee: Ping An Technology Shenzhen Co Ltd
Current assignee: Ping An Technology Shenzhen Co Ltd
Priority date: 2020-04-30
Filing date: 2020-04-30
Publication date: 2024-04-05
Anticipated expiration: 2040-04-30
Also published as: WO2021217868A1; CN111666081A

Abstract

The invention discloses a Git-based project version release method, a device, equipment and a medium, wherein the method comprises the following steps: receiving a project version creation and release instruction, and acquiring a creation and release file package; creating a release file package comprising an initial version number, an initial version file and an initial deployment job file which are mutually related; storing the initial version file to a Git local warehouse and pushing the initial version file to a Git central warehouse; transmitting a version initial instruction containing an initial version number to a first target server; after receiving a first pulling instruction of a first target server, transmitting an initial version file to the first target server through a Git central warehouse according to a first transmission mode; installing the initial version file to a first target server according to the initial deployment command file; and after receiving all the installation success instructions, determining that creating the release file package is successful in release. The invention realizes the environment of automatically configuring the target server based on the Git distributed control system, improves the efficiency and reduces the cost.

Description

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

Technical Field

The present invention relates to the field of distributed deployment, and in particular, to a method, an apparatus, a computer device, and a storage medium for publishing a project version based on Git.

Background

Currently, in the field of project development, from project testing to project online, project developers or project consignors can put forward different requirements for projects, so a plurality of project versions often occur, and in the prior art, a single backbone centralized publishing system is generally based on svn (version control system of an open source code), so that management of the plurality of project versions is realized in the following manner: all developers develop on the same backbone of one svn warehouse, the testers perform test verification in the same test environment, and finally the modified file increment is manually deployed on line. The defects of the prior art scheme are as follows: firstly, the development and testing stage cannot realize remote sharing of codes to a plurality of target servers, and a tester can only test and verify under the environment of the same configuration file; secondly, when the project version is deployed and online, the problems of file missing release and entrainment release are very easy to occur, only codes are deployed when the project version is deployed and online, and configuration files are required to be manually deployed for each target server; meanwhile, the operation of rolling back to the historical version when an abnormality occurs after the deployment is online is complex.

Disclosure of Invention

The invention provides a method, a device, computer equipment and a storage medium for publishing a project version based on Git, which realize the automatic configuration of the environment of a target server based on a Git distributed control system, improve the efficiency, greatly reduce the manual configuration cost, reduce the operation cost and greatly shorten the project version publishing time.

A Git-based project version release method comprises the following steps:

receiving a project version creation and release instruction, and acquiring a creation and release file package; the creation and release file package comprises an initial version number, an initial version file and an initial deployment job file which are mutually related; the initial version file comprises an initial code file and an initial configuration file; the initial deployment job file comprises a first IP address set and an initial deployment command file;

storing the initial version file to a Git local warehouse, and pushing the initial version file to a Git central warehouse;

transmitting a version initial instruction containing the initial version number to all first target servers matched with the first IP addresses in the first IP address set;

after a first pulling instruction, which is fed back by the first target server and is aimed at the version initial instruction, containing the initial version number is received, transmitting the initial version file associated with the initial version number contained in the first pulling instruction to the first target server through the Git central warehouse in a first transmission mode; the first transmission mode 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;

According to the initial deployment command file, the initial version file is installed to the first target server in a non-interactive dialogue mode with the first target server;

and after receiving all the installation success instructions sent by the first target server which feeds back the first pull instruction, determining that the creation and release file package is successfully released.

A Git-based project version issuing apparatus comprising:

the receiving module is used for receiving a project version creation and release instruction and acquiring a creation and release file package; the creation and release file package comprises an initial version number, an initial version file and an initial deployment job file which are mutually related; the initial version file comprises an initial code file and an initial configuration file; the initial deployment job file comprises a first IP address set and an initial deployment command file;

the storage module is used for storing the initial version file to a Git local warehouse and pushing the initial version file to a 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 with first IP addresses in the first IP address set;

The transmission module is used for transmitting the initial version file associated with the initial version number contained in the first pull instruction to the first target server according to a first transmission mode through the Git central warehouse after receiving the first pull instruction which is fed back by the first target server and contains the initial version number for the version initial instruction; the first transmission mode 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 installation module is used for installing the initial version file to the first target server in a non-interactive dialogue mode with the first target server according to the initial deployment command file;

and the determining module is used for determining that the creation and release file package is successfully released after receiving all the installation success instructions sent by the first target server which feeds back the first pull instruction.

A computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, the processor implementing the steps of the Git-based project version issuing method described above when the computer program is executed.

A computer readable storage medium storing a computer program which, when executed by a processor, implements the steps of the Git-based project version issue method described above.

According to the invention, the initial version file in the creation and release file package is obtained and stored in the Git local warehouse, and is pushed to the Git central warehouse, and then the version initial instruction containing the initial version number is sent to all first target servers, after a first pulling instruction fed back by the first target servers for the version initial instruction is received, the initial version file is transmitted to the first target servers through the Git central warehouse according to a first transmission mode, in the deployment process, the initial file is installed to the first target servers through a non-interactive dialogue mode according to an initial deployment command file, and after installation success instructions sent by all the first target servers which have fed back the first pulling instruction are received, the creation and release file package is determined to be successfully released, so that the automatic installation of the initial code file and the initial configuration file accurately transmitted to the target servers is completed through a non-interactive dialogue mode based on the initial deployment file, the automatic control system is realized, the cost of the distributed service based on the Git is greatly reduced, and the operating cost is greatly reduced.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings that are needed in the description of the embodiments of the present invention will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present invention, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a schematic view of an application environment of a Git-based project version publishing method according to an embodiment of the present invention;

FIG. 2 is a flow chart of a Git-based project version publishing method according to an embodiment of the present invention;

FIG. 3 is a flowchart of step S60 of the Git-based project version issuing method according to an embodiment of the present invention;

FIG. 4 is a flowchart of step S120 of the Git-based project version issuing method according to an embodiment of the present invention;

FIG. 5 is a flowchart of step S40 of the Git-based project version issuing method according to an embodiment of the present invention;

FIG. 6 is a flowchart of step S100 of the Git-based project version issuing method according to an embodiment of the present invention;

FIG. 7 is a flowchart of step S110 of the Git-based project version issuing method according to an embodiment of the present invention;

FIG. 8 is a functional block diagram of a Git-based project version issuing device according to an embodiment of the present invention;

FIG. 9 is a functional block diagram of a determination module 16 in a Git-based project version issuing device in accordance with an embodiment of the present invention;

FIG. 10 is a schematic diagram of a computer device in accordance with an embodiment of the invention.

Detailed Description

The following description of the embodiments of the present invention will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are some, but not all embodiments of the invention. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.

The method for publishing the item version based on the Git can be applied to an application environment as shown in figure 1, wherein a client (computer equipment) communicates with a server through a network. Among them, clients (computer devices) include, but are not limited to, personal computers, notebook computers, smartphones, tablet computers, cameras, and portable wearable devices. The server may be implemented as a stand-alone server or as a server cluster composed of a plurality of servers.

In one embodiment, as shown in fig. 2, a method for publishing a project version based on Git is provided, and the technical scheme mainly includes the following steps S10-S60:

s10, receiving a project version creation and release instruction, and acquiring a creation and release file package; the creation and release file package comprises an initial version number, an initial version file and an initial deployment job file which are mutually related; the initial version file comprises an initial code file and an initial configuration file; the initial deployment job file comprises a first IP address set and an initial deployment command file.

Understandably, the application scenario of the present invention may be an operation on a web page or an operation on an application program, in an embodiment, through an application web page interface, a user uploads related files according to a web page template requirement, that is, sequentially uploads related files according to a set order requirement of the web page template, where the application web page interface refers to an interface for implementing an application operation through a web page; after receiving all the determined files related to the project version, triggering the project version to create an issue command, wherein the project version is a version corresponding to the project to be issued, so that all the files related to the project version are combined according to a preset initial template, namely all the files related to the project version are split and combined according to the requirement of the initial template, the initial template refers to a template corresponding to the project to be issued for the first time, the created issue file packet is generated by compressing according to a preset initial compression parameter, the initial compression parameter can be set according to requirements, for example, the initial compression parameter is a parameter converted into a rar format, or the initial compression parameter is a parameter converted into a zip format, and the like, and the created issue file packet after compression is uploaded to a cloud server; after the cloud server receives the creation release file package, the creation release file package is decompressed, so that the initial version number contained in the creation release file package, the initial version file associated with the initial version number and the initial deployment job file associated with the initial version number are obtained, the creation release file package is compressed and uploaded to the cloud server, the creation release file package is decompressed and obtained, a plurality of compressed creation release file packages can be received through the cloud server, and transfer and backup are carried out on the plurality of compressed creation release file packages, so that risks of losing in the process of obtaining a plurality of creation release file packages can be avoided.

The initial version file comprises the initial code file and the initial configuration file, the initial code file is a source code file of an item initial version, the initial configuration file is a file related to an operation environment required to be configured for operating the initial code file, the initial deployment job file comprises the first IP address set and the initial deployment command file, and the first IP address set is a set of IP addresses corresponding to all target servers to which the initial version file needs to be issued.

And S20, storing the initial version file to a Git local warehouse, and pushing the initial version file to a Git central warehouse.

The Git local warehouse is a storage warehouse set based on a Git distributed control system, the Git distributed control system is a system built based on Git and comprises a Git local warehouse and a Git central warehouse, the Git local warehouse can accept project version files and version records uploaded or updated by users and store the project version files and the version records, the Git central warehouse is a temporary storage warehouse set based on the Git distributed control system, and the Git central warehouse is used for receiving the initial version files pushed by the Git local warehouse and temporarily storing the initial version files.

S30, transmitting a version initial instruction containing the initial version number to all first target servers matched with the first IP addresses in the first IP address set.

Understandably, the first target server is a target server consistent with the first IP address, the first IP address is an element in the first IP address set, the version initial instruction is sent to all the first target servers, 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, a version initial instruction is generated according to an initial instruction template provided by a Docker container management tool, and the version initial instruction includes the initial version number.

S40, after receiving a first pulling instruction containing the initial version number fed back by the first target server aiming at the version initial instruction, transmitting the initial version file associated with the initial version number contained in the first pulling instruction to the first target server through the Git central warehouse according to a first transmission mode; the first transmission mode 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.

Understandably, after the first target server receives the version initiation instruction, the first target server detects the version initiation instruction in the first target server, and when the first target server does not detect that any file related to the initial version number is included, the first target server feeds back the first pull instruction, which indicates that the first target server needs to pull the initial version file, where the first transmission mode is to directly push the file to the first target server, and through the Git central repository, the initial version file is transmitted to the first target server according to the first transmission mode.

In an embodiment, as shown in fig. 5, in step S40, that is, the transmitting, by the Git central repository, the initial version file associated with the initial version number included in the first pull instruction to the first target server according to a first transmission manner includes:

s401, transmitting the initial version file to the first target server through the Git central warehouse.

Understandably, the transmission manner may be set according to requirements, for example, the set central repository is connected to the first target server by an SSH (Secure Shell protocol) manner, and the initial version file is transmitted to the first target server after the connection, where the SSH manner is that a public key and a private key are generated based on an asymmetric encryption method by an SSH protocol, and a communication connection is established by means of cryptographic authentication or public key authentication, so as to ensure the security and integrity of information interaction.

S402, receiving a creation success instruction fed back after the first target server creates a 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 repository, the first target server creates a local Git file associated with the initial version number locally after receiving the initial version file, marks that the first target server contains a file related to the initial version number, and feeds back the creation success instruction.

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

The initial deployment command file is a set of instruction commands corresponding to the process commands fed back by the first target server in the deployment process, the non-interactive dialogue mode is to execute the instruction commands without manually interacting with the target server, the corresponding instruction commands are directly and automatically executed according to the one-to-one correspondence, and the initial version file is installed to the first target server in the non-interactive dialogue mode, so that manual configuration is not required in the first target server, and automatic installation of the initial configuration file and the initial code file is realized.

S60, after receiving all the installation success instructions sent by the first target server which feeds back the first pulling instruction, determining 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 completing the installation of the initial configuration file and the initial code file, and confirms that the creation and release file package is successfully released after receiving all the installation success instructions fed back by the first target server that has fed back the first pull instruction.

The method comprises the steps of obtaining a creation and release file package by receiving a project version creation and release instruction; the creation and release file package comprises an initial version number, an initial version file and an initial deployment job file which are mutually related; the initial version file comprises an initial code file and an initial configuration file; the initial deployment job file comprises a first IP address set and an initial deployment command file; storing the initial version file to a Git local warehouse, and pushing the initial version file to a Git central warehouse; transmitting a version initial instruction containing the initial version number to all first target servers matched with the first IP addresses in the first IP address set; after a first pulling instruction which is fed back by the first target server aiming at the version initial instruction and contains the initial version number is received, transmitting the initial version file associated with the initial version number contained in the first pulling instruction to the first target server through the Git central warehouse according to a first transmission mode; the first transmission mode 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; according to the initial deployment command file, the initial version file is installed to the first target server in a non-interactive dialogue mode with the first target server; and after receiving all the installation success instructions sent by the first target server which feeds back the first pull instruction, determining that the creation and release file package is successfully released.

In this way, the invention realizes that the initial version file in the creation and release file package is stored in the Git local warehouse by acquiring the creation and release file package, and is pushed to the Git central warehouse at the same time, the version initial instruction containing the initial version number is sent to all the first target servers, after the first pulling instruction fed back by the first target servers for the version initial instruction is received, the initial version file is transmitted to the first target servers through the Git central warehouse according to the first transmission mode, the initial file is installed to the first target servers according to the initial deployment instruction file in a non-interactive dialogue mode, after the installation success instruction sent by the first target servers which have fed back the first pulling instruction is received, the creation and release file package is determined to be successfully released, the automatic installation of the initial code file and the initial configuration file which are accurately transmitted to the target servers is completed according to the initial deployment file through the first transmission mode, thereby realizing the automatic installation of the initial code file and the initial configuration file which are accurately transmitted to the target servers through the non-interactive mode, greatly reducing the cost of the distributed control system based on the initial configuration file, greatly reducing the cost of the distributed service system, and greatly reducing the cost of the operation.

In one embodiment, as shown in fig. 3, after the step S60, that is, after the determining that the creation distribution file package is successfully distributed, the method includes:

s70, receiving a project version update issue command, and acquiring an update issue file packet; the update release file package comprises an update version number, a branch version file and an update deployment file which are mutually related; the branch version file comprises an update code file and an update configuration file; the update deployment file comprises a second IP address set and an update deployment command file.

Understandably, when there is an updated version to be released in the process of project development, preferably, through the application web interface, the user uploads the related files to be updated according to the web page template requirement, that is, sequentially uploads the related files to be updated according to the sequence requirement of the set web page template; after receiving all the determined files related to the updated version of the project, triggering the project version update issue command, wherein the updated version of the project is a version corresponding to the update and update of the issued project, so that all the files related to the updated version of the project are combined according to a preset update template, namely all the files related to the updated version of the project are split and combined according to the requirement of the update template, the update template refers to a template corresponding to the project of which the update and update has been issued, compression is performed according to a preset update compression parameter to generate the creation issue file package, the update compression parameter can be set according to the requirement, for example, the update compression parameter is a parameter converted into an rar format, or the update compression parameter is a parameter converted into a zip format, and the like, wherein the update compression parameter can be consistent with the initial compression parameter, can be inconsistent, and the compressed update issue file package is uploaded to the server in cloud; after the cloud server receives the update release file package, the update release file package is decompressed, so that the update version number contained in the update release file package, the branch version files related to the update version number and the update deployment files related to the update version number are obtained, the update release file package is compressed and uploaded to the cloud server, the update release file package is obtained through decompression, a plurality of compressed update release file packages can be received through the cloud server, and the plurality of compressed update release file packages are transferred and backed up, so that risks of losing in the process of obtaining a plurality of update release file packages can be avoided.

The branch version file comprises the update code file and the update configuration file, the update code file is a source code file corresponding to the project update version, the update configuration file is a file related to an operating environment required to be configured for operating the update code file, the update deployment job file comprises the second IP address set and the update deployment command file, and the second IP address set is a set of IP addresses corresponding to all target servers to which the branch version file needs to be issued.

S80, storing the branch version file to the Git local warehouse, and pushing the branch version file to the Git central warehouse.

The Git local warehouse is a storage warehouse set based on a Git distributed control system, the Git distributed control system is a system built based on Git and comprises a Git local warehouse and a Git central warehouse, the Git local warehouse can accept project version files and version records uploaded or updated by users and store the project version files and the version records, the Git central warehouse is a temporary storage warehouse set based on the Git distributed control system, and the Git central warehouse is used for receiving the branch version files pushed by the Git local warehouse and temporarily storing the branch version files.

And S90, transmitting a version update instruction containing the branch version number to all second target servers matched with the second IP addresses in the second IP address set.

It may be appreciated that the second target server is a target server consistent with the second IP address, where the second IP address is an element in the second IP address set, and the version update instruction is an instruction for issuing a branch version file, where the version update instruction may be set according to a requirement, for example, a version update instruction is generated according to an update instruction template provided by a Docker container management tool, where the version update instruction includes the update version number, and where 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 second IP address that is different from all the first IP addresses in the first IP address set.

S100, after receiving a second pulling instruction containing the branch version number fed back by the second target server aiming at the version updating instruction, transmitting a difference file corresponding to the second target server through the Git central warehouse according to a second transmission mode; and the second transmission mode is to determine a difference file corresponding to the second target server according to the local Git file associated with the branch version number in the second pull instruction, and transmit the difference file corresponding 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 in the second target server, and the second target server feeds back the second pull instruction, where the second transmission manner is that, according to a local Git file associated with the branch version number in the second pull instruction, the local Git file associated with the branch version number is a file stored in the second target server and recorded in a Git folder directory format that reflects an association relationship between folders, determines a difference file corresponding to the second target server, and transmits the difference file corresponding to the second target server, that is, if the second target server detects that the second target server does not include any local Git file associated with the branch version number, a second pull instruction without a local Git file associated with the branch version number is fed back, and according to the second pull instruction, determines that the second target server needs to pull the whole version number, and thus the second target server needs to send the branch version number to the second target server; and if the second target server detects that the local Git file associated with the branch version number is locally contained and the local Git file associated with the branch version number is determined through the matching degree of the branch version number, a second pulling instruction containing the local Git file associated with the branch version number is fed back, the received local Git file associated with the branch version number is compared with the branch version file, the difference file obtained after the local Git file associated with the branch version number is compared with the branch version file is obtained, and therefore the difference file corresponding to the second target server is determined, the difference file corresponding to the second target server comprises a code difference file and a configuration difference file, the code difference file is a file of difference content between the code file in the local Git file associated with the branch version number and an update code file in the branch version file, the configuration difference file is a difference file corresponding to the second difference file in the branch version number, and the second target server transmits the difference file corresponding to the second target server.

In an embodiment, as shown in fig. 6, in step S100, after receiving the second pull instruction including the branch version number fed back by the second target server for the version update instruction, the transmitting, by the Git central repository, the difference file corresponding to the second target server according to the second transmission manner includes:

s1001, the second pulling instruction sent after the second target server determines a local Git file associated with the branch version number according to the branch version number is received;

understandably, the second target server searches the relevant local Git file matched with the branch version number locally according to the branch version number, determines the second pull instruction according to the query result, that is, if the second target server detects that the second target server does not contain any local Git file associated with the branch version number, the second pull instruction without the local Git file associated with the branch version number is fed back; and if the second target server detects that the local Git file associated with the branch version number is contained locally, feeding back a second pull instruction containing the local Git file associated with the branch version number.

S1002, comparing the local Git file with the branch version file through a 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 the Git files in the Git central repository, converts the branch version file into a Git file corresponding to the branch version file, inputs the Git file corresponding to the local Git file and the branch version file into the Git tool for comparison, and obtains the difference file corresponding to the second target server, where the difference file is a file with difference content between the local Git file and the Git file corresponding to the branch version file.

S1003, after the difference file corresponding to the second target server is transmitted to the second target server through the Git central warehouse, an update success instruction fed back after the second target server updates the local Git file associated with the initial version number is received.

The difference file is understandably transmitted to the second target server through the Git central repository, after that, the second target server updates the received difference file to a local Git file associated with the initial version number, namely, the difference file with the same name as the local Git file associated with the initial version number in the difference file is covered by the local Git file, the difference file with the different name as the local Git file associated with the initial version number in the difference file is directly stored in a storage path of the local Git file associated with the initial version number, and the second target server feeds back the update success instruction after completing the update, wherein the update success instruction refers to an instruction triggered after the second target server completes the update of the difference file.

Therefore, the invention 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.

And S110, updating the received branch version file to the second target server in a non-interactive dialogue mode with the second target server according to the update deployment command file.

The update deployment command file is a set of update instruction commands corresponding to the update process commands fed back by the second target server in the update deployment process, the non-interactive dialogue mode is to execute the command commands without manually interacting with the target server, the corresponding command commands are directly and automatically executed according to the one-to-one correspondence, and the branch version file is installed to the second target server in the non-interactive dialogue mode, so that manual configuration is not required in the second target server, and automatic installation of the update configuration file and the update code file is realized.

In an embodiment, as shown in fig. 7, in step S110, the updating the received branch version file with the second target server according to the update deployment command file through a non-interactive dialogue manner includes:

S1101, receiving a transmission completion instruction sent by the second target server after the second target server receives the branch version file, and sending 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 transmission completion instruction after confirming that the branch version file is received, and after receiving the transmission completion instruction, the stop instruction and the deployment instruction are sequentially sent to the second target server, where 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 an instruction in the update deployment command file to execute the branch version file to deploy operations related to the operation in the second target server.

S1102, when an abnormal instruction fed back by the second target server in the process of executing the stop instruction and the deployment instruction is received, searching a repair instruction matched with the abnormal instruction from the update deployment instruction file, and sending the repair instruction to the second target server to complete the update process until a completion instruction fed back by the second target server is received.

Understandably, when an abnormal condition exists in the process of executing the stop instruction and the deployment instruction by the second target server, for example, the abnormal condition is downtime, the abnormal instruction corresponding to the abnormal condition is fed back, for example, the abnormal instruction is an instruction corresponding to downtime, after the abnormal instruction is received, a repair instruction matched with the abnormal instruction is searched for in the update deployment instruction file, the repair instruction is sent to the second target server, for example, the repair instruction is an instruction for restarting the server corresponding to the downtime, and the like, the update process refers to the process of executing the stop instruction and the deployment instruction until the second target server is received to feed back the completion instruction, and the completion instruction is an instruction triggered after the second target server completes the update process.

S1103, when receiving the completion instruction fed back after the second target server completes all the deployment instructions, sending a starting instruction in the update deployment command file to the second target server, and confirming 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, where the start instruction is an instruction related to starting the branch version file in the update deployment command file, and it is determined that the branch version file has been updated to the second target server.

Therefore, the invention completes the non-interactive dialogue mode with the second target server, and does not need manual configuration in the deployment process, thereby realizing automatic updating of the updating code file and the updating configuration file in the branch version file, greatly reducing manual operation, improving the efficiency of releasing the project version and reducing the operation cost.

S120, after receiving all the update success instructions sent by the second target server which has fed back the second pull instruction, determining that the update issue file packet is issued successfully.

Understandably, the second target server that has fed back the second pull instruction triggers the update success instruction after the installation of the branch version file is completed, and confirms that the update issue file package issues successfully after receiving all the update success instructions fed back by the second target server that has fed back the second pull instruction.

In this way, the invention realizes that the branch version files in the update release file package are stored in the Git local warehouse and pushed to the Git central warehouse, and then the version update instruction containing the update version number is sent to all second target servers, after the second pull instruction fed back by the second target servers is received, the update version files are transmitted to the second target servers through the Git central warehouse according to the second transmission mode, in the deployment process, the update files are installed to the second target servers through the non-interactive dialogue mode according to the update deployment command files, after the update success instruction sent by the second target servers which have fed back the second pull instruction is received, thereby determining that the update release file package is successfully released, realizing that the update code files and the update configuration files are released through the second transmission mode based on the Git distributed control system, completing the automatic update of the update code files and the update configuration files transmitted to the plurality of target servers through the non-interactive dialogue mode according to the update deployment files, thereby realizing the automatic update of the update code files and the update configuration files transmitted to the target servers, greatly reducing the service release cost and greatly, and greatly shortening the service release cost.

In one embodiment, as shown in fig. 4, after the step S120, that is, after the determining that the update distribution package is successfully distributed, the method includes:

s130, receiving a rollback issuing instruction of a project version, and acquiring a rollback issuing file packet; the rollback release file package comprises a rollback version number and a rollback deployment job file; the rollback deployment job file includes a third set of IP addresses and a rollback deployment command file.

It may be appreciated that, when an exception is found in the running process after the update issue file packet is issued successfully, a version number needs to be rolled back to a certain history, or a version number needs to be rolled back to a certain history according to a requirement, a rollback version number needs to be selected from all the historical version numbers in the application web interface, where the rollback version number is one of the initial version number and all the historical update version numbers (i.e. except the current update version number), and a rollback deployment job file is input, where the rollback deployment job file includes the third IP address set and a rollback deployment command file, and the third IP address set may be set as required, for example, the third IP address set is the same as the second IP address set.

S140, inquiring and acquiring a version file associated with the version number consistent with the rollback version number from the Git local warehouse.

Understandably, the Git local repository stores version numbers of all item versions and version files associated with version numbers, the version numbers including the initial version number and at least one of the updated version numbers, the version files including the initial version file and at least one of the updated version files, the version numbers being associated one-to-one with the version files, i.e. the initial version numbers being associated with the initial version files, the updated version numbers being associated with the updated version files.

And S150, pushing the version file associated with the version number consistent with the rollback version number to the Git central warehouse.

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

And S160, transmitting a version rollback instruction containing the rollback version number to all third target servers matched with the third IP addresses in the third IP address set.

It may be appreciated that the third target server is a target server consistent with the third IP address, the third IP address is an element in the third IP address set, the version rollback instruction is sent to all the third target servers, the version rollback instruction is an instruction for issuing a rollback to a historical project version to the second target server that has been issued, the version initiation instruction may be set according to a requirement, for example, a version rollback instruction is generated according to a rollback instruction template provided by a Docker container management tool, the version initiation 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 a third pulling instruction which is fed back by the third target server aiming at the version rollback instruction and contains the rollback version number, transmitting a difference file corresponding to the third target server through the Git central warehouse according to a third transmission mode; and the third transmission mode is to determine a difference file corresponding to the third target server according to the local Git file associated with the rollback version number in the third pull instruction, and transmit the difference file corresponding 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 in the third target server, and the third target server feeds back the third pull instruction, where the third transmission mode is that according to a local Git file associated with the rollback version number in the third pull instruction, the local Git file associated with the rollback version number is a file stored in the third target server and recorded in a Git folder directory format that embodies an association relationship between folders, determines a difference file corresponding to the third target server, and transmits the difference file corresponding to the third target server, that is, if the third target server detects that the third target server does not include any local Git file associated with the rollback version number, then feeds back a third pull instruction without a local Git file associated with the rollback version number, and according to the third pull instruction, determines that the third target server has a corresponding version number to the third target server, and then determines that the version number is consistent with the target version number and the target server; and if the third target server detects that the local Git file associated with the rollback version number is contained locally, namely, the local Git file associated with the rollback version number is determined through the matching degree of the branch version number, a third pulling instruction containing the local Git file is fed back, the received local Git file associated with the rollback version number is compared with the acquired version file, and a difference file obtained after the local Git file associated with the rollback version number is compared with the acquired version file is acquired, so that the difference file corresponding to the third target server is determined.

And S180, rolling back the version file to the third target server through a non-interactive dialogue mode with the third target server according to the rollback deployment command file.

The rollback deployment command file is a set of rollback instruction commands corresponding to rollback process commands fed back by the third target server in the rollback deployment process in all execution rollback deployment processes, the non-interactive dialogue mode is to execute the command commands without manually interacting with the target server, the corresponding command commands are directly and automatically executed according to a one-to-one correspondence, and the version file associated with the version number consistent with the rollback version number is installed to the third target server in the non-interactive dialogue mode, so that manual configuration at the third target server is not required, and automatic installation of the version file associated with the version number consistent with the rollback version number is realized.

And S190, after receiving all rollback success instructions sent by the third target server which has fed back the third pull instruction, determining that the rollback release file package is successfully released.

Understandably, after the third target server that has fed back the third pull instruction installs the version file associated with the version number consistent with the rollback version number, the rollback success instruction is triggered, and after the rollback success instructions fed back by all the third target servers that have fed back the third pull instruction are received, the rollback issue file package issue success is confirmed.

Therefore, the invention realizes that the version files associated with the rollback version numbers are inquired and acquired from the Git local warehouse by acquiring the rollback version numbers, the version files associated with the rollback version numbers are issued by the Git distributed control system through a third transmission mode, and the automatic rollback of the version files transmitted to a plurality of target servers is completed through a non-interactive dialogue mode according to rollback deployment files, so that the environment corresponding to the rollback version numbers is automatically configured for the target servers, and the operation cost is reduced by rapidly rollback to a historical version under the condition that the release of the project version is abnormal.

In an embodiment, a Git-based project version publishing device is provided, where the Git-based project version publishing device corresponds to the Git-based project version publishing method in the above embodiment one by one. As shown in fig. 8, the Git-based project version issuing apparatus includes a receiving module 11, a storing module 12, a transmitting module 13, a transmitting module 14, an installing module 15, and a determining module 16. The functional modules are described in detail 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 comprises an initial version number, an initial version file and an initial deployment job file which are mutually related; the initial version file comprises an initial code file and an initial configuration file; the initial deployment job file comprises a first IP address set and an initial deployment command file;

the storage module 12 is configured to store the initial version file to a Git local repository, and push the initial version file to a Git central repository;

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

the transmission module 14 is configured to, after receiving a first pull instruction including the initial version number fed back by the first target server for the version initial instruction, transmit, to the first target server, the initial version file associated with the initial version number included in the first pull instruction according to a first transmission manner through the Git central repository; the first transmission mode 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 installation module 15 is configured to install the initial version file to the first target server through a non-interactive dialogue manner with the first target server according to the initial deployment command file;

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

In one embodiment, as shown in fig. 9, the determining module 16 includes:

a receiving unit 61, configured to receive an update issue instruction of a project version, and obtain an update issue file package; the update release file package comprises an update version number, a branch version file and an update deployment file which are mutually related; the branch version file comprises an update code file and an update configuration file; the update deployment file comprises a second IP address set and an update deployment command file;

a storage unit 62, configured to store the branch version file to the Git local repository, and push the branch version file to the Git central repository;

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

The transmission unit 64 is configured to, after receiving a second pull instruction including the branch version number fed back by the second target server for the version update instruction, transmit, to the second target server, a difference file corresponding to the second target server through the Git central repository according to a second transmission manner; the second transmission mode is to determine a difference file corresponding to the second target server according to the local Git file associated with the branch version number in the second pull instruction, and transmit the difference file corresponding to the second target server;

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

and the determining unit 66 is configured to determine that the update issue file package issues successfully after receiving all 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 used for receiving the rollback issuing instruction of the project version and acquiring a rollback issuing file packet; the rollback release file package comprises a rollback version number and a rollback deployment job file; the rollback deployment job file comprises a third IP address set and a rollback deployment command file;

A query subunit, configured to query and obtain a version file associated with a version number consistent with the rollback version number from the Git local repository;

a pushing subunit, configured to push a version file associated with a version number consistent with the rollback version number to the Git central repository;

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

the first transmission subunit is configured to transmit, to the third target server, a difference file corresponding to the third target server according to a third transmission manner through the Git central repository after receiving a third pull instruction including the rollback version number, which is fed back by the third target server for the version rollback instruction; the third transmission mode is that a difference file corresponding to the third target server is determined according to the local Git file associated with the rollback version number in the third pull instruction, and the difference file corresponding to the third target server is transmitted to the third target server;

the rollback subunit is used for rollback the version file to the third target server in a non-interactive dialogue mode with the third target server according to the rollback deployment command file;

And the determining subunit is used for determining that the rollback issuing file package is successfully issued after receiving rollback success instructions sent by all the third target servers which have fed back the third pull instructions. In one embodiment, the transmission module 14 includes:

the transmission unit is used for transmitting the initial version file to the first target server through the Git central warehouse;

and the feedback unit is used for receiving a creation success instruction fed back after the first target server creates the local Git file associated with the initial version number.

In one embodiment, the transmission unit 64 includes:

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

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

and the second transmission subunit is used for transmitting the difference file corresponding to the second target server through the Git central warehouse, and receiving an update success instruction fed back after the second target server updates the local Git file associated with the initial version number.

In one embodiment, the updating unit 65 includes:

the third receiving subunit is used for receiving a transmission completion instruction sent by the second target server after the second target server receives the completion of the branch version file, and sending a stop instruction and a deployment instruction in the update deployment command file to the second target server;

the execution updating subunit is used for searching a repairing instruction matched with the abnormal instruction from the updating deployment command file when the abnormal instruction fed back by the second target server in the process of executing the stopping instruction and the deployment instruction is received, and sending the repairing instruction to the second target server to complete the updating process until a completion instruction fed back by the second target server is received;

and the completion updating subunit is used for sending a starting instruction in the update deployment command file to the second target server when receiving a completion instruction fed back after the second target server completes all the deployment instructions, and confirming that the branch version file is updated to the second target server.

For specific limitations regarding the Git-based project version issuing apparatus, reference may be made to the above description of the Git-based project version issuing method, and no further description is given here. The respective modules in the above-described Git-based project version issuing apparatus may be implemented in whole or in part by software, hardware, and combinations thereof. The above modules may be embedded in hardware or may be independent of a processor in the computer device, or may be stored in software in a memory in the computer device, so that the processor may call and execute operations corresponding to the above modules.

In one embodiment, a computer device is provided, which may be a server, and the internal structure of which may be as shown in fig. 10. The computer device includes a processor, a memory, a network interface, and a database connected by a system bus. Wherein the processor of the computer device is configured to provide computing 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, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface of the computer device is used for communicating with an external terminal through a network connection. The computer program, when executed by a processor, implements 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 on the memory and executable on the processor, where the processor implements the Git-based project version issue method in the above embodiments when executing the computer program.

In one embodiment, a computer readable storage medium is provided, on which a computer program is stored, which when executed by a processor implements the Git-based project version issue method in the above embodiment.

Those skilled in the art will appreciate that implementing all or part of the above described methods may be accomplished by way of a computer program stored on a non-transitory computer readable storage medium, which when executed, may comprise the steps of the embodiments of the methods described above. Any reference to memory, storage, database, or other medium used in embodiments provided herein may include non-volatile and/or volatile memory. The nonvolatile memory can include Read Only Memory (ROM), programmable ROM (PROM), electrically Programmable ROM (EPROM), electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double Data Rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous Link DRAM (SLDRAM), memory bus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), among others.

It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-described division of the functional units and modules is illustrated, and in practical application, the above-described functional distribution may be performed by different functional units and modules according to needs, i.e. the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-described functions.

The above embodiments are only for illustrating the technical solution of the present invention, and not for limiting the same; although the invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present invention, and are intended to be included in the scope of the present invention.

Claims

1. The item version release method based on Git is characterized by comprising the following steps:

after a first pulling instruction which is fed back by the first target server aiming at the version initial instruction and contains the initial version number is received, transmitting the initial version file associated with the initial version number contained in the first pulling instruction to the first target server through the Git central warehouse according to a first transmission mode; the first transmission mode 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;

2. The Git-based project version issuing method according to claim 1, wherein after the determining that the creation issue file package issue is successful, comprising:

receiving a project version update issue instruction, and acquiring an update issue file packet; the update release file package comprises an update version number, a branch version file and an update deployment file which are mutually related; the branch version file comprises an update code file and an update configuration file; the update deployment file comprises a second IP address set and an update deployment command file;

storing the branch version file to the Git local warehouse, and pushing the branch version file to the Git central warehouse;

transmitting a version update instruction containing the branch version number to all second target servers matched with second IP addresses in the second IP address set;

after receiving a second pulling instruction containing the branch version number fed back by the second target server aiming at the version updating instruction, transmitting a difference file corresponding to the second target server through the Git central warehouse according to a second transmission mode; the second transmission mode is to determine a difference file corresponding to the second target server according to the local Git file associated with the branch version number in the second pull instruction, and transmit the difference file corresponding to the second target server;

Updating the received branch version file to the second target server in a non-interactive dialogue mode with the second target server according to the update deployment command file;

and after receiving all the update success instructions sent by the second target server which feeds back the second pull instruction, determining that the update release file package is successfully released.

3. The Git-based project version issuing method according to claim 2, wherein after the determining that the update issue file package issue is successful, comprising:

receiving a rollback issuing instruction of a project version, and acquiring a rollback issuing file packet; the rollback release file package comprises a rollback version number and a rollback deployment job file; the rollback deployment job file comprises a third IP address set and a rollback deployment command file;

querying and acquiring a version file associated with the version number consistent with the rollback version number from the Git local warehouse;

pushing a version file associated with the version number consistent with the rollback version number to the Git central repository;

transmitting a version rollback instruction containing the rollback version number to all third target servers matched with a third IP address in the third IP address set;

After receiving a third pull instruction which is fed back by the third target server aiming at the version rollback instruction and contains the rollback version number, transmitting a difference file corresponding to the third target server through the Git central warehouse according to a third transmission mode; the third transmission mode is that a difference file corresponding to the third target server is determined according to the local Git file associated with the rollback version number in the third pull instruction, and the difference file corresponding to the third target server is transmitted to the third target server;

according to the rollback deployment command file, the version file is rolled back to the third target server through a non-interactive dialogue mode with the third target server;

and after receiving all rollback success instructions sent by the third target server which feeds back the third pull instruction, determining that the rollback release file package is successfully released.

4. The Git-based project version issuing method according to claim 1, wherein the transmitting, by the Git central repository, the initial version file associated with the initial version number included in the first pull instruction to the first target server in a first transmission manner includes:

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

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

5. The method for publishing a Git-based project version according to claim 2, wherein after receiving the second pull instruction including the branch version number fed back by the second target server, transmitting, to the second target server, the difference file corresponding to the second target server through the Git central repository according to the second transmission mode, includes:

the second target server receives the second pulling instruction sent after determining a local Git file related to the branch version according to the branch version number;

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

and after the difference file corresponding to the second target server is transmitted to the second target server through the Git central warehouse, receiving an updating success instruction fed back after the second target server updates the local Git file associated with the initial version number.

6. The Git-based project version issuing method according to claim 2, wherein updating the received branched version file with the second target server according to the update deployment command file through a non-interactive dialogue manner comprises:

receiving a transmission completion instruction sent by the second target server after the branch version file is received, and sending a stop instruction and a deployment instruction in the update deployment command file to the second target server;

searching a repair instruction matched with the abnormal instruction from the update deployment command file when an abnormal instruction fed back by the second target server in the process of executing the stop instruction and the deployment instruction is received, and sending the repair instruction to the second target server to complete the update process until a completion instruction fed back by the second target server is received;

and when receiving a completion instruction fed back after the second target server completes all the deployment instructions, sending a starting instruction in the update deployment command file to the second target server, and confirming that the branch version file is updated to the second target server.

7. A Git-based project version issuing apparatus, comprising:

the transmission module is used for transmitting the initial version file associated with the initial version number contained in the first pull instruction to the first target server according to a first transmission mode through the Git central warehouse after receiving a first pull instruction containing the initial version number fed back by the first target server aiming at the version initial instruction; the first transmission mode 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;

8. The Git-based project version issuing apparatus according to claim 7, comprising:

the receiving unit is used for receiving the project version update issue command and acquiring an update issue file packet; the update release file package comprises an update version number, a branch version file and an update deployment file which are mutually related; the branch version file comprises an update code file and an update configuration file; the update deployment file comprises a second IP address set and an update deployment command file;

the storage unit is used for storing the branch version file to the Git local warehouse and pushing 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 with second IP addresses in the second IP address set;

The transmission unit is used for transmitting a difference file corresponding to the second target server according to a second transmission mode through the Git central warehouse after receiving a second pulling instruction which is fed back by the second target server aiming at the version updating instruction and contains the branch version number; the second transmission mode is to determine a difference file corresponding to the second target server according to the local Git file associated with the branch version number in the second pull instruction, and transmit the difference file corresponding to the second target server;

the updating unit is used for updating the received branch version file to the second target server in a non-interactive dialogue mode with the second target server according to the update deployment command file;

and the determining unit is used for determining that the update release file package is successfully released after receiving update success instructions sent by the second target server which feeds back the second pull instruction.

9. A computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor implements the Git-based project version issuing method of any one of claims 1 to 6 when executing the computer program.

10. A computer readable storage medium storing a computer program, wherein the computer program when executed by a processor implements the Git-based project version issue method as claimed in any one of claims 1 to 6.