I’ve been neglecting this site. I know.
Given that the current year has had enough happenings to fill multiple years already, I’ve been thinking that I should try to get in the habit of writing more regularly. Writing is a skill which I was previously much more adept in. After many years without critiqued practice, I’ve quite quickly fallen off the literary wagon, but that’s a talk for another day.
However, the relevant problem I kept running into was that I never wanted to write because I knew it was going to be a manual pain in the rear to actually deploy the new content I wrote. Well, after being frustrated with this for who knows how long, I finally did something about it.
As I’ve previously written, after fumbling around with a couple of different solutions, I found my technology of choice for writing content on the Web in Jekyll.
The other relevant piece of the puzzle is Gitolite which I use for some extra control over my Git repositories. While I do love Github for my programming projects, I’ve found that self-hosting is rather convenient for the more infrastructure-related projects. More importantly, self-hosting is great for automating deployment of updates to this site.
Post-Commit Hooks and Gitolite
Like a vanilla-Git repository, Gitolite provides the means to run a script on the server when changes are pushed. In this case, when I push some edits to the CSS or write a new post, I commit and push my changes which then triggers a script on my server called a hook.
This hook create a fresh clone of the repository (to avoid any issues with trying to fully clean and update an existing repository), generate the site using Jekyll and then copy the results into the configured web-root. The tricky part of this was working around Gitolite.
Gitolite has this interesting approach where it uses specifically named public-keys in Gitolite’s admin repository. Gitolite accepts SSH connections for a single user, identifying the real end-user by the provided SSH key. It would also be a faux paus to allow local filesystem access to Gitolite’s property, so I knew I couldn’t take a shortcut by avoiding SSH completely. So, after forgetting how to properly configure that a few times, realizing I needed to make a brand new key pair to avoid a password on the private key, and then fixing a few Unix file-permissions issues, I finally got the hook working.
The end result is that, suddenly, my time to deploy some new changes has essentially been reduced to zero. And I couldn’t be happier. I can’t help but think that it might even have a positive impact on the quantity of my writing (hey, I’m writing this the night of).
The reason I find this important enough to write about is that automation has been something often on my mind lately during “normal working hours”. I can’t help but see over and over again the large human cost when machine automation is missing. We make life, both present and future, so unnecessarily difficult simply because we either fail to recognize that there’s even a solution to automate from the start or we consciously decide that the effort required to automate that solution is just too excessive.
From the help of a few great engineers over the past 12 months, I’ve at least come to understand the folly in accepting either of these excuses as valid. It’ll be a cold day in Hell when some series of manual steps for any task is a true one-off. Now I’m not saying I’m an expert in the practice I’m preaching, but at least I’m a bit more cognizant of the problem now. The smile that crossed my face when I pushed some code and immediately saw it deployed did bring a wide grin to my face. That’s motivation enough for tomorrow to try to find something else to automate.