Journey to Blogging CI/CD: Introduction

Judging by my prolonged absence from posting new content, it could safely be assumed that I've spent the last two years encased in block of carbonite. If that idea doesn't resonate with you, you might simply assume that life got busy. While one of those options is statistically more likely than the other, neither will take home any points for correctness. The truth of the matter is that I've avoided posting new content because posting new content is hard.

I mean, finding a topic to write about, putting together something even moderately useful, and then proofing it definitely takes time, but that isn't what I mean. Literally the process of posting content is hard. Why? Well, let's fire up the Mr. Fusion, get the flux capaciter fluxing, and take a quick trip back in time.

Site V1: CMS

When I first started posting content, I was running Drupal 5. It definitely wasn't blazing, but it worked well enough. Posting was easy; write a post, hit save, and it was done. Working with images was a bit unpleasant, but other than that, things worked work. Over time I upgraded through Drupal 6, and 7. Each version provided a trade-off of increased usability and decreased performance. While it might have been fine at first, over time the site began to feel a bit sluggish.

Even beyond that though, it required a large time-sink: maintenance. Running a LAMP stack with Drupal, and Memcached required time. Security updates, bug-fixes, backups, and OS upgrades all had to happen. Beyond this, content lived in a database, making source control of content difficult and making much of the content non-portable between systems.

Site V2: Static Site Generator

Running a full-blown CMS was fine in college, but as time went on, it became harder and harder to ignore the siren song of static-site generators. There was something awesome about the idea that I could store all of my posts as markdown files, these markdown files could be stored in Git, and that any application with an awareness of markdown could use my posts.

Accepting the promise it made, I chose Jekyll and started on my way. Overall it was a very pleasant experience. It was easy to tell that the level of maintenance required had gone down significantly. However, it was also easy to see that it brought a few issues of its own.

The biggest issue was that I lost my ability to write while away from my primary computer: building out the site meant that I needed to have, at minimum, SSH and my ssh keys. More practically though, I also needed a full Ruby install with Jekyll installed. While an arrangement of this could be done on a tablet, it would be hard to classify it as anything beyond an academic exercise.

The other issue I had was specific to Jekyll, the theme, and the plugins that I was using. At some point I reinstalled the operating system on my laptop. When it was time to reinstall Jekyll, I found out that gem install didn't just work, as I had hoped. Because the template I was using hadn't made use of version pinning, I had to spend a while figuring out just what versions of each library it had expected. This made me take some time to reconsider which generator I wanted to use.

Site V3: Static Site Generator with CI/CD

I enjoy writing, but the tooling I was using wasn't providing a workflow that encouraged it. If anything, the added friction of bad workflow constraints was enough to discourage any writing unless I had plenty of time to dedicate to it. So, how did I address my bad workflow? If you read the title of this post, you can probably guess that I converted my blog over to use a CI/CD driven workflow.

In short, I can write a post from either the GitLab web interface, or from my iPad. Once I check in my branch, GitLab CI will build a Docker container of my site and publish it out to my web server.

While that sounds easy, there were several little caveats that required some special configuration along the way because of a few personal requirements for my site (HTTPS-only, hosted on my own server, multiple independent services must be able to be deployed, and no human directly administers the webserver)

I'll be going over all of the configuration and pipeline behavior in this series, a series that I expect to rival my Fiddler series in length. If anything, I guess that means I'm back to posting again.

Hello World.

– This post written from my iPad. From the passenger seat of a car. In the middle of nowhere.