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:
- The generated content is committed and pushed to a repository.
- 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.
The first part is performed from within the root folder of the Octopress installation on my computer.
It is as simple as executing
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 = "push"
Furthermore, the repository to push to needs to be configured. This is done by cloning it into the folder
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.
The second part is performed on the Web server and just as simple:
- I cloned the content repository - the one I already cloned in part 1 - to the DocumentRoot of the Blog’s virtual host.
I created a bash script that pulls the latest changes from that repository:
#!/bin/bash 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
I created a new cronjob that executes this script every five minutes. To do this, I executed
crontab -eand 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.