| I worked briefly for a wordpress consultancy last year. Our main workflow involved using Yeoman, Grunt, NPM, wp (the wordpress command line tool) and vagrant. Locally, we'd run vagrant just so we don't have to monkey around with environment issues (too much). Yeoman, grunt, npm and wp were used in tandem to script the creation of a new wordpress install, install any dependencies needed, run any tools needed through grunt (like sass and JS minifiers), and pull plugins and themes from their separate git repositories. We still had to import the database by hand, though, when setting up our environment as well as add lines to wp-config for however we wanted to handle debugging. Then we'd write code and check it in via git as with any other project. If you were working on frontend anything (html,css,js) you either ran grunt all the damned time or ran grunt watch. Those of us who had a hard time with the unique programming requirements of wordpress (escaping, sanitizing, formatting) used phpcs to automate that. As for deployment, we'd just go through the same setup on the server that we do locally. Updates were pushed via git. The fundamental problem my company runs into with WP is that only a theme can be meaningfully checked into version control. Everything else, including installation of plugins is coupled with entries in the database. That wasn't my experience. We separated functional features into separate plugins (so they could be disabled or enabled on a site by site basis) and had no problem using version control with them. In fact, one project had some government security problems and required each plugin to be in its own repo. I wouldn't suggest that, but it works. the database also includes changes necessarily made on the production instance, like comments to blog posts That was something I found aggravating that was never really addressed at the company I worked at. When new people were brought on to a project, they'd get a mysql dump of the staging environment. After that, as new features were added, you were responsible for adding your own test data to see if those features worked. As for production, the changes made that were specific to the production database were made manually in production. When a new plugin was pushed, you had to log into the production instances manually and turn the new plugin on. Luckily, there are hooks you can use to automate any setup or teardown of plugins when they get turned on and off respectively. |