fd Blog

Daniel Hilgarth on software development

Blog Publishing

The last article in the series about the blog itself shows how I actually publish the generated content.

Using GitHub pages

Initially, I toyed with the idea of using GitHub pages.
You can easily publish your articles with the automatic generator. They let you choose a layout and you can easily publish using Markdown. I tried it and my test article was up in 5 Minutes. No Octopress, Ruhoh or similar needed.
Well, actually, it is needed, but they take care of that for you. If you go with this approach, you will be using Jekyll under the hood - the same engine powering Octopress and thus this blog.
If you don’t like the defaults they provide, you can customize anything up to the point of providing everything yourself.

The last point actually would allow me to push the content generated by my current Octopress setup to GitHub pages. You can even point your own domain to the blog generated like this. Your readers won’t notice that you are using GitHub pages. Want an example? Check out Mark Seeman’s excellent blog. It is hosted on GitHub pages!

Using my own Web server

There isn’t really a reason to not use GitHub pages. So why did I decide against using it then?
I already had a Web server for my company’s website, so I wanted to just reuse it, giving it a bit more right to exist. The Website doesn’t really receive a lot of traffic. Luckily, I don’t depend on that :-) Actually, that’s a good thing, because it is a bit outdated…
Anyway, that’s really the only reason to not use GitHub pages - at least for me.

Still, I am using a workflow very similar to that of GitHub pages. This allows me to reuse existing functionality built into Octopress.
The workflow is simple enough:

  1. The generated content is committed and pushed to a repository.
  2. The Web server periodically pulls the latest changes via a cronjob from the repository directly into the DocumentRoot of the virtual host defined in Apache’s configuration file.

Part 1

The first part is performed from within the root folder of the Octopress installation on my computer. It is as simple as executing rake gen_deploy.
This will perform a fresh generation of the content and publish it using the default deployment method. In Octopress this is rsync, but it can be changed to push in the rakefile by adjusting the deploy_default constant:

deploy_default = "push"

Furthermore, the repository to push to needs to be configured. This is done by cloning it into the folder _deploy:

git clone <url> _deploy

One last thing I had to do was to comment out the call to copy_dot from within the deploy task. It didn’t like my posts submodule.

After these changes, rake gen_deploy now happily pushes the content to my content repository.

Part 2

The second part is performed on the Web server and just as simple:

  1. I cloned the content repository - the one I already cloned in part 1 - to the DocumentRoot of the Blog’s virtual host.
  2. I created a bash script that pulls the latest changes from that repository:

     cd /var/www/vhosts/fire-development.com/blog
     git reset --hard
     git clean -fd
     git checkout <content-branch>
     git pull

    The first two commands exist to ensure that we will really only publish what is in the repository (git clean -fd) and that there won’t be any conflicts when pulling (git reset --hard).
    Don’t forget to make that script executable:

     chmod +x /root/update-blog
  3. I created a new cronjob that executes this script every five minutes. To do this, I executed crontab -e and added this line:

     */5 * * * * /root/update-blog

That’s it! I can now execute rake gen_deploy on my local machine and the new content will be available publicly within five minutes without any more actions needed!

BTW: If you are using Bitbucket or GitHub for the content repository, you might want to read this article to be able to pull via SSH.
And if you don’t have git installed on your Web server, this article is helpful. I went with option 2.