Testing, Deploying, and Updating a PHP Site

Question

Pretty soon, I will release my project on the site, and before it sees the light of day, I would like to prepare some kind of “update model”. I use Debian with Apache, PHP 5.3 and MySQL (the latter, it seems to me), is not installed as a single package, but rather separately.

I came up with my simple idea of ​​conducting this process, so please take a look at the weak points:

• Testing . I found somewhere that it is common practice to deploy a test version of the site on the beta.mysite.com subdomain. Tests will use the same database as the live site. After the first release, each new candidate for testing will be a separate branch (combined during deployment, it still knows nothing about branching).
• Deployment If everything works correctly in the beta stage, copy and overwrite the old version of the page.

Problems that I can notice right away:

• Testing will be great if the database stays the same. What to do if it does change?
• I would like the update to be as transparent as possible, without any maintenance modes or anything else, but I am afraid that copying files will lead to problems in this regard.

Is there anything else that could be the problem here, or maybe there is a better way to do this?

Answer 1

1. Testing

Usually you never test something in a production environment and, in particular, on a production base basis for three reasons:

• Performance: Testing can be CPU intensive and discard other precious resources of your servers. Since you do not want to reduce the productivity of the working environment during the tests, you should not use the production environment for this.

• Data protection: you do not want to change data in your production database during tests. This means that not only your tests can have a limited range (i.e. you will probably think twice before testing some error, which can destroy all data related to your actual users, which allows the error to be used later by the hacker), but you can accidentally change the data by executing unverified code in your production database.

• Security: if you are in the context of a company and have a team, you are likely to assign work related to tests to a dedicated tester. Giving this tester access to a production environment is not a good idea for security reasons.

1.1 Test environment

Test conditions should be as similar as possible to the production environment. For example, if you are testing an application that you send for Windows XP with the .NET Framework 3.5, you should not test it under Windows 7 with the .NET Framework 4, because everything will work during the tests and crash as soon as your clients start using Appendix.

^{Example: once I worked on an application using alternative NTFS data streams. Everything worked perfectly both during development and during tests, where no one thought that in 2009 FAT32 was still alive. Of course, once in production, a client installed the application on a FAT32 flash drive and crashed.}

Please note that this does not mean that you must use the same environment during development.

In the case of databases, everything is different. The mechanism and version of the database should be the same, and the scheme should be the same (the same tables, the same restrictions, etc.) , but in most cases the data should be different , the test database is filled with some random data that is not related with the data that you have in production.

1.2 Database: Testing Bottlenecks

For example, if a website was recently released, you do not have a lot of data. If the database has a list of registered users, you will only have a few users at the beginning. On the other hand, you will probably need to test not only if your application is running , but also if the actions are correct and what are the bottlenecks . In this case, you will need to test it with large amounts of data: in this way, you can have several thousand users in the working environment and billions of randomly created user accounts in the test environment.

1.3 Database: validation of output

Another case where you want your test data to be different from production data is to avoid pasting HTML and to verify that the output is correct. If you have an e-commerce site, you have a SQL Products table, and each product has a title that will be displayed on the website. In a test environment, you should have products with names such as:

 1. A very long name of a product goes here. Oh, this name is really huge! 2. javascript:alert('<a>&\é<%你好') 3. 4. '; delete * from Users 

These names ensure that:

• Long names are displayed correctly,
• Names are escaped correctly, Unicode is supported and the encoding is correct,
• Empty names don't break the layout,
• SQL injection is excluded, but without exiting during output (in case the header can be changed via the website).

If you start populating the production database with such things, your users will probably think your site is broken or hacked.

2. Deployment

It all depends on the actual number of requests per second.

2.1 Small sites

If your site is small and not used too often, you really should not care about the update workflow. Copying modified source files may take less than a second because these files are small. If this really bothers you, you can schedule files to be copied during the day when there are few visitors. For most small websites, updating the source code in the middle of the night should be great .

^{In addition, there is nothing wrong with displaying a message that between 4 AM and 5 AM the server can go offline. Working sometimes at night, I often see these messages, for example, on my banking website, where, for security reasons, they may need to be disconnected once a week during maintenance or other scheduled tasks.}

2.2 Server Farms

If your site is large and has thousands of requests per second, you probably have a server farm. In this case, the upgrade process should not be a problem, as the servers will be disconnected one by one, updated, and then returned to the farm .

Answer 2

Using the same database is risky, as you may accidentally delete, modify or otherwise enter erroneous information in the database, which then gets to your production site.

Answer 3

You are correct, copying files can take some time and can potentially break the site when copying. The best option would be to use rsync, so only modified files are copied, which would be faster.

Better yet, use symbolic links. Point the web server to a symbolic link pointing to the "production" directory. Do the same for the test / beta directory. When testing is complete, specify the production symlink in the test directory, which will now become your production directory.

You can name your production catalogs by date and / or version. If there is a problem, you can opt out of reassigning the symbolic link. Keep as many previous versions as possible. Replacement options will be almost instant.

Please note that there are still problems with the repetition of the symbolic link. The only way around this is to have multiple web servers in load balanced setup.