DeployMint: A Staging and Deployment system for WordPress

Written by

Advanced Wordpress, DeployMint, 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)

Then you design your entire site with themes, pages, content on development.example.com.
Once you’re done, you take a snapshot of development.example.com and deploy that snapshot to staging.example.com.
Your client reviews the new site on staging.example.com and suggests changes.
You make the changes on development.example.com, take a new snapshot and deploy that snapshot to staging.example.com
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.

CMS DeployMint WordPress

Comments

10 responses to “DeployMint: A Staging and Deployment system for WordPress”

December 19, 2011

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.

Reply
1. December 19, 2011
  
  David S.
  
  Looks like I am missing table wordpress.dep_options. Not sure where that is supposed to come from.
  
  Reply
June 13, 2013

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.

Reply
1. May 30, 2014
  
  Jamal Robert
  
  Hi roonie, I am interested in your update. Email it to me on dextatek at gmail.com. thanks
  
  Reply
July 9, 2013

Martin Heon

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

Reply
1. July 9, 2013
  
  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.
  
  Reply
January 20, 2014

Chris

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

Reply
June 17, 2014

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.

Reply