WordPress Workflow – WCSYD 2016
Development to Staging to Production
First, big thanks to everyone who attended WordCamp Sydney 2016 and all the awesome people who organised it. This event was my second this year and my second time speaking, truly is the best event to attend.
It’s important to remember that everything I talked about on the day and outline here is my way of doing things, not the way of doing things. There is no right way, only your way. I want to give you some ideas, and you season them however you need to make it work for you.
In the post I will go over the same key points, I covered in my talk on the day. I will go over;
- What the WordPress workflow includes.
- Why you should be using a workflow, even if you are not a developer.
- Some tools I use to make setting up and managing the workflow.
In future posts, I will go into more detail regarding some of my methods and tools.
What is the WordPress workflow?
it is made of three environments:
[bs_col class=”col-xs-10 col-xs-offset-1″][bs_well size=”md”]
also called local, which runs on your computer/laptop and only accessible by you.[/bs_well][/bs_col]
[bs_col class=”col-xs-10 col-xs-offset-1″][bs_well size=”md”]
this runs on an available to the public using a unique URL, preventing any issues with premature Google crawling and duplicate content. You can also restrict access via password if necessary.[/bs_well][/bs_col][bs_col class=”col-xs-10 col-xs-offset-1″][bs_well size=”md”]
Also referred to as live, this is the final version.[/bs_well][/bs_col][/bs_row]
The second factor is the direction of the flow from environment to environment. Initially, it should flow between each environment in one direction. This is during a new site or project.
As you can see I added the definitive NO between DEV and live. At some point you will need to push from DEV to live but always ensure it has gone through the staging process first. I have a second application like, winSCp to upload from DEV to live to ensure there is no accidental overwrite.
There are times when you will need more two-way action, primarily when you are working on refactoring a live site. This is also the configuration to use when testing plugins or completing updates. You can sync live to stage, run updates and tests, then complete on the live site.
Why do you need this?
These steps will a level of difficulty and add time to your process but for several good reasons.
- Create and isolated sandbox to work on where you can safely make changes without affecting end users.
- Allow you to make real-time comparisons between your job and the live site.
- Test during business hours without affecting traffic or site services.
An important note or perhaps rule.
NEVER, EVER WORK ON A LIVE SITE!
DON’T UPDATE PLUGINS!
DON’T UPDATE THEMES!
DON’T MODIFY CODE!
Now I demonstrated a key point to this rule during my session. I asked all the experienced DEV’s in the room to raise there hand if they totally agree with this, there where quite a few hands up. I then asked “Please keep your hand raised if you have broken this rule, more than once?”. Fair to say almost no hands went down.
There are always exceptions to the rule. The point here is to make sure you are aware of the risks. Most people don’t know how bad fire is until they get burnt.
Some things to know when setting up your WordPress workflow.
Both your DEV or local environment and your staging environment should be configured the same as the live or production environment or what is refereed to as the stack.
There are two main stacks used for WordPress.
- LAMP – Linux, Apache, PHP, MySQL
- LEMP – Linux, NGINX, PHP, MySQL
If you don’t know what your live site is running on you can speak with your hosting support to get more info. For the local DEV environment there are several tools to make this setup easy.
- Quick install tools – WAMP, MAMP, XAMPP and Desktop Server
- Advanced tools – Vagrant (VVV or Chassis), Docker, Linux VM & EasyEngine.
WAMP, MAMP, XAMPP and Desktop Server. I haven’t used these tools for a while but have heard good things about Desktop Server as it has some tools specifically directed for WordPress setup.
If you want something closer to the real thing with more tools and power, there are some tools that provide you with a Virtual environment. These include tools like Vagrant, specifically VVV or Chassis witch is actually developed and maintained by a fellow speaker Bronson Quick (@bronsonquick) and available on GitHub. Docker is another tool that is gaining massive traction and is OS agnostic or you go middle ground and use a vanilla Linux virtual environment like Ubuntu server LTS with an absolutely awesome CMD tool like easy engine. Witch is what I use.
If you are new to this stuff, please don not let the idea of command line scare you. these more advanced environments gives a lot more control and power with tools like WP-CLI. If you don’t know WP-CLI put it on your list of things to read about. Lost count the number of times it has saved my bacon and made things simple as it gives you access to DB import/export, plugin install, activate, deactivate and update, completing WP install/configuration and way more. A little bit of time learning how to use it will save a massive amount of time down the track.
More ideas for your WordPress workflow staging environment.
I believe it is important, if not vital, to use a dedicated WordPress hosting provider for your Live hosting as they will generally provide you with a staging environment that is isolated. Isolated is important for when you are testing and installing plugins, moving from live to staging and back again. If by chance something happens that causes a major problem it will not effect the live site. Providers like WPengine, Pantheon or Conetix are great, these are the ones I have looked at and played with.
What to look for when setting up a staging environment:
- WordPress dedicated hosts may provide service as inclusion to hosting.
- AWS EC2 micro instance is a cost effective option.
- Create a dedicated custom domain for staging.
I personally do some things outside the box with Laravel PHP witch is why I still have instances on Amazon AWS, they not hard to manage and very cost effective. I also play with Microsoft Azure virtual machines as well, they great for staging.
I have a created a dedicated domain for my staging. Keeps things easy for me to manage and I have issues with Google crawling this to early.
If you are running your own staging servers try and match the config or stack as close as possible as well as the location. You don’t want the hosting running in one country and the staging in another as it will produce some interesting results when testing and doing demos with your client.
Finally I would try and avoid running your staging on the same [bs_tooltip placement=”top” trigger=”hover”]Virtual Private Servers[/bs_tooltip]. Although it is rare you don’t want change something and crash the server or you may need to reboot the server for some reason. That is not something you want to do to your production environment during the day. Might make some unhappy people.
Tools to help you move your data around.
Migrate DB Pro – https://deliciousbrains.com/
My number one favorite tool is Migrate DB Pro witch is fantastic for easily migrating and moving the database from location to location. It takes care of completing the URL renaming process making the DB migration seamless. Another great bonus is it will do a complete a backup before you sync so you can roll back if needed.
The developer version also has some extra tools for migrating the uploads directory and keeping it in sync. Once you have it in place it will only sync the changed files saving a tonne of time.
Brad Touesnard and the team at Deliecous Brians, awesome name, have been working on a new tool called mergbot. This will allow you to actually sync the database without overwriting so you merge your changes with the live site. Hopefully will be playing with sometime real soon.
WPCore – https://wpcore.com/
WP-core. This allows you to create a collections of plugins and then install them all at once as well create a collection from an existing site and install that collection on the other site.
UpdraftPlus WordPress Backup Plugin – https://wordpress.org/plugins/updraftplus/
Generally speaking the three most important things that come to mind when working with a WordPress site are Backup, Backup and Backup.
Tool I like for that is Updraft PLUS, even for general operation it is a great backup tool, offers fantastic revision capabilities. Allowing you to keep the last x number of backups. Another great feature is its ability to separate files and database. On a live site the database is what changes frequently so backing that up daily and then backing up your plugins, themes and media weekly will save you a lot of space.
You can then set the plugins/uploads/themes to backup weekly or even monthly. Everything can be backed up off-site to AWS S3, Dropbox, Google Drive, Rackspace, FTP, SFTP, email. That is important, even you make regular backups local so they are quick and easy to restore, always have at least a monthly off-site or downloaded just in-case, one-day you cant get to the server.
ManageWP – https://managewp.com/
will post a walk through video soon
If you work with a lot of sites you should look at a management tool as these have awesome features including a clone feature, like ManageWP. It also has some great tools for backup, site clone and migration, site up-time, plugin, theme and core updates plus a few more. When managing several WP sites, being able to access and manage the wp-admin from one place is priceless.
So that’s my take on the WordPress workflow. There are a tonne of other areas to look at, like continuous deployment using git and online services like SemaphoreCI or task runner tools like flightplan. Working my way into these items slowly but surely. I run a GitLab server in my office witch allows for builds and continuous deployment with git so will be testing that soon.
Really hope you get something from all this and if you have any questions, you know what to do. Keep on Developing!