Local vs Live

It's been a little overdue, but I've successfully made the transition moving from working on live files to working almost exclusively on local files and then deploying those to a live environment... but clearly it's not always been that way, neither are things quite so simple.

A tweet from @HelloMountee prompted me to write a (perhaps overly long) blog about the transition… but first an amusing image from a tweet by @masuga:

{pagebreak}

As always a little history…

Back when we started Moogaloo nearly 3 years ago, I went through a period of realising I'd picked up a lot of bad habits. A lot of this was due to having a purely self-taught approach to web design. Doing some freelance work at a local design / social media agency meant I got to see a very different approach. These were academically trained software engineers that did things in a very technically accomplished manner; they did things, for want of a better word, properly.

One of the biggest things for me to get my head round was Version Control Software (VCS). Being used to a more simple approach of only ever having one person in the team working on a project files and site updates consisting of downloading files, backing them up, working on a copy of them and then re-uploading them, the Version controlled route seemed almost backwards to this... more likely it was actually the right way round and I was used to the backwards approach!

Low point: thinking I lost a days worth of work from a while back. High point: finding it in an obscure git branch.

@joshuarudd, 2 June '11

Jump forwards a couple years and I was finding that I was still, in day to day work working largely on live files. I'd develop a site live on a server, preferably a separate development server, but still across the internet. When a client wanted something added to their site I'd be working on their live site, being very careful not to break anything on the front end that their visitors would see.

Not good.

{pagebreak}

Mounting up for the big change.

Around the end of 2010, as I was just starting to get used to having the Mac Mini, an OSX app called Mountee was created with a lot of very positive press (and it still gets lots too), and it's been very much appreciated by the #eecms community. It acts as a bridge to allow you to work direct on the template files from your Mac, create new templates, adjust settings that sync with the database without needing to be in the EE Control Panel all the time. I got a copy of it and started using it, and really enjoyed the speed it allowed me to work.

And then, through no fault of Mountee's, I broke a site I was developing. Not entirely sure what did happen, but it highlighted very clearly the flaw in the process - I was still working on live files. The closest I could come to back tracking was hitting undo in the HTML editor and hope I'd not made the mistakes yesterday or searching through various template revisions.

Once again, not good.

Enter Git.

One of the many reasons I love Expression Engine is because I can use it to make all the sites we do make without needing to know any PHP (or .asp or Ruby or any other programming language). That said, the moment came at the beginning of the year when I decided to bite the bullet and learn this otherwise dauntingly technical VCS thing. Most people in the Expresion Engine community were avid Git fans, so with a recommendation from @mikos to start with the Pro-Git I cleared my workload and dived right in.

Several mistakes and much head scratching later, I was getting it. Using something like Git Tower makes a massive difference to a designer who finds Terminal a bit too alien an interface, but it's good to at least have used it to get a feel for the principles on which VCS and more specifically Git are built.

Add into that an account with the awesome Beanstalk web app, and I'm now happily working away on all new sites on local versions, committing work as I go, creating branches to try out a new addon, and easily rolling back to previous commits when things go wrong. Using Beanstalks automatic deployments means I can also set Git Tower to push work done to the development server, uploading only the updated files (far smarter and more streamlined than the traditional FTP client method). From there I can merge development work to the production branches and then push those changes as and when I want to update the live site.

Back to the future.

It's a well oiled and slick forge of industry here in this little Sheffield office… and more to the point, when (not if!) I do mistake, it's pretty easy to fix. I'm finally free of working on live files. I'm free to try things out and make mistakes.

Referring back to the original tweet, I'm therefore pretty interested to see where Mountee and Git Integration may meet up again. I did like Mountee, but it went down a path that was incompatible with working on version controlled local environments, and ultimately working in a local workflow has won against live.