Road Codin’

When your tech support team is out on the road, and a critical issue arises, it’s important that they have the ability to provide support – with whatever tools are available to them.
Published on Mar 15 2015 by Tim Larsen

My partner and I are currently house-hunting. We’re whiling away our weekends, cruising through the (increasingly remote) northern suburbs in an effort to secure our dream first home. 

I know what you’re thinking:

But Tim, I don’t care! Talk to me about techy things!

Well, anonymous reader, you’re quite right… and kind of rude. 

So there I was, driving around Preston on a Saturday afternoon – when all hell breaks loose. We had been under heavy development for one of our clients sites, and a small bug had been identified on the development server. Given the scale and nature of web development on this site, a minor bug every now and then is an unavoidable outcome for any development team - however, the way that the support team addresses these bugs speaks volumes.

Let me preface by saying that in this particular instance, this was a Syntax Bug, not to be confused with the more serious types of bugs. More on that here. This means that the bug wasn’t showing an error, wasn’t breaking anything and wasn’t an obvious issue unless testing a specific “story” in very specific conditions. We have tests set up to see if anything “breaks”, but this wasn’t essentially “broken” - just not behaving as expected. This doesn’t excuse the issue – to the client, if it’s not behaving as expected, it’s broken – but it does explain how the issue slipped through the cracks.

12:27 – 07/03/2015

Received a call from Marco Rosano (Soul Digital's Managing Director) who handles issues of this nature outside of business hours. Marco informed me that a minor bug had been found on the development site. Although this would generally not be an issue, a presentation had been set up with shareholders to showcase functionality related to the bug – this needed to be addressed ASAP.

At this point, I consider my options:

  1. Drop everything. Drive home and fix the bug on my laptop. From my location at that point, it would be approximately 1.5 hours before I even get to a computer to start looking in to the bug.
  2. As above, but straight to the office instead of home. Shave off about 10 minutes.
  3. Get creative. The only devices I have at my disposal are my Galaxy S4 Active and my partner’s HTC One M8. Neither of which would be my first choice for a task involving editing PHP code nor pushing changes to a live server. The upside is I can get started on the diagnosis immediately.

I chose option 3.

After a 4-minute phone call with Marco getting a detailed brief of the issue and the users affected, I get cracking.

12:31 – 07/03/2015

From my trusty Galaxy S4 Active, I log in to my work computer via the Microsoft RDP App (available here). A few minutes in, I realize I need a little bit of help. I access the play store and download The Hackers Keyboard (available here). 

12:35ish – 07/03/2015

Luckily, my local development server was still running from the previous night’s work. While awkwardly navigating my work desktop machine via my little phone’s touch interface, I manage to open my IDE (phpStorm – an amazing application that streamlines any development). A quick look through my code relating to the functionality with the bug confirms my suspicions – an errant permissions check on a piece of functionality was causing the bug. I fix the code and then begin my testing checklist around that functionality. All tests pass, I manually check the functionality – all good. I commit my changes as a hotfix. Now I just needed to push my changes to the dev server, then on to the live server. This entire process would have taken about 5-10 minutes if I were directly in front of the computer, but due to my impaired input method, this process took about 15 minutes. 

12:50ish – 07/03/2015

With the latest commit ready to be pushed live, I simply needed to log in to the remote server to pull the latest change. After another 5 minutes of discovery (fun fact, the default on-screen keyboard that Windows 8.1 supplies doesn’t have a ctrl key!) I finally managed to push the server to the development server.

13:01 – 07/03/2015

A quick run-through of my tests on the live dev server and I was confident to push the changes to the live server. 

13:05 – 07/03/2015

The changes are pushed to the live server. I run through the previous tests on the live site – I can confirm that all related functionality is working as expected.

13:07 – 07/03/2015

A quick call to Marco: 

“All sorted.”

I actually said a lot more than that, but you know - it's not as dramatic. 

From start to finish - and with a little creativity - we had a bug fix created, tested and deployed in under an hour on a Saturday afternoon. Our client was EXTREMELY happy, we were pretty stoked - all was well in the world.

Issues like the above are unwanted but unavoidable opportunities for learning. So… what have we learned? 

  1. Sometimes going above and beyond for a client means getting creative.
  2. Wherever possible Behat testing is a tedious and expensive, but necessary exercise.
  3. In a pinch, an Android device can be used as viable gateway to a development environment.
  4. Prices in Preston are going up.

 

Alternate names for this post: phPreston, Remote Remote Desktop, Coding on the road: Yes I can(Droid)

Images credit: __ken's photobucket (http://i75.photobucket.com/albums/i295/__ken/mad_dogging_78ushqke-1.jpg)