because wordpress 3.6 dropped editorial flow i'm about to give a promising plugin a try: http://t.co/Fp9DPBTAox – anyone used it?
Month: April 2013
Local, Dev, Staging, Production WordPress…
Local, Dev, Staging, Production WordPress Workflow http://t.co/C0XsWsAI61
Local, Dev, Staging, Production WordPress…
Local, Dev, Staging, Production WordPress Workflow http://t.co/t0KRT40Ro2
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.