Deployment

After we write, test, and document your web applications, we still need to actually get them on to live production servers that operate on the network for your target audience (that is, the Internet or local intranet). Without careful planning and organization, this can be a process fraught with problems, bugs, and human error.

Test Servers

One of the first and most important things we can do to help reduce problems in deploying our web applications is to set up at least one (and perhaps even more) test deployment of our web application. These are environments that mimic our production server environment but do not interact live with the real customers or audience of the final application. They permit those developing and testing the web applications to make sure they truly work, before customers find out they do not, and they provide an opportunity to rehearse the process via which the application is deployed (see Figure 29-6).

Figure 29-6. Deploying our web applications.

One of the concerns with setting up a test deployment has to do with money. If our production environment is going to be an expensive system with a lot of servers, disk arrays, and network appliances, those paying the bills are likely to balk at paying for another full set of servers. It is not unreasonable to say, however, that if we are going to run 10 servers in our production environment, we will be fine in our testing environment with only a few, and they will not need to be as robust or expensive as our production servers.

In extreme cases, you do not even need to use new computers. Software that allows you to run operating systems virtually within your current workstation permits us to run test deployments right on your existing machines. Even such simple configurations will provide information about the ease of deploying your web applications and provide ample opportunity to practice the actual deployment.

Scripting and Automating the Process

The PHP scripts and code used for the test deployment (and the eventual production server deployment) should not come from individual development or testing machines. Instead, they should come from clean computers that contain the latest set of scripts, content, and other information as per the source tree. A clean computer is one that runs only the software needed to power the web application and is relatively free of other clutter. It has not had dozens of different database programs installed and uninstalled; numerous web servers installed, configured, moved, and deleted; or otherwise had a high potential for residual files and software that could adversely affect the successful operation of our web application.

The actual process of taking these files and scripts and putting them on a deployment server is something that you should automate as much as possible (via shell scripts or small programs) so that you reduce the chances of human error. When it's impossible to write these scripts, we should at least write down the exact set of steps required to create the production environment.

Consider having your deployment scripts do the following:

• Verify that the correct versions of your web server, PHP5, and your database server are installed and running.

• Create the directory tree in the correct location on your production server.

• Copy over all appropriate files into this location.

• Execute any scripts, in particular those that will set up your initial database structure or restore any dumped databases from which we will start the operation of your application.

• Copy, update, or otherwise configure php.ini so that it has the correct security and runtime settings for our web application.

• Do any other last-minute configuration, such as copying over any SSL certificates or making sure that the server is otherwise ready to run the application.

The more certain we are that the deployment of your web application was successful and is a predictable process, the easier it will be to eliminate potential problems related to deployment when things go wrong in your web applications.

Deploying to the Live Server

After successfully testing your web application on one or a number of test deployment systems, it's time to deploy the system to your live production servers. If you are installing and publishing the web application for the first time, you should not experience problems. If you have an existing version of the application that you want to upgrade to the new one, however, we must plan carefully. You can use a number of different strategies to handle this, including the following:

• Schedule some "downtime" for the system, during which people will not be able to connect while you install and upgrade to the new version. This is especially attractive for corporate intranet scenarios, where there are likely to not be as many users accessing the system at certain times of the day (although that can be untrue in companies spanning multiple countries).

• Set up a number of new machines to run the new version of the application and then quickly switch from the old ones to the new ones. This requires a bit of work to make sure that any last-minute data processed by the old servers then gets moved to the new, but this can be a way to upgrade with minimal interruption.

• You can optionally also start running both the old and new version of the web application together, and gradually remove those servers running the older version. This requires careful planning and an extremely thorough understanding of how the two systems will interact and share data. It can, however, be a way to test new features on some users while leaving others to use the more established ones.

Any way that you decide to upgrade to the new environment, keep in mind a couple of key items:

• Rehearse the process as much as possible, and have an exact script or plan of action for how the upgrade will proceed.

• Understand how to abort, and be prepared to do so (at any point); you can restore the old system to operational status in case of catastrophic failure.

If you do not do these two things, you are playing with fire when upgrading your system and guaranteeing yourself maximal aggravation at some point in the future when things go horribly, horribly wrong.