Deploying WordPress: What’s your Workflow?

Yesterday I posted some general tips and tricks for WordPress beginners on how to edit WordPress files. The discussion came up in the comments about workflow when it comes to setting up a fresh WordPress install or deploying to a site live.

Below I’ll share the tools and workflow I use, but I’m fully aware my process could be improved, so think of this as a jumping off point for a great discussion in the comments on your own workflow.

Situations for Deploying WordPress

Here are some situations where you need to set up WordPress, clone or migrate a site:

  1. Totally new project (local install)
  2. Deploy local to live
  3. Migrate/clone live site to development site.
  4. Migrate/clone development site to brand new live site.
  5. Push changes from development site to an existing live site.

I’ll break out each of these below and which tools I use for which job

Totally New Project

For a local development environment, I used to use MAMP and a single WordPress install. Before you scream at me for just a single install, I’ll explain why: I could drop my entire library of themes and plugins into that install without replicating them a million times.

But then I screamed at myself and how terrible one install was. About this time I met Gregg Franklin at WordCamp Las Vegas and he ran me through a demo of Desktop Server. I fell in love with it.

The beauty of it is that I can set up my Perfect (or “Blueprint”) Install (i.e. already have my basic settings , favorite plugins, etc.) and copy it all over the place. So, when I need to start a new project, I fire up Desktop Server, click a button, and voila! It gives me a fresh local install of WP based off my Blueprint. In all of two minutes I’m up and running with a local development site.

You can use the free version of Desktop Server for this.

Deploy Local to Live

Desktop Server is still my choice here, but you’ll need to upgrade to their premium license ($99.95) to use the direct deploy to live server feature.

The process is ridiculously easy (unless you’re pushing to a WPEngine server, in which case there are extra hoops to jump through). Desktop Server deploys both your database and your files and updates all instances of your site URL along the way. The premium version also supports MultiSite, if that’s something you need.

Now, Migrate DB Pro (which I’ll talk more on shortly) has the ability to push a local database up to a staging or production database. I discovered Migrate DB Pro after Desktop Server, so I haven’t tried out that feature yet.

Migrate Live Site to Development Site

Migrate DB Pro

I like Migrate DB Pro so much that I’m an affiliate for them. Use coupon code SUPER20 to save 20%.

Depending on the nature of a project, I might never do a local install and just develop on a designated development site. In this case, I want to take an existing site in its entirety and pull it over to a development site where I can tinker.

Enter Migrate DB Pro, which is easily the best $199 I’ve spent all year. An important distinction to note for this software… it’s Migrate DB Pro – not Migrate All Site Files Pro.  This tool is best for moving databases from one spot to another, although they recently added a Media Files add-on that pulls over a site’s media gallery (super handy!). You’ll need to manually upload any themes or plugins you want.

So, my workflow looks like this: On the development server, I install WP, activate the same theme and plugins being used on the live site, and lastly do a database pull using Migrate DB Pro. Working in that order means that when the data comes in, it’ll automatically put widgets where they belong and restore any plugins or settings from the live site. If you work in the reverse order and bring over your data and then install theme/plugins, you’ll miss out.

Migrate Development Site to a Brand New Live Site

A year or so ago I started using ManageWP‘s site clone feature to copy a site (files + database) from one spot to another. While I loved the idea of the clone feature, it turned out a little clunky. For instance, the automated search/replace for dev URL to live URL was incomplete (URLs in widgets needed to be manually updated). Also, the clone feature seemed to only work on small sites. Larger sites timed out or just crapped out. I still like ManageWP for general site management tasks and scheduled backups, but I no longer use it for cloning sites.

I make the distinction of a “brand new live site” here because I want to emphasize that I’m doing a full clone of the development site to the new site – any existing data on the live site be damned and overwritten!

Migrate DB Pro is the winner here. Note that I do need a WP install plus theme and plugin files already set up on the live server, but once that’s done I can pull in the dev database and 1 minute later have my entire dev site replicated perfectly on my live server.

Push changes from development site to an existing live site

It’s confession time. This is the weakest area as far as a deployment routine. Let’s say I’m building a new theme for a client. The end deliverable is an installed theme on their server with their data. Doing a database overwrite isn’t ideal, but neither is waiting until the theme is live on the client’s site to go through all the settings and options ideal either.

For simple sites, there’s no true deployment. I just upload new theme files, activate a maintenance plugin, and work as fast as I can to bring the site back online (typically an hour or less). Can’t believe I just confessed that out loud.

For complex sites, I again go with Migrate DB Pro, but I ended up pulling the latest db files over to development, completing the site setup, and then pushing everything back over to live (so, overwriting the database). That means minimal downtime for the live site (typically 10 minutes or less). But, something in my gut doesn’t feel right about this and a database syncing option would be better.

What’s your Workflow?

How to you deploy WordPress? What are your preferred tools and workflow? Leave a comment below – I’m curious to hear.

* Featured image photo credit to U.S. Army

Comments

  1. says

    Basically the same process here. I had actually been using Desktop Server for a little while before I discovered the Blueprint feature. My mind was blown. It’s incredibly helpful, especially if you have a plugin, or group of plugins, that you always include with a site that require licensing (i.e. Gravity Forms).

  2. says

    Been using DesktopServer since the beginning of the year… I’ve deployed from local to live, I’ve set up a local from a live site to tinker and then manually pushed out changes. I just yesterday set up a site on Flywheel and they moved it all for me, that was fantastic! Should be launching very soon.

    • says

      Glad to hear you like their local to live process! I’m hosting this site with Flywheel and I love it. So easy to set up dev environments and pass billing to a client, but I wish they had a playground, so to speak, where I could play on a live environment, but not necessarily transfer that to a client at some point.

  3. says

    Hi, Carrie — first time commenter.
    Super helpful post as I’m just getting started. Also a MAMP user, but intend to play around with ServerPress to see what it’s all about. I do use ManageWP, but have yet to try the cloning feature.
    Thanks so much for the help! Looking forward to the office hours!
    Sandee

  4. says

    Hey again Carrie!

    Thanks for the mention here as well. I just finished reading the article you posted a couple of days ago, so I’ll just say thanks again and if anyone has any questions about DesktopServer, please feel free to ask!

  5. says

    I build all client sites live on a test domain, then use BackupBuddy to move them to the client’s server (assuming it’s a brand new site). I’ve been considering ServerPress but for right now, I see no reason to change up my workflow since it works well. PluginBot is a great tool for live builds since I can install all my preferred plugins at once.

    • says

      I’ve done basically the same thing as you, Andrea, but using ManageWP instead of backupbuddy and just manually going through the migration process in the rare instance it doesn’t work (I encourage clients to host on my server, and as long as the server is quick enough, that has seemed to work even on larger sites).

      I’m probably going to switch over to DesktopServer, though, after watching a few of their demo videos. Actually found this blog entry while looking around for DesktopServer coupon codes. Main advantage for me would be that on a local server it’s just so much faster to refresh, change settings, etc.

      Glad to see other people looking at this sort of a tool, too. I feel like a cheater when I use some of these one-click solutions for things that I know how to do, but just don’t enjoy doing.

  6. Janet says

    THANK YOU!!! It’s like Christmas all over again! I’ve have a major need for a better work flow – just read the previous post too – double the goodness!! :-)

  7. says

    Thanks for sharing this, my friend. I love (honest) workflow posts! I recently started using Desktop Server as well, and am loving what I see so far (but still have a long ways to go, I think). You got me hooked on ManageWP a year ago, but I’ve had similar issues with cloning so will check out the other option now. So thanks!

  8. says

    Hi Carrie… I’m sort of a WP newbie started a few months back. But, i am a computer tech by trade. Just thought I would share that haven’t learned all the tricks people talk about but I really do appreciate all the help I get around here.. especially with all the God loving people using Genesis.

    I use Siteground and have used another host just prior and no comparison. I like SG due to the fact it is really fast, support is great when I need it and they have a staging feature that I love.. I can stage up to 10 sites and push them to live in a matter of seconds. Takes about 30 seconds each way. I still have a ton to learn and love your dedication to help people like myself. Thanks for all you do.

    Siteground also allows me to refer someone and they can get a basily a year free after they pay for only a month. I’m not here to post the affiliate link but if anyone would like that deal they can certainly request it from me and I will send. I actually have their Geek acct. and could not be happier. I have about 10 sites I and working on and finished up 3 so far.

  9. says

    Hey Carrie your post is most timely as just today I’ve invested in Serverpress and am still basking in the glow of its awesomeness.

    Having previously worked with MAMP Serverpress is definitely a great way forward and although I’m only stepping out with Coda, the integration with it is superb.

  10. says

    This is awesome. You’ve opened up the curtain to let us see inside all things Awesome Carrie! That is super cool and very helpful. We probably need to discuss workflows more so that we all can learn from one another and improve. I’m definitely sharing with my team!

    Todd

    • says

      Thanks for bring up VVV! I’ve been a little intimidated to set it up, but am curious about it. Can you share how it’s used for deploying local to live sites or is it excel just as a local dev setup?

    • says

      Better is a subjective term. Note that Vagrant out of the box, doesn’t have copy or blueprint features. Keep in mind that DesktopServer runs natively on your computer without a Virtual Machine. There is no “booting” up, virtual hard drive, virtual network drivers, file system transfers, or anything like that. It uses less memory, less CPU, and runs faster than Vagrant. It works on your local computer just like “Word” or “Excel” and is built specifically for your computer’s microprocessor and operating system. You can edit your files directly in your favorite editor without having to mount a virtual file system, etc.

      Both DesktopServer and Vagrant are open source. I think what you mean is that Vagrant is “free-er” as in “free beer”, “I don’t have to pay for anything” for access vs SaaS, updates, or support. Not to be confused with “free” open source which pertains to copyright (or “copyleft” as us FOSS developers like to call it).

      That being said, Vagrant has some bonuses if you have the extra hardware to run it. You might not be creating a site in under 5 seconds like you can on the latest Macbook Air with DesktopServer, but once you do boot up a Vagrant, you can customize it to look more like your hosting provider’s hardware. That can be advantages if you want a more seamless environment (provided your hosting provider reveals their internal specs. or you do the research to find out what those are).

    • says

      I use VVV for much of my development, but also use DesktopServer alongside it. They hit two different markets if you ask me, and actually work well for me side-by-side. Vagrant is amazing at providing a full server environment that can mimic your live environment for fuller testing and VVV specifically gives you a great WP environment. DS brings an unmatched ease-of-use that many designers and beginning developers will prefer and has some pretty sweet features with their deploy method and blueprints.

      I’d hesitate to say that one is really “better” over the other. It’s all a matter of how you develop and what your needs are.

  11. says

    Great post, Carrie, as usual! I’ve been using Migrate WP Pro, DesktopServer (Loves it), along with Git and DeployHQ. Although, Siteground and WP Engine’s Git push capability are pretty amazing.

    I’m intrigued by setting up Vagrant and Grunt, but not seeing too enough benefits to abandon what I have. Though, with that line of logic I may be going the way of the WebKing (http://www.webkinglasvegas.com/) sooner than later.

  12. says

    Oh, how I struggle with workflow. Thanks for sharing yours. The hardest part is pushing changes to an existing site. I wish it were more straightforward. You can set up Git and deploy changes to your files, but then there is still that pesky database! I wish that WordPress would enhance its native export/import to include everything (menus, widgets, etc). I’m not sure why they don’t or if there are any plans to in the future, but it sure is a pinch point in the process. I also struggle with the idea of writing over the entire db when you only want to update certain things. I haven’t tried WP Migrate DB Pro yet, but I know I need to, as it seems to be the best solution as of now.

  13. says

    Great post! Just found your site. I’m new to Genesis and really love it.

    Here’s what I do…

    New site:

    - create on dev domain on my own hosting acct
    - once complete, clone entire site using WP Twin by Rapid Crush software, but Backup Buddy would probably work well, too. I love WP Twin as it copies the db, changes all urls, never times out.
    - deploy with WP Twin on live url. WP Twin deploys is seconds.

    Existing site:

    - clone with WP Twin and deploy to a dev domain
    - make changes and reclone
    - wipe live WP install, create a fresh install of WP and deploy cloned update.

  14. Katrina Moody says

    A few nuggets (especially in the comments!) that I haven’t heard of. I want to start playing with Desktop Server – I need a deploy to live solution that works better than the old FTP one ;-)

    My biggest problem comes with deploying to a live site that has its own content on it. Depending on what is on the old site – if all they want to keep is the posts/postmeta – I might pull the database and then merge the two SQL backups (from development and live) before dropping all the tables in the database and re-importing the new, merged, one (of course I make sure to keep a full backup in case I mess up royally, which never happens <– , :D

    Great post – I love seeing what others are doing!

  15. Matt says

    Great post, thank you for sharing! You made me excited about Desktopserver and now I see there’s a coupon code possible. Does anyone know a working coupon code?

    • says

      Thanks Matt! Not sure of a coupon for DS (the one I mention is for Migrate DB Pro). I’d suggest starting with the free version of DS – it’s still a really awesome piece of software. The primary capability of the paid version is deployment to live server.

      Cheers,
      Carrie

      • says

        Another huge benefit of the paid version is the ability to create your own blueprints.

        You can use blueprints to create a site in the free version but you’re stuck with the stock blueprints.

        Just my two cents :-)

        • says

          Austin, thanks for the comment. Actually, you can create a blueprint and put it in your xampplite/blueprints directory and it will show up in the dropdown. The main difference is that the blueprint you create will not have the plugins activated, whereas with the paid version, you can use the “export” feature which has all of your plugin registration information along with whether or not it was activated.

          Hope that clears things up! :)

  16. says

    We don’t do much maintenance to sites we didn’t create.

    And we don’t like to develop locally, but for clients who are first-time web owners or established clients that are getting a new domain but have not decided on it yet, we often develop the client site on a local iMac ( via XAMPP) or on one of our domains we use for testing on our dedicated server (at Pair.com.) We then migrate it to the client’s server and domain.

    Over the years, we find that the WP Codex migration instructions work just fine and without any added expense. In the past we’ve been bitten on our “bottoms” with 3rd party plugin tools and pay-per-month services.

    Do understand: I’m sure that the services and products mentioned in the comments here are fine… but we like being in as much control as we can, to say nothing about the costs involved.

    The really big ‘gotcha’ in migrating WP sites from a development platform to a client’s production domain is the fact that WP (for some dumb reason I’ll never understand) decided to serialize the site URL in some of its tables.

    Lots of people will do an SQL dump of the database to plain text and use a text editor to search and replace… i.e development-domain-name.com –> client-domain-name.com. Well, because of string lengths and other issue with serialized data, that method can also bite you on the “bottom.”

    So, what is the answer? Simple. There is a terrific free tool that has never failed to work for us.

    We dump the development MySQL file and load it to the client’s site (both via phpMyAdmin) and then upload this little PHP program and run it with the database’s user, passwords, DB-name, sever info (same stuff in wp-config.)

    You can read about and download the program here;

    https://interconnectit.com/products/search-and-replace-for-wordpress-databases/

    My guess is that there is code similar to to what is in the above in the routines by the various services and plugins that seek to make migration easier.

    If you follow the WP Codex methodology ( and I can’t believe that professional developers would have any trouble doing so) AND use the little PHP program by InterConnect/It you will get flawless results and won’t have to pay 3rd party costs.

    Yes, it takes us a tad more time but we get to control the process which is one way we protect our “bottom.”

    Hope this is of value to someone.

    (And Carrie, we love your blog. While you are a strong supporter of WP ( and Genesis, which is our weapon of choice) you are also one of the few writers in the genre not afraid to be critical of WP or some of the products (themes, plugins, services) when criticism is warranted. You’re the best of the best!)

    • says

      Hey Al,
      Great points you bring up – you’re right that serialized data has always been the biggest PITB (Pain in the Bottom) when it comes to moving sites around. Thanks for sending the Interconnect link – I hadn’t seen that.

      Cheers!
      Carrie

  17. adamvclark says

    I start everything with a git repo in Beanstalk. I clone that locally and build my site, committing along the way. (Beanstalk automatically deploys to my staging server when I do a local commit and push). Once I’m ready for the client to see the site, I use Sequel Pro to export my local db and import into the staging server’s db and replace the appropriate URL strings.

    And of course I have this whole process automated down to a few clicks using Alfred. ;)

Leave a Reply