DeploymentAfter 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 ServersOne 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 ProcessThe 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:
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 ServerAfter 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:
Any way that you decide to upgrade to the new environment, keep in mind a couple of key items:
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. |