Jekyll and the build scripts a few years on

A few years ago I moved my sites from a PHP templating system to static generation using Jekyll. How is it working out?

Pretty well. I’ve had no downtime (that I haven’t caused) which is to be expected on a low-traffic website serving HTML files. Updating content and templates has been easy, with Jekyll remaining simple to use. While I’m sure I’m in need of an update, that is less of a concern than if I was running code exposed to a user. Overall no problems with the technology or maintenance - indeed I find it much easier to work with than previous versions of the site as I don’t have to re-learn my configuration each time I want to do anything more complicated than change some words.

The biggest win - and something I actually considered skipping when I initially implemented - has been with the build scripts. In professional life I wouldn’t think twice about writing automated build scripts for a project but we all know that this kind of thinking isn’t as rigorously followed for personal projects. I wrote a simple mina script for deploying (and updating) my sites and several years on I deeply thankful to my past self. I haven’t had to keep my build process in my brain at all - just the magic command, which is in a README somewhere. This has meant small updates have been easy, the most boring part of site maintenance has all but gone away and consequently those updates have actually happened.

The lesson to take away here is that doing the hard (and dull) work up front of defining a development process and writing deployment scripts was worth it. Not so much because of time saving, or the consistency inherent in an automated process - but because these benefits actually encouraged me to maintain my sites in a way I simply wouldn’t have done had I been required to remember how to deploy my work each time I did anything.