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):
- Pull down the Github repository
- Develop locally at local.example.com
- Commit changes and push to Github
- Push to Beanstalk if you want changes immediately pushed to dev.example.com
- Merge master to production and push to Github and Beanstalk
- The production branch is automatically deployed to staging
- 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)
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.
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
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.