Local, Dev, Staging, Production WordPress Workflow

I just wanted to share real quickly (because I’m pretty stoked) that after months (really, years) of development I finally have what I consider a professional workflow for WordPress development.

Below is a graphical representation of what takes place. But it breaks down to this (with Git, but can easily be accomplished with SVN as well):

  1. Pull down the Github repository
  2. Develop locally at local.example.com
  3. Commit changes and push to Github
  4. Push to Beanstalk if you want changes immediately pushed to dev.example.com
  5. Merge master to production and push to Github and Beanstalk
  6. The production branch is automatically deployed to staging
  7. Manually deploy to production from within Beanstalk

Notes:

  • Local and Dev share a database (but don’t have to)
  • Staging and Production share a database (but staging only has read access)

WordPress Workflow

 

You can fork the Denton Bible Church Website even if you just want to use this is a framework for your project.This is built off of Hybrid Enterprise which is a cleaner repository that accomplishes the same thing.

Finally, and sadly, I am still looking for the best multi-environment database solution. Ideally, a fourth environment would be used to make content changes against the latest production branch code and then changes would be selectively deployed to the production database. WordPress 3.6 almost had a great solution.

2 Replies to “Local, Dev, Staging, Production WordPress Workflow”

  1. Thanks for the post, im looking for a good WP work flow. I currently use this formula and had appended another layer on top of it to have a dev,staging,prod environment http://joemaller.com/990/a-web-focused-git-workflow/. It works great but Im still looking for the best DB solution.

    I am wondering why you push automatically to dev and staging… assuming you work locally. I feel you would want to work on these completely separate from one another. Otherwise what’s the point of a dev and staging if they both get updated automatically

    1. I still don’t have the DB figured out either and was really disappointed when 3.6 dropped versions workflow of posts.

      I auto deploy trunk to dev. Then I merge trunk to staging when ready and that merge auto deploys to staging.

Leave a Reply

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