Help Docs Server Administration Creating a Staging and Development Environment

Creating a Staging and Development Environment

Don't risk your hard work – create a staging server to test changes before implementing them on your live site. It's a safe way to optimize and update without compromising your site's functionality.

You and your developer spend a lot of time and money creating your site, optimizing your server, and making sure your viewers have access to the information on your site – why would you compromise your hard work by making changes to your live site without testing first? It makes sense that you would create a staging domain or server to make changes to your site, server configurations, run updates and test those changes before implementing them on your live site. The often tongue-in-cheek joke is that “everyone tests in production, right?” Sadly, that’s more true than false. 

So, how do you solve the problem of wanting to test without it affecting your live site? The answer is simple, you can:

A staging or development server is a copy of your server and the sites hosted on it that you can use to test and develop new code, configurations to optimize your server, update your site, and test applications before putting any of it on the live server. Once you’re done testing on your staging server and everything is working correctly, you can copy those changes and upload them to the live server. A staging or development domain is a copy of your live site, hosted on the same server, that you can use to test and develop code on your website before you make changes to the live site.

Which is better – a staging server or staging domain?

The answer to this question depends on a few things, let’s take a look at some of the most common answers: 

  • Large data sites or high number of sites – if you have a large number of sites or the sites on your server are particularly large and hold a lot of data, you are likely best served by creating a copy of your server and using that copy for staging and development.
  • Small, low data websites –  if you have just a few small sites on your server, and are only changing code for the sites, then a subdomain will work just fine.
  • Application development – if you run web applications on your server, you will need to copy the server to test additional functions on your applications.
  • Server optimization – you can optimize your server for the type of sites you are hosting on it to help handle high traffic loads, prevent malicious attacks, and help with caching issues. If you’ve done the work to optimize your server, making a copy to test your sites is the best option.

Creating a Staging/Development Server

The first step in creating a staging or development server is to clone the current server you are running your live site on. By creating a clone, you create a carbon copy of the server infrastructure and the sites you are running on it. It will have a separate IP and should have a different hostname to make sure the staging and development server isn’t being found and used by your site users. Let’s take a look at how to create a clone of your server. 

Warning:
A cloned server should never be created as a backup of your current server. Any changes made on the original server after the cloning process will not be transferred. For information on backups, please see our article Creating a Backup of Your Cloud VPS.

  1. Log into your my.liquidweb.com account with your username and password, or sign in with Google SSO.

  2. Click on Servers in the left menu.
  3. Click on the three dot menu to the right of the server’s name and select Clone Server.
  4. A pop-up will appear asking you to confirm the details of your clone.
  5. Confirm the request to clone the server and click Add to Cart to proceed.
  6. You are now presented with a view of the new server in the shopping cart. You can adjust details of the server as needed. When ready, click “Checkout” to confirm the purchase of the new server.
  7. The cloning process will begin. Keep track of the process in the Notifications section of your account home page.
Tip:
Now that your new staging and development server is created, you can start to test different configurations, code changes, and modifications. It is highly suggested that you keep a log of changes made to the server and sites to help troubleshoot any issues you may encounter during testing and when transferring the updates to your live server.

Creating a Staging/Development Domain

If you are looking to only test or run development on your sites, and the server configuration is not altered often, you can create a domain on your server to use for this purpose. This helps you make code changes and run updates to software without affecting your live site and you can view visual changes before making them live on your site.  

First, you’ll need to know the document roots you’ll be using. In this example, I have a source domain of samplesite.com and a target domain of staging.samplesite.com, where the source is your current live site and the target is the site you are going to create for staging and development.

Warning:
These instructions use the root user to create your staging domain. Make sure that before you make any changes, even cloning your site, take a backup of your current server and sites. Follow the instructions in our article Creating a Backup of Your Cloud VPS to find out how.

  1. From the command line, run the following command:
[root@host ~]# grep samplesite.com /etc/userdatadomains
samplesite.com: sampleuser==root==main==samplesite.com==/home/samplesite/public_html==192.0.2.0:80==192.0.2.0:443====0==ea-php56

[root@host ~]# grep staging.samplesite.com /etc/userdatadomains
staging.samplesite.com: staginguser==root==main==staging.samplesite.com==/home/staging.samplesite/public_html==192.0.2.0:80==192.0.2.0:443====0==

Tip:
Using grep shows the information for each account and the location of the document roots. If you already know the location of the document roots, you can skip this step. In our example above, it shows that for samlplesite.com, it’s /home/samplesite/public_html and for staging.samplesite.com it’s /home/staginguser/public_html. This is the directory that will need to be copied, since it holds all the site data.

  1. Next, you’ll match the contents of the source to the target.
[root@host ~]# rsync -avHP /home/samplesite/public_html/ /home/staginguser/public_html/
Warning:
If there is already information in the target directory, you will need to use an –update flag to preserve the data while copying new over.

  1. Once you’ve matched the contents, make sure the ownership is up to date in the directory and allow public_html to be readable by nobody. The commands below should change the ownership of all files in the directory path to the proper user, instead of the source user it came from. Using a period (.) will look for hidden files while the asterisk, (*), is used as a wildcard for everything. That way no hidden files will be missed.
  2. Use chown to assign ownership to the account:

[root@host ~]# chown -R staginguser. /home/staginguser/public_html/.*
  1. Make public_html readable by nobody:

  1. In the command below, you’ll need to look for all files inside the /home/samplesite directory and print them so you can find your source database username and password so you can copy the databases into some new ones we’ll create later in this article:
[root@host ~]# find /home/samplesite/ -type f -print0|xargs -0 grep -Il samplesi_
/home/samplesite/public_html/configuration.php

Tip:
Remember that MySQL will only use the first eight (8) characters of a user name by default for the database username.

  1. Then, look for the previous user with an underscore to show we’re looking for database information:
[root@host ~]# grep samplesi_ /home/samplesite/public_html/configuration.php
  1. Locate the username and password for the database:

public $user = 'samplesi_joom205';
public $db = 'samplesi_joom205';


public $password = 'qS.p08]C91';
public $host = 'localhost';

  1. With the username and password, you can create the database, database user and assign the user to the database. You can follow the instructions found in our article Setting Up a Database with MySQL Database Wizard in cPanel.
  1. Once the database is created, dump the database and import it into the newly created database(s):
[root@host ~]# mysqldump --routines samplesite_joom205 >samplesi_joom205.sql
[root@host ~]# mysql stagingu_joom205 < samplesi_joom205.sql

  1. Change the configuration file found earlier on the target site, and you are ready to test the new site. Once it tests ok, it’s time to have the developer review the database information and make sure everything gets changed to the new domain name – things like plugins or modules may need adjustments and there will likely be changes in the database to make.
Warning:
Your database on the target domain will have mismatch data,  you must update the data in the database to match the target domain name to avoid any issues. Please talk to a developer for assistance if you’re unsure how to match the data. Liquid Web does not assist with incorrect data or code on your site, please see our article Management and Support Levels to see what we will assist you with.

Was this article helpful?