A workflow for WordPress development

by Rob Jones

A workflow for WordPress development for teams that use local, staging and production environments whilst incorporating GIT version control.

The aim of my workflows is automate as many processes as possible to maintain maximum efficiency, whilst using the command line as little as possible. Personally I find having to switch to the command line (constantly!) hugely inefficient if the following processes are set up.








Workflow 1.2

After using Workflow 1.1 (below) for six months (which has held up really well!), I’ve made a few minor tweaks. I’ve switched from MAMP to Local by Flywheel for my local environment and switched to Atom instead of Coda for my code editor.

I was finding that both MAMP & Coda were fairly sluggish… the speed difference was extremely noticeable when I switched.



What you’ll need:

You can swap some of the following choices for your preferred software if you like but the general idea will still stand:


Developers Workflow - Local by Flywheel

Local by Flywheel
Allows the creation of local Wordpress websites.

Developers Workflow - Atom

Atom
A fast and clean text editor.

Developers Workflow - Codekit

Codekit
Automate tasks like compiling SASS & minifying code.

Developers Workflow - Bitbucket

Bitbucket
GIT version control for teams.

Developers Workflow - Sourcetree

Sourcetree
Provides an easy to use interface for GIT.

Developers Workflow - BackupBuddy

BackupBuddy
Move WordPress sites quickly from different development environments.

Developers Workflow - WP Remote

WP Remote
Update multiple Wordpress websites in one go.



What’s new in this workflow?

The biggest change has been to Local by Flywheel. It instantly looks easy and quick to use and setting up WordPress sites was extremely quick. There’s the odd quirk but the benefits by far out weigh the negatives. Creating “blueprints” for sites gives you a lightning quick starting point. Also the ability to just drop a Backup Buddy file into the projects to setup a new site is a nice touch.

Atom has always looked impressive and although it’s early days (there might even be a switch back to ol’ faithful!), on the surface it’s handling everything very well. Removing white space at the end of containers has always been a bad habit so with a click of a button all that’s gone… hello sexy code!



Additional refinements

One thing that I’d originally overlooked was Codekit’s ability to auto refresh the browser on any code changes. It may seem a very minor thing but when you have to manually refresh the browser hundreds of times a day, it becomes integral.

All that needs to be done is to turn on Codekit’s browser refresh setting and to enter your Local by Flywheel address. They’ll both work hand in hand so when you save any code changes the browser will refresh in the background (along with minifying any of your code).



Current problems with the workflow

Although I’ve not needed it just yet – I’m no longer able to share the build with another developer. Previously I would run MAMP on a server and load the database from there, whilst using the files on my local computer. I’d then use GIT to keep the other developer up to date.

Ideally I’d like to do the same as soon as I can figure it out.








Workflow 1.1

I’ve been using this workflow for a few months, it’s held up really well so I thought I’d document what I use on a daily basis.



What you’ll need:

You can swap some of the following choices for your preferred software if you like but the general idea will still stand:


Developers Workflow - MAMP

MAMP
Allows the creation of local Wordpress websites.

Developers Workflow - Coda

Coda
A fast and clean text editor.

Developers Workflow - Codekit

Codekit
Automate tasks like compiling SASS & minifying code.

Developers Workflow - Bitbucket

Bitbucket
GIT version control for teams.

Developers Workflow - Sourcetree

Sourcetree
Provides an easy to use interface for GIT.

Developers Workflow - BackupBuddy

BackupBuddy
Move WordPress sites quickly from different development environments.

Developers Workflow - WP Remote

WP Remote
Update multiple Wordpress websites in one go.



Local workflow:


Local workflow environment for Wordpress



Beginning the project:

We’ll start the whole process by firing up MAMP. If you’re working alone then just using MAMP with it’s standard settings is fine. You can create a project folder and move onto the next part.

If you’re part of a team then things get a bit more complicated. We’re going to be using MAMP on our local machine and MAMP on a separate machine to host the database. Essentially all the team members will be reading from the same database whilst using the files on their local machine.

Whether you work alone or part of a team then you should be using GIT, I use Sourcetree and Bitbucket as it’s free and easy to use. GIT will be used to keep your files in sync, whilst the shared database will be used to keep the data in sync.



Moving WordPress:

By far the easiest way to move WordPress is by using Backup Buddy. If like us you have a starting point for WordPress to allow you to start projects quickly and efficiently, then it’s an easy way to quickly move things around. It especially helps to have a flying start with a version fully loaded with all the plugins already setup.



Sharing WordPress:

Each team member will need to use Backup Buddy to install WordPress on each of their machines (or use your preferred method). It’s important that the host is set to the shared WordPress MAMP database. (The IP of the computer and 3306 being the MAMP MYSQL port.)

define( 'DB_HOST', '192.168.1.75:3306' );


Keeping everyone in sync:

This now means each team member will have WordPress running the files from their local machine, with the database being run from a central point.

If each team member works on a particular feature then files can be committed to the shared Bitbucket account using Sourcetree at regular intervals. Each team member can then pull down these files.

It’s best to all have single Bitbucket accounts and then utilise the team functionality in Bitbucket, each member can then be part of that team.

The database will stay in sync automatically between all team members but you will need to push/pull to Bitbucket to share features.

Personally I prefer Sourcetree instead of the command line but that’s entirely up to you.



Coding efficiently:

There’s several ways that your coding can be made more efficient but if you’re not using SASS then you really should be! I won’t go into the ins and outs of it but one thing that you will need to do as a result is to compile your code. This is where Codekit comes in. Your .scss files can be automatically compiled on save using Codekit without any command line tools. Simple.

Not only will you be able to make single line CSS changes that will be mirrored throughout your code, it’s also worth minifying your code using Codekit. Once that’s set up for the first time, whenever you save a file, it will automatically minify the code each time.

Another handy feature is auto refreshing the browser on save – it may not seem a big deal but having to refresh the browser a billion times a day will soon start to drive you crazy!!

(On a side note, I tend to use Zurb’s Foundation as a framework, it allows me to create responsive sites quickly and efficiently)



Staging workflow:


Local workflow environment for Wordpress



Migrating from local to staging:

Once you’re at a point of showing the client (typically we have a “Clients” area), Backup Buddy will give you an easy way to move the website.

There’s one feature that proves incredibly useful though – “Remote Destinations”. You can specify destinations to push/pull to/from using the deployment key. So any new changes can be pushed directly to the staging site. This can be split up into just the database, files, uploads, plugins etc.

As a rule, always work locally and push to the staging site. If on the rare occasion that the staging site has been updated then make sure you pull these changes down locally.



Production workflow:


Local workflow environment for Wordpress



Migrating from local to production:

The same process can be applied going from local to production as local to staging. Generally any time we need to work on the local site then we pull down a full version of the live site.

There isn’t an easy way to keep the local and live site in sync currently so this process is always a pain. Generally any file changes are made locally with any data changes matched up on the live site – the files are then pushed live.

One thing we tend to do on the live site is update multiple sites plugins all at the same time using WP Remote. We haven’t found this to be a problem as we always pull the live version down to the local version before working on any new features.



Conclusion

This isn’t a definitive process but has served us well up to this point… we’re always looking to improve it and make it more efficient. If you have any suggestions or questions then please don’t hesitate to ask below.








Rob Jones - Wordpress Developer

Rob Jones

Rob is a WordPress developer based in Cardiff with over 10 years experience in the industry. Some of the clients he has worked with include BBC, Barclays, AXA, NHS, Curzon Home Cinema, Moving Picture, Starbucks, Save the Children and Welsh Government amongst others.