Tag: DeployMint

  • 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.