I used to be a project Publisher when I was working as a cash manager. This work can help you better understand the actual operation of the entire project, but I gave up later, I feel that I am rough and not suitable for this highly risky job. However, this billing center project does not let me back up, but I can only go top of it.
The billing Center is a new project with zero release and production environments. The difficulty lies in the need to build the infrastructure from scratch. This project is built using Maven instead of Alibaba's self-developed antx. Therefore, the project structure and build script are not the same as those of previous projects. However, for new users who are new to this project, it is just a more favorable aspect. This will free me from any historical burdens and allow me to fully follow my own design, when problems occur during the release process, you can handle them more easily. The following summarizes the precipitation during the entire release process.
Project release Flowchart
Functions and responsibilities of various environments:
- Build Machine
There are three main functions: 1) SVN up environments need to be releasedCodeAnd use Maven to build a deployable ear package. 2) Distribute the ear packages in various environments to the corresponding prerelease. 3) control the prerelease servers, such as restarting the servers of the prerelease servers.
Therefore, the build machine needs a script that can complete the above functions. The script operation panel is as follows:
- Release and prerelease
This project combines the launch server and the prerelease server. It also means that this environment is responsible for the pre-release environment and delivery project to the formal environment. Therefore, there are three main functions: 1) pre-release running environment. 2) Distribute the ear package to the corresponding official machine. 3) control various formal machines, such as restarting the servers of each formal machine. The Operation Panel of the script is as follows:
In fact, this script is similar to the script function on the build machine. The main difference is that this environment does not need to build the ear Package function, and it is also responsible for pre-release verification, therefore, it is a deployable and running environment.
- Official Server
The runtime environment for actual users. In addition to the control scripts of the server environment, no additional operation scripts are required, and no other environments are required. Therefore, you do not need to perform operations directly in this environment without special requirements.
Experience summary:
- Use a robust script to replace the actual command operations
The scripts used in the release process are very simple. They are nothing more than a collection of the commands that need to be used, but the effects are extraordinary, because hitting these commands does not cost much, however, there are still some risks in the formal release process, and the release process is not smooth sailing. We often need to repeat multiple releases and often fight all night. Simple selection operations are definitely more stable and efficient than hitting commands. Therefore, you must transform the foreseeable operations into executable scripts, even simple operations.
- Integrate the information required during the release process for easy access
The publishing process requires a lot of information, such as logon passwords, commands for verifying whether the service is started, SQL queries for production databases, domain names and IP addresses of various environments, etc, this information must be aggregated to avoid searching around during the release process.
- Ensure consistency between the test environment and the formal environment
An important reason for this pre-release to AM is that the inter-system interface call is not smooth, although the specific reason is unclear, however, it must be because the test environment and the formal environment are inconsistent, so that this problem is not found during the test stage, which increases the risk of formal release. Therefore, we must strictly check the environmental differences, especially the basic environment. This is because of the differences between Apche configuration and cross-data center.
- Be familiar with the details of underlying technologies and project associations
One of the major problems encountered in this release is that inter-system interface calling is not smooth, but it has nothing to do with the development code of the project itself, which is caused by the underlying environment. Finally, we can identify the problem by capturing packets and analyzing the three-way handshake of TCP/IP. The keepalive parameter of Apache needs to be changed to off. I will discuss the problem in detail after technical details, however, it can be seen that the person who handles the problem must be familiar with the underlying technologies and protocols. Otherwise, the person who builds the environment (myself) may not be able to start or expose the problem) no clear understanding of parameters in the underlying Environment
- Publishing is a cooperative effort and requires prior communication with the dependent party.
Publishing is a task that requires the cooperation of publishers, developers, testers, PD, SA, and DBA. Make sure that the dependencies in all stages are in place and backup is not in place.
In general, the first release is still successful, but some problems are also exposed. Of course, these problems are also the direction for improvement.
