If you are using Deskpro On-Premise, it's a good idea to make a test copy of your installation to try out any big changes to configuration before you put them in production.
Why make a test environment?
Situations when may want to do this include:
1. Deploying a major update to Deskpro - for example, the May 2014 update which added a new admin interface. The vast majority of updates don't need testing, but in rare cases it may not be possible to make an update work without requiring some manual changes - for example, the new admin update affected how triggers worked. We will warn you in the News post about an update if we recommend testing.
2. Making a big change to your configuration - for example, you want to redesign all your triggers, edit your portal templates extensively, etc. It's useful to be able to test and refine your changes before putting them into production.
3. You want to change some aspect of your hosting environment - e.g. switching from IIS to Apache, updating PHP version, or separating MySQL and your webserver to run on different physical machines.
If you want to install a test helpdesk to a brand new database, then you can just follow the standard installation guide. The instructions below explain how to copy your existing helpdesk data into a new installation.
Steps to make a test environment using a copy of your database
1. Dump the Deskpro MySQL database, then reimport it with a new name (e.g. deskpro_duplicate). For full details of how to do this, see this MySQL documentation. Here's an example of the commands you would use:
$ mysql -uroot -pMYPASS
mysql> CREATE DATABASE deskpro_duplicate;
mysql> exit;
$ mysqldump -uroot -pMYPASS deskpro_original | mysql -uroot -pMYPASS deskpro_duplicate
2. Download a new copy of the Deskpro installation files from http://www.deskpro.com/downloads/deskpro.zip and extract the files to a new folder on the webserver.
3. Ensure that your webserver will serve files from the folder in step 2.
4. Complete the installation of Deskpro. You can use your existing licence code.
5. You probably don't want to read email from your real support accounts into the test installation, so either don't set up the cron job/Scheduled Task, or disable the ticket accounts in Admin > Tickets > Email Accounts. If cron/Scheduled Tasks aren't enabled the automatic upgrader won't work, but you can use the interactive command-line upgrader.
6. If you are reading email into your test installation, be sure to disable sending outgoing email:
Edit /config.php and find the section "OPTIONAL : Mail Debug" and enable the disable_send option by changing the value to true.
$DP_CONFIG['debug']['mail']['disable_send'] = true;
7. If you normally use URL redirections to auto-correct the URL (e.g., always use HTTPS links), then you should disable these. Edit /config.php and find the section "OPTIONAL : Disable URL corrections" and change the value to true.
$DP_CONFIG['disable_url_corrections'] = true;
Lisää kommentti
Please log in or register to submit a comment.