This is a short presentation made at the WordPress developers meetup, Melbourne Australia. It provides a simple overview of the set-up and tools that are used to create a development environment where updates can be completed in a staged and version controlled process.

1. Workflow for managing
ongoing projects
James Bundey
@jamesbundey
Melbourne WordPress Developer Meetup November ‘15

2. The Rationale
1. Move away from a whole host of bad practises.
2. Streamline the management & development process.
3. Eliminate issues.
4. Allow for easy collaboration.
5. Have something that was version controlled.

3. The Thought Process
1. Set-up site for local development.
2. Develop/modify theme and store changes with version
control.
• Use task runners, preprocessors etc.
• Manage plugins, libraries and dependencies
3. Automatically deploy updates to staging server for
review.
4. Test & debug in a live environment.
5. Easily deploy to production.

4. Local Setup
The Server
• Built using Vagrant, VirtualBox & Varying Vagrant Vagrants (VVV)
to set up a WordPress specific install.
The Site
• Fresh install created using Variable VVV site wizard plugin.
(https://github.com/bradp/vv)
• VVV installation clones ‘wp-content’ git repo that contains theme
framework and common plugins.
• Theme folder contains base grunt/gulp and bower package files for
common dependencies, and core file/sass structure and function files.
• Once installed, .git is removed from ‘wp-content' as we want to add the theme
folder as a new repo.
• If needed the production DB is pulled using WP Migrate DB Pro.

5. Developing locally
The Theme
• The theme is stored and versioned controlled via a git repo. All commits
are documented and pushed to a Bitbucket company account.
• All collaborators have access and update as required.
The Deployment
• Beanstalk (http://beanstalkapp.com) is used to deploy the all theme
updates.
• To do this a repository is created in beanstalk and added as a remote to
the existing git repository.
• Set-up an automatic ‘Deployment’ in beanstalk to the staging server.
• Once final changes have been committed we simply push to the bitbucket
repo and then push to beanstalk.

6. Live environment
Staging
• We made the decision to use a premium WordPress host -
https://pressidium.com
• Primary reason was the ability to easily clone and deploy from production to
staging and back.
• The staging site theme is automatically updated whenever changes are
committed to git and push to beanstalk.
• If required Migrate DB pro is again used to push any database changes to
staging server.
• If there are significant changes to the site we create a new DB install and
update the wp-config file.
Production
• Never touch it apart from deploying staging to production when approved.

7. Working with limitations
No staging server.
• Set-up an automatic deployment to “theme name_staging”.
• Use Theme Test Drive Plugin.
• Review and test on live server.
• From beanstalk manually deploy to “theme name_prod”.
No money
• Don’t want to pay for Beanstalk.
• Grunt SFTP deploy(https://github.com/thrashr888/grunt-sftp-deploy)
• Gulp-sftp (https://www.npmjs.com/package/gulp-sftp)
• Private repositories on Bitbucket are free.
• Take a look at wordmove - https://github.com/welaika/wordmove

8. Questions?
Connect with me
@jamesbundey
www.linkedin.com/in/jamesbundey