A summary of the first time you worked as a project publisher

In the past to do the money when the shopkeeper wanted to do project publishers, because this work can help you to the actual operation of the project to touch more clearly, but then gave up, mainly feel that they are more coarse, not too suitable to do this high-risk work. But this charge center project let me have no retreat, only oneself can top up.

Billing Center is a new project, the release environment and production environment are 0, the difficulty lies in the need to build the infrastructure from the beginning. The project was built with Maven instead of Ali-made Antx, so the project structure and build scripts were different from previous projects. But for me this project launches the novice, is precisely the more advantageous side, may let me not have any historical baggage, may completely follow own design, the release process has appeared the question to be able to handle it more easily. The following summary of the entire release process of precipitation.
Project Release flowchart

Functions and responsibilities of various environments: Build machine
There are three main features: 1 the code to be published in the SVN up environment and the deployment of the ear package with Maven. 2 Distribute the ear packets of each environment to the corresponding pre-sending machine. 3 control each pre-hair machine, such as restarting each of the pre-hair machine server.
So the build machine needs a script that can perform the above functions, and the script's operator panel looks like this:
Release and pre-sending machine
This project is a combination of the publisher and the pre-release machine, which also says the environment is responsible for the advance environment and the distribution of the project to the formal environment. Therefore, there are three main functions: 1. Pre-issued operating environment. 2 Distribute the ear packet to the corresponding official machine. 3 control all the official machines, such as restarting the servers of the official machines. The script's operator panel looks like this:

In fact, this script is very similar to the script on build, and the main difference is that the environment does not require the ability to construct an ear package, but it also assumes the responsibility of pre-validation and is therefore a deployable and operational environment. Official machine
A running environment for use by actual users. In addition to the control scripts for the server environment itself, no additional operational scripts are required and no other environment is required to control, so no special requirements do not need to operate directly in this environment.

Experience Summary: Use robust scripting instead of actual command operations
The scripts used in the release process are very simple, nothing but the need to use the command to assemble, but the effect is extraordinary, because the impact of these commands can not do much, but in the formal release process there is a certain degree of risk, and the release process is not smooth sailing, often need to repeat several times, and often fight overnight. The simple choice of operation is definitely more reliable and efficient than tapping the command. Therefore, be sure to turn predictable operations into executable scripts, even if they are simple. Gather the information you need in the release process for easy access
The release process requires a lot of information, such as login password, verify that the service is started, check the SQL of the production library, the domain name and IP of the environment, etc., must gather this information together, avoid the publishing process around to ensure that the test environment and formal environmental consistency
An important reason for this advance to 2 o'clock in the morning is that the interface calls between systems are not smooth, although the final specific reason is not clear, but it can be sure that the test environment and the formal environment inconsistencies caused in the test phase did not find this problem, increased the risk of formal release. Therefore, must strictly verify the environmental difference, especially the basic environment, this time is due to the Apche configuration and the difference between the engine room. Need to be familiar with the details of the underlying technology and project linkages
One of the major problems with this release is that the interface calls between systems are not smooth, but they have nothing to do with the development code of the project itself, which is caused by the underlying environment. Finally, through the GRASP and analysis of TCP/IP three times to shake hands to locate the problem is Apache keepalive parameters need to be changed to off, require technical details I will be more detailed, but can be seen to deal with the problem of the underlying technology and protocols have enough familiarity, or not start, Also exposes the problem is that the people who build the environment (that is, myself) do not have a clear understanding of the parameters of the underlying environment The release is a collaborative work, need to communicate with the relying party in advance.
Publishing is a work that needs to be done by a publisher, developer, Test, PD, SA, and DBA to ensure that the dependencies of each link are in place and not in position to find backup.

Overall, the first release was a success, but also exposed some problems, of course, these problems are their own need to improve the direction.