Why you need to start using a staging environment

Have you ever made a change to a client’s WordPress site and it crashed? Maybe you were updating a plugin or customizing code in the theme, and the site just goes down.

Panic sets in as you try desperately to bring the site back online. You realize visitors are seeing that the site is down, and are probably going to call your client soon. Not long after that, you’ll get a call from a very irritated client.

As professional developers, we obviously want to avoid situations like this. So how can we? Well, instead of making code changes or updates to a live site, you want to test your changes on staging environment. From there, you can transition them to the live site..

What is a staging environment?

In a nutshell, a staging environment is a copy of your site where you can test changes without it being public.

 It’s a great place to test updates to plugins, themes, and the WordPress core. You can also install new plugins or themes and make sure there are no conflicts — as well as make customizations to themes without any visitors being able to see your work in progress.

Once you’ve finished testing changes, you can then make those changes live. It’s a much cleaner workflow.

How to make a staging environment

Luckily, many managed WordPress hosting companies have staging environments built in to their system. With the click of a button, you can deploy a staging copy of your site. It’s fast, easy, and requires no technical knowledge.

But what if you don’t have managed WordPress hosting? You can still create a staging environment. It requires a bit more work and technical knowledge, but it is easy to learn. And the more you do it, the faster it becomes.

Creating a staging environment requires three steps:

1. Make a staging subdomain (for instance, staging.domain.com)
2. Copy all WordPress files from your live site to your staging site
3. Duplicate your database from your live site and connect it with your staging site

For an in depth tutorial on making your staging environment, check out WPBeginner.com’s tutorial: How To Create a Staging Environment For a WordPress Site.

An important pointer: moving databases between sites can be tricky. You need to replace the old site’s URL in the database with the new one. But there are tools that makes it easy. I recommend WP Migrate DB Pro.

So this process of creating a staging environment to make and test changes before making them live is great, but maybe you want to take it up a notch.

Let me show you how the best WordPress developers set up their workflow.

 An even better development workflow

In this process we’ll still be using a staging environment, but we’ll add a development environment. So now we have three environments total:

1. Development: all code changes are made here. For instance, if you are developing a brand new theme, you’d do the development here. Once completed, you move your changes to the staging server.
2. Staging: because we are only making code changes to the development server, it is ok if the development database is not up to date. But before you move your development changes to the live site, you want to test them. So move your development files to the staging server and make a copy of your LIVE database to your staging server. You can then test your site and make sure all looks good.
3. Live: Once testing is completed, you can move your files to your live site.

 To make the workflow as easy to manage as possible, many developers use Git to track changes and make moving between environments easier.

Chris Lema has a great tutorial on using Git within your workflow: One touch deployments and staging environments for WordPress.

As you make changes to your development environment, you commit those changes to a Git repository. So, for instance, when you finish coding a page template, you would commit the changes. If you ever need to undo your changes, you can easily restore to a point before you made the commit.

Once you have completed all changes, you can deploy your commits to a specific environment. So when you complete your development work, you can deploy it to your staging environment. Add when you’ve tested it, you can deploy it to the live site.

As you can imagine, this becomes incredibly effective when working with a team of developers who need to know when changes are made to the code and what changes have been made.

Final thoughts

In this article, I’ve shown you why you need to stop making changes to a live site. I’ve also presented three alternatives for setting up a development workflow. Obviously, having a host with a staging environment built in is the easiest option. But the other solutions are effective as well.

In my own development work, I use all three techniques. It usually depends on the complexity of the job and the client’s needs.

If you have any tips for creating a better development workflow, please share them in the comments below!

---

Brandon Yanofsky is a freelance WordPress developer and troubleshooter. He also shares WordPress tips, tricks, and tutorials at www.mywpexpert.com. You can email him at [email protected].