Software deployment involves all of the activities that make a software system available for use on a particular environment.
There are different ways to deploy software, such as using an FTP client or using SSH and rsync.
With eZ Publish, the suggested activities to deploy a website are:
Each of the above steps are covered in the following sections.
We have to download and install the extension called eZ Deploy. We will use this extension to synchronize the different environments with the latest code that we created. To download the extension, we have to check out the code from the public repository, by using a subversion client.
Usually, Subversion is installed by default in all of the modern Linux distributions, but you can also download it from http://subversion.tigris.org/.
cd /var/www/packtmediaproject/
svn export http://svn.projects.ez.no/ezsync/trunk extension/ezsync
Here, we have to enable the extension from the global site.ini
file located in the settings
folder:
vi settings/override/site.ini.append.php
Add the following lines:
[ExtensionSettings]
ActiveExtensions[]=packtmedia
...
ActiveExtensions[]=ezsync
Note that eZ Deploy should work in order to install it in the production and staging environment of both the SSH and rsync servers. Later in this chapter, we will see how to configure the extension in order to make it work.
This step isn't mandatory. However, to be certain that the site will run without any glitches on the staging server, we should perform some assurance tests by using software such as Selenium IDE, and then run them automatically by using Selenium RC and PHPUnit.
One of the best software applications for fulfilling this task is Selenium (http://seleniumhq.org). This is a quality assurance suite based on a remote control written in Java, and on an IDE that can manage different browsers on different machines.
As we can see here, the IDE is a Firefox plugin that allows us to record a navigation session and export it in different formats so that it is reproduced automatically by a test framework such as PHPUnit (http://www.phpunit.de).
The PHPUnit will then use the Selenium RC (Selenium Remote Control) to run the tests and create a complete report about them.
In the official PHPUnit documentation, you can read how to integrate and use it with Selenium, at http://www.phpunit.de/manual/3.4/en/selenium.html.
The Selenium IDE (Integrated Development Environment) is a tool that you can use to develop your Selenium test cases. It's a Firefox plugin and is generally the most efficient way to develop test cases.
It also allows us to save all of our tests in a useful test suite, or to export it in the PHPUnit test format.
To install it, we have to download it, using the Firefox browser, from http://seleniumhq.org/download/.
Now, as we can see in this screenshot, Firefox will ask us to install the new component and then restart it in order to use the new extension.
We can now use the Selenium IDE to record our first test session. We will see how to create a simple test, but you can play with the IDE to make the best use of all of its features.
Open your browser , and navigate to the site URL (in our case, http://packtmediaproject
). In the Tools menu of Firefox, select the Selenium IDE option, as shown here:
The IDE will then open, and we can start recording our session by clicking on the record button (in red) located on the rightmost side of the IDE window, as seen here:
Now every time we use the browser Selenium, we will record our actions to create a test. For example, we will test the Forum to see if it works correctly.
Click on the Forum link in the navigation menu of the site, and take a look at the IDE to see what it has registered:
As you can see in the previous screenshot, Selenium recorded an open action for the index and a click on the link. The clickAndWait command means that the IDE will wait for a complete render of the page from the browser before testing its content.
Browsing a site with Selenium should be sufficient in most cases, but sometimes you also need to check for the page contents. Starting from the previous test, we will extend it to check to see if the page contains the forum we created.
Now, stop the recording and choose the assertText command in the Command select box of the IDE. This will be used to confirm the existence of a string in the XPath position. Now, in the Target input area, we have to specify the XPath path where we want to check the text filled, in the Value field.
XPath is used to navigate through elements and attributes in an XML document. XPath is a major element in the W3Cs XSLT standard, and XQuery and XPointer are both built on XPath expressions. You can learn how to use XPath from the W3School tutorials site at http://www.w3schools.com/XPath/.
As you can see in our example screenshot, we have to check that the forum name is Tech and gadgets.
Save your test from the File menu and play it using the Play current test case button, to check if everything is fine, as shown in the following screenshot:
We suggest that you create as many tests like this as possible to cover all of the pages of the site, which would assure good quality assurance coverage.
To create useful tests, read the Selenium IDE documentation and tutorial at http://seleniumhq.org/docs/03_selenium_ide.html#building-test-cases.
As we saw in Chapter 2, when we created the siteaccess, we had to create different siteaccesses for different environments. So far, we used only the development siteaccess. But now we have to configure the staging and production siteaccesses.
To do that, we have to be sure that all of the cache settings we discussed in the previous chapter are enabled, and that the databases and other settings (site URL, regional settings, and so on) are configured accordingly, for the staging or production servers.
We can check everything from the site.ini.append.php
file which can be found in the settings/siteaccess/staging
and settings/siteaccess/staging_panel
directories of the eZ Publish installation.
Moreover, in the same site.ini.append.php
file, we have to disable debugging in both environments by changing the Debug
value from enabled
to disabled
.
[DebugSettings]
Debug=disabled
After we create the test and check the siteaccesses configuration, we can start with the real deploy process.
First, we have to copy the development database to the staging server. To do this, we have to create a dump file of the development database and then restore it onto the staging server.
If you didn't change the username and the password of the MySQL user, you make this copy by using the following commands:
cd ~
mysqldump packtmediaproject -upacktuser -ppacktpwd > packtmediadump.sql
After we copy the generated packmediadump.sql
to the new server, we have to execute the following shell command to restore the dump:
mysqlimport packtmediaproject -upacktuser -ppacktpwd /path/to/packtmediadump.sql
If you change the name of the database, the username, or the password of the database user in the previous step, then you need to use the correct ones.
To copy the development files to the staging server, we will use the eZ Deploy extension. This extension was specifically created for this kind of tasks, and uses the rSync protocol to send and synchronize the code from one server to another. The extension will send the files incrementally, so that only the changed files will be sent from one deployment to another.
We have to configure the extension so that it works with the servers where we want to deploy the files. To do this, we have to edit the sync.ini.append.php
file located in the settings
directory of the extension.
cd /var/www/packtmediaproject/extension/ezsync
vi settings/sync.ini.append.php
Let's suppose that we have the staging server in a subdomain of the packtmediamagazine.com
domain, and then add the following lines:
[DefaultSyncSettings]
Host=
Dir=
User=
Port=22
Parameters=
FileRsyncEclude=extension/ezsync/settings/rsync_exclude.txt
[StagingSyncSettings]
Dir=/var/www/staging
Host=staging.packtmediamagazine.com
User=packtmedia
[ProductionSyncSettings]
Dir=/var/www/production
Host=www.packtmediamagazine.com
User=packtmedia
As you can see, the StagingSyncSettings
section is used to configure the staging server, whereas the ProductionSyncSettings
section is used for the production server. If you want to create other environments, you should easily create new deployment configurations by adding new sections.
The Dir
parameter specifies the remote directory where rSync will place the files, the Host
is the remote server to contact, and the User
is the SSH user that will have write permission on the Dir
directory.
We should also exclude files from the synchronization directories, or files that are used only in the development process, or that are generated by the CMF cache system. To do so, we have to edit the file named rsync_exclude.txt
, which can be found inside the extension settings
directory.
cd /var/www/packtmediaproject/extension/ezsync
vi settings/rsync_exclude.txt
We need to add the names of the files and directory that we want to exclude, by editing the rsync_exclude.txt
file and adding the following lines:
.svn var/* update doc
This will ensure that, on the staging or production server, we will not copy the subversion directories, the local cache, the update script, and all the documentation we created for internal development that is not suitable for publishing on the Web.
After configuring the extension, we have to move back to the root of the eZ Publish installation and execute the sync script in the dry-run mode:
cd /var/www/packtmediaproject/
php extension/ezsync/bin/php/sync.php --env=staging
The dry-run mode will not send anything, but it will show us which files will be sent during the real deployment. To execute this, we have to add the --go
parameter to the shell script:
php extension/ezsync/bin/php/sync.php --env=staging --go
Now the site has been deployed to the staging server.
After we have deployed the code, we need to check if we have configured the server and the CMF correctly. Luckily, eZ Publish will help us to do this, through its Check Validity functionality. To enable this feature (which will again run the configuration wizard that we saw in Chapter 1), we have to set the CheckValidity
parameter to true
in the SiteAccessSettings
section of the main site.ini
file:
cd /var/www/packtmediaproject/
vi settings/site.ini
Now, in the file add the following code:
[SiteAccessSettings] ... CheckValidity=true ...
Now, we can check to see if the staging installation is working correctly, by browsing the site itself and taking a look at the configuration wizard, which we used to configure eZ Publish in Chapter 1. To do that, we have to open the browser on the staging server URL and follow the configuration wizard instructions as shown here:
As we can see in the screenshot, if something goes wrong, the wizard will help us to fix the problem, step-by-step. After we have checked that everything works fine, we need to change the CheckValidity
parameter back to false
, and reload the site.
Now, we can run all of the acceptance tests that we created previously, to confirm that all of the functionality works fine. To automatically run the test, we should install the Selenium Remote Control on the staging server, instead of using the IDE.
The Selenium RC guide can be found on the Selenium project site at http://seleniumhq.org/projects/remote-control/.
After we check that everything works smoothly on the staging server, we can deploy the site to production. To synchronize to the production server, we will execute the following script:
php extension/ezsync/bin/php/sync.php env=production -go
After the synchronization, as we saw previously, check the validity, run the acceptance tests and that's all. Now it's time to publicize the site to our customers!
3.149.250.11