September 26, 2013 - Comments Off on Deploywhatnow?


Is deployment a mystery to you? Never fear… in this blog, I’ll be delving into the dank, dim depths, and emerging with the diamond bright gem of deployable revelation.

Deployment; it’s a somewhat understated word. Simply put, it’s the process of moving a web application from one computer to another computer (or computers).

Usually, the first computer is a desktop computer, and the other is a web server; in effect, you’re pushing a web application somewhere where your colleagues, your clients, and/or your public can see it and glory in your genius.

Pretty straightforward, right?

Not really, and here’s why…

First a quick confession

Okay… I admit it. Back in the beginning, when I compiled my first programs, cascaded my first style sheets, and hacked together my first scriptlets, I did it the “easy way”. I’d manually transfer files straight to the live website. Occasionally, I even made the cardinal sin of editing my code directly on the live server!

I learned by lesson pretty quickly. After all, no matter how bright, how brilliant, how obsessive the developer, they are human. Mistakes are made, and if these mistakes are shoved straight onto a live server you’re just asking for trouble, egg on your face, unhappy clients, and general mayhem as you try to figure out what went wrong and how to fix it as fast as possible.

Of course, I do things very differently now. Not only am I wiser and more learned, but nowadays, I’m responsible for far more complex, interesting, and challenging web solutions; some of which have to stay online at all times.

Web development has historically been treated somewhat haphazardly when compared to “proper” software development, but this is no longer an option for any serious web developer. We’ve adopted agile methodologies, continuous integration, and advanced system infrastructures and design patterns. Rare is the case when we stick with one server-side technology, and, more often than not, our applications need to utilise multiple web and database servers.

And deployment isn’t just about getting a web application where it needs to be; it’s also about making sure that web application works as intended and meets all the requisite coding standards and requirements. It’s a quality assurance and control process as well as a logistical one; both of them increasingly daunting challenges.

Getting the job done

Our deployment processes always are tailored to the client, infrastructure, and project. They include continuous integration platforms, code sniffers to hunt out coding no-nos, minifying and optimisation scripts, synthetic user tests, UNIT tests, and a range of migration technologies designed to work on a multitude of different platforms.

When we’re ready, we send our web applications to our testing servers where they under-go full user acceptance tests. We try to break them. We send them to our clients to let them break them. We make sure everyone gets the chance to break everything. Then we rinse and repeat; fix anything that breaks, push it back to the testing servers, and try and break them again.

Then when we and our clients are happy with what we’ve produced, we start the deployment to the live environment; confidant that we’ve done everything to make the end product as robust and high quality as we can… with the option to roll back to the previous version in the unlikely event that things don’t go according to plan.

Perhaps more importantly, we’re constantly improving refining and changing the way we do things. As we adopt new technologies, we need to ensure our deployment process is fine tuned to make the most of these and ensure they are working as expected.

Long story short, it’s an on-going process.

So if you’re wondering what I’m up to right now… well I’m probably tinkering with Jenkins CI, fiddling with some GroovyScript, reading up on the latest optimisations and plugins, and ensuring that when push comes to shove we can deliver the best… every time.