So, a few hours ago I deployed this site. Truth is, it wasn’t the first deployment I had done in a while. In fact, I already had a Jekyll/Git deployment workflow set up. What I actually did in a couple of hours was redesigning and deploying the thing from scratch.
However, there are some funky things I had to do to get around the constraints of my hosting service. These are some of the solutions I came up with.
The site’s stylesheet is written using LESS. That means that everytime I push a style change to the server, the stylesheet needs to be compiled to CSS. The best way to do this without disrupting my workflow was using one of the many LESS plugins for Jekyll available.
I couldn’t do that, since there was no way to install the lessc compiler under my shared hosting account. I figured any compiler written in a scripting language would do, so I used lessphp. The path to the stylesheet is now hard-coded in the post-receive hook script, so that’s one disadvantage, but that beats having to compile the file manually everytime.
So, apparently, NearlyFreeSpeech doesn’t have the Apache GZip/Deflate modules installed. No problem, we just need to pre-compress all static content and then serve it conditionally.
To pre-compress, the following is needed to run after the site has been compiled with Jekyll. I included this near the end of my Git post-receive hook.
This simply finds all files with an extension that denotes plain-text (e.g. html or css), and saves a compressed version of them with a gz extension added.
We could use Apache Multiviews to serve the compressed files, but I found that solution a bit verbose. Instead, I opted for a rewrite directive:
Assets specific to the server
Certain objects that need to be served from this domain name have no relevant place in the Git repository for this website. I didn’t want to clutter the repository by including them.
I uploaded such files to a private directory on the server, and let my Git post-receive hook copy those files to the public directory everytime the site is compiled. It’s not the best solution, since I can’t push those files via Git, but it’s good enough for now.
I based my complete deployment workflow on the one found here. Basically, I only git-push to the remote repository (conveniently named production) whenever I want to deploy, and the post-receive hook takes care of the rest.
The post-receive hook I use is in this Github gist. It includes everything described here except, of course, the Apache configuration directives.