My first Python Web development Framework (19)--product release related matters

Finally small white will system development completed, for the release to the server side and no experience, so after work and find old dishes.

　　Small white: boss, sorry to trouble you again, the project has been finished, but to release the line I also confused, have time to help me explain it?

　　Old dishes: Well, the system is not a simple thing to go online, it can be large and small. If the preparation is not sufficient, there may be many problems arise. How do you think the code should be published after it is written?

　　Small white: Well, after the completion of development, upload to the server, and then the browser can be normal access ...

　　Old dishes: It seems to be popular on-line knowledge.

Regular product on-line can be carried out according to the following several steps:

1. Developer Self-Test (development environment)

2. Test personnel test (test environment)

3. Pre-production environment testing

4. Production Environment Testing

But according to the many companies I have come across, the majority of companies without testers, bosses and even technical leaders of each company have no sense of testing, and it is unclear what the consequences will be if the product tests are given to developers or business people. On the small side of the user experience is not good, to a large extent may be updated to cause data loss, production environment downtime for a period of time.

For the developer self-test, many programmers do not have this habit, most of them are writing code, they believe that there is no problem, and then throw it to the server, and other colleagues or customers to test, many times there will be 500 or a variety of bugs, asked all because of carelessness, not noticed or accidentally caused by , and sometimes the feedback has been good for a long time, the system hangs for how long do not know. Before the company has experienced a small problem with a technical staff for a long time to develop, submitted to do not know how many times to the test environment is not passed, the bug repeatedly appeared, was the Test manager scolded poured situation, I looked at the side almost can not help godless on a copy. It can be seen that no self-test is one of the important reasons for the contradiction between testing and development.

Of course, including me, has not developed the habit of self-test, no testing personnel constraints, write good code on the production environment to throw, failure in the production environment to increase the measurement or restore code, and then slowly change the situation. Used to think that there is no test is irrelevant, in recent years has been in the Test team in the company is not the same, with the constraints, although the update efficiency and speed of the big discount, but the code quality and stability has been a leap in the promotion. Usually code codes will be used to run after a variety of parameters, and the use of test thinking to write code, code security, rigor has been greatly improved.

Self-test It is an attitude, it is also a habit.

Generally have a test position of the company, will create a set of test environment specifically for testing personnel to test, because the test and development of a common environment, the data will often cause confusion, one of the hard-built data, the other side to use, or the technician used to directly open the database to change data, Some data states suddenly change, and testers think they are bugs, causing unnecessary distress. In general, developers do not have a problem with their self-test in the development environment until they submit the code package to the tester for updates to the test environment. This update frequency is usually fixed time, not very frequent, unless there are major bug testers can not continue, because each version of the update, the tester will start from beginning to end, according to the written test cases all rerun, frequent updates will cause the tester workload is very large. Professional testing is a boring, repetitive, very patient and dedicated position, but also I admire a position.

Many companies after the product development is directly on-line, and there is no pre-production environment for testing, a lot of major security incidents are caused by this. For example, do not pay attention to the SQL statement, accidentally the production environment of the data sheet to empty, such as the update of the production environment, such as a direct crash in the work occurs. This year I was in the company also tried to take place a more serious problem, the cooperation of the company's small partners in the development of the code loop is wrong, not after comprehensive testing directly released, the app issued by the production environment of our business interface traffic burst, just a few days of traffic soared to 60 million, server flow, CPU, Memory and other full-load operation, affecting the normal operation of other cooperative companies, because the production environment can not be stopped, the server can only through the rapid expansion of the server group for high-availability groups to resolve, the client by rapid release of the new version replacement.

If the server is not too much affected, usually the pre-production environment and production environment in a server, it is just a copy of the database and program. When conditions are sufficient, an environment that is exactly the same as the production environment will be built locally to perform pre-release testing. Pre-production environment testing can help us avoid a number of server environmental factors (such as configuration or packet inconsistency), database structure or configuration factors (database structure adjustment is not updated or log parameters after the change is not synchronized, etc.) and the SQL statement defects caused by serious errors.

Pre-production environment testing is a strict update step requirement for major releases or change updates. During the entire pre-release test process, the actions of each step must be recorded in real time. For significant updates, the following steps may sometimes require multiple iterations to ensure that updates to the production environment are completely correct.

1) test on the local test environment, ready to update the code package, database update script, server configuration update script and modify the description document;
2) empty pre-production test old database and program (for minor version updates can be done directly in the old environment, do not need to do this step, and if the database data volume is large, you can continue to use the old environment data);
3) Backup the code, database and related configuration files in pre-production test environment;
4) Obtain the code, database and related configuration files in the production environment, and update them to the pre-production test environment, and set up to run properly ;
5) Start Publishing, new server configuration file;
6) Update the database script;
7) Update the code package;
8) Run the front and back end of the program, complete testing (all functions must run once), check whether the program can run properly;
9) If the update does not cause disruptive changes to the original system, the program can be deployed to the production environment on a pre-release basis.
10) If you need to input or change the relevant configuration data, you can let the relevant maintenance personnel login operation input or modify the content, and test pass;
11) Export the data script of the maintenance personnel input;
12) Re-restore the production environment code, database and related configuration files to the pre-production test environment;
13) Perform steps 5th through 7th, and update the data script exported in step 11th to the database;
14) Perform the 8th step operation to confirm that no problem has been posted to the production environment.

Normally, the code that is updated to the production environment is tested without problems, but it is possible that some features can only be tested in a production environment, so the general release will be a late night, and there is no customer to use. After the update, you need to test quickly to ensure that the system runs normally after the launch.

Common updates are hot updates, that is, uploading updates directly, or using automated tools such as SVN to synchronize updates, and when the update is complete, the SVN hooks automatically synchronizes the code to the other servers and restarts the referred services; you can also turn off the highly available one of the externally accessed nodes to update the test. And so the internal test of this node is not a problem, and then automatically synchronized to the other nodes, if it is a microservices architecture, you can also use the micro-service automatically install the release, automatically synchronize the registration of updated features ... Different businesses, service architectures are different, and the steps and methods of updating are not the same.

The front content sounds a bit complicated, a bit more, but for you this small site, you don't have to do that. The first thing you need to do is to buy a good domain name, do well the domain name filing related work; then purchase a cloud server, configure the server according to the tutorial installed in my blog, and finally publish your code to the server.

You follow the link below to build, your program generally run no problem, the following configuration is BATE version of the server environment set up, is my research operation and configuration of the server to write their own learning after the configuration of the normal access will not be too big problem. If you want to deal with high concurrency, you need to tune on this basis, and uwsgi better to use the XML configuration, because the XML and INI used by the package is not the same, the runtime efficiency and stability is quite different, our server processing more than 700 per second concurrency is the use of XML configuration.

Python Server environment Build (1)--Local server preparation

Python Server Environment Build (2)--Install related software

Python Server Environment Construction (3)--parameter configuration

Copyright NOTICE: This article was originally published in the blog Park, the author for Allempty This article welcome reprint, but without the author's consent must retain this paragraph statement, and in the article page obvious location to the original link, otherwise considered infringement.

Python Development QQ Group: 669058475 Author Blog: http://www.cnblogs.com/EmptyFS/

My first Python Web development Framework (19)--product release related matters