My WordPress Development, Testing, and Deployment Workflows


  • I like having three distinct environments: – Local Development – All development happens locally, never on the server. – Staging – Staging is for pre-deployment testing and for team content tweaking before deployment. – Production – Nothing untested gets sent to production. It is always the working copy.

Development & Testing

Version Control and Deployment

  • I use Git for version control and deployment.
  • If I am working on the project solo, my local git repo is the main repo.
  • If I am working with other developers, the Github repo is the main repo and I start my day by doing a git pull.

Here is my testing and deploying workflow:

Testing and deploying

  1. git push staging master – Sends the code up to the staging server on WPengine. If I have database changes to migrate, I do so immediately afterward. For pages/posts I use the general WordPress exporter. For theme settings, both main theme frameworks I use (Genesis and Total) both have theme settings import/export features. For widgets, I use the Widget Settings Importer/Exporter plugin.
  2. After verifying that everything works as intended with Step 1 and getting a second set of eyes on the team to verify, I run git push production master. This pushes my already tested code to the production environment. No code touches production without having been tested on staging first. If database changes need to be moved over, I’ll either use WPEngine’s Deploy Site tool for big changes, or export them from Staging and import them on Production for smaller changes or times when the database on Production is significantly out of sync with staging.

Backing up my work

At the end of my work day, I back up my work:

back up

This is a two-part process:

  1. git push github master pushes my day’s commits up to Github.
  2. gulp dumpDatabase dumps my database from Homestead and saves it to my hard drive, which gets replicated within 30 minutes to Backblaze.

Leave a Reply

%d bloggers like this: