Creating a Staging and Development Environment
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.
Log into your my.liquidweb.com account with your username and password, or sign in with Google SSO.
- Click on Servers in the left menu.
- Click on the three dot menu to the right of the server’s name and select Clone Server.
- A pop-up will appear asking you to confirm the details of your clone.
- Confirm the request to clone the server and click Add to Cart to proceed.
- 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.
- The cloning process will begin. Keep track of the process in the Notifications section of your account home page.
| 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.
- 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==- Next, you’ll match the contents of the source to the target.
[root@host ~]# rsync -avHP /home/samplesite/public_html/ /home/staginguser/public_html/- 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.
Use chown to assign ownership to the account:
[root@host ~]# chown -R staginguser. /home/staginguser/public_html/.*Make public_html readable by nobody:
- 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- 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.phpLocate the username and password for the database:
public $user = 'samplesi_joom205';
public $db = 'samplesi_joom205';
public $password = 'qS.p08]C91';
public $host = 'localhost';- 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.
- 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- 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.