JZT

A Nostalgic Adventure Game

Beta

On Continuous Delivery

Jan 9, 2016

The primary goal for me in creating JZT has always been about learning more about front-end web technologies. If the technology industry is considered one of the fastest moving in the world, then web technology is practically light speed.

One of the more interesting concepts that has been triggering process transitions within companies worldwide is Continuous Delivery. At its core, it means that the moment something (anything) is ready, then it can be made available for everyone to use. Traditionally, the most popular software release process is to hold on to any new features, bug fixes, and changes until you think there’s enough to call it a new version. Once a large enough set is ready (or perhaps when you reach the end of a pre-determined time duration, such as a sprint cycle) then the version would be released. Sometimes it would be released as a beta first, tested live for a bit with a limited set of end users, and then eventually made available to everyone. With the web, though, there’s no need for that. If something’s ready, why can’t it be live immediately?

Even with a project as small as JZT, I had been working with a fairly traditional release cycle. The process of deploying JZT (that is updating the version number, concatenating all the JavaScript files, minifying them for size, updating the HTML to use the new version, uploading the changes, and then testing everything to make sure I didn’t make a mistake) was cumbersome enough that it would actually take longer to deploy a small bug fix than it would take to actually fix the bug. I used tools to do each of those steps, of course, but I’d still have to trigger them manually, in the right order, and then get everything ready for upload.

Although players would never know it, deploying JZT is now a single-click operation. If I make a change, I just click and a new version is live on the web. This is done with a pretty interesting technology stack, some of which I absolutely love, and others I’m still a bit on the fence about, but they get the job done. I use Browserify to modularize and package all of JZT’s JavaScript files (something I had previously done by concatenating files that used a closure-based Module Pattern). Uglify does the minification. Git handles all the source code management. JSLint does my static code analysis (and yes, I’m aware that JSHint and ESLint are less imposing, but I don’t mind being Sheeple to someone as delightfully crotchety as Crockford). Jekyll creates the web pages, and everything is tied together with Gulp (which even watches my files for changes and launches new development builds to my localhost as soon as I save a file). It’s an absolute delight. And will probably mean more small releases in the future, even if I only ever find myself with an hour here and there to work on it!

Previous Post