Who sings on Friday, will weep on Sunday.
—A proverb
It's time to deploy our site! In the previous chapter, we finished working on the site and now, in this chapter, we will understand the differences between the development, staging, and production environments. We will then deploy our development environment to a production server, by using the eZ Deploy extension. We will also use the Selenium IDE to create a functional test for quality assurance.
When we work on an enterprise application, it is always useful to work in three separate environments:
- Development environment
- Staging environment
- Production environment
Basically, an environment is a server configured for specific purposes (for example, to allow users to use a site or develop a new one).
You can also add more environments, such as Integration platform environment, where different teams would test if their code works fine together; usually, only these three are really needed.
This first environment is the one in which we will work. Usually, this environment has installed libraries useful for a development task, such as XDebug PHP module, but is totally useless, or even problematic, in a production server. For example, an enabled XDebug PHP module will slow down our production server, while adding overhead to every PHP execution. If you don't have a development server, this environment should be the computer where you create your whole application.
This environment is used to test the site, or the latest features, on a server that is basically a clone of the production one. The staging server is normally used to run all of the quality assurance and performance tests. For this reason, it's very important that both the staging and the production environments use the same libraries, and have the same configuration. This will ensure that when we deploy to the production server, everything will go according to our plans. Sometimes, to reduce the deployment costs for small sites, the staging server is the same as the production server. But in this case, performance tests have to be done on the development server to avoid slowing down the site.
The last environment is the production environment. In this environment, users will find the site reachable and usable. For this reason, it is very important that it has to be secured and that all of the development stuff, and any unused libraries have been removed.
Moreover, a single server is not always sufficient to host a popular site. Sometimes it is necessary to separate and clone the database and the HTTP servers on different machines, as shown in the following figure:
The production environment should be completely different from the staging or the development one. Basically, it should be a single machine or a virtual machine. As we can see in the previous figure, the production environment uses a load balancer to distribute the work across different HTTP servers and a single (or clustered) database server.
As we don't need to install eZ Publish again as we did in the first two chapters, we will now concentrate on the PHP configuration of our machine. As we said before, a production server should have only the libraries strictly necessary. We have to remove, or disable, the unused libraries from either the package manager of our distribution (yum for Red Hat based distributions or apt-get for Debian based distributions), or from the PHP.ini file.
As we saw in Chapter 1, our eZ Publish site requires only the default PHP libraries, plus the php5-GD and ImageMagik applications and libraries. Moreover, as we saw in the last chapter, to reach the best performance from the PHP interpreter, an opcode cache system such as APC should be installed. As we will see next, we will also need a Secure Shell Daemon (SSHD) and a rsync client, to enable the deploy process.
As this book does not cover the specific system administration tasks, we again suggest that you work with a Linux system administrator to optimize the production server.