WordPress Deployment Workflow: How I Roll

A couple of years ago I wrote about deploying WordPress from a local install to a live site. My workflow has evolved over time (I’m sure yours has, too) and the tools available are consistently getting better. So I figured it was time for an updated look at my WordPress deployment workflow.

For starters, let me define what I’m talking about when I say “WordPress deployment workflow.” I’m talking about the specific process that involves taking a WordPress site on your local machine and moving (“pushing”) it to a live server. This also includes the process of making changes to a WordPress site and keeping your local environment synced with a live site.

What I’m not talking about is a WordPress development workflow. That involves fun things like setting up development environments, version control with Git, and spicing things up with Composer, etc. And that’s not what I’m talking about.

With me?

I’ll use this tweet from Lee to kick off the conversation. I’ll start by sharing my deployment workflow and then wrap up by sharing what other (smarter) developers are doing.

By the way, there are affiliate links in this post because that’s the way I roll.

My WordPress deployment workflow

There are a bajillion different options for setting up your local development environment. While that’s not directly relevant to the conversation, I’m telling you this because I use DesktopServer which, as well as setting up dev sites, includes a freaking awesome way to deploy a WordPress site to a live server.

Before I get started, it is worth noting that I’m coming from the perspective of a single developer (me) working on a project. If you’re collaborating with other developers or working in an agency setting, your deployment workflow will probably look different.

Situation: That very first deployment

Madonna's Like a Virgin meme captioned "deployed for the very first time"DesktopServer is hands down the easiest way to take a brand new WordPress site and deploy it to a live server. Hands. down. Drop the mic.

All you need to use their “quick deploy” feature is a live server with WordPress already installed. You give the admin credentials for that site and then push a button. Your local site wipes out and replaces the destination site. It’s so easy it hurts.

(Here’s detailed tutorials if you want to see it in action)

Situation: I’ve edited theme files and need to push those from local to live

At this point, I’ve got a live site, but I’ve made some tweaks to theme files (or could be plugin files) on my local site that I need to push live. Well, I can’t use DesktopServer’s quick deploy to push those changes because it replaces the entire live site.

I need a way just to push those changed files.

Frankly, I have several different ways of handling this based on the situation (and my mood). 🙂

Quick and dirty

I recently threw together a little site to chronicle my Pokemon Go obsession. This was not a project that called for setting up repositories, compiling CSS, or anything fancy. If I were to accidentally tank this site with a missed semi-colon in a PHP file, it wouldn’t kill me. I’d just restore it and move on.

For sites like this, I use good ‘ole plain FTP/SFTP. It gets my files from Point A to Point B with the least amount of overhead.

Lots of ongoing changes

I like to use Git push for this. From the command line, I can push my changes to the remote (live) server. It’s more work to set up than an SFTP client, but if you’re working in a live staging environment and are gonna be regularly making file tweaks/changes, this is worth the extra effort.

Here’s an article about how I use Git push with WP Engine.

Automated deployment

This last one I’m not actually using any more, but it’s still worth a mention. When I say “automated deployment”, I mean that when your code is pushed to a specified repository, that triggers an action that deploys that code to a server.

I’ve used DeployBot and Beanstalk for this in the past and enjoyed both of those tools. You can do fancy things with those tools, like executing scripts or compiling code on deployment.

If you only need the “push to deploy” feature with the extra fancies, the WP Pusher plugin or the Github updater plugin work nicely.

Situation: There’s new/changed content and I need to sync between local to live

Historically speaking, this has been a pain in the arse. While swapping out files in a WordPress install is a straight-forward affair, dealing with any sort of database sync makes a person want to curl up in the fetal position and cry.

And then came WPSiteSync from Dave Jesch. Imagine you write a new post with some media attachments on your local install and want to push that live. Well, you can. And it’s ridiculously easy. I’m not an affiliate and get nothing for saying that – it’s just a cool product.

You can use it for bi-directional pulls (meaning you can send something live to local or go the other direction with local to live).  The plugin is still young – currently, you can sync regular posts, custom post types, and authors.

Support for other content types (i.e. menus, users, comments) is on the roadmap. Perhaps my favorite thing is their Beaver Builder extension. I’m a fan of Beaver Builder (here’s my review) but boy it’s a major pain to work with locally after you’ve done an initial deploy (because the plugin touches your database, not just your files, and database syncing is… well, fetal position/crying).

Anyhow, keep your eyes on WPSiteSync.

Situation: I need to wholesale replace (or get) a database

Here’s a common scenario: You need to build a new WordPress theme (or tweak an existing one) for a client that already has a WordPress site. In this scenario, you want to build the theme around their existing content (and media files) – not just a bunch of bacon ipsum and place kittens.

This is where I unsheath the amazing Migrate DB Pro. I think I’ve been using this for two or three years now and it’s awesome.

In the scenario I just mentioned, I’d install Migrate DB Pro on both my local site and the live site and then I’d pull down the entire database (and media files, if you want them) to my local install. Of course, you can push as well.

There are plenty of other scenarios, but I find myself most using Migrate DB Pro if it’s a project where I’m getting my hands on an existing WordPress site for the very first time.

Situation: I need to merge two databases

This is one of the biggest headaches in WordPress site management and there hasn’t been an elegant solution. Until now.

Meet MergeBot.

This is a (not yet released) product from the same team that developed Migrate DB Pro. If you’re not sure when you’d ever encounter this situation, here’s a perfect example, taken directly from the MergeBot announcement post:

Ok, so you’ve just landed an exciting new client: Springfield Box Factory (boxes!!!). They need some development done to the site. They have an existing WordPress site, so you get a copy of the files and database, set up the site locally and start coding.

A couple of weeks later, you’re ready to deploy your update but realize that while you were making changes to your database locally, the client was also updating the live database and visitors to the site were also adding data. If you just overwrite the live database with your local database, you’ll lose all the changes to the live site made in the past 2 weeks. — Brad Tousenard

Read it and weep.

Other people’s WordPress deployment workflow

Okay, so I’ve mentioned how I like to go about getting a WordPress site from one spot to another, but I’m just one developer with one way of doing things and my way is certainly not the only way.

Here are some articles from other WordPressers you might enjoy:

So yeah, there’s not just one way to get a WordPress site from local to live — you’ve got a lot of options.

p.s. If you’ve written a post about your WP deployment workflow, leave a link in the comments!

26 thoughts on “WordPress Deployment Workflow: How I Roll”

  1. Thank you for sharing your excellent knowledge AND humor. I’m about to embark on replacing the theme in a WordPress site, which is highly customized, antique , non responsive, had been built from scratch years ago AND the client doesn’t want the look of the site to change one speck. My head is swimming just pondering this task. Would you possibly have a recommendation for an approach?

    1. Well, I have many thoughts about the client wanting it to look just the same. 🙂 As a rule of thumb, I no longer work with code from an unknown developer (as in the case of this legacy theme).

      I’d download just the database and start over redesigning the site using a base theme of your choice. Explain to the client that starting from scratch is actually LESS time-consuming (and therefore less expensive) than trying to modify legacy code of an unknown quality.

  2. Sorry, i mean, my question is:

    I have bought your Utility pro theme. And, i’ve never receive update from your theme. Since, WordPress has done many updates recently.

    1. Oh! I got ya. The current version of UP is 1.3. You can always download the latest copy from your account area. You do not, however, *have* to update the theme (although here are instructions for manually updating). None of the updates in WordPress have necessitated a change/update to UP. If you get stuck or have questions, drop a line through the support forum on store.carriedils.com. 🙂

  3. Oh Carrie, thank you SO much for taking time to answer my question!! Yes, I have many thoughts too about the client wanting it to look the same, but wow do non-visual clients get married to the familiar. This is historically for me a major migraine, so I’ve learned not to wrestle against it like I used to – and it’s the main reason I switched to web design from graphic design, where this syndrome is a zillion times worse. I could talk way too long about this… but I won’t. 🙂 I will proceed as you have recommended – I know you are absolutely correct that this will be easier starting from scratch using a strong base theme. Thanks from the bottom of my heart! ! !

  4. Love reading other developers workflows. Glad you mentioned Mergebot, it could be the magic bullet that a lot are looking for.

    I’ve written an article on workflows but more from a start to finish process (that involves BackupBuddy) – http://www.developersworkflow.com… would love an opinion on it, always looking to improve.

  5. To get around the merge-bot issues, I only work with the live database and then pull it down to local. This way, there is only 1 source of truth and the staging and local servers act as backups as well. Code up / data down. : )

  6. 2 questions:

    1. Using Desktop Server, don’t you find it leaves a lot of things broken when you push – e.g. references to the development temporary domain, and beaver builder stuff broken?

    2. Isn’t there a way to develop an instance in the cloud that doesn’t require spinning up an ec2 server or something, modifying it at will in the cloud – different plugin configs, theme configs, beaver setups, and pushing it to hosting somewhere on demand to form the basis for a new client site?

    1. Hey Asher,

      I haven’t run into the reference issue other than sometimes serialized data is not updated correctly (usually fixed by running Better Search and Replace plugin on whatever instances aren’t behaving). Have you contacted the Beaver Builder team about it?

      I don’t have a workflow for your second scenario, but I’m sure you could. My issue there is that I’d still want to be able to develop locally, free of any online dependencies.

      Since I’ve written this article, I’ve tried out Local by Flywheel. It’s a free alternative to DesktopServer although it’s deployment strength is specifically to Flywheel hosting versus DS which makes it easy to deploy to any host. But it does support PHP 7 which DS doesn’t offer yet. I’ve also tried Vagrant, Docker, and some other local server environment options. I’ve found that every one of them will make you want to throw your computer out of a second-story window at some time or another. 🙂

      Check out the blog at deliciousbrains.com. They’ve got some great (and highly technical) articles on workflows you might find helpful.

  7. Hi! How about quick wordpress deployment using script with simple GUI? You can easily setup latest wordpress version with latest versions of plugins and there are much more tools that helps to speed up developing process on the initial stage. See here https://wpdeployer.com

  8. Since Mergebot was shut down in August 2018, what do you now use to merge your local DB changes with a live site’s changes that occurred while you were developing?

Leave a Comment

Your email address will not be published. Required fields are marked *

Carrie Dils uses Accessibility Checker to monitor our website's accessibility.