MarkMaunder dot com

DeployMint: A Staging and Deployment system for WordPress

Exec Summary: Today I’m launching a Beta open source project called DeployMint. I’m using it on WordPress installations where WordPress is being used as a CMS. It runs as a WordPress plugin and allows for staging and deployment of WordPress sites along with robust version control and zero down-time during deployments. It uses the Git version control system to store site snapshots in a safe and space efficient way. It also takes a “belt and braces” approach and provides an emergency back-out system separate to Git in case a deployment fails. You can download the latest version of DeployMint and see a video demo at the DeployMint project page on Google Code.

Full blog entry:

My company is busy moving to using WordPress as a CMS and I wanted a way to instantly deploy several new pages of content or an entire site and have dev and staging sites to test new ideas. I also wanted version control, instant deployment and an emergency back-out system.

I also needed comments to be preserved on the live site so that if I deploy a new version, the existing comments on the live site stay where they should be and only page or post content is updated.

So I created a WordPress plugin called DeployMint.

DeployMint runs under WordPress MU. You create as many subdomains as you would like, for example:

  • development.example.com
  • staging.example.com
  • example.com (your live site)
  1. Then you design  your entire site with themes, pages, content on development.example.com.
  2. Once you’re done, you take a snapshot of development.example.com and deploy that snapshot to staging.example.com.
  3. Your client reviews the new site on staging.example.com and suggests changes.
  4. You make the changes on development.example.com, take a new snapshot and deploy that snapshot to staging.example.com
  5. Once your client is happy, you take a snapshot of staging.example.com and deploy it to example.com, your live site.

Here is a video showing the basic functionality of DeployMint. DeployMint is installed on this blog and I use it to test out new themes and design changes. It works as well on a blog or when WordPress is being used as a CMS. In this video I take a snapshot of my live site (this blog) and deploy it to my staging site staging.markmaunder.com. Then I make a minor modification, I re-snapshot the staging blog and deploy that snapshot to the live site.

DeployMint is space efficient because it uses Git to store snapshots. It also makes a full copy of your entire WordPress database including all your WordPress MU sites every time you deploy. Because these require more space, you can choose how many of these full backups you want to keep. If things go awry with your database or deployment for some reason, you have an emergency backout system that will restore your WordPress MU installation to the state it was in before your previous deployment.

Behind the scenes, DeployMint (DM) works as follows:

  • To install DeployMint you need to create a data directory that is not under your web root, but is writable by your web server.
  • When you create a new project, a new Git repository is created.
  • When you take a snapshot, DM dumps all tables belonging to the blog you snapshotted into individual files.
  • Those files are checked into a ‘Git’ repository. DM uses git for storage because it’s space efficient and robust.
  • Every snapshot you create is a new branch in the repository and only the changes are stored.
  • When you deploy using DM, it simply checks out the branch you want to deploy and imports it into a temporary database.
  • In that temp database, we merge all existing comments on your site into the site we’re about to deploy.
  • DM also modifies any hostnames it needs to, to reflect the site we’re about to deploy to’s hostname.
  • Before deployment, DM takes a full backup of your entire WordPress MU database including all sites and stores this for emergencies in case you need to back-out your changes.
  • These backups take up more disk space than snapshots, so you can choose how many of them you want to keep and DM auto-deletes the oldest ones first.
  • Then a rename is done which takes a few hundredths of a second to replace your old database with the new database we’re deploying.
  • And you’re live with your new site!

Please post a comment below if you have any features suggestions or comments. Thanks.

10 Comments

    David S.

    Hi – any help would be greatly appreciated with this problem. The options that I am setting through the Options page for DeployMint appear to be saving correctly (at least with respect to the AJAX response), but when I reload the page all of the settings are empty. Any ideas? DeployMint seems like it would be really useful if I could get it working.

    Commented on December 19, 2011 at 6:43 pm

    Ronnie H.

    Nice tool! I have made some updates to it base on our company use case scenarios. We wanted Admins to have the ability to do deployments but only see their sites they have access to and projects that they created. I have added that functionality. I still reserve the “Emergency Revert” and “Option” pages for Super Admin. If anyone is interested in my updates I can send it to them or post it to bitbucket or github.

    When I find some more time I will be updating the tool to deploy to different db’s so you can separate the environments.

    Commented on June 13, 2013 at 8:58 pm

    Martin Heon

    Can’t add a new user after cloning a site. (roles won’t show)

    Commented on July 9, 2013 at 8:12 pm

      Ronnie Hash

      The issue is when deploying your snapshot to another site, it overwrites the option name of wp_*_roles with the site you are deploying from.

      You have to look in the wp_*_options table and update it with the correct name.

      Commented on July 9, 2013 at 8:19 pm

    Chris

    Any thoughts on making this up to date again? Mark, I think there could be a huge potential in this plugin once again.

    Commented on January 20, 2014 at 8:11 pm

    mike

    Hi Mark, I’m wondering if its possible to create multiple dev environments unique for each person adding content (like: dev1.example.com, dev2.example.com, dev3.example.com) and then have all of those users using the dev only be able to post to the staging.example.com site? Ideally only one or two people would be able to login to WP from the staging site and push to production from there. Is this doable? Thanks.

    Commented on June 17, 2014 at 6:59 pm

Leave a Comment

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

My name is Mark Maunder. I've been blogging since around 2003 when I started on Movable Type and ended up on WordPress which is what I use to publish today. With my wife Kerry, I'm the co-founder of Wordfence which protects over 5 million WordPress sites from hackers and is run by a talented team of 36 people. I'm an instrument rated pilot and I fly a Cessna 206 along with a 1964 Cessna 172 in the Pacific Northwest and Colorado. I'm originally from Cape Town, South Africa but live in the US these days. I code in a bunch of languages and am quite excited about our emerging AI overlords and how they're going to be putting us to work for them.