The joy of deploy

“Hi, my name’s Steve...”

(Hi Steve)

“...and I use … FTP”

(applause)

Turns out that’s a bad thing, but any web designer/developer around the 40 mark has been using FTP to publish web files since the dial-up days.

These days it’s just not good enough, especially in collaboration environments, and for good  reason. Aside from the fact that it’s slow and insecure, it’s very easy to lose track of which files have been updated. It’s also a really inefficient way to work - modify, save, upload, refresh, modify, save, upload refresh….wait…...refresh, refresh…. ugh!

I’ve been working this way for years, so when I started at Nexus I decided to sort out my working processes and look into “deployment” options.

I’ve already been using GIT for version control for some time, so my first idea was to install git on the destination server, add it as a remote in my local repository, then deploy the website files with a simple ‘push’. This turned out to be a complete nightmare.

Don’t get me wrong - git is a fantastic way to manage a web build and I use it for every project without exception, using Bitbucket as the main remote repo and utilising the issue tracker that comes with it. The problem is that mistakes can be hard to recover from - git is quite unforgiving. After a certain degree of success I decided that it was too easy to accidentally publish files to the wrong location.  Also, with nearly every project running on a CMS and various extensions, each with their own git repos, it was a tremendous faff adding in submodules/subtrees into the repo.

As is often the case, the answer was in the pub. Over a pint and a packet of pork scratchings, I was recommended Deploy by aTech Media. This is a system that works hand-in-hand with git to keep website files perfectly in sync without any direct contact between you and the web server. Git already takes care of the collaboration side of things - Deploy talks to Bitbucket (or Github, Codebase etc) and moves files from a predetermined git branch to any number of servers. Ironically, this transfer can be done via FTP, but to keep it nice and secure I prefer an SSH connection with SSH keys rather than password authentication.

The clincher for me was the ability to deploy from any subdirectory of the git repository. I usually keep config and uncompiled source files in the root of the repo and the main website inside an "httpdocs" folder. Deploy can read from httpdocs in the repo and push files to the document root on the server. I really messed up the repo for the Nexus website trying to acheive this with git alone.

So, our workflow now looks like this:

The project folder is version controlled with git (I use Sourcetree) which is split into 3 branches:

dev - for local development. We use MAMP to work inside a local virtual host dev.domain.com

staging - This is set up with a webhook, so any changes in this branch pushed to Bitbucket are automatically deployed to a “staging” website set up at staging.domain.com. We password protect this site to keep it from prying eyes and this is the version we send for approval to the client.

master - Once any changes are tested and approved on the staging site, we apply them to this branch and deploy to the live server.

I’ve been working this way for a few weeks now, and while it does take a bit longer to set up a website project initially, it is a much more stable working environment and much less prone to error. We’ve turned off external FTP access on the webserver now and made the internet just a little bit happier.