WP Engine has Staging Environments
One of my favorite features of my WP Engine account is it's staging environments. If you don't know what a staging environment is, let me explain.
In enterprise software development you develop solutions on your own personal computer. So when you're done, you want to push it up to the production server. But guess what? Things break. Because the production environment isn't the same as your computer. And that's why we create staging environments.
They're duplicates of production, but not production, so that we can test software.
But WordPress sites aren't enterprise software, so most of us never think about staging environments. But we've all updated a plugin or theme, only to see our sites break, right?
Well if you use WP Engine, they give you a staging environment, a duplicate of your site, for every site you host with them. It's perfect for testing changes to themes, plugins, or more. And the thing I like most is the one-touch deployment.
But what if you're not hosting with WP Engine?
One of my favorite non-managed WordPress hosts is DreamHost. For years I've been helping non-profits and churches host their sites on DreamHost. They choose it because it's still solid hosting at inexpensive prices. But they don't come with staging environments or ways to deploy your code from one environment to another.
So if you want a one-touch deployment from one environment to another, you normally have to spend some time working on scripts. Scripts to monitor environments. Scripts to find differences. Scripts to move files. Scripts, scripts, and more scripts.
Until now. Now you can use a service called dploy.io.
Now, I'm not going to walk you through every step, but I want to show you what's possible – without writing any scripts at all!
No scripts (and I still have 1-touch staging)
For this example, I'm going to show you a single deployment. But the truth is that you could spin up several sites at DreamHost to function as different environments, including staging. Configuring each one is the same as the first.
Let's start with GitHub.
The first thing I do there is create a repository to hold all my files. This isn't a backup. It's simply a stopping point on my way to one-touch deployments. It's a proactive decision to place files there before sending them on to a server elsewhere.
What you'll notice is that I'm using GitHub's private repositories. You'll also notice I'm running this example on the /prod branch rather than the main one. You can do things differently. I won't get mad.
Here's the good news: if you store your files on public repositories, dploy.io is free.
You may notice that these files are the default WordPress files. Yes, that's right, I'm deploying a WordPress web site. I checked in those files from my local install, which I'll cover in a second.
On my Mac, I use Tower.
There are several Git clients for a Mac, and more for a PC. But I use Tower. And with Tower, I can push any files from my local environment up to Git easily.
What you may notice is that I pushed the ‘baseline' which held all the main WordPress sites, and then again I pushed up another change when I added a new theme to my install (Addler by WooThemes).
This gives me multiple packages to deploy – the baseline and then the theme addition. We'll see that in a second, after configuring dploy.io.
Set up your dploy.io account.
First you need to connect to a repository – like the github account I referenced above. But it can be bitbucket, or your own hosted git repository.
When that's connected, you can link it to any new environment you set up.
Let's quickly review.
You push code to Git. Git is connected to dploy.io. dploy.io is then connected to as many environments (staging, production, etc) as you like. Ready for the one-touch deployments?
Remember those two pushes, two commits that were in my repo at Github? Well, now you see them here, don't you?
That “Deploy” button is the one-touch deployment. And what it does is really simple:
- Monitor your Git repository for changes.
- Find out what files have changed.
- Push them to whatever environment you set up.
But guess what? You can even have it do this continuously without any button pushing. Continuous automatic deployments – all because of the cool working of dploy.io. Pretty cool huh?
Is it worth it?
If you do this for your WordPress sites, it could be free. Public repositories on Github are free. Dploy.io accounts for open source are free. And Dreamhost account are inexpensive. So in that case, yes, go for it.
On the other hand, private repositories cost you money. And to use private repositories, dploy.io also has costs. And if you're going to spend money, can I just suggest you check out WP Engine again?