Web Design Workflow, Reliability Through Drupal & Git

One of the biggest changes in the way we work over the last few years has been the introduction of version control into our workflow. As systems get ever more complex, we need better tools to manage them and this has led to using something called "Git". Git is great because it allows us to easily manage our workflow of "dev", "staging" and "live". Let's break that all down a bit and explain what it means.

Many web design companies, particularly at the low end of the price range, will make a website that sits on a server - and leave it at that. If you want anything adding to it, they add the code to that server and there it is on the site. This is fine - up to a point, and once you get to that point, you will wish you had a different system. Having just one version of a site and relying on one server is a big opportunity for failure.

Here at Turtlereality we always have at least 2 versions of a site and for a live site there are usually 3, we call these dev, staging and live. The dev (development) site lives on a server in our office which is not visible to the internet and is where we actually do the work - adding code, modules, graphics etc. Once we are happy with the way things look on the dev site we want to show it to the client, so we push all of the content and database elements to the staging version.

The staging site lives on a live web sever situated in a data center in Canary Wharf which is visible to the internet - but password protected so only our clients can see it. It allows us to demonstrate changes and new features for our clients approval without changing the live site. For example, we recently changed the homepage layout of https://charlesfarris.co.uk, this started out as a series of designs leading to a final choice. Once the design was approved, we programmed the changes on our development server and pushed those changes to the staging server for approval by the client. After some amendments and final approval, the changes are pushed to live - nothing is live to the public until it is approved by the client.

Pushing the changes to the next server is where Git comes in. Git is a version control system, why it's called Git is a bit of a mystery, Linus Torvalds is quoted as saying "I name all my projects after myself. First 'Linux', now 'Git'", but it's more likely it was just a handy three letter name that was available. So, what is Git? Well, it's a very powerful system for keeping track of the changes to files, which allows any change to be documented and catalogued. Once a web site is under version control, all the changes to code can be seen on a time line which can be moved backwards and forwards. At any point on the time line we can see which files have changed and even the individual changes that took place. Because it keeps track of the changes, we can push only the files which have changed to the next server. We can also go back in time and revert the files on any server to a previous state. In our Charles Farris example, if we wanted to go back to the previous homepage layout, we could revert all of the files back to the previous state with a few commands. We always have a map of exactly what is where.

This system gives us tremendous power to work with code. Whatever we do, we always have a solid working version and a clear path back.