Work Essay--Development Environment with Layer-by-Layer Checks

Our company's program environment is divided into four types, local (L for short), develop (D for short), staging (S for short), production (P for short), which are a bit similar to git flow, but the definitions and names of each branch are different.

Except for L, which refers to the computer used by engineers for their own development, and has no fixed branch, the other three are one of the branches of the project and run on a machine in a cloud.

The best explanation is that P is the version used by website users. It is conceivable that it is required to be as stable as possible and maintain the user's personal data. Engineers do not have permission to view and modify data directly from the database.

When developing new functions, we will open a new branch from D. During the process, we will confirm the integrity of the function in L, and merge the program into the D branch after ensuring that there is no problem. At the same time, the machine running on D will also re-execute the program. Whether the environmental test function fully meets the requirements of the project plan, or whether it is a situation that has not been considered in the middle. In short, it is right to notify the engineer when something needs to be modified, and then the engineer opens a new branch from D again for development.

In addition, in the D environment, in order to facilitate development and find errors, engineers have the right to view and manually modify the contents of the database.

About once every two weeks, the main function development is completed, and after the preliminary acceptance of D is completed, D will be arranged to be merged into the S branch, and the acceptance will continue in S. After all, git is used, and there is no way to choose which changes to add and which not to be added when merging. Therefore, if there are unfinished functions that will be merged together, you need to add environmental judgment to this part of the program, such as "execute only if the environment is L or D" Such conditions avoid affecting existing completed functionality.

The authority control of the S environment is set to be similar to that of the P. In the S environment, engineers also do not have the authority to view and modify the data directly from the database. If it is really necessary, a data change order must be created according to a certain process, and it should be noted in it The reason for use and the syntax for reading and writing the database are kept on record and handed over to the person in charge.

Therefore, it is not easy to find errors when there is an error in the S environment. You can only check the error message from the log of the program operation, sort out the operation process that triggered the error, and then check the corresponding program logic.

After the acceptance of S is completed, S can be merged into P, which is officially launched. After going online, the test account will continue to be used for acceptance, but if there is an error at this time, it will really affect the user and cause the customer service to be overwhelmed.

Therefore, the problems found at this time will go through the emergency repair process. After L is developed and merged into D, after the error is determined to be solved, the modified content will be directly merged into P. Of course, other irrelevant programs should still follow D→S→ The normal process of P can only be launched after the gradual acceptance is completed.

After really starting to develop and maintain the service, you will understand how much effort is needed behind a stable operation of the web page, and you will be better able to understand a large number of bugs after a major update.

At the same time, for bugs that can be triggered by normal operation, I feel that the acceptance is loose and it is hot.