Daniel Groves

Show Nav

Behind the Scenes AppFlow 2.0

Published: 15 December 2012

An insight into the technologies behind the recently re-released AppFlow, from the building of the site all the way up to staging and production servers.

AppFlow is a project that I started back in 2010 with Luke Barnes. AppFlow has always been about trying to improve your workflow with your Mac, taking advantage of both the system default applications and third party ones that help you work faster with your Mac.

Those of you who do follow AppFlow will know that it has been dormant for some time, but this is about to change. A little while back I quietly rolled out an update for the site I've been working on for quite some time.

Why start over?

The previous site was somewhat broken. I have never been hugely keen on the design, but limited time and resources when I did it meant that it ended up getting rolled out.

It should never have been rolled out. It was a sub-standard design which I wasn't happy with; if I wasn't happy with the design, who was ever going to be? The site ended up sticking around for a year and a half in the end while I was busy working on coursework. Over the time that the theme had been live various parts broke, but I never bothered to fix them. Why would I? I didn't like the design so, in turn, I didn't care about it.

Content has also been neglected since I started University. I put this down to the lack of time, but then again we have time for anything if we want it enough.

AppFlow was originally intended to be a high-traffic blog. Not in visitors, but in the amount of content coming out. The problem with this is it's simply isn't a sustainable model to go on when only two people primarily run the site, and of them zero can work on it full-time.

With the new version of AppFlow I'm going to go about the content in a new way altogether. Instead of aiming to write, lets say, two posts every week I am now going to take out one evening a week to write for it. I will not publish anything until I am happy with it. It doesn't really matter how long something takes to write, as long as it is high-quality writing with a valid point to make. It's time to put aside the mass-produced quickly written, poorly edited writing.

As a testament to the past I am leaving the current content on AppFlow, to show how it has changed over time, although I did debate with taking it down and just starting afresh.

Under the Hood

As before this site is run on WordPress, with a custom theme that I have personally developed from the ground up. It doesn't use any base-themes or boilerplates, from my experience these tend to get in the way more than they help.

I did consider migrating to AnchorCMS for the new version of the site; unfortunately it lacks one important feature for AppFlow at the moment though, categories. I am, however, aware that there is a major update for it on the way which may introduce the missing features I require.

Rather than writing straight CSS I decided with work with Less. This allows me to nest styles and use mixins and variables to make development easier, more consistent and faster. If you haven't looked at a CSS preprocessor yet you should check out Less or Sass.

I used Less.app to compile the Less every-time I saved the file. This generates a compressed CSS files with minimal line breaks and white space to minimise the download size for the styles.

In the near future I intend to add media queries to the theme, as a version 2.1, allowing me to provide mobile/touch friendly versions of the site as well. In its current state the site is useable on mobile devices, but not what I describe as ideal.

Version Control

My choice of version control is Git, with the Git Flow extension. The GitFlow extension makes it easy to use git with the GitFlow branching model without having to worry about completing merges into the correct branches when required, such as when releasing a new feature or hot fix.

Git Flow also fits in nicely with my new ideas for a git-centric deployment system.With the use of Git Flow and post receive hooks I can now devise my own way of deploying updates without having to faff-about with FTP.

Deployment with Git

My new workflow now involves multiple stages in order to work; development, staging and production. This clean setup makes it a breeze for me to develop offline, test in a safe environment on my server and then roll out to production feeling confident that nothing will go wrong. While all of this is happening it's also faster for me to roll out updates as Git compresses files, making it faster at transferring than FTP and far safer.

The workflow works as follows:

  1. Development - The development stage is done on my local machine. I implement all new features in this development environment under feature branches. When I am happy with a new change or feature I merge it with the develop branch and push the branch. In the event that I change my mind about a feature at a later date it's easy to roll back.
  2. Staging - When changes are pushed on the development branch a post-receive hook pings a PHP script on the server. This automatically resets the current head of the staging environment and then pulls the latest from the development branch. This allows me to test everything works properly on the server and also makes for an easy place to show features to others for further feedback and tests before I roll them out formally.
  3. Production - Once I am happy the everything is working properly on the staging environment I can tell git flow to release the development branch. This merges it with master and, once pushed to GitLab, pulls the latest changes into the live site on the server.

So far this system works well, each stage of the workflow runs on it's own database so I don't need to worry about something destroying the live one. In the future I may look into a way of synchronising a copy of the live database down into the development environments automatically to making testing with a copy of the live data easy.

Using WordPress with Multiple Deployment Stages

WordPress doesn't play nice with a multi-stage deployment system out of the box, but thats fine because it is easy enough to retrofit a system.

Each stage of the deployment process has a environmental variable set in the Apache VirtualHost. This variable is easy to set (SetEnv SERVER_ENVIRONMENT development) and allows me to easily detect what environment WordPress is sat in. Once the environmental variable is set it's easy to grab the variable, see what is set to and load the correct configuration, as follows:

	if (getenv('SERVER_ENVIRONMENT') == 'production') :
	    // Database settings, Uniuqe Keys, Salts.
	    // And, make sure debug-mode is off in this environment
	    define('WP_DEBUG', false);
	elseif (getenv('SERVER_ENVIRONMENT') == 'staging') :
	    // Database settings, Uniuqe Keys, Salts.
	    // Also, I have debug mode on in this environment
	    define('WP_DEBUG', true);
	elseif (getenv('SERVER_ENVIRONMENT') == 'development') :
	    // Database settings, Uniuqe Keys, Salts.
	    // Also, I have debug mode on in this environment
	    define('WP_DEBUG', true);

This system is simple and effective, automating all the setting changes that are needed as the install is committed and pushed, and pulled between environments.


This new version of AppFlow is bringing a lot of changes. It has a better content strategy, proper version control and a strong deployment system.

If deployment system works well I intend to move other sites that I run over onto the same deployment system making it easy to develop and test with all sites without fear of anything breaking on the live sites. It also makes deployment fast and painless, which I like.

If you have any ideas of how I could improve this and make the system more "bullet-proof" then please do leave a comment; I'm keen to hear what others think of the system.

comments powered by Disqus