Breaking the cycle

As I was adding the finishing touches to the last article of a series I have been writing for the German monthly Linux-Magazin, I decided to write more stuff to put on here. Not necessarily at the same pace or with the same depth, but we’ll see.

The first problem that I always face when I write content for my website is that I forget how to deploy it. Not that it’s terribly complicated, I just forget where I need to push changes to get them deployed, and what parts of the process are automated. This causes mental resistance when I’m trying to write, causing me to write less and forget even more. To break out of this cycle, I decided to document how my blog is deployed. Thus, the following is mostly a memo for myself.

These days, many software-related blogs are static pages generated from markdown, and this one is no exception. The markdown for my blog is kept in a git repository and the blog is automatically re-built whenever the contents of the repository change. When I write new articles, I don’t like to publish them before they’re completely done, but at the same time I work best in iterations, improving things step by step. This is why the content repository has two branches: stable and unstable. The unstable one is where I prepare new content. It’s automatically deployed to m10k.eu/unstable, allowing me to check things as I go. Once the content reaches a state where I can’t find anything obvious to improve, I merge it into stable, triggering a deployment to m10k.eu.

The deployment is done by three scripts, one of which is borrowed from Foundry: watchbot is a deamon that periodically polls git repositories and sends a pub-sub message when it detected a change. This message is received by blogbot, which does little more than trigger blogdeploy, which does the actual deploying.

overview

Blogdeploy will clone the content repository, compile the static pages from the markdown, and then copy the generated pages to the webroot. In case of an unstable deployment, it will set the baseurl in the jekyll configuration to /unstable, but that is pretty much it.

So yeah, it’s really not complicated. I just completely forgot that I had the deployment process automated. When I wrote the last blog post, I still had to deploy everything manually, which was a huge pain.

For the curious, the sources are on Github: https://github.com/m10k/blogdeploy