- 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
- For local development, I use Virtual Box to run the VMs, Vagrant to manage them, and Laravel Homestead as my base environment.
- I use Gulp for automating my compiling and 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
Here is my testing and deploying workflow:
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.
- 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:
This is a two-part process: